趁着双十一买了好几本想买的书，其中就有这本《Windows 核心编程》。首先需要吐槽的就是好好的《Windows via C/C++》这么高端大气上档次的名字怎么就被翻译成了这么个蛋疼样，而且中文版的封面也是扑面而来的一股浓郁的上个世纪气息，以至于在正文里看到 Vista 的字样都感觉各种穿越……

本文是关于这本书的第一篇读书笔记。天知道会不会有第二篇。

虽说之前已经写过好几篇关于字符编码的文章，都快写吐了，不过读了这本书的开篇还是感觉相见恨晚。这里对于前面这几篇里关于字符串的说明进行一下查漏补缺。

Unicode 和 UTF-16

前文书说到，Unicode 定义的是码位（Code Point），即为每一个字符赋一个唯一编号，记作 U+XXXX。Unicode 目前实际占用了 0₁₆ 到 10FFFF₁₆ 的码位，有些已经分配了字符，有些还没有。

Unicode 中最初推出的 U+0000 到 U+FFFF 这 2¹⁶ 个码位称为基本多文种平面（Basic Multilingual Plane，BMP）。早年只有这一个平面的时候，Unicode 与 UTF-16 是等价的，因为可以做到一一对应。然而时过境迁，区区 16 位已经满足不了 U+10000 到 U+10FFFF 的码位了。

与 UTF-8 编码规则的爽快不同，UTF-16 在沦为实实在在的「编码」时，还需要考虑到向后兼容性问题。如何在维持 U+0000 到 U+FFFF 一一对应的同时，把剩余的 U+10000 到 U+10FFFF 编进来？

答案是：把 U+D800 到 U+DFFF 命名为 UTF-16 编码专用字符。即如果 UTF-16 数据流中出现了这一范围内的字符，意味着它本身不是一个字符，紧接着它的 16 位数据需要加上一定的偏移值才是真正的数据。

这一土豪做法让我目瞪口呆。至于 UTF-32，目前来说与它与 Unicode 码位一一对应起来绰绰有余。当然，如果哪天发现了外星文明，需要把他们的字符也编码进来，导致 Unicode 占用的码位暴增，说不定这一一对应的任务就只能交给未来的 UTF-64 了。这就是把问题留给子孙后代去解决的大智慧啊！

CHAR 和 LPSTR

前文书里吐槽过 Windows API 的丑陋不堪，也说过这也是历史遗留、不得已而为之。

没错的，CHAR 和 char 在语义上并不等价，前者专指 8 位字符，后者则只是字符而已，说不定在哪个古董机器上就是 7 位了。（尽管我不认为你会在那上面跑 Windows……）

而 LPSTR 尽管被定义为 CHAR *，但它实际上还借助了编译器扩展实现了「以 NUL 结尾」的语义：

typedef __nullterminated CHAR *LPSTR;

Unicode 和 ANSI 版本

说实话我依旧不喜欢官方的这两个名字，我更喜欢「宽字符版本」和「多字节字符版本」这两个更拗口但更准确的名字。

由于现代 Windows 内部都是以 UTF-16 存储（承袭自 UCS-2），实际提供的 API 本身也都是 Unicode 版本的，即以 W 结尾的版本。而相应的 A 结尾的 ANSI 版本则是在 W 版本基础上的封装。

于是可以想象，全局使用 ANSI 相比全局使用 Unicode 而言要占更多的内存，理论上也要更慢一些。

以上。

CC++Windows编码