确定文本文件的字符集编码--乱码探源(2)

摘要: 介绍了如何去确定一个文本文件所使用的编码, 特别地以记事本保存"联通"为例进行了深入分析.

在上一篇中, 探讨了文件名编码以及非文本文件中的文本内容的编码, 在这里, 将介绍更为重要的文本文件的编码.

混乱的现状

设想一下, 如果在保存文本文件时, 也同时把所使用的编码的信息也保存在文件内容里, 那么, 在再次读取时, 确定所使用的编码就容易多了.

很多的非文本文件比如图片文件通常会在文件的头部加上所谓的 "magic number（魔法数字）" 来作为一种标识.

所谓的 "magic number", 其实它就是一个或几个固定的字节构成的固定值, 用于标识文件的种类（类似于签名）.

比如 bmp 文件通常会以 "42 4D" 两字节开头.

又比如 Java 的 class 文件, 则是以四字节的 "ca fe ba be" 打头. （咖啡宝贝? ）

java class magic number

即便没有文件后缀名, 根据这些信息也是确定一个文件类型的手段.

附: 关于用 Notepad++ 查看十六进制的问题, 这是一个插件, 如果没有装, 菜单--插件--plugin manager--available--HEX-Editor, 装上它.

装上后, 它通常在工具栏的最右边, 一个黑色的大写的斜体的"H"就是它. 单击它可以在正常文本与 16 进制间切换. 要进一步查看二进制, 在文本区, 右键--view in--to binary.

继续阅读

字符集与编码（七）--BOM

摘要: 本文讨论了 Unicode 中的 BOM 及与 BOM 紧密相关的端法（endian）问题.

在前一篇的最后, 留下了一个问题, 即 string.getBytes("UTF-16") 会在开头多出两个字节 FEFF 来, Unicode 中称之为 BOM, 接下来就让我们一起来了解有关 BOM 的知识, 在此之前我们需要说说有关 端法 的知识.

什么是端法（endian）?

在具体介绍它之前, 让我们先看看鸡蛋的两种摆法:

鸡蛋的两种摆法

大家看出区别来了吗?

  • 上面的一排都是尖的一端（或者说 小端）向着左, 较圆的一端（或者说 大端）向着右；
  • 而下面一排正好相反.

画得不咋的, 大家凑合看就是了, 画出了<<蒙娜丽莎>>（Mona Lisa）的达芬奇（Leonardo da Vinci）据说开始学画画时也画过一段时间鸡蛋呢, 有说画了几天的, 也有说画了几年!

如果按照我们从左到右的习惯认为左是前面, 上面可以说是 小端在前, 而下面的则是 大端在前. 有人可能要问, 这与我们的 BOM 有何关系? 我们知道 UTF-16 一个代码单元有两个字节, 如果把一代码单元比作一个鸡蛋, 那么它也有两个端, 一个字节是小端, 另一个则是大端.

继续阅读

字符集与编码（五）--代码单元及 length 方法

摘要: 本文讲述了 Unicode 中的代码单元这一概念, 并以 java 为例, 阐述其对 string.length 方法的影响, 并结合 junit 做了一些具体的测试.

在前一篇章中已经谈了不少 Unicode 中的重要概念, 但仍还有一些概念没有提及, 一则不想一下说太多, 二则有些概念也无法三言两语就说清楚, 本文在此准备谈一下 代码单元 及由此引发的一些话题.

什么是代码单元? UTF-8, UTF-16 和 UTF-32中的 8, 16 和 32 究竟指什么?

代码单元指一种转换格式（UTF）中最小的一个分隔, 称为一个 代码单元（Code Unit）, 因此, 一种转换格式只会包含 整数 个单元.

继续阅读

字符集与编码（四）--Unicode

摘要: 本文系统介绍了 Unicode 方面的一些重要知识, 如码点, 平面, 代理区, 代理对以及 UTF, 用具体的例子讲解了码点到 UTF-8 及 UTF-16 的转换原理与过程. 文中还顺便鸟瞰了一下 BMP 字符集, 以此获取更加直观的印象.

前面谈到不少的 Unicode, 但一直没有系统地谈及 Unicode 的方方面面, 所以本篇文章专门谈谈 Unicode, 当然了, Unicode 是一个庞大的主题, 这里也是拣些重要的方面谈谈而已, 免不了挂一漏万.

什么是 Unicode?

按 Unicode 官方的说法, Unicode 是 Unicode Standard（Unicode标准）的简写, 所以 Unicode 即是指 Unicode 标准.

按 wiki 的说法, 它是一个计算机工业标准（a computing industry standard）.

继续阅读

字符集与编码（三）--定长与变长

摘要: 本文深入探讨了定长与变长两种实现, 阐述了定长到变长演变的一些权衡与取舍, 并把它与CAP理论作了对比. 在最后, 还通过自行实现变长方案的方式来演示变长设计上的一些考虑.

☯, 首先, 这并不是图片, 这是一个 Unicode 字符, Yin Yang, 即阴阳符, 码点为 U+262F. 如果你的浏览器无法显示, 可以查看这个链接http://www.fileformat.info/info/unicode/char/262f/index.htm. 这与我们要讨论的主题有何关系呢? 下面我会谈到.

继续阅读