严格的Unicode编程需要哪些先决条件？
这是否意味着我的代码不应该char在任何地方使用类型,并且需要使用可以处理的函数wint_t和wchar_t？
在这种情况下,多字节字符序列的作用是什么？
C标准(C99)提供宽字符和多字节字符,但由于无法保证这些宽字符可以容纳的内容,因此它们的价值有限.对于给定的实现,它们提供了有用的支持,但是如果您的代码必须能够在实现之间移动,则不足以保证它们将是有用的.
因此,Hans van Eck建议的方法(即编写ICU的包装器 - 用于Unicode的国际组件 - 库)是合理的,IMO.
UTF-8编码有许多优点,其中之一就是如果你不弄乱数据(例如通过截断它),那么它可以被不完全了解UTF-8错综复杂的函数复制.编码.绝对不是这样的wchar_t.
完整的Unicode是21位格式.也就是说,Unicode保留了从U + 0000到U + 10FFFF的代码点.
关于UTF-8,UTF-16和UTF-32格式(其中UTF代表Unicode转换格式 - 参见Unicode)的一个有用的事情是,您可以在三种表示之间进行转换而不会丢失信息.每个都可以代表其他人可以代表的任何东 UTF-8和UTF-16都是多字节格式.
众所周知,UTF-8是一种多字节格式,其结构非常谨慎,可以从字符串中的任何一点开始可靠地找到字符串中字符的开头.单字节字符的高位设置为零.多字节字符的第一个字符以位模式110,1110或11110中的一个开头(对于2字节,3字节或4字节字符),后续字节始终从10开始.连续字符始终在范围0x80 .. 0xBF.有规则必须以尽可能小的格式表示UTF-8字符.这些规则的一个结果是字节0xC0和0xC1(也是0xF5..0xFF)不能出现在有效的UTF-8数据中.
U+0000 .. U+007F 1 byte 0xxx xxxx U+0080 .. U+07FF 2 bytes 110x xxxx 10xx xxxx U+0800 .. U+FFFF 3 bytes 1110 xxxx 10xx xxxx 10xx xxxx U+10000 .. U+10FFFF 4 bytes 1111 0xxx 10xx xxxx 10xx xxxx 10xx xxxx
最初,希望Unicode是一个16位代码集,一切都适合16位代码空间.不幸的是,现实世界更复杂,必须扩展到当前的21位编码.
因此,UTF-16是用于'基本多语言平面'的单个单元(16位字)代码集,意味着具有Unicode代码的字符指向U + 0000 .. U + FFFF,但是使用两个单位(32位)用于超出此范围的字符.因此,使用UTF-16编码的代码必须能够处理可变宽度编码,就像UTF-8必须一样.双单元字符的代码称为代理.
代理是来自两个特殊范围的Unicode值的代码点,保留用作UTF-16中成对代码单元的前导和尾随值.领先的,也称为高的代理人是从U + D800到U + DBFF,而尾随或低代理是从U + DC00到U + DFFF.它们被称为代理,因为它们不直接表示字符,而只是作为一对字符.
当然,UTF-32可以在单个存储单元中编码任何Unicode代码点.它对计算有效,但对存储无效.
您可以在ICU和Unicode网站上找到更多信息.
C11标准改变了规则,但即使是现在(2017年中),并非所有实施都赶上了变化.C11标准总结了Unicode支持的更改:
Unicode字符和字符串(
)(最初在ISO/IEC TR 19769:2004中指定)
以下是功能的最小概述.规范包括:
6.4.3通用字符名称
语法
universal-character-name:
\uhex-quad
\Uhex-quad hex-quad
hex-quad:
十六进制数字十六进制数字十六进制数字十六进制数字7.28 Unicode实用程序
标头
声明了用于操作Unicode字符的类型和函数.声明的类型
mbstate_t(在7.29.1中描述)和size_t(在7.19中描述);char16_t这是一个用于16位字符的无符号整数类型,与
uint_least16_t(在7.20.1.2中描述)的类型相同; 和char32_t这是一个用于32位字符的无符号整数类型,与类型相同
uint_least32_t(也在7.20.1.2中描述).
(翻译交叉引用:size_t,
mbstate_t和uint_least16_t和uint_least32_t.)
mbrtoc16()
c16rtomb()
mbrtoc32()
c32rtomb()
有关使用\unnnn或\U00nnnnnn符号在标识符中使用哪些Unicode字符的规则.您可能必须在标识符中主动激活对此类字符的支持.例如,GCC要求-fextended-identifiers在标识符中允许这些.
请注意,macOS Sierra(10.12.5),但仅限于一个平台,不支持
请注意,这不是关于"严格的unicode编程"本身,而是一些实际经验.
我们在公司所做的是围绕IBM的ICU库创建一个包装器库.包装器库具有UTF-8接口,并在需要调用ICU时转换为UTF-16.在我们的例子中,我们并没有过多担心性能问题.当性能成为问题时,我们还提供了UTF-16接口(使用我们自己的数据类型).
应用程序可以保持原样(使用char),但在某些情况下,他们需要了解某些问题.例如,我们使用一个包装器代替strncpy(),避免切断UTF-8序列.在我们的例子中,这已经足够了,但也可以考虑检查组合字符.我们还有用于计算代码点数量,字形数量等的包装器.
当与其他系统连接时,我们有时需要进行自定义字符组合,因此您可能需要一些灵活性(取决于您的应用程序).
我们不使用wchar_t.使用ICU避免了可移植性方面的意外问题(当然不是其他意外问题:-).
这个FAQ是一个丰富的信息.在该页面和Joel Spolsky的这篇文章之间,你将有一个良好的开端.
我在此过程中得出的一个结论是:
wchar_t在Windows上是16位,但在其他平台上不一定是16位.我认为这是Windows上的一个必要的恶魔,但可能在其他地方可以避免.它在Windows上很重要的原因是你需要它来使用名称中包含非ASCII字符的文件(以及W版本的函数).
请注意,采用wchar_t字符串的Windows API需要UTF-16编码.另请注意,这与UCS-2不同.注意代理对.该测试页面具有启发性测试.
如果你在Windows编程,你不能使用fopen(),fread(),fwrite()等,因为他们只需要char *和不理解UTF-8编码.使可移植性变得痛苦.
要进行严格的Unicode编程:
仅使用字符串的API也支持Unicode(不 strlen,strcpy...但他们的同行WideString的wstrlen,wsstrcpy...)
处理文本块时,使用允许存储Unicode字符(utf-7,utf-8,utf-16,ucs-2,...)的编码而不会丢失.
检查您的操作系统默认字符集是否与Unicode兼容(例如:utf-8)
使用Unicode兼容的字体(例如arial_unicode)
多字节字符序列是一种在UTF-16编码(通常使用的编码)之前编码的编码,wchar_t在我看来它只是Windows版本.
我从来没有听说过wint_t.
京公网安备 11010802040832号 | 京ICP备19059560号-6 