.txt 现在预计会采用 UTF-8 编码吗？我必须以 .utf8 结尾吗？答案

【问题标题】：Is a .txt expected to be in UTF-8 encoding these days? Must I end it with .utf8?.txt 现在预计会采用 UTF-8 编码吗？我必须以 .utf8 结尾吗？
【发布时间】：2020-05-21 02:36:54
【问题描述】：

我正在生成纯文本文件。我不使用 ASCII/ANSI 而是 UTF-8 编码，因为年份是 2020 年而不是 1995 年。Unicode/UTF-8 现在已经非常成熟，假设这些天不支持 UTF-8 是很疯狂的。

同时，我有一种感觉，纯文本文件(.txt) 与ANSI/ASCII 编码相关联，因为它看起来很原始，它使用的编码也必须是原始的。

但是，我希望使用各种 Unicode 字符，而不仅限于基本的 ANSI/ASCII 字符。

由于纯文本没有像 HTML 那样的元数据，所以（我知道）没有办法告诉读者这个 .txt 使用 Unicode/UTF-8，而且据我所知，你不能 detect 它可靠，但必须做出“有根据的猜测”。

我之前看到有人在文本文件的末尾添加.utf8，但这似乎有点丑陋，我强烈质疑对此的广泛支持......

我应该这样做吗？

test.txt.utf8

每当 .txt 文件使用 UTF-8 时？还是只会让人们更难打开它们，而在将其检测为 UTF-8 方面没有任何实际好处？

【问题讨论】：

These days 实际上开始于 1995 年，当时 Windows NT、Java、Javascript 都支持原生 Unicode。 UTF8 与 US-ASCII 无法区分 - 这就是重点。它对前 127 个字符使用完全相同的字节和字符。 UTF16 和其他编码，确实有元数据 - 文件开头的 BOM
没有人将.utf8 放在文件末尾以将它们标记为 UTF8 - 事实上，这是我第一次看到有人提到这一点。而且我住在一个非英语国家，这意味着 Unicode 和代码页在 2000 年之前一直是个问题。utf8 扩展名也 nothing - 没有任何语言可以识别这一点，所以所有人都会像这样阅读它这是一个文本文件。许多语言/库将检测并使用 BOM（如果存在）。否则，他们将使用用户的偏好——在 Linux 上，他们将使用 LC_CTYPE、LANG 或 LC_ALL 中指定的编码。在 Windows 上，它是用户的区域设置。
鉴于 US-ASCII 和 UTF8 是相同的，UTF8 是语言和库的合理默认值，除非用户指定非 Unicode 代码页。 NET 的 StreamReader，例如 defaults to Encoding.UTF8。所以问题真的是——你需要阅读非英语、非 Unicode 文件吗？
@PanagiotisKanavos UTF-8 和 US-ASCII 完全不同。 ASCII 在代码点 127 之上未定义，UTF-8 使用这些字节以一种方式对字符进行编码，传统的 8 位编码（如 Latin-1 和 Windows 代码页 1252）使用这些字节使用不同的逻辑对完全不同的代码点进行编码。但我同意.txt 仍然是一个很好的约定，而且编码通常可以在 Windows 以外的许多平台上推断出来。

标签： unicode encoding utf-8 ascii plaintext

【解决方案1】：

您没有详细说明您生成的文本文件的用例，但实际上“告诉读者这个.txt使用Unicode/UTF-8的方式”是文本文件开头的Byte Order Mark .通过以实际字节表示的方式，它告诉阅读器使用哪种 Unicode 编码来读取文件。

来自Unicode FAQ：

Bytes           Encoding Form
00 00 FE FF     UTF-32, big-endian
FF FE 00 00     UTF-32, little-endian
FE FF           UTF-16, big-endian
FF FE           UTF-16, little-endian
EF BB BF        UTF-8

【讨论】：

很多软件不支持BOM。所以在实践中，它带来的问题比它解决的要多。
不必要的 BOM 的有用性和容忍度取决于平台。 Windows 受害者往往需要 BOM，并且发现它们即使在不需要时也很有用，而在其他平台上则相反。