5 ms·

> Which is to say, Unicode was broken by default in MySQL until just over five years ago. No, stock MySQL has never used a default character set of utf8 (utf8m

> Which is to say, Unicode was broken by default in MySQL until just over five years ago. No, stock MySQL has never used a default character set of utf8 (utf8mb3). Prior to MySQL 8, the default character set was latin1, not utf8 (utf8m3). "utf8" being utf8mb3 is indeed a huge foot-gun, but it isn't correct to say that "Unicode was broken by default in MySQL". utf8mb4 has been available for use since 2010 (MySQL 5.5). As for silent truncation, that bad default was fixed in 2015 (MySQL 5.7), but the option has been available since like 2004 or 2005. That all said, some Linux distros may apply some non-standard defaults (like changing the default charset), and ditto for cloud DBaaS products (e.g. RDS disables strict sql_mode even today in all versions).

bastawhiz 3y ago
latin1 as an encoding also results in broken Unicode support (for obvious reasons). The point still stands that if you did nothing, you didn't have correct Unicode support, and if you tried to do the correct obvious thing, it was still broken. And a lot of people ran into this, enough that it literally made many folks avoid MySQL.
- evanelias 3y ago
  > latin1 as an encoding also results in broken Unicode support That actually depends on whether your application actually relies on collation behaviors for case insensitivity or accent insensitivity of non-Latin characters. From experience I can tell you that some of the largest companies in the world actually store unicode in MySQL tables using latin1 character set! It's not ideal and it's conceptually very gross. But in practice it actually works completely fine for these companies, because the relevant collation logic is handled in the application and/or in ancillary services. Anyway, I agree with your overall point that MySQL should have changed the "utf8" alias to point to utf8mb4 much much earlier. Although I also understand the significant backwards-compatibility concerns (especially regarding logical dumps) which forced MySQL/Sun/Oracle to slow-walk this change.

bastawhiz 3y ago

latin1 as an encoding also results in broken Unicode support (for obvious reasons). The point still stands that if you did nothing, you didn't have correct Unicode support, and if you tried to do the correct obvious thing, it was still broken. And a lot of people ran into this, enough that it literally made many folks avoid MySQL.

evanelias 3y ago
> latin1 as an encoding also results in broken Unicode support That actually depends on whether your application actually relies on collation behaviors for case insensitivity or accent insensitivity of non-Latin characters. From experience I can tell you that some of the largest companies in the world actually store unicode in MySQL tables using latin1 character set! It's not ideal and it's conceptually very gross. But in practice it actually works completely fine for these companies, because the relevant collation logic is handled in the application and/or in ancillary services. Anyway, I agree with your overall point that MySQL should have changed the "utf8" alias to point to utf8mb4 much much earlier. Although I also understand the significant backwards-compatibility concerns (especially regarding logical dumps) which forced MySQL/Sun/Oracle to slow-walk this change.