从这个优秀的“ UTF-8，一路过关斩将 ”的问题，我读到这样的：
不幸的是，你应该检查每个提交的字符串为有效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×69 0x70 0x74为<script和变戏法似的！ XSS。
因为回来的路上Overlongs已被取缔，现代的浏览器不再允许他们。 但是，这是对IE和Opera一个真正的问题很长一段时间，而且也不能保证每一个浏览器是会得到它的权利在未来。 当然，这仅仅是一个例子 - 在面向字节的工具处理你可能有类似的问题Unicode字符串的任何地方。 最好的方法，因此，是在最早输入相以除去所有overlongs。
看起来这是一个复杂的攻击。 检查文档的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
http://www.cgisecurity.com/fingerprinting-port-80-attacks-a-look-into-web-server-and-web-application-attack-signatures.html
