Question

当内容类型为;charset="utf-8"时，是否习惯忽略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

指定表单参数值如何编码的惯例是什么？

Answer 1

1）没有为此媒体类型定义charset参数。

2）有关编码指南，请参阅https://www.w3.org/TR/html5/sec-forms.html#application-x-www-form-urlencoded-encoding-algorithm。

Answer 2

注意：在上述链接的第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文档可能已被转码的字符编码。< / p>

请注意。一些较旧的用户代理使用接收文档的字符编码的字节来简单地处理HTML中的URI。一些较旧的HTML文档依赖于这种做法，并在转码时中断。想要处理这些旧文档的用户代理在收到包含合法集合之外的字符的URI时，应首先使用基于UTF-8的转换。只有当结果URI无法解析时，他们才会尝试根据接收文档的字符编码的字节构造URI。

请注意。基于UTF-8的相同转换应该应用于A元素的name属性的值。

application / x-www-form-urlencoded和charset =“utf-8”？

2 个答案: