Add support for characterset in mb_strtoupper-call

[fschaeffer]

As the internal encoding is not always used in mb_strtoupper I added an option to set the characterset in _options and use it in the _strtoupper-call.

[mtibben]

If we add this as a configurable option, I think we should apply the encoding across all functions that support it. e.g. htmlspecialchars, html_entity_decode

But from what I can see, I don't think this library is even going to work in a charset which doesn't have the ASCII 1-128 characters - heavy use of regular expressions, etc. To support other character sets properly, we would need to convert to UTF-8 right at the beginning

Alternatively, you could just hardcode 'UTF-8' into the mb_strtoupper function, (as the other functions default to UTF-8 also). That way we can say that this library only supports UTF-8, and if you want other encodings you need to do the conversion yourself.

[fschaeffer]

I first thought of hardcoding the characterset into the mb_strtoupper-call but then wanted to give the user the option to override it if necessary. But you're right, the other functions rely on UTF-8 aswell so we could even hardcode it... We're all on the UTF-8 road nowadays, aren't we :-).
During my tests I found no glitches when using romanian, german (or other western latin characters), bulgarian (that is cyrillic) or greek $str-contents. So your class works pretty good with them (didn't test hebrew or kanji though). I'll push another commit ....

[mtibben]

Cool. Can you squash this, and then I'll merge

[fschaeffer]

I would if I knew how? As the commits are already pushed I get into a diverged state if I rebase them into one commit. Any directions how to get this done?

[mtibben]

Yup sure. You can rebase and squash into one commit. Then force push

[fschaeffer]

Ha, learning each day something new about git, always struggled with "detached state", --force did the trick... thanks a ton.

[mtibben]

No probs :)