从这个优秀的“ UTF-8 all way through ”问题中，我读到了这个：
不幸的是，在尝试存储或在任何地方使用它之前，您应该验证每个提交的字符串都是有效的 UTF-8。PHP 的 mb_check_encoding() 可以解决问题，但您必须虔诚地使用它。确实没有办法解决这个问题，因为恶意客户端 可以以他们想要的任何编码提交数据，而且我还没有找到让 PHP 可靠地为您执行此操作的技巧。
现在，我仍在学习编码的怪癖，我想确切地知道恶意客户端可以做什么来滥用编码。一个人能实现什么？有人可以举个例子吗？假设我将用户输入保存到 MySQL 数据库中，或者我通过电子邮件发送，如果我不使用该mb_check_encoding功能，用户怎么会造成伤害？
如果我不使用 mb_check_encoding 功能，用户如何造成伤害？
这是关于过长的编码。
由于 UTF-8 设计的一个不幸的怪癖，如果使用简单的位打包解码器解析，可能会生成与更短的字节序列相同的字符 - 包括单个 ASCII 字符。
例如，字符<通常表示为字节 0x3C，但也可以使用超长的 UTF-8 序列 0xC0 0xBC（或者甚至更多冗余的 3 或 4 字节序列）来表示。
如果您采用此输入并在基于 Unicode 的基于字节的工具中处理它，则可能会避开该工具中使用的任何字符处理步骤。典型的例子是将 0x80 0xBC 提交给 PHP，它具有本机字节字符串。htmlspecialchars对字符进行 HTML 编码的典型用法在<这里会失败，因为预期的字节序列 0x3C 不存在。因此，脚本的输出仍将包含超长编码<，并且任何读取该输出的浏览器都可能读取序列 0x80 0xBC 0x73 0x63 0x72 0x69 0x70 0x74 <script，嘿 presto！跨站脚本。
Overlongs 从很久以前就被禁止，现代浏览器不再允许它们。但长期以来，这对 IE 和 Opera 来说都是一个真正的问题，并且不能保证未来每个浏览器都能解决这个问题。当然，这只是一个例子——任何面向字节的工具处理 Unicode 字符串的地方都可能遇到类似的问题。因此，最好的方法是在最早的输入阶段删除所有超长。
看起来这是一个复杂的攻击。检查文档以mb_check_encoding说明“无效编码攻击”。谷歌搜索“无效编码攻击”带来了一些有趣的结果，我将尝试解释。
当这种数据被发送到服务器时，它会执行一些解码来解释发送过来的字符。现在，服务器将进行一些安全检查，以查找某些可能有害的特殊字符的编码版本。
当无效编码被发送到服务器时，服务器仍然运行它的解码算法，它会评估无效编码。这就是问题发生的地方，因为安全检查可能不会寻找在通过解码算法运行时仍会产生有害字符的无效变体。
在 unix 系统上请求完整目录列表的攻击示例：
http://host/cgi-bin/bad.cgi?foo=..%c0%9v../bin/ls%20-al|
如果您想对算法中发生的事情进行更详细的技术解释，这里有一些链接：
http://www.cgisecurity.com/owasp/html/ch11s03.html#id2862815