posix系统如何支持unicode？答案

【问题标题】：How posix system support unicode?posix系统如何支持unicode？
【发布时间】：2014-04-13 03:35:56
【问题描述】：

我见过很多 API posix 系统，例如 Linux & Mac & android，它们接受 const char* 作为文件路径的参数。

一个例子是dlopen，如文档所示，第一个参数是const char*，那么它是否支持Unicode文件路径，例如带有中文的路径？

【问题讨论】：

仅供参考：有多种 Unicode 编码：UTF-8，有利于交换和 Unix 系统上的所有内容，Windows 使用的 UTF-16 由于 baskwards-compatibility-constraints 和 UTF-32可以将每个 Unicode 代码点表示为一个恒定长度的单位。所有其他人都只对利基应用感兴趣。
@Deduplicator，我想包装一个跨平台的Unicode API，我不想考虑性能和内存使用，因为差异会很小。那么对于生产力和易用性，您对 UTF-8 或 UTF-32 的优缺点有何看法？
使用所有 UTF-8，这样的问题最少。即使在具有 UTF-16 API 的系统上，其他一切都是在 UTF-8 中完成的，所以无论如何你都不得不在那里进行转换。请确保您始终始终使用本机 Unicode API，也许使用专门的加宽/收窄转换器。 utf8everywhere.org

【解决方案1】：

POSIX 不需要支持 Unicode 文件名。（参见：https://stackoverflow.com/a/2306003/481267）但是，只要它们以 UTF-8 编码，支持 Unicode 就没有技术障碍。许多现代文件系统允许文件名中包含除\0 和/ 之外的任何字符。

POSIX API 处理以空字符结尾的字节序列，当字符串以 UTF-8 编码时，没有代码点的表示包含零字节。此外，所有超出 ASCII 范围 (0x00-0x7f) 的字符都完全使用设置了高位 (0x80-0xff) 的字节进行编码，因此系统不会误以为在一些 Unicode 字符的中间。

【讨论】：

当字符串以 UTF-8 编码时，NUL 编码为零字节。 RFC 3629 表示 UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 和 UTF8-1 = %x00-7F。您可能会想到像 variants 这样的 UTF-8，但它们明显不符合 NUL。
是的，对不起，我的意思是除了 NUL 本身之外的所有代码点。

【解决方案2】：

假设在现代 Linux/Unix 系统中，unicode 文件名以面向字节的 UTF-8 语言环境表示（尽管一些底层文件系统在内部以 UTF-16 存储文件名）。

【讨论】：