个人 .txt 档案；utf-8 还是 utf-16？；需要中文和斯堪的纳维亚字符；表现无关

Question

因此，我保留的几乎所有信息都使用纯文本。这些文件已（或将要）与 OSX 和 Linux 上的 shell 脚本、emacs、vim、终端等一起使用。能够使用英文、中文和斯堪的纳维亚字符而不会感到头疼是最理想的。假设性能不是问题，但可移植性和互操作性是问题，utf-8 或 utf-16 是编码的最佳选择吗？如果没有明显更好的选择，那么相关的权衡是什么？

Answer 1

总结：首选UTF-8。

UTF-8 和 UTF-16 之间的差异很少。两者都可以编码 Unicode 支持的 1,112,064 中的任何代码点，并且从一个转换到另一个是微不足道的。主要区别在于程序的支持。

虽然几乎所有的文本编辑器都支持这两种编码，但首选 UTF-8，因为它在前 128 个字节中与 ASCII 兼容——换句话说，#!/usr/bin/env bash两者是相同的；这意味着可以在不修改操作系统或各种解释器的情况下以 UTF-8 编写 shell 脚本。（不过，请务必禁用 UTF-8 中的“字节顺序标记”功能。）

在 Linux 上，大多数程序使用glibc语言环境来决定字符集，UTF-8 是唯一的选择（除了传统字符集）并且根本不支持 UTF-16。

一个细微的区别是存储所需的空间。UTF-8 是可变长度的，使用一到四个字节，而 UTF-16 使用两个字节为单位。如果文本主要使用拉丁字母表，偶尔使用斯堪的纳维亚字符，那么 UTF-16 将使用两倍于 UTF-8 的空间，因为后者可以将拉丁字符表示为单个 ASCII 字节，偶尔使用两个或三个- 字节序列。另一方面，如果文本主要是中文，UTF-8 将需要三个字节的序列来表示每个字符，导致文件比 UTF-16 大 33%。然而，对于文本文件，考虑到 TB 大小的磁盘，这非常微不足道。

但是，在 UTF-16 中使用两字节“代码单元”也是一个缺点：编码需要同时支持“大端”和“小端”字节顺序；这两个54 00 6f 00 72 00和00 54 00 6f 00 72是等价的。这意味着程序需要同时支持两者，并尝试猜测给定文件中使用的字节顺序。54 00可能意味着这两个U + 0054或U + 5400，所以包括BOM -字节顺序标记-通常是一个必要的（ff fe可能只意味着U + FEFF，从来没有U + FFFE）。如果丢失了一个字节，则文档的其余部分将变得不同步。UTF-8 避免了所有这些问题。

不过，最终，Unicode 编码器之间的转换很便宜：这iconv -f utf16 -t utf8就是您所需要的。

另请参阅UTF-8 – 与Wikipedia上的 UTF-16或来自贝尔实验室的原始 UTF-8 文档进行比较。