在标准C++中，我们有char和wchar_t来存储字符。 char可以存储介于0x00和0xFF之间的值。而wchar_t可以存储介于0x0000和0xFFFF之间的值。因此，std::string使用char，只能存储1字节的字符。而std::wstring使用wchar_t，所以可以存储宽度为2字节的字符。这就是我对C++字符串的了解，请在这一点上纠正我如果我说错了什么。
我阅读了UTF-8的维基百科文章，并学到一些Unicode字符需要多达4字节的空间。例如，汉字具有Unicode代码点0x24B62，在内存中占用3字节的空间。
有没有用于处理这些字符的STL字符串容器？我正在寻找类似于
std::string32的东西。此外，我们有main()用于ASCII入口点，wmain()用于16位字符支持的入口点;我们使用哪个入口点来支持3和4字节Unicode支持的代码？首先你需要更好地理解Unicode。你问题的具体答案在底部。
你需要比介绍编程课程时所需的非常简单的文本处理更细致的概念集。
字节是可寻址的最小存储单位。通常为8位，能够存储多达256个不同的值。按定义，char就是一个字节。
代码单元是用于存储文本的最小固定大小的数据单元。当你真的不关心文本的内容，只想将其复制到某个地方或计算文本使用了多少内存时，你关心的是代码单元。否则，代码单元没什么用处。
代码点表示字符集中的一个不同成员。无论字符集中有什么“字符”，它们都被分配一个唯一的数字，每当你看到特定的数字被编码时，你就知道你正在处理字符集的哪个成员。
抽象字符是语言系统中具有含义并且与其表示或任何指定给该含义的代码点不同的实体。
用户感知字符是用户在使用的任何语言系统中认为的字符。
在早期，char代表了所有这些东西:按定义，char是一个字节，在char*字符串中，代码单元是char，字符集很小，所以char可表示的256个值足以表示每个成员，并且支持的语言系统很简单，因此字符集的成员大多直接表示用户想要直接使用的字符。
但是，char代表几乎所有内容的这种简单系统不足以支持更复杂的系统。
首先遇到的问题是有些语言使用超过256个字符。因此引入了“宽”字符。宽字符仍然使用单一类型来表示上述四个概念之一：代码单元、代码点、抽象字符和用户感知字符。但是，宽字符不再是单字节的了。这被认为是支持大型字符集最简单的方法。
代码基本上可以保持不变，只需处理宽字符而不是char。
但是，事实证明许多语言系统并不那么简单。在某些系统中，不必将每个用户感知字符都用单个抽象字符在字符集中表示是有意义的。因此，使用Unicode字符集的文本有时使用多个抽象字符表示用户感知字符，或者使用单个抽象字符表示多个用户感知字符。
宽字符存在另一个问题。由于它们增加了代码单元的大小，因此也增加了每个字符使用的空间。如果想要处理可以用单字节代码单元充分表示的文本，但必须使用宽字符系统，则使用的内存量比单字节代码单元的情况更高。因此，希望宽字符不要太宽。同时，宽字符需要足够宽，以为字符集中的每个成员提供唯一值。举例来说，如果你想获取一个字符串的“大小”，你是在计算字节、代码单元、抽象字符还是用户感知字符？std::string::size()计算的是代码单元数量，如果你需要不同的计数，则必须使用另一种方法。
另一个例子是，如果你要拆分一个编码过的字符串，你需要知道是否以这种方式进行拆分仍然有效，并且数据的含义没有无意间改变。例如，你可能会在属于同一代码点的代码单元之间进行拆分，从而产生无效编码。或者你可能会在必须组合以表示用户感知字符的代码点之间进行拆分，从而产生用户将看到为不正确数据。
今天，char和wchar_t只能被视为代码单元。即使char只有一个字节，也不能阻止它表示需要两个、三个或四个字节的代码点。你只需按顺序使用两个、三个或四个char即可。这就是UTF-8的工作原理。类似地，使用两个字节的wchar_t来表示UTF-16的平台只需在必要时使用两个wchar_t即可。实际上，char和wchar_t的实际值并不分别表示Unicode代码点。它们表示由编码代码点产生的代码单元值。例如，Unicode代码点U+0400在UTF-8中被编码为两个代码单元- > 0xD0 0x80。同样，Unicode代码点U+24B62也被编码为四个代码单元0xF0 0xA4 0xAD 0xA2。
因此，你可以使用std::string来保存UTF-8编码的数据。
在Windows上，main()不仅支持ASCII，而且还支持系统char编码。现在，即使Windows支持以UTF-8作为系统char编码，并且不再局限于旧的编码方式。你可能需要对Windows进行配置；我不确定它是否是默认设置，如果不是，希望它成为默认设置。
你还可以使用Win32 API调用直接访问UTF-16命令行参数，而不使用main()的argc和argv参数。请参见GetCommandLineW()和CommandLineToArgvW。
wmain()函数的argv参数完全支持Unicode。在Windows上，wchar_t中存储的是16位代码单元，即UTF-16代码单元。Windows API本地使用UTF-16，因此在Windows上很容易使用。然而，wmain()是非标准的函数，过度依赖它将导致无法移植。
示例：
#include <iostream>
#include <string>
int main() {
std::string s = "CJK UNIFIED IDEOGRAPH-24B62: \U00024B62";
std::cout << s << '\n';
auto space = s.rfind(' ');
std::cout << "Encoded bytes: ";
for (auto i = space + 1, end = s.size(); i != end; ++i) {
std::cout << std::hex << static_cast<int>(static_cast<unsigned char>(s[i])) << " ";
}
}
s将包含UTF-8数据。如果您正在使用支持UTF-8的终端运行已编译程序，已配置为使用它并使用支持该字符的字体，则应该看到该程序打印出该字符。cl.exe /EHsc /utf-8 tmp.cpp，并运行了命令将控制台设置为UTF-8 chcp 65001，这导致此程序打印出正确的数据。虽然由于字体缺乏支持，字符显示为带有问号的方框。从控制台复制文本并将其粘贴到具有适当支持的位置将显示正确的字符。/utf-8，您还可以直接在字符串文字中编写UTF-8数据，而不是使用\Uxxxxxxxx语法。-fexec-charset=utf-8标志构建此程序，尽管它应该是默认值。-finput-charset=utf-8允许您直接在字符串文字中编写UTF-8编码的数据。 wchar_t 的大小和意义是由实现定义的。在Windows上，它是16位的，就像你说的那样；在类Unix系统中，它通常是32位的，但并不总是这样。wchar_t 大小，但这将无法与系统的其余部分兼容。std::u32string，用于表示unicode代码点字符串。我相信最近的Microsoft编译器包括它。这有点受限，因为Microsoft的系统函数期望16位宽字符（又名UTF-16le），而不是32位的unicode代码点（又名UTF-32，UCS-4）。std::string 中。当然，由于它是一种可变长度的编码方式，您只能通过索引访问字节，而不能访问unicode代码点。但是，即使使用u32string，您通常也不需要按索引访问代码点。由于Unicode存在组合标记，Unicode代码点与可打印字符（“字形”）不是一一对应的，所以学习编程时使用字符串的许多小技巧（如反转字符串、搜索子字符串）在处理Unicode数据时不太容易，无论您将它存储在哪里。Windows使用UTF-16编码。其中，范围在U+0000至U+D7FF以及U+E000至U+FFFF之间的任何代码点都将被直接存储；而超出这些范围的代码点将根据UTF-16编码规则拆分为两个16位值。
例如，0x24B62将被编码为0xd892,0xdf62。
您可以将字符串转换为任何希望的格式，但是Windows API仍然需要并提供UTF-16编码，因此这可能是最方便的方法。
sizeof(char) == 1 so 1 byte per character.
sizeof(wchar_t) == ? Depends on your system
(for unix usually 4 for Windows usually 2).
char和wchar_t并不是用于文本字符串的唯一数据类型。C++11引入了新的char16_t和char32_t数据类型以及相应的STL std::u16string和std::u32string，它们是std::basic_string的typedefs，旨在解决wchar_t类型的歧义问题，因为在不同的平台上，wchar_t的大小和编码方式都不同。在某些平台上，wchar_t是16位的，适用于UTF-16编码，但在其他平台上，它是32位的，适用于UTF-32编码。而char16_t则是专门为16位的UTF-16编码设计的，char32_t则是专门为32位的UTF-32编码设计的，在所有平台上都是如此。