gpt4 book ai didi

c++ - 关于 C++ 中完整 unicode 的基本问题

转载 作者:塔克拉玛干 更新时间:2023-11-03 07:08:28 25 4
gpt4 key购买 nike

在 C++ 中使用哪些适当的工具来实现完整的 unicode?

比如我试过:

int main()                                                                                                                                                                 
{
std::wstring name;
std::wcout << "Enter unicode: " << std::endl;
std::getline(std::wcin, name);

std::wcout << name << std::endl;

return 0;
}

输入字符时,它不会像我预期的那样工作:💖 或其他不在 Unicode BMP 中的字符。我打印出一个空行。

普通字符串适用于最多 16 位的任何代码点,wstring、wcin、wcout 不能像我预期的那样工作,一些谷歌搜索没有帮助我看出这可能是什么错误。

编辑(文件 I/O 也有问题!):

我想知道这是否与控制台 I/O 本身有关,并想尝试对文件 I/O 进行同样的实验。我查看了 api 并想出了这个编译和运行良好的:

int main()                                                                                                                                                                 
{
std::string filename;
std::cout << "Enter file to append to: " << std::endl;
std::getline(std::cin, filename);

std::wifstream file;
std::wstringstream buff;
file.open(filename);
std::wstring txt;
buff << file.rdbuf();
file.close();
txt = buff.str();

std::wcout << txt << std::endl;

return 0;
}

但是当我将它指向我的文件时,它主要包含 lorem ipsum 和一些非 BMP 字符,它会打印文件直到第一个非 BMP 字符,然后提前停止。现代 C++ 中的 Unicode 设施真的这么糟糕吗?

我确定有人知道我在这里缺少的一些基本知识...

最佳答案

您处于 C++ unicode 的灰色地带。 Unicode 最初是从 7 位 ASCII 字符或多字节字符到普通 16 位字符的扩展开始的,后来成为 BMP。这些 16 位字符被 Java 等语言和 Windows 等系统原生采用。 C 和 C++ 在标准观点上更加保守决定 wchar_t将是一个依赖于实现的宽字符集,根据需要可以是 16 位或 32 位宽(或什至更多...)。好的一面是它是可扩展的,不好的一面是当 wchar_t 只有 16 位时,它从未明确表示非 BMP unicode 字符应该如何表示。

然后创建了 UTF-16 以允许那些非 BMP 字符的标准表示,缺点是它们需要 2 个 16 位字符,并且 std::char_traits<wchar_t>::length如果其中一些出现在 wstring 中,将再次出错。

这就是大多数 C++ 实现选择 wchar_t 的原因基本 IO 只会正确处理 length 的 BMP unicode 字符返回真实的字符数。

C++-ish 方法是使用 char32_t当需要完整的 unicode 支持时,基于字符串。事实上wstring_twchar_t (字面量的前缀 L)是依赖于实现的类型,并且从 C++11 开始,您还有 char16_tu16string (前缀 u)明确使用 UTF-16,或 char32_tu32string (前缀 U)通过 UTF-32 获得完整的 unicode 支持。在 u16string 中存储 BMP 之外的字符的问题在于,您丢失了 string 大小 == 字符数 属性,这是使用宽字符而不是多字节字符的关键原因。

u32string 的一个问题是 io 库仍然没有针对 32 位字符的直接专门化,但是正如转换器所具有的那样,当您处理带有 std::basic_fstream<char32_t> 的文件时,您可能可以轻松地使用它们。 (未经测试但根据标准应该可以工作)。但是您将没有 cin 的标准流, coutcerr ,并且可能必须处理来自 string 中的 nativeu16string , 然后转换 u32string 中的所有内容借助 C++14 中引入的标准转换器,或者如果仅使用 C++11,则采用困难的方法。

真正黑暗的一面是,由于该原生部分目前依赖于操作系统,您将无法设置一种完全可移植的方式来处理完整的 unicode - 或者至少我不知道。

关于c++ - 关于 C++ 中完整 unicode 的基本问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45809290/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com