我知道 Linux 文件系统将文件名存储为字节序列，这意味着独立于 Unicode 编码。
但是，UTF-8 或增强型 UTF-8 以外的编码可能会很好地使用 0 字节作为可以出现在文件名中的 Unicode 字符的多字节表示的一部分。在 Linux 文件系统 C 代码中，到处都是以 0 字节终止字符串。那么 Linux 文件系统是如何支持 Unicode 的呢？它是否假定所有创建文件名的应用程序仅使用 UTF-8？但事实并非如此，对吗？
类似地，shell(例如 bash)在模式中使用 * 来匹配任意数量的文件名字符。我可以在 shell C 代码中看到它只是将 ASCII 字节用于 * 并逐字节地分隔匹配项。对于 UTF-8 编码的名称很好，因为它具有这样的属性，如果您采用字符串的字节表示，然后从开头匹配一些字节与 *，并将其余字节与另一个字符串匹配，然后开头的字节实际上匹配了一串完整的字符，而不仅仅是字节。
但是其他编码没有那个属性，是吗？那么，shell 是否采用 UTF-8？
最佳答案
确实，UTF-16 和其他“宽字符”编码不能用于 Linux 中的路径名(也不能用于任何其他兼容 POSIX 的操作系统)。
原则上不任何人都假定 UTF-8 是正确的，尽管随着其他编码的消失，这在未来可能会成为正确的。 Unix 风格的程序采用的是一种ASCII 兼容 编码。具有这些属性的任何编码都是 ASCII 兼容的:
- 编码的基本单位是字节，而不是更大的实体。某些字符可能被编码为字节的序列，但必须至少有 127 个字符仅使用单个字节进行编码，即:
- ASCII 定义的字符(如今，最好将这些描述为 Unicode 代码点 U+000000 到 U+00007F，包括在内)被编码为单个字节，其值等于它们的 Unicode 代码点。
- 相反，值为 0x00 到 0x7F 的字节必须始终解码为 ASCII 定义的字符，而不管周围的上下文。 (例如，字符串 0x81 0x2F 必须解码为两个字符，无论 0x81 解码为什么，然后是
/。)
UTF-8 与 ASCII 兼容，但所有 ISO-8859-n 页面也是如此，EUC编码，还有很多很多其他的。
一些程序可能还需要一个额外的属性:
- 一个字符的编码，被视为一个字节序列，既不是任何其他字符编码的正确前缀也不是正确后缀。
UTF-8 有这个属性，但(我认为)EUC-JP 没有。
也是许多“Unix 风格”程序保留代码点 U+000000 (NUL) 用作字符串终止符的情况。这在技术上不是对编码的约束，而是对文本本身的约束。 (字节 0x00 不出现在字符串中间的密切相关要求是此加上要求 0x00 映射到 U+000000 而不管周围上下文的结果。)
关于linux - Linux shell 和文件系统如何识别 Unicode？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38948141/