The situation is as follows:
- PHP 5.5.11
- Mac OSX 10.9.2, Win7, CentOS 6.3
The code is as follows:
echo preg_replace('/[\s-]+/', '-', '阿树')."\n";
The test results are as follows:
- Mac garbled
- Windows, Linux are normal
Add mode modifier after normal, as follows:
echo preg_replace('/[\s-]+/u', '-', '阿树')."\n";
Look for information, so to speak:
U (PCRE_UTF8)
This modifier enables additional features in a PCRE that are incompatible with Perl. The pattern string is treated as UTF-8. This modifier is available under Unix from PHP 4.1.0 and is available under Win32 from PHP 4.2.3. starting from PHP 4.3.5 Check the UTF-8 legitimacy of the mode.
Excuse me:
- Do you mean to use matching characters as UTF8, and do you have any other effects?
- My code is UTF8, but why is only Mac (Unix) garbled?
Reply content:
The situation is as follows:
- PHP 5.5.11
- Mac OSX 10.9.2, Win7, CentOS 6.3
The code is as follows:
echo preg_replace('/[\s-]+/', '-', '阿树')."\n";
The test results are as follows:
- Mac garbled
- Windows, Linux are normal
Add mode modifier after normal, as follows:
echo preg_replace('/[\s-]+/u', '-', '阿树')."\n";
Look for information, so to speak:
U (PCRE_UTF8)
This modifier enables additional features in a PCRE that are incompatible with Perl. The pattern string is treated as UTF-8. This modifier is available under Unix from PHP 4.1.0 and is available under Win32 from PHP 4.2.3. starting from PHP 4.3.5 Check the UTF-8 legitimacy of the mode.
Excuse me:
- Do you mean to use matching characters as UTF8, and do you have any other effects?
- My code is UTF8, but why is only Mac (Unix) garbled?
The UTF8 of the tree says yes e6 a0 91 . Sensitive words to see here should be understood.
The second byte a0 and \n is the same, which is replaced by-the left and right side of the two bytes into illegal ASCII, displayed as a question mark, as for platform differences, is estimated to be the so-called pcre problem bar, is interested in drilling to find out