这两天正在做一个关键字加亮显示的程序，写好的程序在本地测试也跑得好好的，可是一上去页面就出现一堆一堆的乱码，别说加亮了，简直就是没的看！
我就找错误，找来找去，发现英文没有问题，遇到汉字容易出问题，有的时候遇到汉字必出问题。
总结一下：
当使用模式匹配的时候，如：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。