C++应该像python那样把字符串和二进制字节串分开，各自定义自己的类。

【 在 hgoldfish 的大作中提到: 】
: std::string 最大的问题是它不是 unicode 的。这导致他在现实中几乎无用。对于我们中国人尤其如此。在表情符到处飞的今天，继续用 std::string 就是犯罪啊！
: 拿它来处理网络流很好用。但它真的不是字符串。
: 话说，有没有谁做个真正好用的字符串第三方库啊。其它的功能不用搞，就做好字符串就行了。
: ...................
--
FROM 111.200.40.*

不知道u16string是不是utf-16.
utf-16原本对应unicode基本平面(65536个字符，其中汉字为gbk+cjk-extA，约有2.8万个)，后来unicode字符集不断扩充，超出了基本平面的容纳范围。超出基本平面的汉字utf-16编码就不是双字节编码了，这时utf-16就名不符实了，它成了和utf-8一样的变长编码。当然我们一般人用的字符都在基本平面内，几乎不太可能用到超出两个字节的utf-16字符。所以实践中，还是有不少人直接把utf-16的字符串当成定长变码来对待。但理论上，utf-16已经不符合它原来的定义了（于是出现了utf-32，用来代替utf-16，这个是真正的定长编码方式，不过与utf-8比起来，空间效率更低）。

基本平面内的汉字，三字节的utf-8编码和两字节的utf-16编码，对于今天的计算机存诸技术和网络带宽而言，不是一个值得纠结的点，如果加上zip等无损压缩手段，两字节相对于三字节编码的空间优势更是可以忽略不计（比如在epub、odt文件中）。对于变长的utf-8编码，直接取下标定位字符技术上也是可以做到的。

定长编码的唯一优势是，取下标操作的时间复杂度是常数，而变长编码取下标操作的时间复杂度是线性的。以今天的计算机速度，定长编码（基本平面内的utf-16, 所有平面内的utf-32）的这点优势不值一提。


在编程语言中向程序员暴露每个字符的编码长度（u16、u32）就是误入歧途，程序员只须关心他存的是哪些字符和编码方案即可(比如 a = string('国家',coding='utf-32'))，程序设计语言应该封装具体的码长信息，所有关于字符串的操作都应该基于字符而非关注于其底层编码，非字符/二进制数据应该存放在bytes中，这时应该向程序员暴露字节长度。

utf-8的优势是很明显的。首先它是自同步的，无需额外加入大端小端信息，允许读取程序从任何位置开始并立即检测到字符边界，这是非常重要的一个优点。其次它采用变长编码方式，对最常用的英文字母采取1个字节编码，节省了大量空间。由于长度可以不断扩充，因此本身保持开放性，可以和unicode一同演进。采用变长编码方式还使程序不得依赖/限定文字的编码长度，在更抽象的水平上操作文字，而不是依赖于strcpy、strcat、strstr、strlen、strdup等底层函数。变长编码方式也不影响grep等RE工具的使用。


定长编码不值得留恋。


【 在 hgoldfish 的大作中提到: 】
: 如果多用中文的话，应该是 u16string 最省空间。基本上一个汉字对应两个字节。
: 而且 utf-8 的话，一个汉字基本上对应三个字节。
: python 和 Qt 都会做我刚才说的优化，自动根据 unicode 编码范围，选择适合的存储类型来使用。一来可以节省空间，二来提升处理效率。比如 u8string 里面，想要迭代处理一个个 unicode 字符，一会是一个字节，一会儿是三个字节。效率很差。
:     unicode_string[i]
: 就这个简单的取下标，都是大麻烦。
--
修改:seablue FROM 111.200.40.*
FROM 111.200.40.*

python runtime中的编码应该是由locale/code page决定的。文件中的编码由文件的开头声明决定，默认是utf-8. Python will enable UTF-8 mode(运行时环境) by default from Python 3.15. 这个影响最大的是windows平台，因为mac和linux上，locale通常默认是utf-8.
peps.python.org/pep-3120/
peps.python.org/pep-0686/

在内部，python解释器应该是把各种编码转成某种unicode定长编码（比如ascii、utf-16、utf-32）来分别处理：

Python 3.3 and later (PEP 393):
peps.python.org/pep-0393/


The internal representation can be one of three forms:

- PyASCIIObject:
    Used for strings containing only ASCII characters (code points up to 127). These are stored using 1 byte per character.

- PyCompactUnicodeObject:
    Used for strings containing characters from the Basic Multilingual Plane (BMP), but not beyond. These are stored using 2 bytes per character (similar to UTF-16).

- PyUnicodeObject:
    Used for strings containing characters outside the BMP (requiring code points up to 1,114,111). These are stored using 4 bytes per character (similar to UTF-32).

This flexible representation means that Python dynamically adjusts the internal storage width to minimize memory consumption, unlike older versions (Python 2 and early Python 3) that used a fixed-width UCS-2 or UCS-4 representation determined at compile time.

For example, a string containing only "hello" would be stored using 1-byte characters, while a string containing "hello?" would use a 4-byte representation because of the emoji character. This allows for efficient memory usage while maintaining the ability to represent the full range of Unicode characters.
==========

In Python 3.3 which implements PEP 393. The new representation will pick one or several of ascii, latin-1, utf-8, utf-16, utf-32, generally trying to get a compact representation.

==========
python对字符串的这种处理方式——程序员可以只使用utf-8编码，而内部将字符串拆成ascii、utf-16、utf-32定长编码——既对程序员屏蔽了细节，又使用定长编码来节约存诸空间、加快下标取值速度和方便计算字符串长度，值得C++借鉴。

C++的步子太小了，还把宽窄字符串这种内存细节暴露给程序员，这不是一种现代化的处理思路。



【 在 easior 的大作中提到: 】
: Python 的字符串底层应该是建立在 C 的多字节流之上的吧
: C 的这一套处理方案依赖于本地策略集，也容易出现乱码
: Python 3 预设了所有编码都是 UTF-8，不知道虚拟机如何处理运行环境的？
: ...................
--
修改:seablue FROM 111.200.40.*
FROM 111.200.40.*

表情符号要么没法存，要么超出了两字节。所以utf-16是一个残次品。

【 在 hgoldfish 的大作中提到: 】
: 也不算尴尬。
: Java 的 u16string 在互联网时代存储汉字更高效。
--
修改:seablue FROM 111.200.40.*
FROM 111.200.40.*