Sure, in some cases it makes sense to make the tradeoff of not handling more obscure characters. But if the tradeoff is made, the encoding should not be called UTF-8.

"UTF-8 (UCS Transformation Format—8-bit[1]) is a variable-width encoding that can represent every character in the Unicode character set," says Wikipedia. The UTF-8 implementation in MySQL does not meet this definition because it cannot represent every character in the Unicode character set.

When MySQL first implemented UTF-8 they probably did support every Unicode character... because there were less than 64K Unicode characters. Then Unicode/UTF-8 was redefined out from under them.

> there were less than 64K Unicode characters. Then Unicode/UTF-8 was redefined out from under them.

Unicode 2.0 introduced multiple planes, i.e. more than 65536 characters. That was in 1996. If that was the case, then MySQL has had more than one-and-a-half decades to introduce multiple planes and seems to have done so less than a year ago. I disagree with being 'redefined out from under them', when it was defined a year after MySQL started, at a time when it probably didn't even have Unicode support yet anyway.

Interesting to note is that MySQL was first released in 1995. Which means that only for one year of its existence were there less than 65536 characters.

Yes, but at the time, UTF-8 could encode up to 31 bits per character using six-byte sequences. It has since been restricted to four-byte sequences at the longest.

> seems to have done so less than a year ago

More than 2 years ago. March 2010.

> But when did people really start using more than the 16bit unicode chars?

1996.

China even made it a legal requirement for computer systems in 2000, through mandating GB 18030.

There's the Private Use Area if nothing else. There is NO excuse to not support anything other than the BMP. Adding support is trivial unless you have been using UTF-16 in the erroneous belief that it's two bytes long always (in which case you've really been using UCS-2).

This is just the original argument restated. It's not a rebuttal.

According to Wikipedia, the original version of UTF-8 supported >4 byte characters, and was later restricted to 4 bytes by RFC 3629 in November 2003, seven months before MySQL 4.1 was released with Unicode support. (There were 96,447 Unicode characters at that time.)

There's no good reason for one to be faster than the other, though! They're both utf8 encoded sequences of bytes, and there's no good reason to not stream through them as utf8.

> There's no good reason for one to be faster than the other, though!

Not exactly. A varchar will store it as is, but a char column will allocate a fixed 3 (or 4) bytes for each character.

All data stored in memory (for sorting and such) is always as char, even if it started as varchar.

So by allowing 4 bytes per character they use more memory.

Does anybody really think that UCS-2 is a good idea anymore? Or that random indexability by code point is all that valuable, in a world with combining glyphs and bidirectional characters and whatever other crazy stuff Unicode has? If you just want an upper bound on the number of bytes needed to store n code points, then (a) that's probably not a particularly useful question to ask, and (b) if you assume that 32 bits is enough for any code point, then the space taken by properly-formed UTF-8 is bounded.

So, why would they want to store things internally as UCS-2? Or rather, why should they?

Which is in many cases not faster than UTF-8 since UTF-16 is often more bytes than UTF-8. This matters especially since we are talking about a database which means IO and RAM usage probably are more important than the CPU.

Except it didn't. It used up to three bytes per character. It had the drawbacks of variable width but not the easy-to-add benefits.

Or do you mean in-memory being different from the file format AND different from the I/O format? That doesn't sound terribly efficient.

I think I'll skip both and install postgres

I think one of the main points that the article touches upon is: "It's 2012, unicode was invented 20 years ago, why the hell has no one tested this yet, let alone gotten it to work?"

Because trans-bmp characters are very rare (think less than 1/10000000) and unless you work with specific corpora you may never come across them.