UNICODE字符码的匹配 PHP中正则表达式对UNICODE字符码的匹配方法

网友ainiaa的问题是

PHP代码如下

为什么打印的结果会是：
otherStr: ! #$% & {}| ‘”你好啊我们

麻烦问下其中正则表达式 /[chr(128)-chr(256)]+/is 代表什么意思？
如果/[chr(128)-chr(256)]+/is 指的是ascii码在128到256的字符，为什么a-zA-Z这样的字符也被替换掉了，他们的ascii码是小于127的。
最令人郁闷的是为什么ascii码同在0-127区间”#”,”$”,”%”,”&”, “!”,” {“,”}”,”|”,” ‘”,”确没有被替换掉？？？？
更令人感觉神奇的是 如果把正则表达式修改为”/[chr(128)-chr(256)]+/s”的话，输出的结果就变成了： otherStr: defg ijklmnopq stuvwxyz ! #$% & {}| ‘”你好啊我们
只是把正则表达式中的符号‘i'给去掉，结果缺失这样的。 完全的令我理解不了。
不知各位 有何见解？？？？
另附ascii 码 对照表
（这个ASCII码表的图我就不贴了）

回帖中，有个网友说没解析chr(128)这些，并给出了新的解决方法。首先说下此网友回答的是正确的，先不评论他是否“知其然，且知其所以然”，这位网友没有给出错误的原因。

CFC4N来回答一下这位网友：

PHP的正则的preg_match函数用的是PCRE正则引擎，这位网友的代码中，PCRE引擎处理的正则表达式为【/[chr(128)-chr(256)]+/is】，后面的is是什么呢？
在PHP的正则里，边界字符后面的叫模式修饰符。它会告诉引擎如何解析，处理正则。其中i修饰符表示不区分大小写。s表示“点号通配模式”，用来让正则里的元字符点号【.】可以匹配换行符，这个修饰符仅对点号【.】起作用。在这位网友的问题中，修饰符s并不起作用的。

查找原因：
我们在来分析一下这个网友写的正则表达式【[chr(128)-chr(256)]+】，正则表达式的PCRE引擎是如何解释这个正则的呢？首先，我们要知道，在正则表达式中，中括号【[]】表示字符组，字符组中除了连接符【-】只外，都不是元字符，也就是说，都是普通字符，当然，如果连字符出现在第一个，或者不是标识两个字符之间范围的，都是普通的字符横杠“-”罢了。这里的chr(128)只是标识ASCII码为128（确切的说，ASCII码只是0-127个，128到其他的，应该不叫ASCII码了。），但是在正则里，他仍然代表【c、h、r、(、1、2、8、)】（顿号不是，只是区分易读的）这八个字符罢了。这个正则里的连接字符，是哪些范围呢？很明显，这里的连接字符的范围是【)-c】，“)”ASCII码为0×29，也就是十进制的41；“c”的ASCII码为0×63，也就是十进制的99，那么，他这个连接字符的范围就是ASCII 41（chr(41)）到ASCII 99（chr(99)）之间的字符。也就是说，这位网友的正则的范围是【[hr)-c(]】，就是chr(41)到chr(99)外加hr这两个字母和前面的“(”。
网友第一次测试的时候，有修饰符i，意思就是说，不区分大小写，那么在chr(41)到chr(99)之间的字符，以及这些字符如果有大小写，则包括他们的大小写都符合匹配。都会被替换成空。其第二次测试的时候，去掉了修饰符i，进行了不区分大小写的匹配，由于其范围只到c，但突然，再除了小写字母的“h”、“r”，所以，测试结果会多出“defgijklmnopqstuvwxyz”。所以，他的结果出现了这些差别。

网友的表达式等同于如下图所示

解决办法：
错误的原因找出来了，那么，解决的办法呢？
我们先来看看这位网友的需求，他的需求是将unicode（ASCII只是0-127位的，128之后的，应该叫UNICODE码）的chr(128)到chr(255)之间的字符匹配，替换为空罢了。正则表达式里，对十六进制的字符匹配的表示方式有两种，【\u】和【\x{}】，前者只能表示【\u】后面4位的十六进制数值，而后者【\x{}】则可以表示任意多的十六进制位数（写在大括号中）。
那么，这个正则表达式该如何写？？？？

网友的目的是chr(128)到chr(255)，那么就是【[\u0080-\u00FF]】或者【[\x{0080}-\x{00FF}]】。
其目的是匹配下图中的红框内字符



提醒一下，PHP里正则匹配unicode字符时，需要使用u修饰符。
根据网友需求，更改正则之后的PHP代码如下：

其运行结果是仍然输出那段字符串，为什么呢？因为哪些字符串都不在chr(128)到chr(255)的范围之内。
（测试时，注意文件编码为UTF-8）
以上为鄙人愚见，欢迎批评指正。