utf-8 是否适合 text/plain mime 类型？答案

【问题标题】：Is it utf-8 suitable for text/plain mime type?utf-8 是否适合 text/plain mime 类型？
【发布时间】：2012-03-23 07:10:26
【问题描述】：

我正在通过文件导出数据。输出是base64编码的数据。

$data = base64_encode(serialize($data));

结果如下：

bGFzcyI6MTp7czo1OiJzZXR1cCI7YTo3Mzp7czoyNToicGFnZXNfY29udGFjdF91c19oZWFkbGlu

所以我想知道什么字符集更适合这个数据（纯文本）。 us-ascii 似乎足够了，但 utf-8 似乎总是一个防错默认值。

header('content-type: text/plain; charset=utf-8');

【问题讨论】：

你不应该在 text/plain 或 utf8 部分周围加上引号。
@quentin 谢谢。我真的不知道...
我仍然觉得接受的答案是错误的（即使我的答案被否决了）。我已经澄清了很多我的答案，需要重新考虑吗？
utf8 因为字符集无效，它是utf-8。见iana.org/assignments/character-sets/character-sets.xhtml

【解决方案1】：

真的没关系；您的内容是有效的US-ASCII、有效的UTF-8、有效的ISO-8859-1（或者，我相信任何 ISO-8859-x）、有效的Windows-1252，等等。只是不要输入UTF-16 或EBCDIC 之类的。

（对于它的价值，我会选择US-ASCII，因为即使是预Unicode 计算机也完全支持它，而不像ISO-8859-1 或诸如此类的那样明确地是预Unicode 字符集；但这确实是一个主观偏好。）

【讨论】：

某处有一个规范说您必须将字符集声明为正确描述它的最小字符集。因此，如果它是严格的 ASCII，则必须调用它而不是 ISO-8859-1 或 UTF-8，或者如果它是 Windows-1252 的 ISO-8859-1 子集，您也必须这样说。我认为这是针对电子邮件的，因此可能不适用于这种情况。
@tchrist：你是 90% 正确的。当前相关的 RFC（2046 和 2616）确实提出了该建议，但它们使用“应该”而不是“必须”，这在 RFC 中是一个有意义的区别。此外，有趣的是，RFC 2616 说“不标记实体优于使用标签 US-ASCII 或 ISO-8859-1 标记实体”，但恕我直言，在 ISO-8859-1 方面已经过时，因为许多用户代理现在无视标准假定默认字符集为 UTF-8。（而且我注意到 IETF 本身为某些页面提供 charset=ISO-8859-1。）但它可能仍适用于 US-ASCII。
但是即使它与 US-ASCII 兼容，也不能使它成为 US-ASCII :) 我澄清了我自己的答案，你仍然不同意吗？
@Evert：我从来没有真正不同意你的回答，我不知道为什么有人反对它；从理论上讲，此内容并不是真正的“文本”。但实际上，假装它是文本可能会有好处。例如，如果服务器将其作为文本提供，那么浏览器会将其呈现为文本，这对于复制和粘贴很有用。而且我猜测 OP 正在利用这些好处，否则他可能不会觉得需要对数据进行 Base64 编码。

【解决方案2】：

您实际上甚至不需要字符集。 'text/plain' 可能不正确，因为它也不是真正的文本。

即使它与 ascii、utf-8、latin1 兼容（如 ruakh 所述），您也应该将其视为二进制文件。

更新

我想澄清一下（在所有反对票之后，普通人给我一个机会！）

@dan04：UTF-8 是文本，我没说不是。 Base64 不是，base64 也是一种编码，但它可以编码任何二进制序列。 Base64 的编码方式可以将其包装在 US-ASCII 中（因此也可以使用 UTF-8 和 latin1 / ISO-8859）。

Base64 仍然只是一个二进制序列，而不是每个定义文本。相同范围的八位位组值被用作 US-ASCII（并且任何读取 US-ASCII 的东西都可以“打印”）这一事实并不能使其成为文本。

这也是为什么 Base64 没有自己的 mimetype 的原因。它被认为是一种内容传输编码。（查一下！）

因此，使用字符串包含的 mimetype 以及 Content-Transfer-Encoding 标头来提供 Base64 的实际正确方法。例如，如果您正在编码 jpeg，则这是正确的格式。

Content-Type: image/jpeg
Content-Transfer-Encoding: base64

这也是为什么我觉得如果你不想说字符串的内容（或者没有这个信息），最好把它当作'通用二进制'，例如：

Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

【讨论】：