字符集和“首选 MIME 名称”

Question

HTTP

Accept-Encoding

标头包含可接受字符集的原子，而 MIME

charset=

标头中的

Content-Type

字段包含以下数据的字符集的原子。

我的问题如下：这些原子必须匹配首选的 MIME 编码名称或字符集名称，还是它们可以匹配字符集的任何别名？

使用的别名和首选 MIME 编码 http://www.iana.org/assignments/character-sets.

我计划使用 iconv 转换为平台原生宽 UTF，我不想以 (iconv_alias, { list-of-aliases }) 形式的字段数组形式输入每个字符集。相反，一个简单的（别名，iconv_alias）二元组。

Answer 1

是的，这些原子必须 IMO 匹配首选的 MIME 字符集名称，而不仅仅是任何别名。 解释。 我很惊讶地看到谷歌“MIME 字符集列表”返回的内容比您在 2011 年提到的来自 IANA 的http://www.iana.org/assignments/character-sets“字符集”页面更清晰或更有用那似乎仍然是最好的。该页面上的 Ctrl+F“MIME”仅返回一个命中：“首选 MIME 名称”，这是您和我正在寻找的专栏的标题：实际使用的字符集名称列表，数量非常少异常或错误，在全球每天发送的 350 万亿（即数百万）封电子邮件中。这种高水平的合规性因此在如此庞大的数字上具有可靠性，这归功于 IMO 的电子邮件系统及其实际规范 MIME 从一开始就得到了仔细的关注和智能的实施，从而产生了两个基本特征：

• 字符集在每个文档中仅声明一次，即在每封电子邮件的 MIME 标头中，大多数人都忽略了它的存在，因为它不会引起问题
• 允许的字符集名称列表显然是简短的、可靠的、不变的，没有人会偏离它。 以下是一些：

us-ascii

iso-8859-1（最初是网标）

utf-8（现在的实际标准）

转换日标

EUC

ISO-2022-JP

...

网页在字符集方面没有得到可靠的处理，IMO 有两个主要原因：

• 每天只创建 120 亿个网页（比电子邮件消息少 3,000 倍），因此对此给予的关注较新（网页自 1993 年以来才存在，即 1971 年电子邮件后 22 年），而且相对而言，要小得多
• 在每个网页中，许多设置在两个不同的地方和上下文中说明，HTML 标头（多个但对应于电子邮件的单个 mime 标头）但也在文档内部多次。在数百万甚至数十亿的作家群中，这不可避免地会带来很多误解、分歧、困惑、犹豫、不相容，甚至错误。

我的主张从何而来：

1. 是的，我们都应该只使用已经广泛使用的 IANA“首选 MIME 名称”
2. 最重要的标准化机构，AFAIK IANA 和 IETF 在这个问题上，可以收集并建立一个独特的文件和列表，精心设计，从上面的当前 IANA 列表开始，但更清晰和更短，并将其声明为规范，广泛传播所以每个人都知道。

注意。这是一个很大的问题，因为 UTF-8 是在 1980-90 年代出于政治原因而被强加的，而且还有许多明显的技术和人为原因。稍后会详细介绍。同时，UTF-8 对英语没有任何好处或坏处，对欧洲语言也没什么坏处，但对其他语言（如阿拉伯语和亚洲语言）却带来很多复杂性，有时甚至是其他语言（如西里尔语）。 凡尔赛宫，2023 年 4 月 27 日星期四 18:12:10 +0200，编辑（打字错误）18h16m20