根据C ++ 14标准，
§2.2.1.1 [...]接受的物理源文件字符集是 实现定义。 [...]任何源文件字符都不在 基本源字符集由universal-character-name替换 指定那个角色。 [...]
这是否意味着C ++标准没有为非UCS / Unicode字符提供实现定义或条件支持？例如，物理源文件编码包括没有相应UCS代码点的字符。
我能想到的唯一想法是，如果是这种情况（编译器通过非UCS编码支持非UCS字符），编译器必须使用私有UCS范围来映射这些物理字符，但无论如何，该解决方案不适合“指定该字符”部分的通用字符名称，因为私有范围内的UCS代码点根本不定义任何特定字符。
答案 0 :(得分：1)
不是。。的种类。 [lex.phases]引用IMO的重要部分如下：
物理源文件字符映射到基本源 字符集
仅支持基本源字符集，其他所有内容必须以某种方式映射到它（[lex.charset]）：
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! = , \ " ’
但该标准还表示，如果必要，它应该 。接下来说：
一套物理 接受的源文件字符是实现定义的。
所以我想，只要至少支持基本字符集，它允许编译器最终做任何想做的事。