UTF16比较蛋疼，移植可以用UTF8，这样跟多字节的兼容性更好一些。


【 在 damingge 的大作中提到: 】
: 卧槽，太tmd麻烦了，这么多字符串搞到啥时候？？？？
: 为啥非要分多字节和UNICODE啊？
--
FROM 114.245.90.*

多字节是啥意思？win32api 里面的 wchar?

当年巨硬以为 utf-16 就能容纳全世界所有字符，没想到 unicode 现在连表情符都放进来了。更夸张的是，表情符还是兼容各种肤色，不能搞歧视！

现在别想那么有的没的。在大多数情况下，使用 utf8. 而在内存里面，我看现在的趋势是使用 utf-16.

我记得 Python 和 Qt 在内存里面存储字符串的时候，如果判断是 latin 编码，就使用 latin1 编码存储，如果判断是非 latin 编码，就使用 utf-16 存储在内存里面。在内存里面，可以避免 utf-16 的字节序问题，也能更快的实现字符串的各种算法。

【 在 damingge 的大作中提到: 】
: 卧槽，太tmd麻烦了，这么多字符串搞到啥时候？？？？
: 为啥非要分多字节和UNICODE啊？
--
FROM 183.253.147.*

我估计他说的多字节就是最简单的那种char*字符串，GB2312/GBK编码。

这类程序移植到utf-16最大的问题是改成w_char*后，各种std::string, strcpy, strcat之类以0结尾的字符串算法都得改，极度蛋疼。所以改用utf-8会方便很多，至少大部分情况下还是char*的那坨约定，修改量会小很多，只需要考虑IO部分的转码和内存越界问题。


【 在 hgoldfish 的大作中提到: 】
: 多字节是啥意思？win32api 里面的 wchar?
: 当年巨硬以为 utf-16 就能容纳全世界所有字符，没想到 unicode 现在连表情符都放进来了。更夸张的是，表情符还是兼容各种肤色，不能搞歧视！
: 现在别想那么有的没的。在大多数情况下，使用 utf8. 而在内存里面，我看现在的趋势是使用 utf-16.
: ...................
--
FROM 36.112.193.*

MSVC的编译分multi-byte和unicode两种字符模式

也就是决定TCHAR到底是char还是wchar_t的模式

古老的VC6甚至更早的时代，很多代码是multi-byte的（因为win 3.x、win9x是ansi字符的API），现在除了跨平台的libcurl这种还用multi-byte模式编译，早就是unicode模式了

所以楼主应该是在维护一个上古的工程

【 在 yuanmo 的大作中提到: 】
: 我估计他说的多字节就是最简单的那种char*字符串，GB2312/GBK编码。
: 这类程序移植到utf-16最大的问题是改成w_char*后，各种std::string, strcpy, strcat之类以0结尾的字符串算法都得改，极度蛋疼。所以改用utf-8会方便很多，至少大部分情况下还是char*的那坨约定，修改量会小很多，只需要考虑IO部分的转码和内存越界问题。
:
--
修改:z16166 FROM 222.130.138.*
FROM 222.130.138.*

是的，上古VC6.0上工程，差不多有20年了，代码几万行，多年用过来的算法函数，没人敢去重写，有类，但都是类C写法，大量字符串，太难改了，靠

要重新做新应用程序，新工程VS2022，底层不好动它啊，实在不行分割吧，不编入新工程了，给丫打个包，静态库或动态库引用吧，接口弄弄好，好在之前的项目模块分的还算清晰，算法库和界面耦合的不多








【 在 z16166 的大作中提到: 】
: MSVC的编译分multi-byte和unicode两种字符模式
: 也就是决定TCHAR到底是char还是wchar_t的模式
: 古老的VC6甚至更早的时代，很多代码是multi-byte的（因为win 3.x、win9x是ansi字符的API），现在除了跨平台的libcurl这种还用multi-byte模式编译，早就是unicode模式了
: ...................
--
修改:damingge FROM 180.78.130.*
FROM 180.78.130.*