這兩天正在做一個關鍵字加亮顯示的程序，寫好的程序在本地測試也跑得好好的，可是一上去頁面就出現一堆一堆的亂碼，別說加亮了，簡直就是沒的看！ 我就找錯誤，找來找去，發現英文沒有問題，遇到漢字容易出問題，有的時候遇到漢字必出問題。
總結一下：
當使用模式匹配的時候，如：preg_match_all($pat,……)與preg_replace($pat,……)……
容易出問題的情況如下：
preg_match_all("/(漢字)+/ism","我是漢字，看你把我怎麼著！",$m_a);
這個模式很簡單就是匹配出“漢字”。這種情況模式中包含漢字可以成功匹配出來，但是也不要高興得太早，結果不確定，為什麼不確定你慢慢往下看。
必出現問題情況如下：
preg_match_all("/[漢字]+/ism","我是漢字，看你把我怎麼著！",$m_a);
本想匹配出現“漢”、“字”或者“漢字”。這個必出現問題，匹配的結果一大群亂碼，沒准還會出個死循環呢。為什麼會出現這種情況？是因為PHP內部使用不是UNICODE，不支持多字節文字，所以一個"漢字"就被當成４bytes的ASCII去進行模式匹配，不出錯才怪呢！
後來我又試試重新寫一下模式匹配，發現一種似乎（為什麼說似乎？往後看）方法可以解決：
preg_match_all("/(漢|字)+/ism","我是漢字，看你把我怎麼著！",$m_a);
這樣寫可以匹配出“漢”、“字”或者“漢字”，$m_a中的結果
Array
(
[0] => Array
(
[0] => 漢字
)
[1] => Array
(
[0] => 字
)
)
怎麼樣全匹配的字符串出現了吧！可是高興得太早了，後來在實際中用還是會經常出問題！再去找問題，終於找到問題的根了！PHP不支持多字節文字，所以在進行模式匹配與字符操作的時候都是內碼轉化後進行的（我不知道這樣說對不對），舉個實例吧：
eregi_replace("性","沒有" , "有責任感");這個操作就是要把字符串"有責任感"中"性"字替換成"沒有"，最後的結果是什麼？因為"有責任感"中沒有"性"就個字，結果應該是沒有執行替換操作返回"有責任感"，可是結果竟然是"用揮敘任感"！
沒想到吧！為什麼？看一下ASCII碼你就明白了，2個ASCII碼代碼一個漢字"有責任感"的ASCII編碼依次為：211,208(有)，212,240(責)，200,206(任)，184,208(感)
而"性"的編碼為：208,212(性)，恰好與有的第2字節和責的第1字節組合是一致的！所以PHP就認識找到相同的模式進行匹配，拆成一半的漢字再與替換後的字串進行組合，所以就出錯了！
當時我想最常用的str_replace()，應該不會有問題的，但是事實上str_replace()執行同樣的操作也會出錯！現在我想以前進行漢字替換實在是太幸運了！可能是那個時候進行的漢字替換都是比較長的漢字串吧，不太容易出現以上的情況。即使沒有出問題，也要知道那是不安全的！
問題是有的，工作還要繼續做，克服的困難也就::::現在的自我了。
好在想起一組PHP的擴展模塊，Multibyte String Functions，添加許多支持多字節文字的操作的函數，如：ereg_replace() 對應著mb_ereg_replace() 等等。具體的函數說明請查詢相關的文章。
總結：對於中文漢字安全的操作最好是使用Multibyte String Functions。
