来自RFC-3986，第2.5节：
当新的URI方案定义表示文本数据的组件时 由通用字符集[UCS]中的字符组成 首先应根据UTF-8将数据编码为八位字节 字符编码[STD63];然后只有那些没有的八位字节 对应于未保留集中的字符应为百分比 - 编码。例如，字符A将表示为“A”， 将代表拉丁文大写字母A WITH GRAVE 作为“％C3％80”，将代表角色KATAKANA LETTER A. 为“％E3％82％A2”。
所以这里What is the proper way to URL encode Unicode characters?人们声称IRI中的非ASCII符号应该在编码它们之前先转换为UTF-8。
但是我找到了一个带有 application / x-www-form-urlencoded Content-Type的教育网页样本，我试图用四个浏览器填充一些非ASCII符号（Firefox，Chrome） Opera，IE）并查看了我在wireshark中获得的POST查询。事实证明，％H1H2％H3H4 ...％HkHk + 1符号的编码是提交表单时表单页面的编码。
因此对于字母'Ж'，如果表单页面编码设置为UTF-8，我得到％0D96但是，如果我切换到8位Windows-1251，我得到％C6并且如果我切换到CP -1252我得到％26％231046其中％26是＆amp;，％23是＃，因此，我得到xml Unicode编号'Ж'：＆amp;＃1046，因为CP-1252中没有这样的字母。< / p>
所以我的问题是为什么浏览器不会首先将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。
感谢您的关注。