- 主题:macos/linux上都用什么做字符串的编码转换？
libiconv？ICU？
std::ctype<CharT>::widen、std::mbsrtowcs、std::wstring_convert这些貌似都依赖当前进程/线程的locale设置，locale被修改了，结果可能就不是预期的。
--
FROM 125.35.123.*
项目内部全使用utf8。
需要输入输出非utf8时用libiconv转一下。
我经历过的所有项目都是这样处理的，代码里只用char*或std::string，没用过wchar/wstring，挺顺的没啥毛病。
【 在 z16166 的大作中提到: 】
: libiconv？ICU？
: std::ctype<CharT>::widen、std::mbsrtowcs、std::wstring_convert这些貌似都依赖当前进程/线程的locale设置，locale被修改了，结果可能就不是预期的。
--
FROM 183.192.17.*
utf8的话，大小写转换、（区分大小写的、不区分大小写的）比较怎么弄的？直接对utf8的byte sequence做？
【 在 RunningOn 的大作中提到: 】
: 项目内部全使用utf8。
: 需要输入输出非utf8时用libiconv转一下。
: 我经历过的所有项目都是这样处理的，代码里只用char*或std::string，没用过wchar/wstring，挺顺的没啥毛病。
: ...................
--
FROM 125.35.123.*
好像用utf8不保长，大多需要分配空间做，以前看到个夸张的先开辟三倍空间再做。
【 在 z16166 的大作中提到: 】
: utf8的话，大小写转换、（区分大小写的、不区分大小写的）比较怎么弄的？直接对utf8的byte sequence做？
: --
发自「今日水木 on 钛星」
--
FROM 222.129.53.*
这个问题不大，一般都是返回一个新串，内存可以由新串内部自己控制。外部控制的话，要预先计算长度。
瞅了一下基于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.*
你要是有这需求的话，就得ICU一下了，或用boost里的string库，iconv不处理这些。
也就是存储时使用utf8/string，转换大小写、比较时先转为wstring再做。
【 在 z16166 的大作中提到: 】
: utf8的话，大小写转换、（区分大小写的、不区分大小写的）比较怎么弄的？直接对utf8的byte sequence做？
--
FROM 183.192.17.*
求字符串 size 的时候会不对。
python 内部是存 utf16 还是 utf32 来着？给忘了。
【 在 RunningOn 的大作中提到: 】
: 项目内部全使用utf8。
: 需要输入输出非utf8时用libiconv转一下。
: 我经历过的所有项目都是这样处理的，代码里只用char*或std::string，没用过wchar/wstring，挺顺的没啥毛病。
: ...................
--
FROM 59.60.24.*
区分大小写，关键看你要不要根据 locale 判断大小写。
【 在 z16166 的大作中提到: 】
: utf8的话，大小写转换、（区分大小写的、不区分大小写的）比较怎么弄的？直接对utf8的byte sequence做？
--
FROM 59.60.24.*
感觉还是略麻烦。这些基础库不应该再由程序员轮过一遍又一遍。
【 在 RunningOn 的大作中提到: 】
: 你要是有这需求的话，就得ICU一下了，或用boost里的string库，iconv不处理这些。
: 也就是存储时使用utf8/string，转换大小写、比较时先转为wstring再做。
--
FROM 59.60.24.*
还是windows傻瓜式，内存里面全部UTF16搞定，能解决大多数情况，只有超出1个UTF16的surrogate pair要特殊处理（windows码农估计很少处理过这个情况）
ICU的UChar也是这个搞法
看起来可以这么搞
【 在 hgoldfish 的大作中提到: 】
: 感觉还是略麻烦。这些基础库不应该再由程序员轮过一遍又一遍。
:
--
FROM 125.35.123.*