“在执行字符集中可表示”是什么意思？

Question

字符文字的类型由以下规则指定：

不以 u8、u、U 或 L 开头的字符文字是普通字符文字。包含可在执行字符集中表示的单个 c-char 的普通字符文字具有 char 类型，其值等于执行字符集中 c-char 编码的数值。包含多个 c-char 的普通字符文字是多字符文字。多字符文字，或包含无法在执行字符集中表示的单个 c-char 的普通字符文字，是有条件支持的，具有 int 类型，并具有实现定义的值。

所以考虑下面的例子

#include <iostream>
int main(){
    auto c = '\u0080';
    std::cout<< typeid(c).name();
}

的类型c是int（由GCC报告）。为什么类型cIS int？

根据c-char的语法，它被定义为：

c-字符：

• 源字符集的任何成员，单引号 '、反斜杠或换行符除外
• 转义序列
• 通用字符名称

在这个例子中，\u0080是一个通用字符名称，它是一个单一的 c-char。所以普通字符字面量'\u0080'不包含超过一个 c-char。GCC 的默认执行字符集是 UTF-8。这意味着，\u0080完全可以由 UTF-8 集表示。为什么 GCC 指定的类型c是int？虽然我知道这样的代码点值不能用 char 对象表示，但这不是上述规则所述。这是海湾合作委员会的错误还是我误解的东西？如何解释“在执行字符集中可表示”？

Answer 1

GCC的默认执行字符集是UTF-8。

问题就在这里。也就是说，这不是真的。或者至少，不是按照 C++ 标准的方式。

该标准将“基本字符集”定义为 96 个不同字符的集合。但是，它没有为它们定义编码。也就是说，字符“A”是“基本字符集”的一部分。但该字符的值未指定。

标准在定义“基本执行字符集”时，在基本集中添加了一些字符，但同时也定义了存在从字符到值的映射。然而，除了 NUL 字符为 0（并且数字必须以连续序列编码）之外，它还允许实现自行决定映射是什么。

问题是：根据该术语的任何合理定义，UTF-8 都不是“字符集”。

Unicode 是一种字符集；它定义了一系列存在的字符及其含义。它还为 Unicode 字符集中的每个字符提供一个唯一的数值（Unicode 代码点）。

UTF-8 不是那样的。UTF-8 是一种字符编码方案，通常采用 Unicode 字符集（尽管它并不挑剔；它可以适用于任何 21 位数字，并且可以扩展到 32 位）。

所以当 GCC 的文档说：

【执行字符集】由用户控制；默认为 UTF-8，与源字符集匹配。

这种说法没有任何意义，因为如前所述，UTF-8 是一种文本编码，而不是字符集。

GCC 文档（以及可能的 GCC 命令行选项）似乎发生的情况是，他们将“执行字符集”与“窄字符编码方案”的概念混为一谈。UTF-8 是 GCC 默认编码窄字符串的方式。但这与说它的“执行字符集”是什么不同。

也就是说，您可以仅使用 UTF-8 来编码C++ 定义的基本执行字符集。使用 UTF-8 作为窄字符编码方案与执行字符集无关。

请注意，Visual Studio 有一个类似名称的选项，并对这两个概念进行了类似的合并。他们称之为“执行字符集”，但他们将该选项的行为解释为：

执行字符集是用于在所有预处理步骤之后输入到编译阶段的程序文本的编码。

那么... GCC的执行字符集是什么？好吧，由于他们的文档将“执行字符集”与“窄字符串编码”混淆了，所以几乎不可能知道。

那么该标准对 GCC 的行为有何要求呢？好吧，采纳你引用的规则并扭转它。字符文字中的单个通用字符名称可以是 achar或 an int，并且只有当通用字符名称命名的字符不在执行字符集中时，它才会是后者。因此，系统的执行字符集不可能包含比char允许的字符数更多的字符。

即GCC的执行字符集不可能全部是Unicode。它必须是 Unicode 的某个子集。它可以选择它是 Unicode 的子集，其 UTF-8 编码占用 1 char，但这大约是它能容纳的最大大小。

虽然我将此视为 GCC 的问题，但从技术上讲，它也是 C++ 规范中的一个问题。您引用的段落还将编码机制（即：char意味着什么）与执行字符集（即：可以存储哪些字符）混为一谈。

通过添加以下措辞已认识到并解决了该问题：

不可编码字符文字是一种字符文字，其 c-char-sequence 由单个 c-char 组成，该 c-char 不是数字转义序列，并且指定的字符要么缺乏该文字关联的字符编码中的表示，要么不能被编码为单个代码单元。多字符文字是一种字符文字，其 c 字符序列由多个 c 字符组成。不可编码的字符文字或多字符文字的编码前缀应不存在或为 L。此类字符文字是有条件支持的。

由于这些建议是作为 CWG 问题的解决方案提出（并被接受）的，因此它们也追溯适用于该标准的先前版本。