ID: 49958
User updated by: mjong at magnafacta dot nl
Reported By: mjong at magnafacta dot nl
-Status: Feedback
+Status: Open
Bug Type: mbstring related
Operating System: Windows Vista
PHP Version: 5.2.11
New Comment:
Ah... I assumed that mb_check_encoding() will use
mb_internal_encoding() when none is specified.
Anyhow, I used UTF-8 as internal encoding, but I have just now tested
it with all internal encodings (setting them using
mb_internal_encoding()).
Previous Comments:
------------------------------------------------------------------------
[2009-10-23 10:21:00] j...@php.net
mb_strtoupper() defaults to mb_internal_encoding(), so what does latter
give you? If it's not the right encoding, then there is no bug here. And
strtoupper() or ucfirst() or anything without mb_* in front of it aren't
even supposed to work with such.. :)
------------------------------------------------------------------------
[2009-10-22 16:14:01] mjong at magnafacta dot nl
Description:
------------
Using strtoupper, ms_strtoupper and derived functions like ucfirst
produced incorrectly encoded strings when used on strings containing
Japanese Hirigana or Katakana characters.
As no uppercase versions of these characters exists they should be
treated as e.g. numbers.
Workaround: use mb_check_encoding to revert to the old string when this
happens.
Reproduce code:
---------------
// $s = strtoupper('まてえす and
ジョング');
$s = strtoupper(
base64_decode('44Gm44GI44GZ').
' and '.
base64_decode('44K444On44Oz44Kw'));
if (mb_check_encoding($s)) {
echo $s;
} else {
echo 'Error';
}
Expected result:
----------------
まてえす and ジョング
Actual result:
--------------
Error
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=49958&edit=1
