你说的好像正好反过来 代码页(code page)遗留下来的东西 先有的代码页 后有的Unicode

http://www.

https://en.

每一套方案，就是一套协议。其实ASCII最早虽然是美国的（ASCII是American Standard Code for Information Interchange的缩写，其A就是美国），但在欧美运用的时候，就已经有了“代码页”的操作手段，在不同的国家，同样的编码可以代表不同的字母或字符，那是由程序（程序是操作系统和应用程序的通称）解释的，归根结底就是由程序员自己解释的。明白了加粗的这句话，即明白了问题的实质！

跟楼主说几句

编码相关的东西挺复杂的 好在一般的编程工作不需要接触特别深入的 要是自己编程就选择一种兼容性最好的方式 要是工作上 就尽量让转化平滑

那是错的，或者是你理解错的。utf-16就是定长16位，在兼容ascii的部分，也是以16位储存的！同样，utf-32也是定长32位的。定长的编码，高位补零。之所以定长，是为程序处理方便而设，不定长的处理，增加了编程的复杂性，代码量比定长的大（换取的优势是数据储存量小，但正如我之前说过，这种优势对以中文为主的文本来说是不存在的）。

[ 本帖最后由 TonyDeng 于 2015-7-2 10:33 编辑 ]

16位的编码長度，只能代表六万多字符，并不能囊括所有中文，所以用16位方案的，都需要代码页切换（这与前面提及ASCII在不同欧洲国家有不同的字符解释的原理一样）。32位才是一次性的解决方案，只是在内存成本高居不下的时代，这种方案不切实际，才折衷改用16位方案而已，其实时至今天，配备32位编码系统的條件已经足够了，未来的系统将逐步过渡过去。

[ 本帖最后由 TonyDeng 于 2015-7-2 10:42 编辑 ]

为什么不定长的编码处理代码量会比较复杂呢？其实，写过DOS时代中文处理的人都很清楚原因，即使是现在，只要你写控制台下处理中文的程序，也会遇到同样的问题（在视窗模式下已交由系统处理，反而简单）。我一向说，自己动手写过就知道了，不动手，敷衍了事，当然无法理解，也绝不会明白历史遗留下来至今沿用的的一些东西为什么会是这样。

汉字占用两个字节，用字符数组输出（%s输出的是字符串）时，读进去就是4个字节，比如说*str=“中国”，总共占用4+1 个字节后边还有个'\0',而你用%c输出是，只能输出2个字节，所以连续输出两个字节也是一个存在数组中的汉字，所以在某种程度上两个是等价的，只不过这样输出太繁琐了！还是建议用%s输出！

可能你说的UTF-16和我说的UTF-16不是一个东西 我说的是Unicode里面的编码方式

你喜欢就好 祝您工作顺利 身体健康

ASCII编码实质上是7位的，但它的储存容量是8位，这就是顶楼问题的根源——之所以能设计出16位的中文编码方案，即由此而来，也是乱码问题的答案。