3 ms·

Remember this is for in-table storage, so it makes a certain amount of sense - this saves a byte over UTF-16 with support beyond the BMP. You have a hard limit

Remember this is for in-table storage, so it makes a certain amount of sense - this saves a byte over UTF-16 with support beyond the BMP. You have a hard limit on the byte size of the table - how do you determine a priori how much storage a 20 character UTF8 field will consume? The alternatives are to store the value in a clob field or set a hard byte count on the field and let the application or user be surprised when 20 print characters are rejected. I actually don't know how other providers handle in-table Unicode fields, MySQL made some poor choices on naming things at the least.

eridius 9y ago
At a bare minimum you'd expect it to be something like utf-8bmp for 3-byte storage and utf-8 for 4-byte.
- ars 9y ago
  It's historical. When it was implemented 4 byte unicode did not exist. Now that it does they can not change the names anymore. It's the same as why windows is stuck with utf-16, because when they implemented it unicode was 2 bytes.
  - eridius 9y ago
    > When it was implemented 4 byte unicode did not exist. Incorrect. When UTF-8 was invented, it was actually variable up to 6 bytes in length, being capable of representing code points up to U+7FFFFFFF. It was only shortened to 4 bytes in 2003. There is no point in history where UTF-8 was only limited to 3 bytes.
    - deleted 9y ago
      [deleted]
  - Dylan16807 9y ago
    That doesn't seem right. The 1998 version of MySQL didn't support unicode at all yet. Unicode 2.0 introduced UTF-16 in 1996, making the need for non-BMP characters very explicit. And UTF-8 at the time supported 31-bit code points.