blocks|key|3530000|text|要执行严格的Unicode编程：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3530001|3530002|仅使用支持Unicode的字符串API(不支持strlen、strcpy+...但是它们对应的宽字符串wstrlen，wsstrcpy，...)+|unordered-list-item|offset|length|style|CODE|3530003|在处理文本块时，使用允许存储Unicode字符的编码(utf-7，utf-8，utf-16，ucs-2，...)没有损失。|3530004|检查操作系统默认字符集是否兼容Unicode+(例如:+utf-8)+|3530005|使用兼容Unicode的字体(例如arial_unicode)+|3530006|3530007|多字节字符序列是一种早于UTF-16编码(通常与wchar_t一起使用)的编码，在我看来，它只适用于Windows。|3530008|我从来没听说过wint_t。|3530009|entityMap^0|0|0|N|6|U|6|1F|7|1N|8|0|0|0|0|0|O|7|0|7|6|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Y|8|@$F|Z|G|10|H|I]|$F|11|G|12|H|I]|$F|13|G|14|H|I]|$F|15|G|16|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|18|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|19|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@$F|1C|G|1D|H|I]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@$F|1F|G|1G|H|I]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|V|$]]

To do strict Unicode programming: 

<ul>
<li>Only use string APIs that are Unicode aware (NOT <code>strlen</code>, <code>strcpy</code>, ... but their widestring counterparts <code>wstrlen</code>, <code>wsstrcpy</code>, ...) </li>
<li>When dealing with a block of text, use an encoding that allows storing Unicode chars (utf-7, utf-8, utf-16, ucs-2, ...) without loss. </li>
<li>Check that your OS default character set is Unicode compatible (ex: utf-8) </li>
<li>Use fonts that are Unicode compatible (e.g. arial_unicode) </li>
</ul>

Multi-byte character sequences is an encoding that pre-dates the UTF-16 encoding (the one used normally with <code>wchar_t</code>) and it seems to me it is rather Windows-only. 

I've never heard of <code>wint_t</code>.

blocks|key|1018699|text|请注意，这本身并不是关于“严格的unicode编程”，而是一些实际经验。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1018700|我们公司所做的就是围绕IBM的ICU库创建一个包装器库。包装库具有UTF-8接口，并在需要调用ICU时转换为UTF-16。在我们的例子中，我们并不太担心性能问题。当性能是一个问题时，我们还提供了UTF-16接口(使用我们自己的数据类型)。|1018701|应用程序可以在很大程度上保持原样(使用char)，尽管在某些情况下，它们需要了解某些问题。例如，代替strncpy()，我们使用了一个包装器来避免截断UTF-8序列。在我们的例子中，这已经足够了，但也可以考虑检查组合字符。我们还提供了用于计算码点数量、字素数量等的包装器。|1018702|在与其他系统交互时，我们有时需要进行自定义字符组合，因此您可能需要一些灵活性(取决于您的应用程序)。|1018703|我们不使用wchar_t。使用ICU可以避免在可移植性方面出现意想不到的问题(当然，不会出现其他意想不到的问题:-)。|1018704|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Note that this is not about "strict unicode programming" per se, but some practical experience.

What we did at my company was to create a wrapper library around IBM's ICU library. The wrapper library has a UTF-8 interface and converts to UTF-16 when it is necessary to call ICU. In our case, we did not worry too much about performance hits. When performance was an issue, we also supplied UTF-16 interfaces (using our own datatype).

Applications could remain largely as-is (using char), although in some cases they need to be aware of certain issues. For instance, instead of strncpy() we use a wrapper which avoids cutting off UTF-8 sequences. In our case, this is sufficient, but one could also consider checks for combining characters. We also have wrappers for counting the number of codepoints, the number of graphemes, etc.

When interfacing with other systems, we sometimes need to do custom character composition, so you may need some flexibility there (depending on your application).

We do not use wchar_t. Using ICU avoids unexpected issues in portability (but not other unexpected issues, of course :-).

blocks|key|4377426|text|据我所知，wchar_t是依赖于实现的(从这个wiki+article可以看出)。而且它不是unicode。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4377427|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Wide_character^0|N|C|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

From what I know, wchar_t is implementation dependent (as can be seen from this <a href="http://en.wikipedia.org/wiki/Wide_character" rel="nofollow noreferrer">wiki article</a>). And it's not unicode.

blocks|key|4377517|text|基本上，您希望将内存中的字符串作为wchar_t数组而不是char进行处理。当您执行任何类型的I/O+(如读/写文件)时，您可以使用UTF-8+(这可能是最常见的编码)进行编码/解码，这很容易实现。只要搜索一下RFC就行了。所以在内存中没有任何东西应该是多字节的。一个wchar_t代表一个字符。但是，在进行序列化时，需要将其编码为UTF-8之类的格式，其中某些字符由多个字节表示。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4377518|您还必须为宽字符串编写新版本的strcmp等，但这不是一个大问题。最大的问题将是与只接受char数组的库/现有代码进行互操作。|4377519|当涉及到sizeof(wchar_t)时(如果你想做好它，你需要4个字节)，如果你需要的话，你可以用typedef/macro+hack将它重新定义为更大的大小。|4377520|entityMap^0|H|7|3Q|7|0|F|6|0|4|F|1E|7|1M|5|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|T|8|@$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|K|$]]

You basically want to deal with strings in memory as <code>wchar_t</code> arrays instead of char. When you do any kind of I/O (like reading/writing files) you can encode/decode using UTF-8 (this is probably the most common encoding) which is simple enough to implement. Just google the RFCs. So in-memory nothing should be multi-byte. One <code>wchar_t</code> represents one character. When you come to serializing however, that's when you need to encode to something like UTF-8 where some characters are represented by multiple bytes.

You'll also have to write new versions of <code>strcmp</code> etc. for the wide character strings, but this isn't a big issue. The biggest problem will be interop with libraries/existing code that only accept char arrays.

And when it comes to <code>sizeof(wchar_t)</code> (you will need 4 bytes if you want to do it right) you can always redefine it to a larger size with <code>typedef</code>/<code>macro</code> hacks if you need to.

blocks|key|1018806|text|C99或更早版本|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1018807|C标准(C99)提供了宽字符和多字节字符，但是由于不能保证这些宽字符可以容纳的内容，它们的值在某种程度上是有限的。对于给定的实现，它们提供了有用的支持，但如果您的代码必须能够在实现之间移动，则不能充分保证它们将是有用的。|1018808|因此，Hans+van+Eck建议的方法(即为Unicode库编写ICU+-+International组件的包装器)是合理的。|1018809|UTF-8编码有很多优点，其中之一是，如果您不去处理数据(例如，通过截断它)，那么它可以被不完全了解UTF-8编码复杂性的函数复制。这绝对不是wchar_t的情况。|offset|length|style|CODE|1018810|完整的Unicode是一种21位格式。也就是说，Unicode保留了从U%2B0000到U%2B10FFFF的代码点。|1018811|UTF-8、UTF-16和UTF-32格式(其中UTF代表Unicode转换格式-参见Unicode)的一个有用之处在于，您可以在这三种表示之间进行转换，而不会丢失信息。每一个都可以代表其他人可以代表的任何东西。UTF-8和UTF-16都是多字节格式。|1018812|众所周知，UTF-8是一种多字节格式，具有精心的结构，可以可靠地找到字符串中字符的开头，从字符串中的任何位置开始。单字节字符的高位设置为零。多字节字符的第一个字符以位模式110、1110或11110之一开始(对于2字节、3字节或4字节字符)，后续字节始终以10开始。连续字符始终在0x80范围内。0xBF。有一些规则要求UTF-8字符必须以最小可能的格式表示。这些规则的一个后果是字节0xC0和0xC1+(也就是0xF5..0xFF)不能出现在有效的UTF-8数据中。|1018813|+U%2B0000+..+++U%2B007F++1+byte+++0xxx+xxxx
+U%2B0080+..+++U%2B07FF++2+bytes++110x+xxxx+++10xx+xxxx
+U%2B0800+..+++U%2BFFFF++3+bytes++1110+xxxx+++10xx+xxxx+++10xx+xxxx
U%2B10000+..+U%2B10FFFF++4+bytes++1111+0xxx+++10xx+xxxx+++10xx+xxxx+++10xx+xxxx|code-block|syntax|javascript|1018814|最初，人们希望Unicode是一个16位的代码集，所有的东西都可以放在一个16位的代码空间中。不幸的是，现实世界更加复杂，它必须扩展到目前的21位编码。|1018815|因此，UTF-16是用于“基本多语言平面”的单个单元(16位字)代码集，这意味着具有Unicode代码点U%2B0000的字符。U%2BFFFF，但对此范围之外的字符使用两个单位(32位)。因此，使用UTF-16编码的代码必须能够处理可变宽度编码，就像UTF-8一样。双单位字符的代码称为代理。|1018816|1018817|代理是来自两个特殊范围的Unicode值的代码点，保留用作UTF16中成对代码单元的前导值和拖尾值。领先的，也称为高，代理人是从U%2BD800到U%2BDBFF，和尾随，或低，代理人是从U%2BDC00到U%2BDFFF。它们被称为代理，因为它们不直接表示字符，而只是作为一对字符。|blockquote|1018818|1018819|1018820|当然，UTF-32可以在单个存储单元中对任何Unicode代码点进行编码。它对于计算是有效的，但对于存储是无效的。|1018821|你可以在ICU和Unicode网站上找到更多的信息。|1018822|C11和<uchar.h>|1018823|C11标准改变了规则，但直到现在(2017年中)，并不是所有的实现都跟上了这些变化。C11标准将Unicode支持的更改总结为：|1018824|1018825|1018826|1018827|1018828|Unicode字符和字符串(<uchar.h>)+(最初在ISO/IEC+TR+19769:2004中指定)|unordered-list-item|1018829|1018830|下面是对该功能的一个简单概述。该规范包括：|1018831|1018832|+6.4.3通用字符名称|1018833|1018834|语法|BOLD|1018835|通用字符名称：|1018836|\u十六进制四边形|1018837|\U十六进制-四进制|1018838|十六进制四元组：|1018839|十六进制数字十六进制数字十六进制数字|1018840|7.28+Unicode实用程序<uchar.h>|1018841|头<uchar.h>声明了用于操作Unicode字符的类型和函数。|1018842|声明的类型是mbstate_t+(在7.29.1中描述)和size_t+(在7.19中描述)；|1018843|char16_t|1018844|它是用于16位字符的无符号整数类型，与uint_least16_t相同(在7.20.1.2中描述)；以及|1018845|char32_t|1018846|它是用于32位字符的无符号整数类型，与uint_least32_t相同(也在7.20.1.2中描述)。|1018847|1018848|(翻译交叉引用：<stddef.h>定义size_t，<wchar.h>定义mbstate_t，<stdint.h>定义uint_least16_t和uint_least32_t。)<uchar.h>头还定义了一组最小的(可重新启动的)转换函数：|1018849|1018850|1018851|1018852|1018853|mbrtoc16()|1018854|c16rtomb()|1018855|mbrtoc32()|1018856|c32rtomb()|1018857|1018858|在使用\unnnn或\U00nnnnnn表示法的标识符中可以使用哪些Unicode字符是有规则的。您可能必须主动激活对标识符中此类字符的支持。例如，GCC要求-fextended-identifiers在标识符中允许这些。|1018859|请注意，仅举一个平台的例子，macOS+that+(10.12.5)不支持<uchar.h>。|1018860|entityMap|0|LINK|mutability|MUTABLE|url|http://unicode.org/|1|http://icu-project.org/^0|0|0|0|1Z|7|0|0|17|7|0|0|0|0|0|0|0|0|0|0|0|4|3|1|0|4|9|0|0|0|0|0|0|E|9|0|0|0|0|0|0|0|2|0|0|0|2|0|0|2|0|0|0|G|9|0|1|9|0|6|9|T|6|0|0|J|E|0|0|J|E|0|0|8|A|K|6|R|9|12|9|1C|A|1O|E|23|E|2J|9|0|0|0|0|0|0|A|0|0|A|0|0|A|0|0|A|0|0|3|6|A|A|27|M|0|11|9|0^^$0|@$1|2|3|4|5|6|7|3D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|3E|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|3F|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|3G|8|@$H|3H|I|3I|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|3J|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|3K|8|@]|9|@$H|3L|I|3M|1|3N]]|A|$]]|$1|P|3|Q|5|6|7|3O|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|3P|8|@]|9|@]|A|$U|V]]|$1|W|3|X|5|6|7|3Q|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|3R|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|3S|8|@]|9|@]|A|$]]|$1|11|3|12|5|13|7|3T|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|3U|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|3V|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|3W|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|3X|8|@]|9|@$H|3Y|I|3Z|1|40]]|A|$]]|$1|1A|3|1B|5|6|7|41|8|@$H|42|I|43|J|K]]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|44|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|45|8|@]|9|@]|A|$]]|$1|1F|3|-4|5|13|7|46|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|47|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|48|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|1K|7|49|8|@$H|4A|I|4B|J|K]]|9|@]|A|$]]|$1|1L|3|-4|5|6|7|4C|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|4D|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|4E|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|13|7|4F|8|@]|9|@]|A|$]]|$1|1R|3|-4|5|6|7|4G|8|@]|9|@]|A|$]]|$1|1S|3|1T|5|6|7|4H|8|@$H|4I|I|4J|J|1U]]|9|@]|A|$]]|$1|1V|3|1W|5|6|7|4K|8|@]|9|@]|A|$]]|$1|1X|3|1Y|5|6|7|4L|8|@$H|4M|I|4N|J|K]]|9|@]|A|$]]|$1|1Z|3|20|5|6|7|4O|8|@$H|4P|I|4Q|J|K]]|9|@]|A|$]]|$1|21|3|22|5|6|7|4R|8|@]|9|@]|A|$]]|$1|23|3|24|5|6|7|4S|8|@]|9|@]|A|$]]|$1|25|3|26|5|6|7|4T|8|@$H|4U|I|4V|J|K]]|9|@]|A|$]]|$1|27|3|28|5|6|7|4W|8|@$H|4X|I|4Y|J|K]]|9|@]|A|$]]|$1|29|3|2A|5|6|7|4Z|8|@$H|50|I|51|J|K]|$H|52|I|53|J|K]]|9|@]|A|$]]|$1|2B|3|2C|5|6|7|54|8|@]|9|@]|A|$]]|$1|2D|3|2E|5|6|7|55|8|@$H|56|I|57|J|K]]|9|@]|A|$]]|$1|2F|3|2G|5|6|7|58|8|@]|9|@]|A|$]]|$1|2H|3|2I|5|6|7|59|8|@$H|5A|I|5B|J|K]]|9|@]|A|$]]|$1|2J|3|-4|5|6|7|5C|8|@]|9|@]|A|$]]|$1|2K|3|2L|5|6|7|5D|8|@$H|5E|I|5F|J|K]|$H|5G|I|5H|J|K]|$H|5I|I|5J|J|K]|$H|5K|I|5L|J|K]|$H|5M|I|5N|J|K]|$H|5O|I|5P|J|K]|$H|5Q|I|5R|J|K]|$H|5S|I|5T|J|K]]|9|@]|A|$]]|$1|2M|3|-4|5|6|7|5U|8|@]|9|@]|A|$]]|$1|2N|3|-4|5|13|7|5V|8|@]|9|@]|A|$]]|$1|2O|3|-4|5|6|7|5W|8|@]|9|@]|A|$]]|$1|2P|3|-4|5|6|7|5X|8|@]|9|@]|A|$]]|$1|2Q|3|2R|5|1K|7|5Y|8|@$H|5Z|I|60|J|K]]|9|@]|A|$]]|$1|2S|3|2T|5|1K|7|61|8|@$H|62|I|63|J|K]]|9|@]|A|$]]|$1|2U|3|2V|5|1K|7|64|8|@$H|65|I|66|J|K]]|9|@]|A|$]]|$1|2W|3|2X|5|1K|7|67|8|@$H|68|I|69|J|K]]|9|@]|A|$]]|$1|2Y|3|-4|5|6|7|6A|8|@]|9|@]|A|$]]|$1|2Z|3|30|5|6|7|6B|8|@$H|6C|I|6D|J|K]|$H|6E|I|6F|J|K]|$H|6G|I|6H|J|K]]|9|@]|A|$]]|$1|31|3|32|5|6|7|6I|8|@$H|6J|I|6K|J|K]]|9|@]|A|$]]|$1|33|3|-4|5|6|7|6L|8|@]|9|@]|A|$]]]|34|$35|$5|36|37|38|A|$39|3A]]|3B|$5|36|37|38|A|$39|3C]]]]

<h3>C99 or earlier</h3>

The C standard (C99) provides for wide characters and multi-byte characters, but since there is no guarantee about what those wide characters can hold, their value is somewhat limited. For a given implementation, they provide useful support, but if your code must be able to move between implementations, there is insufficient guarantee that they will be useful.

Consequently, the approach suggested by Hans van Eck (which is to write a wrapper around the ICU - International Components for Unicode - library) is sound, IMO.

The UTF-8 encoding has many merits, one of which is that if you do not mess with the data (by truncating it, for example), then it can be copied by functions that are not fully aware of the intricacies of UTF-8 encoding. This is categorically not the case with <code>wchar_t</code>.

Unicode in full is a 21-bit format. That is, Unicode reserves code points from U+0000 to U+10FFFF.

One of the useful things about the UTF-8, UTF-16 and UTF-32 formats (where UTF stands for Unicode Transformation Format - see <a href="http://unicode.org/" rel="noreferrer">Unicode</a>) is that you can convert between the three representations without loss of information. Each can represent anything the others can represent. Both UTF-8 and UTF-16 are multi-byte formats.

UTF-8 is well known to be a multi-byte format, with a careful structure that makes it possible to find the start of characters in a string reliably, starting at any point in the string. Single-byte characters have the high-bit set to zero. Multi-byte characters have the first character starting with one of the bit patterns 110, 1110 or 11110 (for 2-byte, 3-byte or 4-byte characters), with subsequent bytes always starting 10. The continuation characters are always in the range 0x80 .. 0xBF. There are rules that UTF-8 characters must be represented in the minimum possible format. One consequence of these rules is that the bytes 0xC0 and 0xC1 (also 0xF5..0xFF) cannot appear in valid UTF-8 data.

<pre><code> 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
</code></pre>

Originally, it was hoped that Unicode would be a 16-bit code set and everything would fit into a 16-bit code space. Unfortunately, the real world is more complex, and it had to be expanded to the current 21-bit encoding.

UTF-16 thus is a single unit (16-bit word) code set for the 'Basic Multilingual Plane', meaning the characters with Unicode code points U+0000 .. U+FFFF, but uses two units (32-bits) for characters outside this range. Thus, code that works with the UTF-16 encoding must be able to handle variable width encodings, just like UTF-8 must. The codes for the double-unit characters are called surrogates.

<blockquote>
 Surrogates are code points from two special ranges of Unicode values, reserved for use as the leading, and trailing values of paired code units in UTF-16. Leading, also called high, surrogates are from U+D800 to U+DBFF, and trailing, or low, surrogates are from U+DC00 to U+DFFF. They are called surrogates, since they do not represent characters directly, but only as a pair.
</blockquote>

UTF-32, of course, can encode any Unicode code point in a single unit of storage. It is efficient for computation but not for storage.

You can find a lot more information at the <a href="http://icu-project.org/" rel="noreferrer">ICU</a> and Unicode web sites.

<h3>C11 and <code>&lt;uchar.h&gt;</code></h3>

The C11 standard changed the rules, but not all implementations have caught up with the changes even now (mid-2017). The C11 standard summarizes the changes for Unicode support as:

<blockquote>
 <ul>
 <li>Unicode characters and strings (<code>&lt;uchar.h&gt;</code>) (originally specified in
 ISO/IEC TR 19769:2004)</li>
 </ul>
</blockquote>

What follows is a bare minimal outline of the functionality. The specification includes:

<blockquote>
 <h3>6.4.3 Universal character names</h3>
 
 Syntax 
 universal-character-name: 
 &nbsp;&nbsp;&nbsp;&nbsp;<code>\u</code> hex-quad 
 &nbsp;&nbsp;&nbsp;&nbsp;<code>\U</code> hex-quad hex-quad 
 hex-quad: 
 &nbsp;&nbsp;&nbsp;&nbsp;hexadecimal-digit hexadecimal-digit
 hexadecimal-digit hexadecimal-digit
 
 <h3>7.28 Unicode utilities <code>&lt;uchar.h&gt;</code></h3>
 
 The header <code>&lt;uchar.h&gt;</code> declares types and functions for manipulating Unicode characters.
 
 The types declared are <code>mbstate_t</code> (described in 7.29.1) and <code>size_t</code> (described in 7.19);

<pre><code>char16_t
</code></pre>
 
 which is an unsigned integer type used for 16-bit characters and is the same type as <code>uint_least16_t</code> (described in 7.20.1.2); and

<pre><code>char32_t
</code></pre>
 
 which is an unsigned integer type used for 32-bit characters and is the same type as <code>uint_least32_t</code> (also described in 7.20.1.2).
</blockquote>

(Translating the cross-references: <code>&lt;stddef.h&gt;</code> defines <code>size_t</code>,
<code>&lt;wchar.h&gt;</code> defines <code>mbstate_t</code>,
and <code>&lt;stdint.h&gt;</code> defines <code>uint_least16_t</code> and <code>uint_least32_t</code>.)
The <code>&lt;uchar.h&gt;</code> header also defines a minimal set of (restartable) conversion functions:

<blockquote>
 <ul>
 <li><code>mbrtoc16()</code></li>
 <li><code>c16rtomb()</code></li>
 <li><code>mbrtoc32()</code></li>
 <li><code>c32rtomb()</code></li>
 </ul>
</blockquote>

There are rules about which Unicode characters can be used in identifiers using the <code>\unnnn</code> or <code>\U00nnnnnn</code> notations. You may have to actively activate the support for such characters in identifiers. For example, GCC requires <code>-fextended-identifiers</code> to allow these in identifiers.

Note that macOS Sierra (10.12.5), to name but one platform, does not support <code>&lt;uchar.h&gt;</code>.

blocks|key|312544|text|这个FAQ包含了丰富的信息。在该页面和this+article+by+Joel+Spolsky之间，您将有一个良好的开端。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|312545|一路走来，我得出了一个结论：|312546|312547|wchar_t在Windows上是16位的，但在其他平台上不一定是16位。我认为这在Windows上是必要的，但在其他地方可能可以避免。它在Windows上很重要的原因是，您需要它来使用名称中包含非ASCII码的文件(以及W版本的functions).|unordered-list-item|style|CODE|312548|Note，接受wchar_t字符串的Windows需要使用UTF16编码。另请注意，这与UCS-2不同。注意代理项对。这个test+page有启发性的测试。|312549|如果你在Windows上编程，你不能使用fopen()，fread()，fwrite()等，因为它们只接受char+*，不理解UTF-8编码。让可移植性变得痛苦。|312550|312551|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cl.cam.ac.uk/~mgk25/unicode.html|1|http://www.joelonsoftware.com/articles/Unicode.html|2|http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt^0|2|3|0|J|S|1|0|0|0|0|7|0|7|7|1P|9|2|0|K|7|S|7|10|8|1H|6|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]|$A|16|B|17|1|18]]|C|$]]|$1|D|3|E|5|6|7|19|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|G|3|H|5|I|7|1B|8|@$A|1C|B|1D|J|K]]|9|@]|C|$]]|$1|L|3|M|5|I|7|1E|8|@$A|1F|B|1G|J|K]]|9|@$A|1H|B|1I|1|1J]]|C|$]]|$1|N|3|O|5|I|7|1K|8|@$A|1L|B|1M|J|K]|$A|1N|B|1O|J|K]|$A|1P|B|1Q|J|K]|$A|1R|B|1S|J|K]]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1U|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]|Y|$5|T|U|V|C|$W|Z]]|10|$5|T|U|V|C|$W|11]]]]

This <a href="http://www.cl.cam.ac.uk/~mgk25/unicode.html" rel="nofollow noreferrer">FAQ</a> is a wealth of info. Between that page and <a href="http://www.joelonsoftware.com/articles/Unicode.html" rel="nofollow noreferrer">this article by Joel Spolsky</a>, you'll have a good start.

One conclusion I came to along the way:

<ul>
<li><code>wchar_t</code> is 16 bits on Windows, but not necessarily 16 bits on other platforms. I think it's a necessary evil on Windows, but probably can be avoided elsewhere. The reason it's important on Windows is that you need it to use files that have non-ASCII characters in the name (along with the W version of functions).</li>
<li>Note that Windows APIs that take <code>wchar_t</code> strings expect UTF-16 encoding. Note also that this is different than UCS-2. Take note of surrogate pairs. This <a href="http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt" rel="nofollow noreferrer">test page</a> has enlightening tests.</li>
<li>If you're programming on Windows, you can't use <code>fopen()</code>, <code>fread()</code>, <code>fwrite()</code>, etc. since they only take <code>char *</code> and don't understand UTF-8 encoding. Makes portability painful.</li>
</ul>

blocks|key|3530448|text|最重要的是，总是要在文本和二进制数据之间做出明确的区分。尝试遵循Python+3.x+str+vs.+bytes或SQL+TEXT与BLOB的模型。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|3530449|不幸的是，C对"ASCII字符“和int_least8_t都使用了char，从而混淆了这个问题。您将希望执行以下操作：|3530450|typedef+char+UTF8;+//+for+code+units+of+UTF-8+strings
typedef+unsigned+char+BYTE;+//+for+binary+data|code-block|syntax|javascript|3530451|您可能还需要针对UTF-16和UTF-32代码单元的typedefs，但这要复杂得多，因为没有定义wchar_t的编码。你只需要一个预处理器#ifs。在C和C%2B%2B0x中一些有用的宏是：|3530452|3530453|__STDC_UTF_16__+-如果已定义，则类型Unicode存在且为UTF-16.|unordered-list-item|3530454|__STDC_UTF_32__+-如果已定义，则类型Unicode存在且为UTF-32.|3530455|__STDC_ISO_10646__+-如果已定义，则_Char32_t为UTF-32.|3530456|_WIN32+-在Windows上，wchar_t为UTF-16，即使这破坏了_Char16_t+-可用于确定_Char32_t的大小，但不能用于确定操作系统是否使用它来表示wchar_t。|3530457|3530458|3530459|这是否意味着我的代码不应该在任何地方使用字符类型，并且需要使用可以处理wint_t和wchar_t的函数？|blockquote|3530460|3530461|3530462|另请参阅：|3530463|3530464|UTF-8+or+UTF-16+or+UTF-32+or+UCS-2|3530465|Is+wchar_t+needed+for+Unicode+support?|3530466|3530467|不是的。UTF-8是一种使用char*字符串的完全有效的Unicode编码。它的优点是，如果你的程序对非ASCII字节是透明的(例如，一个行结束转换器，它作用于\r和\n，但通过其他字符不变)，你将不需要做任何更改！|3530468|如果你使用UTF-8，你需要改变char+=字符(例如，不要在循环中调用toupper+)或char+=屏幕列(例如，用于文本换行)的所有假设。|3530469|如果使用UTF-32，您将拥有固定宽度字符的简单性(但不是固定宽度字形，但需要更改所有字符串的类型)。|3530470|如果使用UTF-16，则必须放弃固定宽度字符的假设和8位代码单元的假设，这使得从单字节编码升级最困难。|3530471|我建议积极避免使用+wchar_t，因为它不是跨平台的:有时是UTF-32，有时是UTF-16，有时是前Unicode东亚编码。我推荐使用typedefs|3530472|更重要的是，avoid+TCHAR。|3530473|entityMap|0|LINK|mutability|MUTABLE|url|http://diveintopython3.org/strings.html|1|https://stackoverflow.com/questions/3473295/utf-8-or-utf-16-or-utf-32-or-ucs-2/|2|https://stackoverflow.com/questions/2259544/is-wchar-t-needed-for-unicode-support|3|http://koverflow.com/questions/234365/is-tchar-still-relevant/3002494#3002494^0|6|C|17|3|1F|5|1P|4|1U|4|W|O|0|0|H|C|X|4|0|0|1D|7|1Y|3|0|0|0|F|0|0|F|0|0|I|R|9|0|0|6|I|7|13|9|1J|9|2F|7|0|0|0|0|0|0|0|0|0|Y|1|0|0|12|2|0|0|E|5|28|2|2B|2|0|G|4|10|7|1A|4|0|0|0|A|7|1X|8|0|C|5|6|B|3|0^^$0|@$1|2|3|4|5|6|7|24|8|@$9|25|A|26|B|C]|$9|27|A|28|B|D]|$9|29|A|2A|B|D]|$9|2B|A|2C|B|D]|$9|2D|A|2E|B|D]]|E|@$9|2F|A|2G|1|2H]]|F|$]]|$1|G|3|H|5|6|7|2I|8|@$9|2J|A|2K|B|D]|$9|2L|A|2M|B|D]]|E|@]|F|$]]|$1|I|3|J|5|K|7|2N|8|@]|E|@]|F|$L|M]]|$1|N|3|O|5|6|7|2O|8|@$9|2P|A|2Q|B|D]|$9|2R|A|2S|B|D]]|E|@]|F|$]]|$1|P|3|-4|5|6|7|2T|8|@]|E|@]|F|$]]|$1|Q|3|R|5|S|7|2U|8|@$9|2V|A|2W|B|D]]|E|@]|F|$]]|$1|T|3|U|5|S|7|2X|8|@$9|2Y|A|2Z|B|D]]|E|@]|F|$]]|$1|V|3|W|5|S|7|30|8|@$9|31|A|32|B|D]|$9|33|A|34|B|D]]|E|@]|F|$]]|$1|X|3|Y|5|S|7|35|8|@$9|36|A|37|B|D]|$9|38|A|39|B|D]|$9|3A|A|3B|B|D]|$9|3C|A|3D|B|D]|$9|3E|A|3F|B|D]]|E|@]|F|$]]|$1|Z|3|-4|5|6|7|3G|8|@]|E|@]|F|$]]|$1|10|3|-4|5|6|7|3H|8|@]|E|@]|F|$]]|$1|11|3|12|5|13|7|3I|8|@]|E|@]|F|$]]|$1|14|3|-4|5|6|7|3J|8|@]|E|@]|F|$]]|$1|15|3|-4|5|6|7|3K|8|@]|E|@]|F|$]]|$1|16|3|17|5|6|7|3L|8|@]|E|@]|F|$]]|$1|18|3|-4|5|6|7|3M|8|@]|E|@]|F|$]]|$1|19|3|1A|5|S|7|3N|8|@]|E|@$9|3O|A|3P|1|3Q]]|F|$]]|$1|1B|3|1C|5|S|7|3R|8|@]|E|@$9|3S|A|3T|1|3U]]|F|$]]|$1|1D|3|-4|5|6|7|3V|8|@]|E|@]|F|$]]|$1|1E|3|1F|5|6|7|3W|8|@$9|3X|A|3Y|B|D]|$9|3Z|A|40|B|D]|$9|41|A|42|B|D]]|E|@]|F|$]]|$1|1G|3|1H|5|6|7|43|8|@$9|44|A|45|B|D]|$9|46|A|47|B|D]|$9|48|A|49|B|D]]|E|@]|F|$]]|$1|1I|3|1J|5|6|7|4A|8|@]|E|@]|F|$]]|$1|1K|3|1L|5|6|7|4B|8|@]|E|@]|F|$]]|$1|1M|3|1N|5|6|7|4C|8|@$9|4D|A|4E|B|D]|$9|4F|A|4G|B|D]]|E|@]|F|$]]|$1|1O|3|1P|5|6|7|4H|8|@$9|4I|A|4J|B|D]]|E|@$9|4K|A|4L|1|4M]]|F|$]]|$1|1Q|3|-4|5|6|7|4N|8|@]|E|@]|F|$]]]|1R|$1S|$5|1T|1U|1V|F|$1W|1X]]|1Y|$5|1T|1U|1V|F|$1W|1Z]]|20|$5|1T|1U|1V|F|$1W|21]]|22|$5|1T|1U|1V|F|$1W|23]]]]

The most important thing is to always make a clear distinction between text and binary data. Try to follow the model of <a href="http://diveintopython3.org/strings.html" rel="nofollow noreferrer">Python 3.x <code>str</code> vs. <code>bytes</code></a> or SQL <code>TEXT</code> vs. <code>BLOB</code>.

Unfortunately, C confuses the issue by using <code>char</code> for both "ASCII character" and <code>int_least8_t</code>. You'll want to do something like:

<pre><code>typedef char UTF8; // for code units of UTF-8 strings
typedef unsigned char BYTE; // for binary data
</code></pre>

You might want typedefs for UTF-16 and UTF-32 code units too, but this is more complicated because the encoding of <code>wchar_t</code> is not defined. You'll need to just a preprocessor <code>#if</code>s. Some useful macros in C and C++0x are:

<ul>
<li><code>__STDC_UTF_16__</code> &mdash; If defined, the type <code>_Char16_t</code> exists and is UTF-16.</li>
<li><code>__STDC_UTF_32__</code> &mdash; If defined, the type <code>_Char32_t</code> exists and is UTF-32.</li>
<li><code>__STDC_ISO_10646__</code> &mdash; If defined, then <code>wchar_t</code> is UTF-32.</li>
<li><code>_WIN32</code> &mdash; On Windows, <code>wchar_t</code> is UTF-16, even though this breaks the standard.</li>
<li><code>WCHAR_MAX</code> &mdash; Can be used to determine the size of <code>wchar_t</code>, but not whether the OS uses it to represent Unicode.</li>
</ul>

<blockquote>
 Does this imply that my code should
 not use char types anywhere and that
 functions need to be used that can
 deal with wint_t and wchar_t?
</blockquote>

See also: 

<ul>
<li><a href="https://stackoverflow.com/questions/3473295/utf-8-or-utf-16-or-utf-32-or-ucs-2/">UTF-8 or UTF-16 or UTF-32 or UCS-2</a></li>
<li><a href="https://stackoverflow.com/questions/2259544/is-wchar-t-needed-for-unicode-support">Is wchar_t needed for Unicode support?</a></li>
</ul>

No. UTF-8 is a perfectly valid Unicode encoding that uses <code>char*</code> strings. It has the advantage that if your program is transparent to non-ASCII bytes (e.g., a line ending converter which acts on <code>\r</code> and <code>\n</code> but passes through other characters unchanged), you'll need to make no changes at all!

If you go with UTF-8, you'll need to change all the assumptions that <code>char</code> = character (e.g., don't call <code>toupper</code> in a loop) or <code>char</code> = screen column (e.g., for text wrapping).

If you go with UTF-32, you'll have the simplicity of fixed-width characters (but not fixed-width graphemes, but will need to change the type of all of your strings).

If you go with UTF-16, you'll have to discard both the assumption of fixed-width characters and the assumption of 8-bit code units, which makes this the most difficult upgrade path from single-byte encodings.

I would recommend actively avoiding <code>wchar_t</code> because it's not cross-platform: Sometimes it's UTF-32, sometimes it's UTF-16, and sometimes its a pre-Unicode East Asian encoding. I'd recommend using <code>typedefs</code> 

Even more importantly, <a href="http://koverflow.com/questions/234365/is-tchar-still-relevant/3002494#3002494" rel="nofollow noreferrer">avoid <code>TCHAR</code></a>.

blocks|key|3530498|text|我不相信任何标准库的实现。只需使用您自己的unicode类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3530499|#include+<windows.h>

typedef+unsigned+char+utf8_t;
typedef+unsigned+short+utf16_t;
typedef+unsigned+long+utf32_t;

int+main+(+int+argc,+char+*argv[]+)
{
++int+msgBoxId;
++utf16_t+lpText[]+=+{+0x03B1,+0x0009,+0x03B2,+0x0009,+0x03B3,+0x0009,+0x03B4,+0x0000+};
++utf16_t+lpCaption[]+=+L"Greek+Characters";
++unsigned+int+uType+=+MB_OK;
++msgBoxId+=+MessageBoxW(+NULL,+lpText,+lpCaption,+uType+);
++return+0;
}|code-block|syntax|javascript|3530500|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I wouldn't trust any standard library implementation. Just roll your own unicode types.

<pre><code>#include &lt;windows.h&gt;

typedef unsigned char utf8_t;
typedef unsigned short utf16_t;
typedef unsigned long utf32_t;

int main ( int argc, char *argv[] )
{
 int msgBoxId;
 utf16_t lpText[] = { 0x03B1, 0x0009, 0x03B2, 0x0009, 0x03B3, 0x0009, 0x03B4, 0x0000 };
 utf16_t lpCaption[] = L"Greek Characters";
 unsigned int uType = MB_OK;
 msgBoxId = MessageBoxW( NULL, lpText, lpCaption, uType );
 return 0;
}
</code></pre>

What prerequisites are needed to do strict Unicode programming?

Does this imply that my code should not use <code>char</code> types anywhere and that functions need to be used that can deal with <code>wint_t</code> and <code>wchar_t</code>?

And what is the role played by multibyte character sequences in this scenario?

C programming: How to program for Unicode?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

进行严格的Unicode编程需要哪些前提条件？这是否意味着我的代码不应该在任何地方使用char类型，并且需要使用可以处理wint_t和wchar_t的函数多字节字符序列在此场景中扮演的角色是什么？

问C编程:如何为Unicode编程？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C编程:如何为Unicode编程？EN