gio*_*ele 6 character-encoding compatibility posix unicode locale
C 语言环境被定义为使用 ASCII 字符集，而 POSIX 不提供一种在不更改语言环境的情况下使用字符集的方法。
如果将 C 的编码改为 UTF-8 会发生什么？
积极的一面是 UTF-8 将成为任何进程的默认字符集，甚至是系统守护进程。显然，有些应用程序会中断，因为它们假定 C 使用 7 位 ASCII。但这些应用真的存在吗？现在很多编写的代码在一定程度上是语言环境和字符集感知的，我会惊讶地看到只能处理 7 位干净输入的代码并且不能轻易适应接受支持 UTF-8 的 C .
C 语言环境不是默认语言环境。这是一个保证不会导致任何“令人惊讶”行为的语言环境。许多命令在或语言环境中具有保证形式（例如ps或df标题、date格式）的输出。对于编码 ( )，保证只包含 ASCII 字母，依此类推。如果区域设置被修改，这会导致许多应用程序行为不端。例如，他们可能会拒绝无效的 UTF-8 输入，而不是将其视为二进制数据。CPOSIXLC_CTYPE[:alpha:]C
如果您希望系统上的所有程序都使用 UTF-8，请将默认语言环境设置为 UTF-8。所有操作单一编码的程序，即。一些程序只操作字节流而不关心编码。一些程序处理多种编码并且不关心区域设置（例如，Web 服务器或 Web 客户端设置或读取标头中每个连接的编码）。
你有点困惑，我想。“C 语言环境”与任何其他语言环境一样，正如您指出的那样，它通常是 7 位 ASCII 的同义词。
它内置于 C 库中，我想因此该库具有某种后备功能——不能没有语言环境。
然而，这与从 C 代码构建的程序如何处理输入没有任何关系。语言环境用于转换传递给可执行文件的输入，如果系统语言环境是 UTF-8，则 UTF-8 是程序获得的，无论其源代码是用 C 还是其他语言编写的。所以：
我会惊讶地看到只能处理 7 位干净输入并且不能轻易适应接受支持 UTF-8 的 C 的代码
没有意义。从标准输入读取的最小标准 C 源代码从系统接收字节流。如果系统使用 UTF-8 并且它从某些 HID 硬件生成流，则该流可能包含 UTF-8 编码字符。如果它来自其他地方（例如，网络、文件），它可能包含任何内容，这就是假设UTF-8 标准有用的原因。
C 语言环境是一个比 UTF-8 语言环境更受限制的字符集这一事实与此无关。它只是被称为“C 语言环境”，但实际上它与编写 C 代码没有任何关系。
事实上，您可以将 UTF-8 字符硬编码为源代码中的 c 字符串。假设系统是 UTF-8，这些字符串在被生成的可执行文件使用时看起来是正确的。
您在评论中发布的“Roger Leigh”链接我相信是指使用扩展集（UTF-8）作为用于嵌入式环境的 C 库中的 C 语言环境，因此无需为系统加载其他语言环境处理UTF-8。
所以这个问题的答案，“如果 C 语言环境是 UTF-8 而不是 ASCII 会破坏什么？” 是，我猜，没有什么，但在嵌入式环境之外，等等。没有太多需要这样做。但是很可能它会在某个时候成为诸如 GNU C 之类的库的规范（我认为也可能是）。