Unicode

Unicode 代码点是计算机科学中用于对立示意各种文字零碎中字符的一个标准化办法。在具体探讨这个概念之前，咱们须要了解 Unicode 的根本指标。Unicode 的设计初衷是为了解决传统字符编码方案的局限性，比方 ASCII 只能示意英文字符和一些控制字符，而不能示意世界上其余语言的文字。Unicode 旨在提供一种可能示意地球上简直所有文字零碎的字符编码方案。 Unicode 中的 代码点 是指调配给每个字符的惟一编号。这些代码点示意为 U+ 后跟一串十六进制数，十六进制数的长度能够从 4 到 6 位不等，这容许 Unicode 有足够的空间来包容超过一百万个惟一的字符。例如，英文字母 A 的 Unicode 代码点是 U+0041，而中文字符 中 的代码点是 U+4E2D。 要深刻了解 Unicode 代码点，咱们必须把握几个要害概念： 立体（Plane）：Unicode 字符集被分为 17 个立体，每个立体蕴含 65536（即 16 的 4 次方）个代码点。第一个立体被称为根本多文种立体（BMP），它蕴含了大多数罕用字符。其余 16 个立体称为辅助立体或扩大立体。字符集与编码方案：字符集是一组字符的汇合，而编码方案是如何将这些字符转换为计算机能够了解的数字的办法。Unicode 通过引入如 UTF-8、UTF-16 和 UTF-32 等编码方案，提供了将代码点转换为字节序列的具体方法。例如，UTF-8 是一种可变长度的编码方案，可能应用 1 到 4 个字节来示意一个 Unicode 代码点，这使得它既能兼容 ASCII，也能高效地示意任何 Unicode 字符。字符属性：每个 Unicode 代码点都调配了一组属性，这些属性提供了对于字符的各种信息，比方字符是不是字母、数字、标点符号，以及字符的书写方向等等。Unicode 的实现使得文本处理在寰球范畴内变得更加统一和简略。开发者不须要为每种语言或文字零碎设计不同的编码方案，而是能够利用 Unicode 来解决简直所有语言的文本。这对于晋升软件的国际化和本地化程度，以及促成寰球信息的交换和共享，具备重要意义。 举几个具体的 Unicode 代码点例子来进一步阐明： U+1F600 代表一个笑脸表情符号 。U+2601 代表云 ☁ 的符号。U+6211 代表中文字符 我。Unicode 的倒退和保护由一个非营利组织 Unicode Consortium 负责。这个组织一直地对规范进行更新和扩大，以包含新的字符集，比方最近几年风行的各种表情符号。随着全球化的不断深入，Unicode 在古代软件开发中的重要性一直减少，它帮忙软件开发者逾越语言和文化的阻碍，创立可能在寰球范畴内应用的应用程序和服务。 ...

Unicode 字符表：https://en.wikibooks.org/wiki...\xa0 是 NO-Break Space，不间断空格\xad 是 Soft Hyphen，软连接符，常被显示为短横或者空格可打印字符>>> '你好'.isprintable()True>>> '\x41'.isprintable()True>>> '\xa0'.isprintable()False>>> '\xad'.isprintable()FalseUTF8>>> import codecs>>> utf8_decoder = codecs.getincrementaldecoder('utf8')()>>> utf8_decoder.decode(b'hello')'hello'>>> utf8_decoder.decode(b'\x41')'A'>>> utf8_decoder.decode(b'\xa0')UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 0: invalid start byteregex>>> regex.findall(r"[\p{L}]", '水_A_\x41_\xa0_\xad_0 地')['水', 'A', 'A', '地']>>> regex.findall(r"[\p{Z}]", '水_A_\x41_\xa0_\xad_0 地')['\xa0', ' ']>>>regex.findall(r"[\p{C}]", '水_A_\x41_\xa0_\xad_0 地')['\xad']pandahousepandahouse 解决 \xad 之类的非常规字符会有问题本文出自 qbit snap

人类交换应用 A、B、C、中 等字符，但计算机只意识 0 和 1。因而，就须要将人类的字符，转换成计算机意识的二进制编码。这个过程就是字符编码。 ASCII最简略、罕用的字符编码就是 ASCII（American Standard Code for Information Interchange，美国信息替换规范代码），它将美国人最罕用的 26 个英文字符的大小写和罕用的标点符号，编码成 0 到 127 的数字。例如 A 映射成 65 (0x41)，这样计算机中就能够用 0100 0001 这组二进制数据，来示意字母 A 了。 ASCII 编码的字符能够分成两类： 控制字符：0 - 31和 127 (0x00 - 0x1F 和 0x7F)可显示字符：32 - 126 (0x20 - 0x7E)具体字符表能够参考：ASCII - 维基百科，自在的百科全书。 UnicodeASCII 只编码了美国罕用的 128 个字符。显然不足以满足世界上这么多国家、这么多语言的字符应用。于是各个国家和地区，就都开始对本人须要的字符设计其余编码方案。例如，中国有本人的 GB2312，不够用了之后又扩大了 GBK，还是不够用，又有了 GB18030。欧洲有一系列的 ISO-8859 编码。这样各国人民就都能够在计算机上解决本人的语言文字了。 但每种编码方案，都只思考了本人用到的字符，没方法跨服交换。如果一篇文档里，同时应用了多种语言的字符，总不能别离指定哪个字符应用了那种编码方式。 如果能对立给世界上的所有字符调配编码，就能够解决跨服交换的问题了，Unicode 就是来干这个事件的。 Unicode 对立编码了世界上大部分的字符，例如将 A 编码成 0x00A1，将 中 编码成 0x4E2D，将 编码成 0x03B1。这样，中国人、美国人、欧洲人，就能够应用同一种编码方式交换了。 ...

Unicode 中有些非凡的字符，能够由其余不同的特殊字符组合进去。例如 ñ (U+00F1) 和 n (U+006E U+0303)。这两个字符在展示和含意上是齐全等价的，但其编码却是不同的。为了对这种字符进行比拟，就须要在比拟前先进行标准化 (Normalization) 解决。 Unicode 定义了四种标准化模式 (Unicode Normalization Form)： 合成合成再重组规范等价NFD (Normalization Form Canonical Decomposition)NFC (Normalization Form Canonical Composition)兼容等价NFKD (Normalization Form Compatibility Decomposition)NFKC (Normalization Form Compatibility Composition)阐明： 合成与重组： 合成：就是把字符能拆的全拆开，例如： 把 ñ (U+00F1) 拆成 U+006E U+0303。重组：就是把拆开的字符能组的再全组起来，例如： 把 n (U+006E U+0303) 组合成 U+00F1。规范与兼容： 规范等价：就是只有含意和长得完全相同的两个字符才相等，例如： ñ (U+00F1) 和 n (U+006E U+0303) 能够相等；但 ff (U+FB00) 和 ff (U+0066 U+0066) 不能相等。兼容等价：就是只有长得差不多就能够相等了，规范等价的肯定也是兼容等价的，例如： ff (U+FB00) 和 ff (U+0066 U+0066) 也能够相等；ñ (U+00F1) 和 n (U+006E U+0303) 更是能够相等了。示例： ...

编程语言中的 Unicode因为 Unicode 能够给世界上大部分字符编码，因而大部分编程语言外部，都是应用 Unicode 来解决字符的。例如在 Java 中定义一个字符 char c = '中'，这个字符理论是应用两个字节在内存中存储着他的 UTF-16 编码。所以如果将这个字符强转成整型 int i = (int) c，失去的后果 20013 (0x4E2D)，就是 中 在 Unicode 中的 Code Point 值。 这个说法不齐全精确，因为大部分编程语言定义的时候，Unicode 还没有辅助立体，所以个别都是固定的用两个字节来存储一个字符。 在有了辅助立体当前，辅助立体的字符，会被 UTF-16 编码成两个 Code Unit，须要 4 个字节来存储。而编程语言为了兼容性，不太可能将原有的 char 类型长度改为 4 个字节。所以就有可能须要用两个 char 来存储一个理论的字符。而原有的获取字符串长度的 API，理论获取到的是字符串中 Code Unit 的个数，不是理论字符的个数。获取某个地位字符的 API 也是同理，获取到的可能是一对 Code Unit 中的一个。因而须要应用编程语言提供的新的 API 或者通过额定的代码，来正确处理辅助立体的字符。 在编程语言中应用 Unicode次要波及以下操作： @startumlhide empty descriptionstate Characterstate CodePointstate BytesCharacter -up-> CodePointCodePoint -down-> CharacterCodePoint -down-> BytesBytes -up-> CodePointCharacter -right-> BytesBytes -left-> Character@startuml这其中最要害的就是字符和 Code Point 之间的转换。因为这里波及字符集的映射，如果编程语言不反对，咱们就要本人外挂编码表能力实现，否则无论如何都是没方法通过枚举实现的。 ...

通用字符集 (Universal Character Set, UCS) 和 Unicode 能够了解就是两个组织干的雷同的事件，他们都想给世界上的所有字符对立编码。当初他们也都互相兼容，就是说对于同一个字符，UCS 和 Unicode 都会把他们映射成同一个 Code Point，反过来也一样。所以能够把他们当成是一回事。 有一些不同的中央，UCS 的编码空间原本是 0 到 0x7F FF FF FF (32 位，第一位固定为 0)。但因为 UTF-16 代理对的实现形式，只能编码到 0x10 FF FF 范畴。所以 UCS 规范也规定了只应用 0x10 FF FF 范畴内的编码。 UCS-4 与 UCS，相似于 UTF-32 与 Unicode 的关系。因为 UCS 也规定了只应用 0x10 FF FF 范畴内的编码，所以它两理论就是一回事。 UCS-2 与 UCS，相似于 UTF-16 与 Unicode 的关系。但不同的是，UCS-2 是固定两字节的，没有思考辅助立体。能够把 UCS-2 当做是不反对辅助立体的 UTF-16。 相干文章： 详解字符编码与 Unicode

原创：打码日记（微信公众号ID：codelogs），欢送分享，转载请保留出处。简介古代编程语言都形象出了String字符串这个概念，留神它是一个高级形象，然而计算机中理论示意信息时，都是用的字节，所以就须要一种机制，让字符串与字节之间能够互相转换，这种转换机制就是字符编码，如GBK，UTF-8 所以能够这样了解字符串与字符编码的关系: 字符串是一种形象，比方java中的String类，它在概念上是编码无关的，外面蕴含一串字符，你不须要关怀它在内存中是用什么编码实现的，只管字符串在内存中存储也是须要应用编码机制的。字节串才须要关怀编码，当咱们要将字符串保留到文件中或发送到网络上时，都须要应用字符编码机制，将字符串转换为字节串，因为计算机底层只认字节。常见字符编码方案ASCII全称为American Standard Code for Information Interchange，美国信息替换规范代码，用来编码英文字符，一个字符占一个字节，只用了字节中的低7位，最高位始终为0，因而只能示意2^7=128个字符。 ISO8859-1对ASCII的裁减，增加了西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号，也称latin-1，将ASCII中最高一位也利用起来了，能示意2^8=256个字符，当最高位是0时，编码方式就是ASCII，所以ISO8859-1是兼容ASCII码的。 GBK全称为Chinese Internal Code Specification，于1995年制订，用来编码汉字的一种计划，一个汉字编码为两个字节，兼容ASCII码编码方案，ASCII中的英文字符编码为一个字节。 UnicodeUnicode 的全称是 universal character encoding，中文个别翻译为"对立码、万国码、繁多码"，用于定义世界上所有的字符，防止了各个国家设计的本地字符集相互不兼容的问题。晚期因为另一个组织也定义了一种与Unicode相似的计划ucs，而后与Unicode合并，故有时Unicode也称为ucs。 留神，Unicode是一种字符集，而不是一种具体的字符编码，要了解Unicode具体是什么，首先要了解字符集与字符编码的关系，一般来说，字符集定义字符与代码点(codepoint)之间的对应关系，而字符编码定义代码点(codepoint)与字节之间的对应关系。 比方ASCII字符集规定A用65示意，至于65在计算机中用什么字节示意，字符集并不关怀，而ASCII字符编码定义65应该用一个字节示意，对应为01000001，十六进制表示法为0x41，它是ASCII字符集的一种实现，也是惟一的实现。 但Unicode做为一种字符集，它没有规定Unicode中的字符该如何编码为字节，而UTF-16、UTF-32、UTF-8就都是Unicode的字符编码实现计划，它们具体定义了如何将Unicode字符转换为相应的字节。 UTF-32 UTF-32编码，也称UCS-4，是Unicode 最间接的编码方式，用 4 个字节来示意 Unicode 字符中的 code point ，比方字母A对应的4个字节为0x00000041。它也是 UTF-*编码家族中惟一的一种定长编码（fixed-length encoding），定长编码的益处是能疾速定位第N个字符，便于指针运算。但用四个字节来示意一个字符，对于英文字母来说，空间占用就太大了。 UTF-16 UTF-16编码，也称UCS-2，起码能够采纳 2 个字节示意 code point，比方字母A对应的2个字节为0x0041。须要留神的是，UTF-16 是一种变长编码（variable-length encoding），只不过对于 65535 之内的 code point，只须要应用 2 个字节示意而已。然而，很多历史代码库在实现 UTF-16 编码时，间接应用2字节存储，这导致在解决超出 65535 之外的 code point 字符时，会呈现一些问题，另外，UTF-16对于纯英文存储，也会节约1倍存储空间。 字节序与BOM 不同的计算机存储字节的程序是不一样的，比方 U+4E2D 在 UTF-16 能够保留为4E 2D，也能够保留成2D 4E，这取决于计算机是大端模式还是小端模式，UTF-32也相似。为了解决这个问题，UTF-32与UTF-16都引入了BOM机制，在文件的起始地位搁置一个特殊字符BOM(U+FEFF)，如果 UTF-16 编码的文件以FF FE开始，那么就意味着其字节序为小端模式，如果以FE FF开始，那么就是大端模式。所以UTF-16依据大小端可辨别为两种，UTF-16BE(大端)与UTF-16LE(小端)，UTF-32同理。Unicode表示法 咱们常常会看到形如 U+XXXX 或 \uXXXX 模式的货色，它是一种示意Unicode字符的形式，俗称Unicode表示法，其中XXXX是 code point 的十六进制示意，比方 U+0041 或 \u0041 示意Unicode中的字母A。咋一看，这玩意有点相似 UTF-16 ，但要留神它是一种用英文字符串指代一个Unicode字符的形式，不是一种字符编码，字符编码是用字节串指代一个Unicode字符。 ...

咱们通过在操作系统里进行一些简略的分割，能够加深对 Unicode 编码这些基础知识的了解和记忆。 Windows10 操作系统下，新建一个记事本文件，输出 123ABCabc 默认的 encoding 格局为 UTF8： 应用 winhex 这款 16进制文件编辑器关上该记事本文件： 看到注释区域的 31 32 33 41 42 43 61 62 63。这些数字代表什么含意？ UTF8 (Universal Character Set/Unicode Transformation Format) 是针对 Unicode 的一种可变长度字符编码。它能够用来示意 Unicode 规范中的任何字符，而且其编码中的第一个字节仍与 ASCII 相容，使得原来解决 ASCII 字符的软件毋庸或只进行少部分批改后，便可持续应用。 ASCII 是美国规范信息替换代码（American Standard Code for Information Interchange）的缩写, 为美国英语通信所设计。它由 128 个字符组成，包含大小写字母、数字0-9、标点符号、非打印字符（换行符、制表符等4个）以及控制字符（退格、响铃等）组成。 ascii 对照表能够从这个链接取得。 其中数字 1，2，3 的 UTF8(ASCII) 编码别离为 31，32和33： 大写的 A B C 的 UTF8(ANSI) 编码为 41 42 43，小写字母为 61 62 63： ...

简介咱们晓得计算机最先衰亡是在国外，出于过后计算机性能的思考和外国罕用字符的思考，最开始计算机应用的是ASCII，ASCII编码可能示意的字符毕竟是无限的，随着计算机的倒退和全世界范畴的风行，须要更多的可能示意世界各地字符的编码方式，这种编码方式就是unicode。 当然在unicode呈现之前，各个国家或者地区依据外国的字符需要都制订过外国的编码标准，当然这些编码标准都是本地化的，不适用于全世界，所以并没有失去遍及。 明天咱们来讨论一下unicode编码的字符进行排序和正则匹配的问题。 ASCII字符的排序ASCII的全称叫做American Standard Code for Information Interchange，也就是美国信息替换规范代码，到目前为止，ASCII只有128个字符。这里不具体探讨ASCII字符的形成。感兴趣的同学能够查看我之前写的对于unicode的文章。 ASCII字符蕴含了26个字母，咱们看下在javaScript中怎么对ASCII字符编码的： const words = ['Boy', 'Apple', 'Bee', 'Cat', 'Dog'];words.sort();// [ 'Apple', 'Bee', 'Boy', 'Cat', 'Dog' ]能够看到，这些字符是依照咱们想要的字典的程序进行排序的。 然而如果你将这些字符批改成中文，再进行排序，那么就失去的并不是咱们想要的后果： const words = ['爱', '我', '中', '华'];words.sort();// [ '中', '华', '我', '爱' ]这是为什么呢？ 其实默认的这种sort是将字符串转换成字节，而后依照字节进行字典程序排序。如果是中文，那么并不会将其进行本地文字的转换。 本地字符的排序既然应用ASCII字符不能对中文进行排序，那么咱们其实是想将汉字转换为拼音，而后依照拼音字母的程序来对其排序。 所以下面的”爱我中华“实际上是要比拟”ai“、”wo“、”zhong“、”hua“ 这几个拼音的程序。 有什么简略的办法来进行比拟吗？ 在一些浏览器中提供了Intl.Collator和String.prototype.localCompare两种办法来进行本地字符的比拟。 比方我在chrome 91.0版本中： 应用Intl.Collator是能够失去后果的，而应用String.prototype.localCompare并不行。 再看下在firfox 89.0版本中： 后果和chrome是统一的。 上面是在nodejs v12.13.1版本的执行后果： 能够看到在nodejs中，并没有进行本地字符的转换和排序。 所以，上述的两个办法是和浏览器有关系的，也就是说和具体的实现是相干的。咱们并不能齐全对其信赖。 所以，要给字符串进行排序是一件十分傻的事件！为什么不应用unicode进行排序那么为什么不应用unicode进行排序呢？ 首先，对于普通用户来说，他们并不知道unicode，他们所须要的也就是将字符串转换为本地语言进行字典排序。 其次，即便应用本地字符进行排序也是十分艰难的一件事件，因为浏览器须要对不同的语言进行本地化排序反对。这使得工作量变得微小。 emoji的正则匹配文章最初，咱们来讲一下emoji的正则匹配问题。 emoji是一系列的表情，咱们能够应用unicode来对其示意，然而emoji表情十分多，差不多有3521个，如果要对emoji进行正则匹配，咱们须要写出上面的代码： (?:\ud83e\uddd1\ud83c\udffb\u200d\u2764\ufe0f\u200d\ud83d\udc8b\u200d\ud83e\uddd1\ud83c\udffc|\ud83e\uddd1\ud83c\udffb\u200d\u2764\ufe0f\u200d\ud83d[... 前面省略很多]以一个图像来直观的看一下emoji表情有多少： 这么多的emoji，有没有简略的方法对其进行正则匹配呢？答案是有的。 早在ECMAScript的TC39提议外面，就曾经把emoji的正则匹配退出了规范之中，咱们能够应用{Emoji_Presentation}来示意。 \p{Emoji_Presentation}是不是很简略？ ...

你已经对神秘的Content-Type标签感到好奇吗？就是那个在HTML中常常用到然而很少有人理解为什么要去应用它的标签。 你已经收到过一封来自保加利亚的敌人发给你的邮件，邮件的题目是“???? ?????? ??? ????” ? 我很悲观的发现有十分多的软件开发者并不理解字符集，编码，unicode等相干的常识。几年前， FogBUGZ网站的一个测试人员想要晓得它是否可能胜利接管来自日本的邮件。日本？日本也要用这个邮件系统？我一头雾水。在认真钻研用来解析MIME邮件音讯的商业ActiveX控制器后，发现它解析字符集的形式是齐全谬误的，所以咱们不得不大胆的写一些代码来纠正错误的转化使其正确解析。看了其余的商业化代码库之后，发现它们的字符解析实现也十分的简陋。我分割了那个库的开发者，他们的态度是“咱们啥都做不了”。和很多程序员一样，他心愿这件事件能够就这么过来了。 然而显然这个问题不能就这么算了。当我发现PHP这个如此风行的Web开发工具都简直齐全忽视了字符编码的问题, 随便的用着8位存储的字符，使得简直无奈用其开发国际化网页利用。我感觉真的够了，再也忍不了了！ 所以在此我要郑重声明：如果你当初是一名程序员却不理解字符，字符集，编码和Unicode的基础知识，一旦被我发现，我就要罚你到深海潜水艇上寂寞的剥6个月的洋葱！ 我还要说一点，这个问题并没有设想中的那么难！ 这篇文章我会聊一些每一个程序员所必须晓得的内容。什么“plain text = ascii = 8位自符”这些货色几乎是大错特错。如果你还用那种思路编程，就好像是一个不置信细菌存在的外科医生。请在浏览完本文之后再去持续你的编码生涯。 在开始之前，我要揭示那些极少数理解国际化编程的同学，你们会发现这篇文章的内容有些适度简化。因为我只分享了最根底的内容，从而让每一个人可能了解并且试着写出一个非英语环境下都可能正确运行的程序。我还要申明，正确的字符编码只是国际化程序可能良好运行的一个很小的前提，但这次不扩大范围，先只聊这件事。 历史的视角理解这个问题最好的形式就是沿着工夫线追溯。 你可能认为我要说一说十分古老的字符集EBCDIC，然而我不～EBCDIC曾经和咱们当初的编码无关了，咱们不须要追溯那么远的历史。 在上古期间，当Unix刚刚被创造进去，K&R还在写C语言的时候，一切都是那么的简略。EBCDIC刚刚被淘汰出局，咱们只须要关注一种字符类型，那就是英文字母。咱们应用了一种叫做ASCII的编码方式，通过32和127之间的数字来示意任意一个字符。比方Space的编码是32，A的编码是65。这种编码能够用7位轻松存储。那个年代大多数的电脑都应用8位字节，因而咱们不仅能够存储每个ASCII码字符，还有一个闲暇位来反对一些控制指令，比方7能够示意让电脑告警，12能够命令打印机的当前页移出并引入新的纸张。 所有看上去是那么美妙，前提是你是一个英文开发者。 因为一个字节有8位而ASCII编码只用了其中的7位，很多人都开始想，“诶哟，咱们能够自定义128～255这个区间所代表的字符”。问题是，过后很多人同时产生了这个想法，并且创造了各式各样的自定义编码映射。IBM电脑提出了一个称为OEM的字符集，其中蕴含了一些欧洲语言中带有音调的字符和一些绘图式字符… 比方水平线，垂直线，带有小箭头的水平线等等。你能够用这些线状字符在屏幕上绘制出精美的盒子形态图形，直到现在还能在一些装有8088芯片的洗衣机上看到这些图形。事实上，随着美国之外的人们开始买电脑，各种各样的字符集应运而生，各自都有着不同的含意。比方，在一些电脑上130编码代表é，然而在一些以色列售卖的电脑上却是希伯来语Gimel()。所以当美国人将résumés发送到以色列，它将被翻译成rsum。甚至是一个国家内，比方俄罗斯，对于128位以上的字符都有很多不同的映射，所以同一份俄语文件都可能被解释成不同的内容。 最终，这些随便的OEM编码们在ANSI规范中得以扭转。在ANSI规范中，每个人对于128以下的编码内容达成统一，这部分根本和ASCII编码，然而对于128以上的编码映射在不同的地区有不同的解决形式。这些不同的区域编码零碎被称为_编码页_。比方在以色列的DOS零碎中用的编号862的编码页，而希腊用户应用编号737的编码页。这些编码页在128以下的内容雷同，然而在128位以上的字符就形形色色了。MS-DOS的国内版本有几十个这样的编码页，用于解决各种各样的语言，甚至有一些编码也可能同时反对多种语言！然而，换句话说，要想用一个编码页在一台电脑上同时反对希伯来语和希腊语是不可能的，除非写一个自定义的程序来展现位图图形，因为希伯来语和希腊语须要应用不同的编码页来翻译高位的编码。 于此同时，在亚洲，编码变得更加疯狂，因为亚洲的语言通常有上千个字母，根本无法只用8位来示意这些字母。这个问题通常用一个叫做DBCS（double byte character set）的很蹩脚的零碎来解决，这个零碎中局部字符用一字节来示意，一些用两字节来示意。这样的设计使得在string中从前往后遍历很轻松，然而简直不可能从后往前遍历。程序员通常被倡议不要应用s++或者s--来前移或后移，而是调用函数如Windows的AnsiNext和AnsiPrev，让操作系统决定如何解决这些字符。 即便如此，很多人仍然认为一个字节就是一个字符，一个字符是8位。只有不将这个字符串挪动到另一台电脑上，或者这个字符串不波及别的语言，这所有都看上去很失常。然而，随着国际化趋势，将字符串挪动到另一台电脑变成了一件很常见的事件，于是所有开始崩塌。幸好，Unicode随之问世了。 UnicodeUnicode做了一个大胆的尝试，它创立了一个字符集编码将这个星球上所有的正当的或是假造的（如Klingon）语言都囊括进来。有些人误以为Unicode就是一种长度为16位的编码，每16位代表一个自负，因而一共有65,536中可能的字符。这个了解不完全正确。这也是对于Unicode最常见的误会。所以如果你也是这么认为的，不必感觉丧气。 事实上，Unicode用一种全新的形式来翻译字符。试着用它的形式来思考才可能真正明确Unicode的编码方式。 当初，咱们假如一个字母被映射成一些二进制位从而可能存储到磁盘或者内存中：A -> 0100 0001 在Unicode中，一个字母映射到一个称为代码点（code point）的货色，这依然只是一个实践上的概念。至于这个代码点是如何在内存或者磁盘上示意的就是另一个问题了。 在Unicode中，A这个字母是一个理想化的符号。这个理想化的A不等于B，也不等于a，然而和 不同模式的_A_ 和A却是雷同的。在一种字体下的A和另一种字体下的A被认为是一个符号，然而和小写的a相比就是不同的符号。这看上去没什么争议，然而在一些语言中明确一个字符到底是什么就会产生争议。比方德语字母ß到底是一个理想化的符号还是只是用来表白ss的简写？如果一个字母的在单词开端时形态扭转了，那它是否是另一个字母？希伯来语对这个问题的答复是必定的，然而阿拉伯语却不是。总而言之，那些创造Unicode的聪明人儿在过来十年将这个问题想明确了，尽管随同这很多高度政治化的争执，然而他们究竟还是梳理分明了。 每一个现实符号都被调配了一个相似于U+0639的魔法值。这个魔法值被成为代码点（code point）。U+代表是Unicode编码，前面紧跟着十六进制的数字。U+0639代表阿拉伯字母Ain，而英文字母A则是U+0041。你能够在Windows 2000/XP的charmap工具或者Unicode网站上查看全副的编码信息。 Unicode可能定义的字母数量其实没有下限，它们早就超过了65,536个字母，所以并不是每个Unicode字母都可能被压缩进两个字节，这个问题到本文目前为止还是一个谜。 好了，假如咱们当初又一个字符串Hello，在Unicode中对应这么5个代码点U+0048 U+0065 U+006C U+006C U+006F。至于这些代码点将如何在内存中存储或者在邮件中展现，咱们还没有做介绍。 编码接着就要聊一聊编码了。晚期Unicode的编码采纳了两个字节来存储，所以Hello这个单词被编码成00 48 00 65 00 6C 00 6C 00 6F。看上去还不错～等下，那是不是也能够被编码成48 00 65 00 6C 00 6C 00 6F 00。事实上这么编码也不是不能够，而晚期的开发者心愿可能依据具体的CPU架构来抉择是采纳高位模式还是低位模式来进行存储。所以人们不得不遵循一种奇怪的约定，在每个Unicode字符串前存储一个FE EF前缀，这个前缀被称为Unicode字节程序标记位（Unicode Byte Order Mark）。而如果你将字符串的高下位对换地位后，你就须要加上FF FE前缀，从而让阅读者晓得这里须要做一次替换。然而，并不是每一个Unicode字符串的结尾都有字节程序标记位的。 ...