让我困惑的是 HTTP 标头值的解码。
示例标题：Some-Header: "quoted string?"; *utf-8'en'Weirdness
标题值的可以被引用吗？ " 本身的编码呢？ ' 是有效的引号字符吗？分号 (;) 有什么意义？ HTTP 标头的值解析器是否可以被视为 MIME 解析器？
我正在制作一个透明代理，它需要透明地处理和修改许多 in-the-wild 标头字段。这就是为什么我需要如此详细的格式。
【问题讨论】：
标签： unicode http-headers mime quoting
可以引用标题值吗？
如果您的意思是 RFC 5987 parameter 生产适用于标头值的主要部分，那么不。
Some-Header: "foo"; bar*=utf-8'en'bof
这里标头值的主要部分可能是"foo"，包括引号，但是...
分号 (;) 有什么意义？
为每个命名的标头分别定义特定的处理。所以分号对于Content-Disposition 很重要，但对于Content-Length 则不重要。
显然这不是一个非常令人满意的解决方案，但这就是我们坚持的问题。
我正在制作一个透明代理，它需要透明地处理和修改许多 in-the-wild 标头字段。
您不能以通用的方式处理这些，您必须知道每个可能的标题的形式。对于您不认识的任何内容，请不要尝试分解标头值；真的，目前支持 RFC 5987 的东西很少，你不太可能对它做很多有用的处理。
目前的现状是，标头值中的非 ASCII 字符不能很好地跨浏览器使用，无论是编码的还是原始的。
幸运的是，它们很少需要。唯一真正常见的用例是 Content-Disposition 的非 ASCII 文件名，但通过将文件名放在结尾的 URL 路径部分中更容易解决。
HTTP 标头的值解析器是否可以视为 MIME 解析器？
没有。 HTTP 大量借鉴了 MIME 和 RFC 822 系列标准，但它不是 822 系列的一部分。它有自己的低级标题语法，看起来像 822，但不太兼容。任意 MIME 功能不能在 HTTP 中使用，必须有一种标准化机制将它们显式拖入 HTTP — 这就是 RFC 5987 的内容，用于（部分）RFC 2231。
（有关其他一些差异的讨论，请参阅 RFC 2616 的第 19.4 节。）
理论上，multipart 表单提交是 822 系列的一部分，您应该能够在那里使用 RFC 2231 编码。但现实情况是浏览器也不支持。
【讨论】：