【问题标题】:application/x-www-form-urlencoded and charset="utf-8"?应用程序/x-www-form-urlencoded 和 charset="utf-8"?
【发布时间】:2013-05-29 16:39:11
【问题描述】:

Content-type 为application/x-www-form-urlencoded 时是否习惯省略;charset="utf-8"

特别是,当在表单标签中使用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

指定表单参数值如何编码的约定是什么?

【问题讨论】:

    标签: forms http post encoding utf-8


    【解决方案1】:
    1. 没有为此媒体类型定义字符集参数。

    2. 有关编码指南,请参阅https://url.spec.whatwg.org/#application/x-www-form-urlencoded

    application/x-www-form-urlencoded 标准意味着 UTF-8 和百分比编码。

    虽然:

    一个遗留的面向服务器的实现可能必须支持 UTF-8 以外的编码以及对元组的特殊逻辑 名称为_charset。这种逻辑在此不作仅描述 UTF-8 符合标准。

    【讨论】:

    • 哦,我不知道的有趣的花絮:“如果条目的名称是“_charset_”并且它的类型是“隐藏”,则将其值替换为字符集。”
    • 请注意,您正在链接到 HTML 5 规范,但有问题的 HTML 使用的是 HTML 4。这是 HTML 4 的表单提交算法:w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13,虽然它没有讨论字符集处理。
    • Remy:文档类型不会影响浏览器在表单编码方面的操作。
    【解决方案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 文档可能已转码到的字符编码。

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

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-01-19
      • 2016-02-21
      • 2020-04-13
      • 2013-11-10
      • 1970-01-01
      • 1970-01-01
      • 2014-05-19
      • 2011-04-29
      相关资源
      最近更新 更多