C++11之后,对源代码增加了UTF8和UCS4的支持(Windows内部使用Unicode,因为nt内核用的是ucs2,那是89年,utf8到了92年才发明出来)

在C++编程中, 我们常打交道的无非是编辑器和编译器, 对编辑器起来说,我们常遇到就是乱码问题, 比如中文注释显示或是保存不了等, 解决办法就是把你的文件保存成Unicode(UTF8)。

对于编译器来说, 编码方式取决于它对C++标准的支持程度, 比如C++ 11以前,字符串我们只能指定成2种:一种是MBCS,如char* p="abc哈哈"; 还有一种是UCS2, 比如wchar_t*p = L"abc哈哈", 这样编译器就知道你要表示的字符串类型。C++11之后,标准增加了UTF8和UCS4的支持, 比如char* p=u8"abc哈哈"表示UTF8,wchar_t* p=u"abc哈哈"表示UCS2(实际上和L"xxxx"一样), char32_t* p=U"abc哈哈"表示UCS4。这里要区分编译期和运行期, 尽管C++11之前在编译期我们没法告诉编译器我们这个常量串是UTF8格式的,但是程序运行期我们还是可以使用所有的编码式(MBCS/UTF8/UCS2/UCS4), 因为这些最终在内存里都是二进制流。

另外C++11还增加了UTF8, UCS2, UCS4相互转码的支持:

std::codecvt_utf8 封装了UTF8相关的编码转换
std::codecvt_utf16 封装了UCS2相关的编码转换
std::codecvt_utf8_utf16 封装了UTF8与UCS2的编码转换

对于C++跨平台开发, 我们经常遇到的就是默认用那种编码方式的问题,我们会发现Windows 的UCS2解决方案对其他平台来说是个异类, 一般来说有2种解决方法:

一种是统一用UTF8 , 但是这样对Windows来说有点麻烦, 因为Windows的API都是UCS2的,所以这种方式意味着任何字符串在传给Windows API 之前都要从UTF8转成UCS2; 还有一种就是用#define宏了, Windows上将字符串相关宏全都定义成UCS2, 其他平台则全都定义成UTF8, 该方式要求就你在写代码时头脑要比较清醒,因为同样的代码在不同平台上的编码格式是不一样的。

一直很好奇,谁知道Windows为什么不用UTF8,非要搞得和其他平台不一样?

因为nt内核用的是ucs2,那是89年,utf8到了92年才发明出来。

http://www.cppblog.com/weiym/archive/2015/07/25/211370.html

时间: 2024-11-05 14:43:06

C++11之后,对源代码增加了UTF8和UCS4的支持(Windows内部使用Unicode,因为nt内核用的是ucs2,那是89年,utf8到了92年才发明出来)的相关文章

【CEF3编译】增加对mp3/mp4等格式支持的编译手记 完成编译,增加mp3/mp4等格式支持(3) 2018-5-21

经过前两天的准备工作,好在有几位前辈们留下的"血泪史" -( ̄▽ ̄-) 实际操刀的过程中并没有遇到太大的困难,今天终于可以开始尝试编译cef.master分支了. PS: 以下摘自官方: Create a Debug build of CEF/Chromium using Ninja. Edit the CEF source code at "~/code/chromium_git/chromium/src/cef" and repeat this step mul

C++11 新特性一增加了 __func__宏

在C11的新特性中,新增加了宏定义 __func__ 用来描述直接得到当函数的名称. 如: const char* hello() {return __func__;} //返回hello. 也可作为初始化参数传递如: struct TestStruct { TestStruct (): name(__func__){}  //返回TestStruct结构体类型. const char* name; }; __VAR_ARGS__ 表示可变参数的宏串,如下 #define LOG(...) {\

HPUX 11.31 LVM VG 增加Max PV 方法之一

场景:有一个文件系统空间不足,需要扩容空间,准备工作中发现,文件系统对应LV所在VG 的"Free PE" 值是0,VG已经没有空间了,因此要先扩容VG,再扩容LV,但是扩容VG发现"MAX PV"已经到达限制了再增加PV,必需要先增加"MAX PV"具体信息如下: #vgdisplay /dev/datavg --- Volume groups --- VG Name                     /dev/datavg VG Wri

LINUX 源代码安装与配置samba服务,支持从windows上读写LINUX文件。

###动机###在windows编写代码文件比较方便,因为有source insight.但是需要在LINUX上编译.一种办法就是使用samba文件共享. [1] 下载samba代码.按照configure && make && make install, 编译安装samba.NOTE: configure遇到错误时,按照提示修改(一般是缺少包导致的错误).一般是安装到: /usr/local/samba/子目录有:/usr/local/samba/bin/usr/loca

python中文utf8编码后是占3个字符,unicode汉字为2字节

一个中文utf8编码后是占3个字符,所以求长度的函数可以这样写 def str_len(str): try: row_l=len(str) utf8_l=len(str.encode('utf-8')) return (utf8_l-row_l)/2+row_l except: return None return None unicode中汉字为两字节, utf-8中汉字为三字节 https://en.wikipedia.org/wiki/Unicode https://en.wikipedi

为co-body增加xml等文本类型的支持

co-body是TJ大牛编写的使用Generator解析表单的模块. 当前co-body仅显示支持:application/json.application/x-www-form-urlencoded和text/plain,而有时候我们需要接收xml格式的数据(其类型为text/xml),可以通过如下方式增加其对xml的支持: 在lib目录下复制json.js文件一份,改名为textxml.js,修改try{ done(null, JSON.parse(str); }为try{ done(nul

UTF-8、UTF-16、UTF-32编码的相互转换

最近在考虑写一个可以跨平台的通用字符串类,首先需要搞定的就是编码转换问题. vs默认保存代码文件,使用的是本地code(中文即GBK,日文即Shift-JIS),也可以使用带BOM的UTF-8.gcc则是UTF-8,有无BOM均可(源代码的字符集可以由参数-finput-charset指定).那么源代码可以采用带BOM的UTF-8来保存.而windows下的unicode是UTF-16编码:linux则使用UTF-8或UTF-32.因此不论在哪种系统里,程序在处理字符串时都需要考虑UTF编码之间

关于字符集,编码格式,大小端的简单总结

只要你和计算机打交道,这些问题可以说是天天会遇到,但是很多人是似懂非懂, 能真正完全理解的人却不多, 下面是个人的一些理解,有错欢迎指正. 最早的计算机只支持ASCII码, 具体来说就是用1个字节(最高位为0, 没有用)表示0到127,总共128个字符, 这样就可以完全满足英语应用的要求了. 后来扩展到欧洲语系,理论上一个字节可以表示256个字符, 欧洲人就把剩余的128个字符(最高位为1)按照自己语言(法语,德语...)的要求扩充应用了起来, 好像也能满足需要. 然后又到了亚洲国家,比如中国,

python网页爬虫小项目开发

这是我最近接的一个小项目,花了是整整四天多时间,最终老师也很好,给了两千块的报酬. 任务是将http://www.examcoo.com/index/detail/mid/7网站下所有的试卷里的试题全部提取出来,首先按照题型进行分类,接着分析出题目的类型 类别 来源 出题时间等等信息,最终将这些信息转化到excel表格中,excel中的数据有着统一的格式.其中有些信息有关医学,故而需要自行了解. 由于仅仅是是为了完成最终的任务,故而没有使用什么爬虫框架之类的,也没有使用什么数据库来保存数据,尽量