- 主题:macos/linux上都用什么做字符串的编码转换？
不要使用wstring，它只是wchar_t的实例。wchar_t不是可移植的，在win上，它占据2个字节，在linux/mac上，它4个字节
wstring_convert/codecvt已经被废弃。所以编码转换还是用第三方库。
内部存储字符串，要么使用utf8，要么直接u32。建议直接用u32。rust的char类型就是4个字节。
【 在 z16166 的大作中提到: 】
: libiconv？ICU？
:
: std::ctype<CharT>::widen、std::mbsrtowcs、std::wstring_convert这些貌似都依赖当前进程/线程的locale设置，locale被修改了，结果可能就不是预期的。
: ...................
--来自微微水木3.5.12
--
FROM 223.167.168.*
我现在就是要移植win代码到macos
win上肯定都是std::wstring或者WCHAR，移植过来后，继续用这个貌似暂时可以，虽然是2 -> 4。
先实现功能，然后也看看什么是比较好的实践。
【 在 KillnCov 的大作中提到: 】
: 不要使用wstring，它只是wchar_t的实例。wchar_t不是可移植的，在win上，它占据2个字节，在linux/mac上，它4个字节
: wstring_convert/codecvt已经被废弃。所以编码转换还是用第三方库。
: 内部存储字符串，要么使用utf8，要么直接u32。建议直接用u32。rust的char类型就是4个字节。
: ...................
--
FROM 125.35.123.*
网络通讯或者文件读写，才需要考虑跨平台通用的编码形式，这时用utf8才有足够意义
平台内部，用wchar_t 可以提升处理效率，意义也很明显
【 在 KillnCov 的大作中提到: 】
: 不要使用wstring，它只是wchar_t的实例。wchar_t不是可移植的，在win上，它占据2个字节，在linux/mac上，它4个字节
: wstring_convert/codecvt已经被废弃。所以编码转换还是用第三方库。
: 内部存储字符串，要么使用utf8，要么直接u32。建议直接用u32。rust的char类型就是4个字节。
: ...................
--
FROM 120.231.182.*
平台内部，从正确性上来说也应该用vector<int32>啊，直接处理Unicode码点不用担心犯错。
【 在 hehao 的大作中提到: 】
: 网络通讯或者文件读写，才需要考虑跨平台通用的编码形式，这时用utf8才有足够意义
: 平台内部，用wchar_t 可以提升处理效率，意义也很明显
--
FROM 222.129.53.*
已经先用std::wstring在macos上搞完了，先实现功能保证工期再说，哈哈
都转为wchar_t虽然费内存，不过有个好处，就是用libiconv之类的转换时不需要扩大预估分配的缓冲区的长度，因为得到的utf32结果串的字符长度肯定不会超过源串的字节长度。
libiconv的字符串的code page和windows上的int类型的code page之间的映射，是个体力活。
--
修改:z16166 FROM 125.35.123.*
FROM 125.35.123.*
Python字符串是8/16/32自适应…
- 来自 水木社区APP v3.5.5
【 在 hgoldfish 的大作中提到: 】
: 求字符串 size 的时候会不对。
:
: python 内部是存 utf16 还是 utf32 来着？给忘了。
--
FROM 124.217.188.*
utf8就是这个问题。不知道预开多少空间。
【 在 ble 的大作中提到: 】
: 好像用utf8不保长，大多需要分配空间做，以前看到个夸张的先开辟三倍空间再做。
: 发自「今日水木 on 钛星」
--
FROM 221.221.53.*