我有一个网站告诉输出是 UTF-8，但我从不确保它是。我应该使用正则表达式或 Iconv 库将 UTF-8 转换为 UTF-8（留下无效序列）吗？如果我不这样做，这是一个安全问题吗？
【问题讨论】：
首先，我永远不会盲目地将其编码为 UTF-8（可能）第二次，因为这会导致您所说的无效字符。在尝试这样的事情之前，我肯定会尝试检测内容的字符集是否是 not UTF-8。
其次，如果有问题的内容来自您可以控制和控制字符集的来源，例如表和连接中使用 UTF-8 的文件或使用 UTF-8 的数据库，我会相信这个来源，除非有什么东西给我暗示我做不到，并且发生了一些奇怪的事情。如果内容来自您无法控制的或多或少的随机位置，则更有理由对其进行检查，并且如果您可以检测到它，可能会尝试从其他字符集重新编码 og 转换。所以底线是：这取决于。
至于这是否是一个安全问题，我不这么认为（至少我想不出任何可以利用它的场景），但我会留给其他人来确定这一点。
【讨论】：
不是安全问题，但如果您发送无效的 UTF-8 字节流，您的用户（尤其是不会说英语的用户）会非常恼火。
在最好的情况下（大多数浏览器都会这样做），所有无效字符串都会消失或显示为乱码。最坏的情况是浏览器退出解释您的页面并说诸如“无效编码”之类的内容。例如，Linux 上的某些文本编辑器（即 gedit）就是这样做的。
好的，保持现实：如果您有一个以英语为中心的网站，而不严重依赖某些数学字符或 Unicode 箭头，那几乎没有什么区别。但是如果你服务于，例如，一个中文网站，你就完全可以搞砸了。
干杯，
【讨论】：
每个人的字符集都搞砸了，所以通常你不能相信任何外部来源。验证提供的输入对于它声称使用的字符集确实有效是一种很好的做法。幸运的是，使用 UTF-8，您可以对有效性做出相当安全的断言。
【讨论】：
如果用户可以发送任意字节，那么是的，不确保有效的 utf8 输出存在安全隐患。但是，根据您存储数据的方式，不确保 input 上的有效 utf8 数据也存在安全隐患（例如，可以创建与 utf8 输入一起使用的 this SQL injection attack 的变体utf8 被允许是无效的 utf8），所以你真的应该使用iconv 在输入上将 utf8 转换为 utf8，并避免在输出上验证 utf8 的整个问题。
您要检查输出是否为有效 utf-8 的两个主要安全原因是避免“过长”字节序列 - 即表示某些字符（如 '<' 但编码为多个字节 - 并避免无效的字节序列。编码过长的问题很明显 - 如果您的过滤器将“<”更改为“<”，它可能不会转换表示“<”但写法不同的序列。请注意，所有当前的浏览器都会将过长的序列标记为无效，但有些人可能正在使用旧浏览器。
无效序列的问题是某些 utf-8 解析器将允许无效序列吃掉无效序列后面的一些有效字节。同样，如果每个人都使用当前浏览器，这不是问题，但是...
【讨论】：