最近在用angularjs進行開發時遇到了靈異事件，從某**拷貝下來的看似無比正確的**執行總是出錯。
經驗告訴我們，看上去正確的**可能實際上並不正確。我是指字元層面上。其中可能存在亂碼，存在奇怪的空白字元，這些均會導致問題。
然而我仔細檢查了一番，並未發現亂碼和多餘空格。唯一的異常情況是，angularjs的插值字串}在visual studio中的**著色不太對。在安裝了vs的最新web工具後，這插值字串中***應當被編輯器識別並顯示紫色，}會加粗顯示，但是這一段貼上來的**中它們仍顯示藍色，和正常html attribute一樣。
我起初並未放在心上，以為這只是vs的乙個小bug。但諸般走投無路後，我開始重新審視這個異常。當我嘗試就地手打乙個{{進去並觀察到正確的加粗、著色後，我認為目標已鎖定。
我複製了這個手打的{{並貼上取代原來的「{{」，那著色一下子就正常了。替換了所有的插值字串後，程式執行完全正常了。
很明顯，這看上去完全一樣的「{{」是不同的字元。在chrome console中檢驗相等性，返回false。
但到了這一步，我的思維還未達到。我推斷其中至少有乙個{不同。用charcodeat()函式檢驗一下，果然，charcodeat(0)為123，這是正常的{符號無疑；charcodeat(1)返回8203，這是個什麼鬼！是{的孿生兄弟嗎？
不是的。查詢資料後得知，這個字元叫做zero width space，中文可稱為「零寬空白」。看到這裡我恍然大悟，原來之前我一直被騙了，那個**的字串居然不是你看到的兩個字元，而是三個。參見維基百科
8203字元即其中的u+200b。
乙個有趣的js****式的應用見
這個字元在主流文字編輯器中均沒有任何顯示效果，就像乙隻看不見、摸不著的幽靈。我一般習慣讓文字編輯器顯示空白字元，以區分普通空白、製表符、換行符等，但是遇到這個零寬空白，我真是給跪了。
負向零寬斷言
如果我們只是想要確保某個字元沒有出現，但並不想去匹配它時怎麼辦？例如，如果我們想查詢這樣的單詞 它裡面出現了字母q,但是q後面跟的不是字母u,我們可以嘗試這樣 b w q u w b 匹配包含後面不是字母u的字母q的單詞 但是如果多做測試 或者你思維足夠敏銳，直接就觀察出來了 你會發現，如果q出現在...
grep 零寬斷言
參考參考二 算是正則環視的乙個簡單應用吧。前兩天因為第三方遊戲伺服器掉線，導致大量使用者同時登入我的伺服器，將伺服器負載瞬間提高到200 如此恐怖的數字讓我不得不考慮增加伺服器來抵抗問題重現，然而我的伺服器平時負載都很低，0.1都不到，增加伺服器來應付這樣短暫的風暴未免太過於浪費，於是我決定從日誌下...
vim 零寬斷言
vim 中使用零寬度斷言，包括 符號vim符號 描述示例 vim示例 正先行斷言 存在 foo bar foo bar 負先行斷言 排除 foo bar foo bar 正後發斷言 存在 foo bar foo bar?負後發斷言 排除 foo 先行斷言和後發斷言都屬於非捕獲簇 不捕獲文字 也不針對...