我刚刚修改了我的Encoding::FixLatin Perl模块来处理超长的UTF-8字节序列并将它们转换为最短的正常形式。
我的问题很简单“这是一个坏主意”？
许多来源（包括this RFC）表明，任何超长的UTF-8都应被视为错误并被拒绝。他们警告不要“天真的实施”，并让我觉得这些事情本质上是不安全的。
由于我的模块的整个目的是用混合编码清理凌乱的数据文件并将它们转换为漂亮干净的utf8，这似乎只是我可以清理的一件事，因此应用程序层不必处理它。我的代码并不关心结果字符可能具有的任何语义含义，它只是将它们转换为标准化形式。
我错过了什么。我没有考虑过隐藏的危险吗？
答案 0 :(得分：4)
是的，这是一个坏主意。
可能会检查其中一个混乱数据文件中的某些数据，看它是否包含危险的ASCII字符序列。
导致许多问题的规范示例：'\xC0\xBCscript>'。将过长的序列“修复”为纯ASCII <并且您不小心创建了一个安全漏洞。
任何工具都没有为任何合法目的生成过关。如果您正在尝试修复混合编码文件，则应考虑将其中一个视为错误猜测编码的标志。
答案 1 :(得分：2)
从安全性或可用性的角度来看，我认为这不是一个坏主意。
从安全角度来看，您应该在使用前清理用户输入。因此，您可以运行清理例程，然后确保数据在打印之前不包含大于/小于符号<>。您还应该确保在将mysql_real_escape_string（）插入数据库之前调用它。请记住，当您不使用mysql_real_escape_string（）时，语言编码问题（如GBK vs Latin1）可能会导致sql注入。 （无论您的平台特定的mysql库绑定如何，此函数名称应非常相似）
清理所有用户输入通常是一个糟糕的主意，因为您不知道如何使用特定变量。例如，sql注入和xss具有非常不同的控制字符，并且两者的相同敏感性经常导致漏洞。
答案 2 :(得分：1)
但是，我不知道你的场景中是不是一个坏主意，因为这种变化不是双射的，可能会导致数据丢失。
如果您错误地检测到数据的编码，您可能会将数据解释为合法的UTF-8保留，并以最短的正常形式更改它们。以后无法检索原始数据。
作为一种个人经历，我知道当这些事情发生时，他们会这样做，你可能会在为时已晚之前没有注意到错误......