- 主题:c++为什么要搞宽窄两套字符？
直接用std::string支持宽字符不行吗？
--
FROM 112.123.170.*
因为这个世界除了有拉丁字母，还有其它文字的存在。为了方便展示中文，只好发明出 gbk, unicode 这些文字编码方案。
宽字符在 win 里面应用得比较多，主要是因为以前 windows 是为 gbk/utf16 这两种文字编码方案而优化的。
在 linux/bsd 领域，大家一般就不用宽字符了。
c/c++ 因为接近底层，所以很多时间不得不去碰这些繁琐的东东。事实上，Python 和 Qt 都区分 bytes 和 string 两种类型。bytes 自然还是 char[] 类型。而对于 string，Python 和 Qt 底层会根据其中的字符类型，交叉使用 char, wchar, int 四种编码方案。
【 在 miui 的大作中提到: 】
: 直接用std::string支持宽字符不行吗？
--
修改:hgoldfish FROM 117.28.110.*
FROM 117.28.110.*
我的意思是，就统一用宽字符得了，不要弄string/wstring, char/wchar了，现在转换来转换去不胜其烦，偏偏std::codecvt_utf8在c++17又被弃用了，只能用API转换
【 在 hgoldfish 的大作中提到: 】
: 因为这个世界除了有拉丁字母，还有其它文字的存在。为了方便展示中文，只好发明出 gbk, unicode 这些文字编码方案。
: 宽字符在 win 里面应用得比较多，主要是因为以前 windows 是为 gbk/utf16 这两种文字编码方案而优化的。
: 在 linux/bsd 领域，大家一般就不用宽字符了。
: ...................
--
FROM 112.123.170.*
那人家用拉丁字母的不愿意啊。每个字符串都得浪费一个字节。
要知道，这个世界的文字资料，还是西方文字占多数的。中文互联网很凋零的。
【 在 miui 的大作中提到: 】
: 我的意思是，就统一用宽字符得了，不要弄string/wstring, char/wchar了，现在转换来转换去不胜其烦，偏偏std::codecvt_utf8在c++17又被弃用了，只能用API转换
--
FROM 117.28.110.*
就跟ipv6无法完全取代ipv4一样吧
【 在 miui 的大作中提到: 】
: 直接用std::string支持宽字符不行吗？
--
FROM 103.216.43.*
std::string 其实是 std::bytes，如果需要处理多国文本应该搞个std::unicodes，std::wstring 其实真没啥用
--
FROM 38.92.186.*
因为C++字符串char*的约定是以0结尾。而宽字符的所有ASCII字符都会带一个高位字节0。
【 在 miui 的大作中提到: 】
: 直接用std::string支持宽字符不行吗？
--
FROM 221.216.117.*
因为c++够老，1980年代的c++还没动力考虑cjk地区的事。它兼容的c就更老了，所以还要考虑一个字节不是8比特之类的事。
新一点的语言也没好到哪里去，把自己锁死在UCS2的有Java、C#，后来不够用就换UTF-16。
【 在 miui 的大作中提到: 】
: 直接用std::string支持宽字符不行吗？
: --
: FROM 112.123.170.*
--
修改:milksea FROM 221.221.153.*
FROM 221.221.153.*
我现在搞跨平台的字符串就用std::wstring，
wchar_t虽然是和编译器实现相关的，但是锁定编译器和OS，处理大小写相关的转换/查找这种内存任务啥的还是方便的。 文件、网络的对外接口里是可以统一用utf-8的。
【 在 Madlee 的大作中提到: 】
: std::string 其实是 std::bytes，如果需要处理多国文本应该搞个std::unicodes，std::wstring 其实真没啥用
--
FROM 221.218.161.*
历史包袱是去不掉的，就跟intel的酷睿cpu还有8086模式一样
兼容老代码，既是c++的优势，也是它的劣势/包袱
【 在 miui 的大作中提到: 】
: 我的意思是，就统一用宽字符得了，不要弄string/wstring, char/wchar了，现在转换来转换去不胜其烦，偏偏std::codecvt_utf8在c++17又被弃用了，只能用API转换
:
--
FROM 221.218.161.*