HTML 编码不只是安全话题，它还和数据质量息息相关。当编码和解码在错误的环节发生、或发生了不止一次时，轻则用户在页面上看到一串刺眼的乱码，重则数据在反复转换中被悄悄污染，最终存进数据库的已经不是原本的内容。这类问题往往隐蔽，等到发现时数据可能已经损坏。理解编码解码该在何时何地发生，是守护数据质量的关键。
编码与解码是一对操作
编码把特殊字符转成 HTML 实体，解码则把实体还原回原始字符。理想情况下，数据在即将写入 HTML 时被编码，在浏览器渲染时被解码显示，整个过程干净利落、各发生一次。这一对操作必须严格配对，多一次少一次都会出问题。
麻烦在于，在一个有多层的系统里，编码和解码可能在多个地方各自发生，彼此并不知情。一旦失去协调，数据就会在层与层之间被反复转换，偏离它本来的样子。
双重编码：最常见的祸根
最典型的故障是双重编码：一段内容被编码了一次，又在另一个环节被当作未编码内容再编码一次。结果，实体里的和号本身又被编码，页面上最终显示出的不是原本的符号，而是实体的字面字符。用户看到的是一串莫名其妙的 & 之类的东西。
双重编码往往源于"每一层都觉得自己该负责编码"。要避免它，就得明确编码只在一个确定的环节进行，其余各层都把数据当作"已就绪"来对待，不再重复处理。
该解码时没解码
反过来的问题同样常见：内容在某处被编码后，到了需要还原的环节却没有被正确解码。于是用户直接看到了实体的原始写法，而不是它代表的字符。这在数据经过多个系统转手、各自有不同的编码假设时尤其容易发生。
这类问题提醒我们：编码和解码必须成对出现、彼此呼应。在系统的每一道边界上，都要清楚地知道流入的数据是编码态还是原始态，并据此决定该不该解码。
编码态的数据不该进数据库
一个值得警惕的原则是：存进数据库的，应当是原始数据，而不是已经为 HTML 编码过的数据。如果你把编码态的内容存进去，那么这份数据就和"将来要显示成 HTML"这个假设绑死了。一旦它被用在别的场景——比如导出、发邮件、给另一个系统——就会带着不该有的实体字符。
更稳妥的做法是：数据库里始终保存干净的原始内容，编码只在它真正要输出到 HTML 的那一刻才进行。这样同一份数据可以安全地服务于各种不同的输出场景，而不会被某一种格式污染。
在正确的边界做正确的事
把上面的原则归纳起来，就是一句话：让每种转换都发生在它该发生的边界上。输入时把数据规范成干净的原始形式，存储时保持原始，输出到 HTML 时才编码，浏览器渲染时才解码。每一步各司其职，数据就能在整条链路里保持一致。
反之，如果编码解码散落在各处、没有清晰的边界，数据就会在不知不觉中被反复加工，最终谁也说不清它到底是什么状态。清晰的边界，是数据质量的保障。
编码不一致带来的乱码
除了实体层面的编码，字符编码本身的不一致也会破坏数据。如果数据在某一环节以错误的字符编码被读取或写入，多字节字符就会变成乱码。这和 HTML 实体问题叠加在一起时，排查起来格外令人头疼。
稳妥的做法是在整条链路上统一使用一致的字符编码，并在每道边界核对它。把字符编码的一致性和 HTML 实体的正确处理都照顾到，才能从根上避免那些难以追查的乱码。
把数据质量和安全一起守住
归根结底，HTML 编码解码既是安全问题，也是数据质量问题，两者其实同源：都要求你清楚地知道数据在每个环节处于什么状态、该做什么处理。存原始、输出时编码、渲染时解码、全程统一字符编码——这些纪律既挡住了注入攻击，也避免了数据被悄悄污染。
把编码和解码放在正确的边界、各发生恰当的次数，你的数据就能既安全又干净地走完它的整个生命周期，而不会在某个不起眼的环节被悄悄改变模样。