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.. :)

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()).

[PLEASE ALLOW LONGER ENTRIES] 

Using strtoupper() all encodings create nonsense strings, but in half 
the cases the error can be tested using mb_check_encoding(). 
Strangely enough the 2-byte definitions including UTF-8 cannot be 
checked, while UTF-8 and the 4-byte encodings do OK.

Using mb_strtoupper() a third of the encodings do a proper 
translation. Half of the encodings generate nonsense and none of them 
can be tested using mb_check_encoding(). The rest of the encodings 
fail when using them with mb_strtoupper(). 
With mb_strtoupper() UTF-8 and UTF-16 work OK, but now UTF-32 fails. 
"Stranger and stranger", Alice said.

Please read this page and especially the last two examples: http://www.php.net/manual/en/mbstring.configuration.php 

Are you using the proper options?

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.

Ever heard of http://www.pastebin.com/ ?

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".

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

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:
Ɨ�光東照宮陽明門

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.