由于UTF8向后兼容ASCII,我以为我一直存储我所有的字符串UTF-8 std :: string,只有当我必须调用某些不寻常的功能时才转换为std :: wstring.
这样做很好,我实现了to_lower,to_upper,iequals为utf8.然而,我遇到了几个死路std :: regex和常规的字符串比较.为了使这个可用,我需要实现基于std :: string的自定义ustring类,并重新实现所有相应的算法(包括正则表达式).
基本上我的结论是utf8对于一般用途来说不是很好.而目前的std :: string / std :: wstring是混乱的.
但是,我的问题是为什么默认std :: string和“”不是简单地更改为使用UTF8？特别是UTF8向后兼容？有可能有一些编译器标志可以做到这一点吗？当然,stl实现需要自动调整.
我看过ICU,但是它与apis不兼容,假设basic_string,例如没有开始/结束/ c_str等…
解决方法
Unicode编码都不是真正适合于文本处理.用户一般会关心字母(屏幕上的内容),而编码是根据代码点定义的,而且一些图形由几个代码点组成.
因此,当一个人问：“Hélène”(法语名字)的第五个字符是什么是问题很混乱：
>在字面上,答案是n.
>在代码点方面,这取决于é和è的表示(它们可以表示为单个代码点或使用变音符号表示)
根据问题的来源(她的屏幕前面的最终用户或编码例程),响应是完全不同的.
因此,我认为真正的问题是为什么我们在这里谈论编码？
今天没有意义,我们需要两个“意见”：格式和代码点.
不幸的是,std :: string和std :: wstring接口是继承自人们认为ASCII足够的时间,而进度并没有真正解决问题.
我甚至不明白为什么应该指定内存中的表示,这是一个实现细节.所有用户应该要的是：
>能够以UTF- *和ASCII读取/写入
>能够处理图形
能够编辑一个字母(来管理变音符号)
谁在乎它是如何代表的？我以为这个好的软件是建立在封装上的？
那么,C关心,我们想要互操作性…所以我想这将是固定的,当C是.
