- 主题:macos/linux上都用什么做字符串的编码转换？
libiconv？ICU？
std::ctype<CharT>::widen、std::mbsrtowcs、std::wstring_convert这些貌似都依赖当前进程/线程的locale设置，locale被修改了，结果可能就不是预期的。
--
FROM 125.35.123.*
utf8的话，大小写转换、（区分大小写的、不区分大小写的）比较怎么弄的？直接对utf8的byte sequence做？
【 在 RunningOn 的大作中提到: 】
: 项目内部全使用utf8。
: 需要输入输出非utf8时用libiconv转一下。
: 我经历过的所有项目都是这样处理的，代码里只用char*或std::string，没用过wchar/wstring，挺顺的没啥毛病。
: ...................
--
FROM 125.35.123.*
这个问题不大，一般都是返回一个新串，内存可以由新串内部自己控制。外部控制的话，要预先计算长度。
瞅了一下基于ICU的Boost.Locale的文档，貌似std里相关的库不太完善
https://www.boost.org/doc/libs/1_79_0/libs/locale/doc/html/std_locales.html
【 在 ble 的大作中提到: 】
: 好像用utf8不保长，大多需要分配空间做，以前看到个夸张的先开辟三倍空间再做。
: 发自「今日水木 on 钛星」
--
FROM 125.35.123.*
还是windows傻瓜式，内存里面全部UTF16搞定，能解决大多数情况，只有超出1个UTF16的surrogate pair要特殊处理（windows码农估计很少处理过这个情况）
ICU的UChar也是这个搞法
看起来可以这么搞
【 在 hgoldfish 的大作中提到: 】
: 感觉还是略麻烦。这些基础库不应该再由程序员轮过一遍又一遍。
:
--
FROM 125.35.123.*
我现在就是要移植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.*
已经先用std::wstring在macos上搞完了，先实现功能保证工期再说，哈哈
都转为wchar_t虽然费内存，不过有个好处，就是用libiconv之类的转换时不需要扩大预估分配的缓冲区的长度，因为得到的utf32结果串的字符长度肯定不会超过源串的字节长度。
libiconv的字符串的code page和windows上的int类型的code page之间的映射，是个体力活。
--
修改:z16166 FROM 125.35.123.*
FROM 125.35.123.*