2

std::iostream 类缺乏对 char16_t 和 char32_t 的专门化,而 boost::format 取决于流。用什么来替换 utf16 字符串的流(最好有本地化支持)?

4

3 回答 3

2

流处理的基本实体是字符,而不是编码字符。对于 Unicode,决定一个字符可以跨多个实体拆分,使其与流抽象本质上不兼容。

添加新字符类型旨在处理处理 Unicode 字符的标准方法,但它被认为太复杂,无法重做 IOStreams 和语言环境的行为以保持增加的复杂性。这部分是由于人们不太喜欢流,部分是由于这是一项庞大而重要的任务。我认为可以将所需的方面定义为能够处理简单的情况,但我不确定这是否会导致快速解决方案以及它是否会涵盖需要 Unicode 的语言:我可以看到它是如何实现的适用于欧洲文本,但我不知道这是否真的适用于亚洲文本。

于 2012-09-01T18:07:17.230 回答
1

这很好。encodings 争论已经结束并且基本已经解决了。您不希望在程序中的任何地方使用 utf16 字符串,除非与遗留 API 通信,即转换整个格式化字符串时,最好通过 boost::narrow 和加宽来完成。当然,除非您正在做一些罕见的边缘案例优化。

请参阅http://utf8everywhere.org

于 2012-09-01T20:45:58.273 回答
0

当前流通常作为模板实现(我这里没有标准的副本,但我很确定它们必须作为模板实现)所以让它们具有宽字符串意识应该是一个简单的实例化问题具有适当字符类型的模板。

您的实现很可能已经为宽字符串提供了预定义的特化。看看像 std::wstringstream 这样的东西。

也就是说,C++ 中的各种字符类型不会对您放入其中的字符串的编码做出任何假设,因此您可以将其作为“按约定”方式处理 - 例如,您的宽字符串被编码为 utf16按照惯例,但图书馆中没有任何内容强制执行此约定。

于 2012-09-01T17:45:27.637 回答