正則表示式的一些探索(偏JavaScript)
簡單的探索下正則表示式的相關知識，首先先了解下正則表示式的引擎和匹配過程區別，再試著掌握如何在場景中編寫正則表示式，再然後探索下根據上文已知的原理和編寫過程怎麼去優化正則表示式，最後給出一些js里正則相關的小擴充套件。
基礎及原理簡單介紹
瞭解一下正則表示式的正則引擎(正則表示式使用的理論模型是有窮自動機，具體實現稱為正則引擎)。
正則引擎分有DFA(確定型有窮自動機)的和NFA(非確定型有窮自動機)的實現，根據編譯相關知識的描述，兩者是可以等價轉換的。NFA又分傳統型和POSIX標準，下面是三者一個簡單的對照表：
-/-回溯忽略優先量詞捕獲型括號應用演算法 DFA:x::x::x:文字主導 傳統型NFA:heavy_check_mark::heavy_check_mark::heavy_check_mark:表示式主導 POSIX NFA:heavy_check_mark::x::heavy_check_mark:表示式主導
回溯指的是：一個類似列舉的搜尋嘗試過程，在搜尋嘗試過程中尋找問題的解，當在分歧點選擇一條路徑，記住另一/多條路徑供之後使用，在選擇路徑後的探索過程中發現不滿足求解條件時，就返回到分歧點，嘗試其他路徑(回溯遵循後進先出原則/LIFO-last in first out)。
忽略優先量詞指的是：支援儘可能少的匹配結果。
捕獲型括號指的是：匹配並捕獲結果，獲取組號。
文字主導指的是：匹配搜尋過程中的每個字元都對匹配過程進行控制(這樣的結果就是：雖然我不能回溯，但我速度快呀 - DFA的傲嬌...)。
表示式主導指的是：表示式中的控制權在不同的表示式元素之間轉換，然後與文字進行匹配。
三者還有一些其他的差異，如編譯階段的處理及匹配最左最長原則等，由於文章裡以js的正則為準，就不做更多區別的介紹，詳情可參考書籍《精通正則表示式》，不過值得注意的是本書中的內容不一定完全適合各個語言或平臺中的正則表示式...
正則匹配的過程規則總結：
1. 優先選擇最左端的匹配結果(匹配是從左到右開始的)
匹配先從需要查詢的字串的第一個字元嘗試匹配；
如果匹配到結果，則返回結果；
如果匹配不到結果，則就需要從字串的第二個字元位置開始重新匹配；
以此類推，直到嘗試過所有的字串位置作為匹配起始點進行匹配後，返回匹配失敗結果。
如 forever 中匹配是否存在 ever：
第一輪：從f開始匹配，fore不匹配ever；
第二輪：從o開始匹配，orev不匹配ever；
第三輪：從r開始匹配，reve不匹配ever；
第四輪：從e開始匹配，ever匹配ever，獲得ever匹配起始點(此處為3)的索引和匹配結果。
2. 標準量詞總是匹配優先的(*、+、?、{m,n})
匹配優先：儘可能多的匹配；忽略優先：儘可能少的匹配。
標準量詞總是匹配優先的，如：foo 針對表示式取 fo|foo(下面匹配基於JavaScript)
匹配優先結果：foo，/f[o]{1,2}/
忽略優先結果：fo，/f[o]{1,2}?/，加?後表示忽略優先量詞
更多原理和匹配過程詳解可以參考園友@BattleHeart的文章"淺析正則表示式—（原理篇） "
在需求場景中構建正則表示式
要構建正則表示式，得先了解一些正則表示式的一些普通字元和元字元。這些可以參照"百度百科-正則表示式_符號 "，該表對於正則使用生疏的同學可以作字典參考，這裡對於這些字元就不多做贅述。
以幾個例子來說明下在有正則需求的場景中該如何來寫表示式。
例子一：查詢句子中某些單詞出現的次數。
首先分析情況得出：先給出個大致形狀，/pattern/g ，經測試發現：
"the weather's often cold in the north and windy in the east".match(/the/g).length // output 4
輸出4，明顯不對，這時候還需要考慮單詞的邊界情況，需要在pattern兩邊加上限制\b，並且注意不需要匹配單詞邊界，於是得出：
/\bthe\b/g
再測一下：
"the weather's often cold in the north and windy in the east".match(/\bthe\b/g).length // output 3
正確。
例子二：比如需要給數字加 ",(逗號)" 形成貨幣格式的場景，如1234567，變成1,234,567。
首先分析情況得出：逗號應該加在"左邊存在數字，右邊的數字個數是3的倍數"。
這裡用到正則的"非獲取匹配，反向肯定預查 : (?<=pattern)" 和 "非獲取匹配，正向肯定預查 : (?=pattern)"，非獲取匹配指的是匹配但不獲取匹配值，正/反向肯定預查指的是正/反向匹配時在任何匹配條件的字串開始處匹配查詢字串。
先反向肯定預查"左邊存在數字"的組合，給出(?<=\d)；再正向肯定預查"右邊數字個數是3的倍數的組合"，給出(?=(\d{3})+$)；結合兩者，加上全域性的匹配 g，得出：
/(?<=\d)(?=(\d{3})+$)/g
測試一下效果：
'123456789'.replace(/(?<=\d)(?=(\d{3})+$)/g,',')
// output123,456,789
'23456789'.replace(/(?<=\d)(?=(\d{3})+$)/g,',')
// output23,456,789
'1234'.replace(/(?<=\d)(?=(\d{3})+$)/g,',')
// output1,234
例子三：比如想把雷老闆的Are you ok 歌詞處理一下。
首先不想替換掉"..."，其次注意轉義字元，最後結合需要取的是引號內包含且非"的字元，於是得出：
/\"([^\"\.]*)\"/g
測試一下：
var str = ` Are you ok? Auther Mr.Lei 1. "Thank you!" 2. "Are you ok?" 3. "Hello" 4. "Thank you" 5. "Thank you every much" 6. "How are you Indian Mi fans?" 7. "Do you like Mi 4i?" 8. "..." `; var reg = /\"([^\"\.]*)\"/g; var replaceStr = str.replace(reg,'\"???\"'); // output // Are you ok? // Auther Mr.Lei // 1. "???" // 2. "???" // 3. "???" // 4. "???" // 5. "???" // 6. "???" // 7. "???" // 8. "..."
如何寫正則表示式的總結：先寫出明確的匹配條件，再根據需求去組合或新增細節。
正則表示式優化的一些探索
《精通正則表示式》書中和網上查找了不少資料，並且根據對NFA的理解，列出了一些符合理論的優化建議(不排除更多可能)：
1. 減少或者優化判斷分支；
2. 精確匹配條件(字元和量詞)；
3. 限制匹配優先的作用範圍，如+和*的區別，+減少了多選結構的回溯次數；
4. 節省引用(使用非獲取匹配)；
5. 將複雜的多條件正則拆分成多個簡單的單條件正則；
6. 錨點的優化，^(a|b)而非(^a|^b)；
7. 量詞等價轉換的效率差異(因語言而異)；
8. 使用固化分組(在支援的情況下，js並不支援)；
9. 使用變數儲存正則表示式(減少正則編譯過程)；
10. 還有更多細節...
《精通正則表示式》的第五及第六章都有涉及這些優化的介紹，網上google/baidu也是不少資料和案例。
根據其主要做的優化過程大致可總結出以下幾點(不排除更多可能)：
1. 減少匹配的回溯次數，減少時間；
2. 節省引用(使用非獲取匹配)，減少空間；
3. 正則表示式自身優化以達到編譯最優；
4. 也許更多吧...
以上是書籍和網上給出的優化建議，給出的案例大多是針對的perl和PHP的，在JavaScript中並不適用，為了驗證js裡的正則如何優化，下面是我給出的一些測試結果...
基於JavaScript的正則表示式...這一小節給不出完整的測試程式碼，因為在多個瀏覽器和nodejs端跑了很多測試程式碼，給定的情況是不同的...
但單獨某個端或者瀏覽器給出的結果是穩定的，以下是給出Chrome和Firefox瀏覽器和Nodejs各跑100000次(原先是1W長度字串跑1000次，後面為了效果更明顯最終增加為10W長度字串跑10W次)測試的結果總結...還有Safari瀏覽器、360瀏覽器、QQ瀏覽器的測試結果也統一不了。
Chrome瀏覽器下： 精確查詢條件比使用.、*這類元字元或者範圍的效能要優； 非貪婪模式和貪婪模式的效率差別不大，按平均值比較非貪婪模式效能優； 獲取匹配和非獲取匹配效率差別不大，按平均值來看非獲取匹配效能優； 優化判斷分支(將最可能匹配的結果放前面)效能更差； Firefox瀏覽器下： 精確查詢條件和使用.、*這類元字元或者範圍的效率差別不大，按平均值比較元字元或者範圍的效能優； 非貪婪模式和貪婪模式的效率差別不大，按平均值比較貪婪模式效能優； 獲取匹配和非獲取匹配效率差別不大，按平均值來看獲取匹配效能優； 優化判斷分支(將最可能匹配的結果放前面)效能更優； Nodejs環境下： 使用.、*這類元字元或範圍比精確查詢條件的效能要優； 非貪婪模式和貪婪模式的效率差別不大，按平均值比較非貪婪模式效能優； 獲取匹配和非獲取匹配效率差別不大，按平均值來看非獲取匹配效能優； 優化判斷分支(將最可能匹配的結果放前面)效能更差；
以上的測試結果並不能給出肯定的答案，所以建議在JavaScript裡使用正則的時候先測一下效能以免導致不愉快的意外，至於JavaScript中正則表示式的實現過程更是需要看V8的程式碼了...
JavaScript RegExp 小擴充套件
lastIndex 和 test 方法的愛恨情仇
var str = 'abcabc'; var regexp = /a/g; console.log(regexp.test(str));// output true console.log(regexp.lastIndex);// output 1 console.log(regexp.test(str));// output true console.log(regexp.lastIndex);// output 4 console.log(regexp.test(str));// output false console.log(regexp.lastIndex);// output 0
test 方法在執行後將 lastIndex 屬性值置為匹配到的結果索引值，並返回匹配結果；下一次執行 test 方法時從 lastIndex 位置開始匹配，並返回匹配結果；以此類推；最後一次執行 test 方法，索引重置為0，匹配結果為false。
RegExp vs indexOf 誰才是快男
在固定匹配值和"只匹配一次"的條件下，針對判斷字串是否包含某個"固定的"字串，indexOf 優於 regexp，效能將近一半。
var str = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36";
console.time('reg');
/Mac/.test(str);
console.timeEnd('reg');
console.time('indexOf');
str.indexOf('Mac');
console.timeEnd('indexOf');
經過多次測試 reg 的平均值 是 indexOf 的近2倍(環境：chrome & nodejs)；然而在其他匹配條件下，RegExp 更靈活，更方便，更全面。
關於String.prototype.indexOf方法內部程式碼暫時不知道怎麼去探究，根據以下文件有解釋，但未明確的理解，參考文件：
[ECMAScript 2015 (6th Edition, ECMA-262)]
[ECMAScript 1st Edition (ECMA-262)](初始定義)