Regex的一些瑣碎
來自： https://napw.xyz/regexde-xie-suo-sui/
最近有一些從日志里分離HTTP請求的想法，最好是能把URL徹底分解開來，這個需求自然而然是用grep了。為了方便調試，表達式是在javascript環境寫的。文檔看了幾遍才知道，js的正則表達居然是閹割版的，幾個功能沒有了：
-
look behind / negative look behind : 中文學名太長了就不寫了，在url中，這個可以匹配到 # 后的 hash 但不包括 # 本身，也可以匹配 ? 后的 query 不包括 ? 本身。
-
if-then / if-then-else : 條件表達式，這個我想對提升效率是有幫助的，假如匹配到 # 再去匹配其后的 hash ，或者匹配到 ? 時再提取后面的 query 。
-
comment : js中提取出來的分組一般是一個數組，用0/1/2/3去訪問提取結果，然而如果有注釋功能的話，就可以給分組命名為 host / port / path 等等，提升代碼可讀性。
經過一晚上的奮斗，寫出來了一個居然長達216個字符的正則表達式。匹配效果可以在 Regexpal 看到，把表達式復制到 Regexper 就可以看到匹配流程圖。
這么長的表達式有存在的必要么，眾所周知在Express中 req 對象什么都有，瀏覽器的話只要 var a = createElement(a); a.href = url; 也可以訪問到url的所有屬性。只有真的極端到需要在 shell 里面時才可能會有用。
這么長的表達式我很好奇性能如何，于是花了一些時間寫了兩個腳本，一是 URL生成器 ，用于隨機生產五百萬條URL并寫入 records.txt ，生成的文件大約200M；二是 URL解釋器 ，從文件中逐行讀取記錄并解析。測試結果如下： 
測試進行了很多遍，結果都差不多，SSD應該可以把磁盤IO的干擾減到最小，V8引擎解析一條記錄差不多是在百萬分之一秒的級別，這樣就沒有什么優化的動力了啊。不過這只是粗略估算，大概也和我的 Intel Core i5 2.5GHz 有關系。
總之吧耗了我不少時間，最后放在grep里面還是抓不出東西來，摔。