Django中数据库存储的Emoji HTML实体渲染异常排查

这种情况几乎可以肯定是双重HTML转义搞的鬼——你的🌶被转义了两次，第一次变成🌶，第二次渲染时又把里面的&转成&，最终就成了🌶。我给你一步步排查和解决：

1. 先确认数据库里的原始内容 #

先直接查数据库，看字段里存的到底是🌶还是🌶。可以用数据库客户端直接查看，或者执行查询语句：

SELECT your_emoji_column FROM your_table WHERE your_condition;

• 如果数据库里已经是🌶：问题出在写入数据库的环节。你的后端代码可能在保存前自动转义了HTML实体（比如用了htmlspecialchars、escape_html这类函数，或者ORM框架默认开启了转义）。这种情况要去掉写入时的转义逻辑，直接存原始的🌶。
• 如果数据库里确实是🌶：问题就出在模板渲染/前端输出环节。

2. 排查模板的自动转义逻辑 #

绝大多数模板引擎（比如Jinja2、Vue、Thymeleaf等）为了防XSS，默认会自动转义HTML实体。比如你用了类似这样的循环代码：

{% for item in data_list %}
  <span>{{ item.emoji_content }}</span>
{% endfor %}

这里的{{ item.emoji_content }}会被模板自动转义，把🌶里的&转成&，最终就变成了🌶。

解决办法就是告诉模板：这个内容是安全的，不需要转义。举几个常见模板的写法：

• Jinja2/Django：使用safe过滤器 → {{ item.emoji_content|safe }}
• Vue：用v-html代替插值表达式 → <span v-html="item.emoji_content"></span>
• Twig：用raw过滤器 → {{ item.emoji_content|raw }}
• PHP原生输出：用html_entity_decode()还原 → echo html_entity_decode($item['emoji_content']);

3. 检查后端接口的返回环节 #

如果上面两步都没问题，那要确认后端从数据库取数据后，返回给前端的内容有没有被再次转义。比如接口返回的JSON里，🌶变成了🌶，那就是后端在返回前做了多余的转义，需要修改后端代码，确保返回原始的实体字符串。

额外建议：直接存emoji字符更省心 #

现在主流数据库（MySQL 5.5+、PostgreSQL等）都支持utf8mb4编码，完全可以直接存这个emoji字符，而不是HTML实体。这样不管是模板渲染还是接口返回，都不需要处理转义问题，直接输出就能显示emoji，反而能避免这类转义坑。

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