Bug #49958 [Fbk->NoF]: mb_strtoupper fails on Japanese characters
Edit report at https://bugs.php.net/bug.php?id=49958&edit=1
ID: 49958
Updated by: php-bugs@lists.php.net
Reported by: mjong at magnafacta dot nl
Summary: mb_strtoupper fails on Japanese characters
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: mbstring related
Operating System: Windows Vista
PHP Version: 5.2.11
Assigned To: moriyoshi
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
------------------------------------------------------------------------
[2011-12-05 10:52:29] magog dot the dot ogre at gmail dot com
Description:
-----------
I actually just encountered this problem as well with ucfirst() but not mb_strtoupper(). I would not
even comment except that PHP 5.3.8 fails on using ucfirst() whereas 5.3.6 succeeds. As such, my code
that had worked previously had stopped working before I put in a workaround using mb_strtoupper().
I do not know if PHP considers this to be a problem or not, since technically the software writer
should not have used ucfirst() to begin with. However, it seems like a problem to me when an
ostensibly minor update has the result of unnecessarily breaking code.
It did not work properly on two system I used, and did work properly on one system. Systems I tried:
*did NOT work - PHP 5.3.8 (cli) (built: Aug 23 2011 12:14:39)
*did NOT work - PHP 5.3.8 (cli) (built: Nov 8 2011 22:18:15) (custom build, IIRC)
*worked properly - PHP 5.3.6-13ubuntu3.2 with Suhosin-Patch (cli) (built: Oct 13 2011 23:09:42)
Reproduce code:
---------------
echo
ucfirst(urldecode("%E6%97%A5%E5%85%89%E6%9D%B1%E7%85%A7%E5%AE%AE%E9%99%BD%E6%98%8E%E9%96%80"));
Expected result:
æ¥å
æ±ç
§å®®é½æé
Result given in failing versions above:
Æ�å
æ±ç
§å®®é½æé
------------------------------------------------------------------------
[2010-04-25 20:48:43] felipe@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
------------------------------------------------------------------------
[2009-11-03 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2009-10-26 11:09:58] jani@php.net
Ever heard of http://www.pastebin.com/ ?
------------------------------------------------------------------------
[2009-10-26 10:12:51] mjong at magnafacta dot nl
mbstring.func_overload = 0. Setting it to 2 or 7 just means there is
no difference between calling sttrtoupper() and mb_strtoupper(), but
ucfirst() still produces incorrectly coded strings. This is using UTF-
8 for internal encoding. Using UTF-16 and UTF-32 basically crashes the
program.
mbstring.strict_detection = Off. Setting it to On does have no effect
whatsoever. I.e. if I check with phpinfo() it stays off, no matter
what I specify as value. This is not the case with other php.ini
settings. Besides there is no documentation on its effect.
I really researched this problem - but cannot not show you because
then this form says I am spammming - but the crux of this problem is
that UTF-8, UTF-16 and UTF-32 each behave differently when used with
strtoupper() and mb_strtoupper() and all can result in string that are
not valid encodings.
I have a working solution for my case, but I think this is a solvable
bug.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=49958
--
Edit this bug report at https://bugs.php.net/bug.php?id=49958&edit=1
Thread (10 messages)