上下文

C11和C++11都支持源文件中的扩展字符，以及通用字符名称（UCN），它允许用户仅使用基本源字符集中的字符输入基本源字符集中未包含的字符。
C++11还定义了编译的几个翻译阶段。特别地，扩展字符在翻译的第一阶段被规范化为UCN，如下所述：

§ C++11 2.2p1.1：

如果需要，物理源文件字符以实现定义的方式Map到基本源字符集（为行尾指示符引入换行符）。接受的物理源文件字符集是实现定义的。三字母序列（2.4）被相应的单字符内部表示所取代。任何不在基本源字符集（2.3）中的源文件字符都被指定该字符的通用字符名替换。（实现可以使用任何内部编码，只要在源文件中遇到的实际扩展字符，以及在源文件中表示为通用字符名称的相同扩展字符（即，使用\uXXXX符号），被等效地处理，除非在原始字符串文字中恢复此替换。

提问

符合标准的程序编译

#include <stdio.h>

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

失败，编译并打印

é
é

或编译打印

\u00e9
\u00e9

，何时运行？

知情个人意见

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

• 实现可以使用任何内部编码，只要在源文件中遇到的实际扩展字符，以及在源文件中表示为通用字符名称的相同扩展字符（即，使用\uXXXX表示法），被处理等效，除非这种替换在原始字符串文字中恢复。*，并且我们不在原始字符串文字中。

然后得出结论

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

实验

不幸的是，现存的编译器不同意我的观点。我已经测试了GCC 4.8.2和Clang 3.5，下面是他们给我的：

• GCC 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

• 叮当声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源文件的问题。
谁是对的？***