In this post on the Dokeos blog, there's a comparison of the mbstring function and the iconv library as it pertains to their use on multi-byte strings.

I was wondering today why use mbstring rather than iconv in Dokeos, and honestly I didn't remember exactly why I had chosen mbstring in the past, but finding information about the *differences* between the two. [...] Searching a bit more, I found a PPT presentation from Carlos Hoyos on Google.

Essentially, it boils down to how the library is integrated - mbstring is bundled and iconv is pulled from an external source. So, if you're looking for maximum portability, he recommends mbstring.

On his blog today, Chris Shiflett has two posts about a problem with Google and a Cross-site Scripting attack that it's vulnerable to.

From this post: The recent cross-site scripting (XSS) vulnerability discovered in Google perfectly illustrates why character encoding matters. This example demonstrates how to use PHP's htmlentities() with the optional third argument that indicates the character encoding.

By way of demonstration, he provides a little PHP script that makes a request in a different character encoding than Google can handle. Coupled with the small response from Google, a UTF-7 character sent to certain browsers could be interpreted and executed.

In this second post, he answers a question from the comments - "how will this effect my site?"

Rather than offer another vague answer, I decided to provide a very simple proof of concept that demonstrates how character encoding inconsistencies can bite you. Google's vulnerability has of course been fixed, but with a simple PHP script, we can reproduce the situation.

The script, though escaped, still causes a Javascript popup box to show when the page is loaded - all due to a lack of improper character encoding handling...