c++ - 为什么 C11 或 C++11 中没有 ASCII 或 UTF-8 字 rune 字？

Question

为什么即使有 UTF-8 字符串文字，C11 或 C++11 中也没有 UTF-8 字 rune 字？我知道，一般来说，字 rune 字表示单个 ASCII 字符，它与单字节 UTF-8 代码点相同，但 C 和 C++ 都没有说编码必须是 ASCII。

基本上，如果我阅读标准正确，则不能保证 '0' 将表示整数 0x30，但 u8"0" 必须表示字符序列 0x30 0x00。

编辑:

我知道并非每个 UTF-8 代码点都适合一个字符。这样的文字仅对单八位字节代码点(又名 ASCII)有用，所以我想称它为“ASCII 字 rune 字”会更合适，所以问题仍然存在。我只是选择用 UTF-8 来构建问题，因为有 UTF-8 字符串文字。我能想象到可移植地保证 ASCII 值的唯一方法是为每个字符编写一个常量，考虑到只有 128 个字符，这还不错，但仍然......

Answer 1

编写不可移植的 C 代码是完全可以接受的，这是这样做的众多充分理由之一。随意假设您的系统使用 ASCII 或其某些超集，并警告您的用户不要尝试在 EBCDIC 系统上运行您的程序。

如果您觉得非常慷慨，您可以对支票进行编码。 gperf 程序可以生成包含此类检查的代码。

_Static_assert('0' == 48, "must be ASCII-compatible");

或者，对于 C11 之前的编译器，

extern int must_be_ascii_compatible['0' == 48 ? 1 : -1];

如果您在 C11 上，则可以在字符常量上使用 u 或 U 前缀，但不能使用 u8 前缀...

/* This is useless, doesn't do what you want... */
_Static_assert(0, "this code is broken everywhere");
if (c == '々') ...

/* This works as long as wchar_t is UTF-16 or UTF-32 or UCS-2... */
/* Note: you shouldn't be using wchar_t, though... */
_Static_assert(__STDC_ISO_10646__, "wchar_t must be some form of Unicode");
if (c == L'々') ...

/* This works as long as char16_t is UTF-16 or UCS-2... */
_Static_assert(__STDC_UTF_16__, "char16_t must be UTF-16");
if (c == u'々') ...

/* This works as long as char32_t is UTF-32... */
_Static_assert(__STDC_UTF_32__, "char32_t must be UTF-32");
if (c == U'々') ...

有一些项目是用非常便携的 C 语言编写的，并且已经移植到非 ASCII 系统 (example)。这需要大量的移植工作，除非您知道要在 EBCDIC 系统上运行您的代码，否则没有真正的理由去做。

关于标准:编写 C 标准的人必须应对所有可能的 C 实现，包括一些非常奇怪的实现。在已知的系统中 sizeof(char) == sizeof(long), CHAR_BIT != 8，整数类型有陷阱表示，sizeof(void *) ! = sizeof(int *), sizeof(void *) != sizeof(void (*)()), va_list 是堆分配的，等等。这是一场噩梦。

不要自责尝试编写将在您从未听说过的系统上运行的代码，也不要在 C 标准中苦苦寻找保证。

例如，就C标准而言，以下是malloc的有效实现:

void *malloc(void) { return NULL; }

请注意，虽然 u8"..." 常量保证为 UTF-8，但 u"..." 和 U"... " 除了编码分别为每个字符 16 位和 32 位之外，没有任何保证，并且实际编码必须由实现记录。

总结:在 2012 年假设 ASCII 兼容是安全的。