向latin1字符集的MySQL数据库发送UTF-8数据会出现什么问题？

一、能否正常查看存入的内容？ #

• ASCII字符：完全没问题，因为ASCII是latin1的子集，且UTF-8对ASCII的编码和latin1完全一致，存入和读取都不会乱码。
• 德语变音符号ü这类latin1覆盖的字符：
  • 要是直接把UTF-8编码的ü（字节为0xC3 0xBC）存入latin1字段，MySQL会把每个字节当作独立的latin1字符存储（对应Ã和¼），之后在UTF-8网页显示时，这两个字节被解析成UTF-8，结果就是乱码（显示为ü）。
  • 但如果PHP在发数据前把UTF-8转成latin1，或者连接数据库时设置SET NAMES latin1让MySQL自动转换，那存入的是latin1编码的ü（字节0xFC），读取时再转成UTF-8，就能正常显示。
• 日语这类非latin1字符：
  • UTF-8的日语字符是多字节（比如“あ”的字节是0xE3 0x81 0x82），直接存入latin1字段时，MySQL不会做转换（因为latin1无法表示这些字符），相当于把字节原样存进去。之后在UTF-8网页读取时，这些字节被解析成UTF-8，反而能正常显示——这就是你用WordPress测试时看到的情况。

二、为什么WordPress存入日语字符显示正常？ #

WordPress本质是做了**“字节透传”**：它没让MySQL做字符集转换，而是把UTF-8的字节直接存在latin1字段里。因为MySQL的latin1字段允许存储任意0x00-0xFF的字节（latin1是单字节编码，每个字节对应一个字符），这些多字节的UTF-8数据只是被当作一串latin1字符存储，没有被修改。读取后直接输出到UTF-8网页，浏览器会把这些字节解析成UTF-8，自然能正确显示日语字符。

三、此时设置字符集latin1的意义是什么？ #

哪怕实际是“存字节”，字符集设置依然有作用：

1. 影响字符串函数行为：比如LENGTH()函数，在latin1字段下返回的是字节数（因为每个字符占1字节）；如果是utf8mb4字段，LENGTH()返回字节数，CHAR_LENGTH()返回字符数。代码如果依赖这些函数的结果，字符集设置会直接影响逻辑。
2. 排序和比较的依据：排序规则（collation）基于字符集，latin1的排序规则是按latin1字符的编码值排序。哪怕字段里存的是UTF-8字节，MySQL排序时会把这些字节当作latin1字符来比较，结果可能和预期的UTF-8排序不一致。
3. 元数据的标识作用：字符集是表结构的元数据，告诉数据库和开发者这个字段“应该”存储什么编码的数据。如果实际存的是UTF-8字节但元数据是latin1，后续维护者可能误解字段用途，引发问题。
4. 理论上的字节约束：latin1定义了每个字节对应的字符映射，虽然MySQL实际允许存所有字节，但这个约束在某些严格的数据库环境下可能生效。

内容的提问来源于stack exchange，提问作者user14487566