许多文本警告将char 值作为整数处理是不可移植的，例如假设 'A' 的值为 65（如 ASCII）。
但是是什么决定了这个字符集是 ASCII（或扩展形式）还是其他字符集？是操作系统决定的，还是编译器决定的？我假设这不依赖于硬件。
例如，Intel PC 是否可以具有诸如 EBCDIC 之类的字符集（理论上）？在 Linux/Unix 中更改 LANG 环境变量是否会更改 C 程序的基本字符集的值（如果随后重新编译）？
（编辑：我现在看到 Linux 中的各种非拉丁字符集都具有相同的基本 ASCII 代码，例如 KOI8-U - 我假设存在与 ASCII 不兼容的字符集的变体）
【问题讨论】：
标准不关心任何这些细节，就它而言，只有“实现”。
在实践中，硬件和操作系统都可以指定该平台上的 C 实现预期使用的实现细节，或者如果它们想要与系统功能互操作，它们是必需使用的（也就是说，随操作系统或硬件提供的代码）。所以我们经常说，“在 Win32 上，sizeof(void*) == 4”。不过，这是一种简写，因为有人可以，如果他们愿意，编写一个在 32 位 Windows 上运行并具有不同指针大小的 C 实现。我们真正的意思是，“在 Win32 ABI 中，sizeof(void*) == 4 和在 Win32 上运行的不遵循 Win32 ABI 的 C 实现被排除在考虑之外”。
因此，实现可以做任何他们喜欢的事情，只要他们不介意他们是否可以（例如）使用遵循系统约定的 dll。可以根据编译器和标准库的编写者的喜好来定义字符集，仅受标准中的内容限制。
也就是说，字符文字的值是编译时常量。这告诉您基本执行字符集在运行时无法更改。
此外，如果它依赖于环境变量，那么确保程序以与编译时相同的值运行将是某人的责任。这对用户来说非常不友好，但该标准实际上并没有禁止某人编写对程序运行方式有特殊限制的 C 实现。
【讨论】：
isspace 可能无法工作。
int 的大小或char 的签名（顺便说一句，gcc 确实有一个选项）。它变成了一个“不同”的 C 实现。
C 标准是这样说的：
C99 中的§5.2.1/1
应定义两组字符及其相关的整理顺序： 写入了哪些源文件（源字符集），以及在 执行环境（执行字符集）。每组又分为一个 基本字符集，其内容由本节给出，以及一组零个或多个 特定于语言环境的成员（不是基本字符集的成员）称为 扩展字符。组合集也称为扩展字符集。这 执行字符集成员的值是实现定义的。
在启动时编译器必须使用 C 语言环境，它只会在调用setlocale(LC_ALL, ""); 时选择操作系统的语言环境。
【讨论】：
编译器清楚地确定使用哪个源和执行字符集，因为可能会发生交叉编译（例如，在使用 ASCII 的 Linux 机器上为使用 EBCDIC 的 IBM 大型机编译代码）。
【讨论】：