来自 RFC-3986，第 2.5 节：
当一个新的 URI 方案定义了一个表示由通用字符集 [UCS] 中的字符组成的文本数据的组件时，数据应首先根据 UTF-8 字符编码 [STD63] 编码为八位字节；那么只有那些与未保留集中的字符不对应的八位字节应该进行百分比编码。例如，字符 A 将表示为“A”，字符 LATIN CAPITAL LETTER A WITH GRAVE 将表示为“%C3%80”，字符 KATAKANA LETTER A 将表示为“%E3%82%A2 ”。
那么在这里对 Unicode 字符进行 URL 编码的正确方法是什么？人们断言 IRI 中的非 ASCII 符号应先转换为 UTF-8，然后再进行百分比编码。
但是我找到了一个带有application/x-www-form-urlencoded Content-Type 的示例教育网络表单，我尝试使用四种浏览器（Firefox、Chrome Opera、IE）用一些非 ASCII 符号填充它，并查看了 POST 查询我进入了wireshark。原来 %H1H2%H3H4...%HkHk+1 符号的编码是提交表单时表单页面的编码。
所以对于字母“Ж”，如果表单页面编码设置为 UTF-8，我会得到 %0D96 但是，如果我切换到 8 位 Windows-1251，我会得到 %C6，如果我切换到 CP-1252 我会得到得到 %26%231046，其中 %26 是 &，%23 是 #，因此，我得到 'Ж': Ж 的 xml Unicode 编号，因为 CP-1252 中没有这样的字母。
所以我的问题是为什么浏览器不首先将 IRI 转换为 UTF-8，尽管 URL RFC 似乎需要它？
也许，这是因为http://是一个旧的 URI 方案？来自https://en.wikipedia.org/wiki/Percent-encoding：
通用 URI 语法要求提供 URI 中字符数据表示的新 URI 方案实际上必须表示来自未保留集中的字符而无需翻译，并且应该根据 UTF-8 将所有其他字符转换为字节，然后百分比编码这些值。此要求是在 2005 年 1 月随 RFC 3986 的发布而引入的。在此日期之前引入的 URI 方案不受影响。
所以说：在此日期之前引入的 URI 方案不受影响。 但这似乎是一个蹩脚的解释。
此外，这里https://unspecified.wordpress.com/2008/07/08/browser-uri-encoding-the-best-we-can-do/一个人发现了和我一样的问题，这个人试图解释它这都是关于模糊的 HTML 规范的方式。但我仍然无法理解 HTML 标准是如何出现在这里的。无论如何，请求都是由浏览器发出的，浏览器应该生成正确的 URI。
感谢您的关注。