因此，我保存的几乎所有信息都使用纯文本。这些文件在 OSX 和 Linux 上与 shell 脚本、emacs、vim、终端等一起使用（或将使用）。能够使用英文、中文和斯堪的纳维亚字符，并且不会带来太多麻烦，这才是理想的。假设性能不是问题，但可移植性和互操作性是问题，utf-8 或 utf-16 是否是最佳的编码替代方案？如果没有明显更好的选择，那么相关的权衡是什么？
答案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 – 与 UTF-16 相比在维基百科上，或者原始 UTF-8 文档来自贝尔实验室。