为什么扩展的 ASCII（特殊）字符需要 2 个字节才能存储？
Why extended ASCII (special) characters take 2 bytes to get stored?
从 32 到 126 的 ASCII 是可打印的。 127 是 DEL，此后被认为是 extended characters。
为了检查，它们是如何存储在std::string中的，我写了一个测试程序：
int main ()
{
string s; // ASCII
s += "!"; // 33
s += "A"; // 65
s += "a"; // 97
s += "â"; // 131
s += "ä"; // 132
s += "Ã "; // 133
cout << s << endl; // Print directly
for(auto i : s) // Print after iteration
cout << i;
cout << "\ns.size() = " << s.size() << endl; // outputs 9!
}
上面代码中可见的特殊字符实际上看起来不同，这些可以在online example中看到（在vi中也可见）。
在字符串s中，前3个正常字符按预期各占1个字节。接下来的 3 个扩展字符每个占用 2 个字节。
问题：
- 尽管是 ASCII（在 0 到 256 范围内），为什么这 3 个扩展字符占用 space 的 2 个字节？
- 当我们使用基于范围的循环遍历
s 时，它是如何计算出对于普通字符它必须递增 1 次而对于扩展字符它必须递增 2 次！？
[注意：这可能也适用于 C 和其他语言。]
您的终端可能使用 UTF-8 编码。它对 ASCII 字符使用一个字节，对其他所有字符使用 2-4 个字节。
C++ 源代码的基本源字符集不包括扩展 ASCII 字符（参考 ISO/IEC 14882:2011 中的 §2.3）：
The basic source character set consists of 96 characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:
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
_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ∼ ! = , \ " ’
因此，实现必须将这些字符从源文件映射到基本源字符集中的字符，然后再将它们传递给编译器。它们可能会映射到通用字符名称，遵循 ISO/IEC 10646 (UCS) :
The universal-character-name construct provides a way to name other characters.
The character designated by the universal-character-name \UNNNNNNNN is that character whose character short name in ISO/IEC 10646 is NNNNNNNN; the character designated by the universal-character-name \uNNNN is that character whose character short name in ISO/IEC 10646 is 0000NNNN.
可以使用多字节编码（参考 ISO/IEC 14882:2011 中的§2.14.5）将窄字符串文字中的通用字符名称（如您的情况）映射到多个字符：
In a narrow string literal, a universal-character-name may map to more than one char element due to multibyte encoding.
这就是您看到的最后 3 个字符。
- Despite being an ASCII (within range of 0 to 256), why those 3 extended characters take 2 bytes of space?
如果您将 'being ASCII' 定义为仅包含 [0, 256) 范围内的字节，则所有数据都是 ASCII：[0, 256) 与一个字节能够表示的范围相同，因此，根据您的定义，所有用字节表示的数据都是 ASCII。
问题是您的定义不正确，并且您对数据类型的确定方式有误；字节序列表示的数据类型不是由这些字节决定的。相反，数据类型是字节序列外部的 metadata。 （这并不是说不可能检查字节序列并从统计上确定它可能是哪种数据。）
让我们检查您的代码，同时牢记以上几点。我从您的源代码的两个版本中提取了相关片段：
s += "â"; // 131
s += "ä"; // 132
s += "â"; // 131
s += "ä"; // 132
您将这些源代码片段视为在浏览器中呈现的文本，而不是原始二进制数据。您已将这两个内容呈现为 'same' 数据，但实际上它们并不相同。上图是两个不同的字符序列。
然而，这两个文本元素序列有一些有趣的地方：其中一个在使用特定编码方案编码为字节时，由与另一个文本元素序列相同的字节序列表示，当该序列使用不同的编码方案将其编码为字节。也就是说，磁盘上的相同字节序列可能表示两个不同的文本元素序列，具体取决于编码方案！换句话说，为了弄清楚字节序列是什么意思，我们必须知道它是什么类型的数据，因此需要知道使用什么解码方案。
这就是可能发生的事情。在 vi 中你写道：
s += "â"; // 131
s += "ä"; // 132
您的印象是 vi 会使用扩展 ASCII 表示这些字符，因此使用字节 131 和 132。但这是不正确的。 vi 没有使用扩展的 ASCII，而是使用不同的方案 (UTF-8) 表示这些字符，该方案恰好使用两个字节来表示这些字符中的每一个。
后来，当您在其他编辑器中打开源代码时，该编辑器错误地假定该文件是扩展的 ASCII 文件并以此显示。由于扩展 ASCII 对每个字符使用单个字节，因此它使用两个字节 vi 来表示每个字符，并为每个字节显示一个字符。
最重要的是，您认为源代码使用的是扩展 ASCII 是错误的，因此您假设这些字符将由值为 131 和 132 的单个字节表示是不正确的。
- When we iterate through the s using range based loop, how is it figured out that for normal characters it has to increment 1 time and for extended characters 2 times!?
您的程序没有这样做。在您的 ideone.com 示例中字符打印正常，因为独立打印出代表这些字符的两个字节可以显示该字符。这里有一个例子可以清楚地说明这一点：live example.
std::cout << "Printed together: '";
std::cout << (char)0xC3;
std::cout << (char)0xA2;
std::cout << "'\n";
std::cout << "Printed separated: '";
std::cout << (char)0xC3;
std::cout << '/';
std::cout << (char)0xA2;
std::cout << "'\n";
Printed together: 'â'
Printed separated: '�/�'
“�”字符是遇到无效编码时显示的字符。
如果您问如何编写执行此操作的程序，答案是使用了解所用编码细节的代码。要么获得一个理解 UTF-8 的库，要么自己阅读 UTF-8 规范。
你还应该记住，这里使用 UTF-8 只是因为这个编辑器和编译器默认使用 UTF-8。如果你用不同的编辑器编写相同的代码并用不同的编译器编译它，编码可能完全不同；假设代码是 UTF-8 可能与您之前假设代码是扩展 ASCII 一样错误。
从 32 到 126 的 ASCII 是可打印的。 127 是 DEL，此后被认为是 extended characters。
为了检查，它们是如何存储在std::string中的，我写了一个测试程序：
int main ()
{
string s; // ASCII
s += "!"; // 33
s += "A"; // 65
s += "a"; // 97
s += "â"; // 131
s += "ä"; // 132
s += "Ã "; // 133
cout << s << endl; // Print directly
for(auto i : s) // Print after iteration
cout << i;
cout << "\ns.size() = " << s.size() << endl; // outputs 9!
}
上面代码中可见的特殊字符实际上看起来不同，这些可以在online example中看到（在vi中也可见）。
在字符串s中，前3个正常字符按预期各占1个字节。接下来的 3 个扩展字符每个占用 2 个字节。
问题：
- 尽管是 ASCII（在 0 到 256 范围内），为什么这 3 个扩展字符占用 space 的 2 个字节？
- 当我们使用基于范围的循环遍历
s时，它是如何计算出对于普通字符它必须递增 1 次而对于扩展字符它必须递增 2 次！？
[注意：这可能也适用于 C 和其他语言。]
您的终端可能使用 UTF-8 编码。它对 ASCII 字符使用一个字节，对其他所有字符使用 2-4 个字节。
C++ 源代码的基本源字符集不包括扩展 ASCII 字符（参考 ISO/IEC 14882:2011 中的 §2.3）：
The basic source character set consists of 96 characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:
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
_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ∼ ! = , \ " ’
因此，实现必须将这些字符从源文件映射到基本源字符集中的字符，然后再将它们传递给编译器。它们可能会映射到通用字符名称，遵循 ISO/IEC 10646 (UCS) :
The universal-character-name construct provides a way to name other characters.
The character designated by the universal-character-name \UNNNNNNNN is that character whose character short name in ISO/IEC 10646 is NNNNNNNN; the character designated by the universal-character-name \uNNNN is that character whose character short name in ISO/IEC 10646 is 0000NNNN.
可以使用多字节编码（参考 ISO/IEC 14882:2011 中的§2.14.5）将窄字符串文字中的通用字符名称（如您的情况）映射到多个字符：
In a narrow string literal, a universal-character-name may map to more than one char element due to multibyte encoding.
这就是您看到的最后 3 个字符。
- Despite being an ASCII (within range of 0 to 256), why those 3 extended characters take 2 bytes of space?
如果您将 'being ASCII' 定义为仅包含 [0, 256) 范围内的字节，则所有数据都是 ASCII：[0, 256) 与一个字节能够表示的范围相同，因此，根据您的定义，所有用字节表示的数据都是 ASCII。
问题是您的定义不正确，并且您对数据类型的确定方式有误；字节序列表示的数据类型不是由这些字节决定的。相反，数据类型是字节序列外部的 metadata。 （这并不是说不可能检查字节序列并从统计上确定它可能是哪种数据。）
让我们检查您的代码，同时牢记以上几点。我从您的源代码的两个版本中提取了相关片段：
s += "â"; // 131
s += "ä"; // 132
s += "â"; // 131
s += "ä"; // 132
您将这些源代码片段视为在浏览器中呈现的文本，而不是原始二进制数据。您已将这两个内容呈现为 'same' 数据，但实际上它们并不相同。上图是两个不同的字符序列。
然而，这两个文本元素序列有一些有趣的地方：其中一个在使用特定编码方案编码为字节时，由与另一个文本元素序列相同的字节序列表示，当该序列使用不同的编码方案将其编码为字节。也就是说，磁盘上的相同字节序列可能表示两个不同的文本元素序列，具体取决于编码方案！换句话说，为了弄清楚字节序列是什么意思，我们必须知道它是什么类型的数据，因此需要知道使用什么解码方案。
这就是可能发生的事情。在 vi 中你写道：
s += "â"; // 131
s += "ä"; // 132
您的印象是 vi 会使用扩展 ASCII 表示这些字符，因此使用字节 131 和 132。但这是不正确的。 vi 没有使用扩展的 ASCII，而是使用不同的方案 (UTF-8) 表示这些字符，该方案恰好使用两个字节来表示这些字符中的每一个。
后来，当您在其他编辑器中打开源代码时，该编辑器错误地假定该文件是扩展的 ASCII 文件并以此显示。由于扩展 ASCII 对每个字符使用单个字节，因此它使用两个字节 vi 来表示每个字符，并为每个字节显示一个字符。
最重要的是，您认为源代码使用的是扩展 ASCII 是错误的，因此您假设这些字符将由值为 131 和 132 的单个字节表示是不正确的。
- When we iterate through the s using range based loop, how is it figured out that for normal characters it has to increment 1 time and for extended characters 2 times!?
您的程序没有这样做。在您的 ideone.com 示例中字符打印正常，因为独立打印出代表这些字符的两个字节可以显示该字符。这里有一个例子可以清楚地说明这一点：live example.
std::cout << "Printed together: '";
std::cout << (char)0xC3;
std::cout << (char)0xA2;
std::cout << "'\n";
std::cout << "Printed separated: '";
std::cout << (char)0xC3;
std::cout << '/';
std::cout << (char)0xA2;
std::cout << "'\n";
Printed together: 'â'
Printed separated: '�/�'
“�”字符是遇到无效编码时显示的字符。
如果您问如何编写执行此操作的程序，答案是使用了解所用编码细节的代码。要么获得一个理解 UTF-8 的库，要么自己阅读 UTF-8 规范。
你还应该记住，这里使用 UTF-8 只是因为这个编辑器和编译器默认使用 UTF-8。如果你用不同的编辑器编写相同的代码并用不同的编译器编译它，编码可能完全不同；假设代码是 UTF-8 可能与您之前假设代码是扩展 ASCII 一样错误。