|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2005-08-13 20:38 UTC] sniper@php.net
[2005-08-21 01:00 UTC] php-bugs at lists dot php dot net
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 01 01:00:01 2025 UTC |
Description: ------------ When "mb_ereg_replace" is used under "UTF-8" source environment, it does not seem to recognize ?gmulti-byte space?h (zenkaku-space in Japanese). The same code runs correctly under ?gEUC-JP?h source environment, so I supposed this was something buggy rather than mis-usage of the function. [mbstring] mbstring.language = Japanese mbstring.internal_encoding = UTF-8 mbstring.http_input = auto mbstring.http_output = UTF-8 ;mbstring.encoding_translation = Off mbstring.detect_order = auto mbstring.substitute_character = none; ;mbstring.func_overload = 0 Reproduce code: --------------- <?php /* the all three var_dump()s "UTF-8", and this verifies the source is actually run under "UTF-8" */ var_dump(mb_regex_encoding()); var_dump(mb_internal_encoding()); mb_regex_encoding(mb_internal_encoding()); var_dump(mb_regex_encoding()); /* Although this var_dump should give "**********?@*****" by recognising "?@"(multi-byte space), when it is run under "UTF-8", it gives "****************". This assures that the "multi-byte space" is not recognised as it should. */ $string = "multi-byte?@space"; var_dump(mb_ereg_replace('[^?@]', '*', $string)); ?> Expected result: ---------------- multi-byte space should not be converted to "*" in the reproduce code since the regular expression is "[^?@]". Actual result: -------------- multi-byte space is ignored and converted to "*".