3 ms·
This is an old article and it was incorrect when written, and it's incorrect today. The author may possibly have learned since writing it that UTF-8, by design,
by daneel_w 5y ago
This is an old article and it was incorrect when written, and it's incorrect today. The author may possibly have learned since writing it that UTF-8, by design, encodes up to 21 bits of character code point in at most 4 bytes of data. It works and behaves as it should.
- echelon 5y agoWell, that sounds great, but I've had to migrate numerous fields to utf8mb4 because we kept getting paged on emoji.
- daneel_w 5y agoSame. Inbound SMSes with emojis. Outbound SMSes with emojis. Names and labels with emojis etc. But the implementation of "utf8" still isn't wrong, nor a bug - just like the 20 year old specs of UTF-8, they just failed to take the future into account.
- chris_wot 5y agoThe OP is wrong about the article being incorrect.
- loeg 5y agoUTF-8 was not restricted to U+10FFFF until November 2003. Prior to that, implementers had to assume it could encode up to 6 bytes of data. The "utf8" mode in MySQL can only encode 3 bytes of data (up to 16 bit codepoints), which is less than 4 (less than 21 bit codepoints). "utf8mb4" correctly encodes all UTF-8 codepoints by current standards.
- daneel_w 5y ago> "utf8mb4" correctly encodes all UTF-8 codepoints by current standards. Yes, all good and known, but not really what the misunderstanding is about. "utf8" follows the definitions of UTF-8 as they stood at the time, adhering to Unicode's former code space limit.
- butlerm 5y agoMySQL's adoption of a utf8mb3 limitation for "utf8" was over seven years obsolete when it was adopted. It would have been obsolete in 1996.