Django操作MySQL：为何同为TextField存特殊Unicode字符一个报1366错误一个正常

报错1366 Incorrect string value的根因是数据库侧的字符集校验机制和你实际存储的内容不匹配，和Django层面的字段类型（TextField/JsonField）没有直接绑定关系——你观测到的“同是文本存储，一个能存一个报错”的反常现象，本质是两个目标列的实际字符集配置不一致。

你觉得“TextField本身支持存Unicode字符”的推断存在偏差，实际的存储逻辑是这样的：

• MySQL中历史存在两个容易混淆的字符集：
  • utf8（实际是截断的utf8mb3，仅能支持有限范围的Unicode字符，不覆盖部分宗教符号、特殊标点、绝大多数emoji）
  • utf8mb4（完整的UTF-8实现，支持所有Unicode字符）
• 你之前能正常存带✝✝✝ (Crosses)内容的字段，大概率经历过从普通TextField存json字符串、后来改成JsonField的改造：当Django把这个字段迁移为MySQL原生JsonField时，MySQL会自动将该列的内部存储逻辑调整为强制utf8mb4编码，不受列本身的外部字符集配置、甚至客户端连接的临时字符集严格约束——MySQL服务端的JSON解析器会先把传入的字符串解码为内部Unicode对象，再用utf8mb4编码存储，全程不会触发普通文本列那种“传过来的字节直接按列字符集硬校验，解析失败立刻抛错”的逻辑。
• 而你现在报错的album_name/name列，是项目早期创建的普通文本列，当时建表没有指定utf8mb4字符集，沿用了MySQL默认的utf8mb3规则；这类普通文本列的逻辑是：客户端（也就是Django的数据库连接）传什么字节流过来，MySQL直接按列的字符集规则做校验，只要遇到超出兼容范围的字符，就会立刻抛出1366错误。

• 没有在Django的数据库连接配置里强制指定统一的utf8mb4字符集：Django 3.1对应MySQL的默认连接配置，如果不手动指定OPTIONS参数，会话会默认沿用MySQL实例的全局字符集配置（很多老版本MySQL默认还是utf8mb3），很容易出现连接和列的字符集不匹配的问题。
• 历史迁移过程中没有统一修正表/列的字符集：从TextField改造为JsonField的那次迁移，只自动升级了对应单个列的字符集，同一张表内其他的普通文本列，还是沿用最早建表时的utf8mb3配置，最终形成了同项目、同数据库内不同列字符集不一致的奇怪状态。
• 认知存在偏差：误以为Django的ORM字段类型统一绑定了相同的字符集规则——实际上ORM只是做代码和数据库的映射，所有字符集校验全部由MySQL服务端完成，和你用的是TextField还是JsonField没有直接关系。

• 先验证列的实际配置：在MySQL中执行SHOW FULL COLUMNS FROM 表名 WHERE Field = '字段名';，对比能正常存储特殊字符的列和报错列的Collation值：能存的列对应是utf8mb4_*规则，报错的列对应是utf8_*（即utf8mb3）规则。
• 第一处修复：在settings.py的DATABASES配置中，给MySQL连接加上强制字符集参数：

  DATABASES = {
      'default': {
          # ...其他原有配置
          'OPTIONS': {
              'charset': 'utf8mb4',
          }
      }
  }
  

• 第二处修复：通过Django迁移，将所有报错的表、对应文本列的字符集统一升级为utf8mb4，彻底替换掉历史的utf8mb3配置。

注：你在pdb.set_trace里看到的传入值是正常的，这个判断没有问题——问题完全出在数据库侧的存储规则，和你代码传入的内容没有关系。

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