Eri*_*ikR 28 forms post encoding http utf-8
;charset="utf-8"在Content-type是application/x-www-form-urlencoded什么时,是否习惯于省略？
特别是,当accept-charset="utf-8"在表单标签中使用时,我希望有一些迹象表明utf-8正在标题中使用,但我没有看到任何.
这是我在Chrome中的简单测试.表单页面是:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
</head>
<body>
<form method="POST" action="printenv.cgi" accept-charset="utf-8">
Your name:
<input name="name" type="text" size="30">
</form>
</body>
</html>
生成的请求的标头是:
POST /printenv.cgi HTTP/1.1
Host: ...:8000
Connection: keep-alive
Content-Length: 19
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Origin: http://...:8000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://...:8000/utf8-test.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
指定表单参数值如何编码的惯例是什么？
Jul*_*hke 28
1)没有为此媒体类型定义charset参数.
2)有关编码指南,请参阅https://www.w3.org/TR/html5/sec-forms.html#application-x-www-form-urlencoded-encoding-algorithm.
注意：在上面链接的第 2 步中，它说：“否则，让选定的字符编码为UTF-8。” （参见：http : //www.w3.org/TR/html5/forms.html#application/x-www-form-urlencoded-encoding-algorithm。）
我也相信这似乎表明用户代理使用 UTF-8 是最佳实践？
http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars
它是这样说的：B.2.1 URI 属性值中的非 ASCII 字符
尽管 URI 不包含非 ASCII 值（参见 [URI]，第 2.1 节），作者有时会在需要 URI 的属性值中指定它们（即，在 DTD 中使用 %URI 定义）。例如，以下 href 值是非法的：
...
我们建议用户代理在这种情况下采用以下约定来处理非 ASCII 字符：
Represent each character in UTF-8 (see [RFC2279]) as one or more bytes.
Escape these bytes with the URI escaping mechanism (i.e., by converting each byte to %HH, where HH is the hexadecimal notation of the byte value).
这个过程产生一个语法上合法的 URI（定义在 [RFC1738]，第 2.2 节或 [RFC2141]，第 2 节），它独立于携带 URI 的 HTML 文档可能已被转码成的字符编码。
笔记。一些较旧的用户代理使用接收文档的字符编码字节简单地处理 HTML 中的 URI。一些较旧的 HTML 文档依赖于这种做法，并且在转码时会中断。想要处理这些旧文档的用户代理应该在收到包含合法集之外的字符的 URI 时，首先使用基于 UTF-8 的转换。只有当结果 URI 无法解析时，他们才应尝试根据接收文档的字符编码的字节构建 URI。
笔记。应将基于 UTF-8 的相同转换应用于 A 元素的 name 属性值。