c就悲剧了。用struct映射数据库时，不知道那些字段留多大空间，只能按字符数×最长编码预留。这也有问题，如果一个串全部是ascii，长度没有超过该字段的最大长度，这在c里是允许的，也是安全的。但是插入数据库就会失败。如果对每个字段都去检查字符数，是一个不小的开销。
不知道c++的String类型，有没有约束字符数的机制。
所以在c应用里，数据库尽量使用varchar类型，而不使用nvarchar类型。

【 在 kirbyzhou 的大作中提到: 】
: 超出2字节就超呗。
: 比utf-8的1~4字节处理起来可是方便太多了。
:
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*

同感。

N年前做过把GB2312编码的项目改成国际版的工作，有几百万行代码要改。最开始尝试了一下utf-16，很快发现完全不可行，因为原来的字符串都是char*和string，要改几万行相关代码变成wchar_t和wstring基本是不可能的，不但工作量大，而且原来的strcpy, strcat，strlen等操作完全失效，都得改成类似wstrcpy, wstrcat之类。就算折腾完了，utf16还是一个变长编码，我这么折腾究竟图啥。

然后UTF8有个最大的好处，就是兼容char*。相对来说，下标访问的需求不算强烈，而且也可以通过函数封装。综合看起来UTF8就是最顺眼的。

最后，在用惯了python和mac这种内建UTF8的系统后，再看windows和C++的很多软件默认还在用老的编码方式，就感觉蛋疼无比。



【 在 seablue 的大作中提到: 】
: 不知道u16string是不是utf-16.
: utf-16原本对应unicode基本平面(65536个字符，其中汉字为gbk+cjk-extA，约有2.8万个)，后来unicode字符集不断扩充，超出了基本平面的容纳范围。超出基本平面的汉字utf-16编码就不是双字节编码了，这时utf-16就名不符实了，它成了和utf-8一样的变长编码。当然我们一般人用的字
: 符都在基本平面内，几乎不太可能用到超出两个字节的utf-16字符。所以实践中，还是有不少人直接把utf-16的字符串当成定长变码来对待。但理论上，utf-16已经不符合它原来的定义了（于是出现了utf-32，用来代替utf-16，这个是真正的定长编码方式，不过与utf-8比起来，空间效率更
: ...................
--
FROM 58.32.190.*

最终用C++的项目，那都是没得选
【 在 hgoldfish 的大作中提到: 】
: 那么你为啥不用其它语言呢？
: 相信本版的 C++ 程序员们，大多数都会一两种其它语言。
:
--
FROM 111.19.6.*