不同机器的preg_match_all结果不一样？[已解决，见四楼]
又遇到preg_match_all的问题，以前遇到过，后来换了php版本，貌似解决了，这次换版本也不行了，再来求救：情况：一段代码：$content = "#测试 #abc"；//utf-8编码
$count = preg_match_all('/(?:^|\s)#([\pL\pN_\-\.]{1,64})/', strtolower($content), $match);
其中“测试”是utf-8编码。一个机器上正常，新安装的机器都不正常，测试的输出为：
array(2) { =>array(2) { =>string(3) "# 貌似可以注意一下文件本身编码
还有mb_internal_encoding 设定 多谢bs版主。
你说的两个地方都检查了，都正常。
经过多次测试，发现5.2.8以上的版本都不能正常显示，5.2.8 以下的版本可以。
一楼的帖子只提到原另三台机器是pcre版本安装的不对。
另外5.2.9的版本更新说明中有一段是：提高的pcre的运行速度，会不会把这功能直接修改了？
[ 本帖最后由 lsstarboy 于 2009-12-22 22:02 编辑 ] 多谢各位的关注！
经过近三天的追踪，从操作系统的选择，到web服务器，再到php和pcre的版本，最终追到了源代码，终于解决了问题，总结如下：
１、linux在某些方面不严格，很多版都可以不加/u参数就能实现utf-8的preg；BSD严格执行标准。
２、php5.2.8以前版本自带的pcre也可以自动实现utf-8。
３、错误根源在于pear的Net_URL_Mapper有bug，提取regex的时候根本没有考虑到utf-8的情况，直接不加任何参数就时行preg_match。
４、把pcre的使用方法完整的读了一次，发现以前有很多地方没注意到。http://www.pcre.org/pcre.txt。学到了/u参数的另一个替代——前置(*UTF8)，这个在需要生成表达式的时候很有用。
５、pear虽然不错，但是要为别人的错误负责！
６、nginx和fpm-php是一个黄金搭档！顺便说一下，php5.3.0加入了fpm的选项。
[ 本帖最后由 lsstarboy 于 2009-12-24 22:58 编辑 ] lsstarboy 在问题研究上相当严谨，pf
:) 本帖应该加入精华。 多谢bs，以后会努力。 又学习了。 宝贵的经验来之不易 感谢分享 ^_^ :emn31: 实在是难得经验。
页:
[1]