c++ - C11 & C++11 扩展和通用字符转义

Question

上下文

C11 和 C++11 都支持源文件中的扩展字符以及通用字符名称 (UCN)，这允许人们仅使用基本源字符集中的字符来输入不在基本源字符集中的字符。

C++11 还定义了编译的几个翻译阶段。特别是，扩展字符在翻译的第一阶段被规范化为 UCN，如下所述:

§ C++11 2.2p1.1:

Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary. The set of physical source file characters accepted is implementation-defined. Trigraph sequences (2.4) are replaced by corresponding single-character internal representations. Any source file character not in the basic source character set (2.3) is replaced by the universal-character-name that designates that character. (An implementation may use any internal encoding, so long as an actual extended character encountered in the source file, and the same extended character expressed in the source file as a universal-character-name (i.e., using the \uXXXX notation), are handled equivalently except where this replacement is reverted in a raw string literal.)

---

问题

因此，我的问题是:

Does a Standard-conforming compilation of the program

#include <stdio.h>

int main(void){
        printf("\é\n");
        printf("\\u00e9\n");
        return 0;
}

fail, compile and print

é
é

or compile and print

\u00e9
\u00e9

, when run?

---

知情的个人意见

我认为答案是它成功编译并打印了 \u00e9，因为根据上面的 §2.2p1.1，我们有

实现可以使用任何内部编码，只要在源文件中遇到实际的扩展字符，并且在源文件中将相同的扩展字符表示为通用字符-character-name(即，使用\uXXXX 表示法)，被等效地处理，除非此替换在原始字符串文字中恢复。，而且我们不在原始字符串文字中。

接下来是

• 在第 1 阶段，printf("\é\n"); 映射到 printf("\\u00e9\n");。
• 在第 3 阶段，源文件被分解为预处理标记(§2.2p1.3)，其中string-literal "\\u00e9\n" 是一个。
• 在第 5 阶段，字 rune 字或字符串文字中的每个源字符集成员，以及字 rune 字或非原始字符串文字中的每个转义序列和通用字符名称都被转换执行字符集的相应成员 (§2.2p1.5)。因此，根据最大蒙克原则，\\ 映射到 \，片段 u00e9 不被识别为 UCN，因此按原样打印.

实验

不幸的是，现存的编译器不同意我的观点。我已经使用 GCC 4.8.2 和 Clang 3.5 进行了测试，这是他们给我的:

• 海湾合作委员会 4.8.2

  $ g++ -std=c++11  -Wall -Wextra ucn.cpp -o ucn
  ucn.cpp: In function 'int main()':
  ucn.cpp:4:9: warning: unknown escape sequence: '\303' [enabled by default]
    printf("\é\n");
           ^
  $ ./ucn
  é
  \u00e9
  

• clang 3.5

  $ clang++ -std=c++11  -Wall -Wextra ucn.cpp -o ucn
  ucn.cpp:4:10: warning: unknown escape sequence '\xFFFFFFC3' [-Wunknown-escape-sequence]
          printf("\é\n");
                  ^
  ucn.cpp:4:12: warning: illegal character encoding in string literal [-Winvalid-source-encoding]
          printf("\é\n");
                   ^
  2 warnings generated.
  $ ./ucn
  é
  \u00e9
  

我使用 hexdump -C ucn.cpp 对 é 字符显示为 C3 A9 进行了双重和三次检查，一致使用预期的 UTF-8 编码。我还验证了普通的 printf("é\n"); 或 printf("\u00e9\n"); 可以完美地工作，所以这不是测试的编译器无法读取 UTF-8 源文件的问题。

谁是对的？

Answer 1

'é' 不是字符串文字中反斜杠转义的有效字符，因此反斜杠后跟 'é' 作为文字源字符或 UCN 应该会产生编译器诊断和未定义的行为。

但是请注意，"\\u00e9" 不是以反斜杠开头的 UCN，并且不可能在字符串或字 rune 字中写入任何基本源字符序列一个反斜杠后跟一个 UCN。因此 "\é" 和 "\\u00e9" 不需要表现相同: "\\u00e9" 的行为可以是完美定义，而 "\é" 的行为未定义。

如果我们假设一些允许反斜杠转义 UCN 的语法，比如说 "\«\u00e9»"，那么这将具有未定义的行为，如 "\é".

---

• In Phase 1, printf("\é\n"); maps to printf("\\u00e9\n");.

é 到 UCN 的第一阶段转换不能创建非 UCN，例如 "\\u00e9"。

---

编译器是对的，但并没有专门用完美的诊断消息来处理这种情况。理想情况下，您会得到:

$ clang++ -std=c++11  -Wall -Wextra ucn.cpp -o ucn
ucn.cpp:4:10: warning: unknown escape sequence '\é' [-Wunknown-escape-sequence]
        printf("\é\n");
                ^
1 warnings generated.
$ ./ucn
é
\u00e9

两个编译器都指定它们在存在未知转义序列时的行为是用转义后的字符替换转义序列，因此 "\é" 将被视为 "é " 整个程序应该解释为:

#include <stdio.h>

int main(void){
        printf("é\n");
        printf("\\u00e9\n");
        return 0;
}

两个编译器确实碰巧得到这种行为，部分是偶然的，但也部分是因为按照他们的方式处理无法识别的转义序列的策略是一个明智的选择:即使他们只看到无法识别的转义序列作为反斜杠后跟字节 0xC3，他们删除反斜杠并将 0xC3 保留在原位，这意味着 UTF-8 序列保持不变以供以后处理。