Menu

tlanyan

十里平湖霜满天,寸寸青丝愁华年

文件和字符编码

转载请注明来源:https://tlanyan.me/ascii-binary-character-encoding/‎

近期对识别文件格式感到好奇,不幸和字符编码搞混,不明其中原理导致心烦意乱。为了消除文件格式和字符编码的疑惑,上网搜索并翻出以前收藏的文章,心结总算了却。本文即是对文件和字符编码的个人总结。

文本文件和二进制

刚开始的疑惑是:文本文件和二进制文件有什么区别?为什么一个能显示内容,另一个的内容经常无法(用文本编辑器)正常显示?

马里兰大学的这篇培训笔记,把两者的区别讲得清楚:文本文件是二进制文件的一种,底层存储也是0和1;文本文件可读性和移植性好,但表现字符有限;二进制文件数据存储紧凑,无字符编码限制。文本文件基本上只能存放数字、文字、标点等有限字符组成的内容;二进制没有字符约束,可随意存储图像、音视频等数据。

用存储数字的例子可以形象的看出文本文件和二进制文件存储内容上的差异。例如要存储数字1234567890,文本文件要存储0-9这十个数字的ASCII码,对应的十六进制表示为:31 32 33 34 35 36 37 38 39 30,占用10个字节;1234567890对应的二进制为“‭0100 1001 1001 0110 0000 0010 1101 0010‬”,占用4个字节(二进制表示32位,一个字节8位),存储到文件的16进制表示为(大端):49 96 02 D2。

文本文件按字符存放内容,二进制按字节存放,这是两种文件最本质的区别。根据这个特性,可以推断出一些常见结论:二进制文件常常比文本文件紧凑,占用空间少;文本文件更友好易用,能用所见即所得的方式编辑;二进制文件常常需要专用程序打开,等等。

回过头看文本编辑器打开二进制文件常常是乱码的现象。例如一个二进制文件存放了一个整数1234(四个字节),用16进制表示为:00 00 04 D2。文本编辑器打开后逐个字符解释,会发现这几个字节拼不出可显示的字符,只好乱码相待。乱码的原因是文本编辑器不能正确解析字节流,这也是二进制文件需要用专用软件打开的原因。例如jpg文件要用看图软件打开,如果用音乐播放器打开,完蛋!视频文件要用播放器打开,用压缩软件打开,歇菜!

文件格式

了解文本文件和二进制文件的区别后,再来看文件格式。我们知道,Windows按文件拓展名识别文件格式,并调用对应的程序打开文件;(类)Unix系统,拓展名可有可无,那么怎么知道这个文件是什么格式呢?

幸好有file命令,这个命令可以告诉我们文件到底是什么格式。文件拓展名不是文件格式的本质区别,内容才是。把a.zip改成a.txt/a.jgp/a.mp3,无论什么文件名,file都让其原形毕露:Zip archive data, at least v1.0 to extract。

file命令的工作原理可这篇文章

编码

说完了文件,再来说文件内容中的编码。常见的127个ASCII字符,没啥编码好说的,反正几乎所有的编码方式都兼容它。双字节、多字节字符,编码方式和字节序,才是困扰程序员的问题。一个汉字,GBK编码需要两个字节,还要考虑本机的大小端,才能确定存放的最终形式;网络通讯时,要转换成网络字节序(大端序),接收方才能正常解析。开发人员如果对字符编码不熟悉,通信时遇到乱码问题,调试就很困难。

UCS(Universal Multiple Octet Coded Character Set)标准的制定,让开发人员远离混乱的多字节字符集。UCS标准里,所有的字符都有唯一的码点(Code Point),根据码点就可查到对应字符。UCS用两个字节表示一个码点(UCS-4标准是4个字节),对应一个字符。由于使用了两个字节,可容纳2^16-1(6w+)字符,基本上容下各国常用的字符(UCS-4理论上可容纳上二十亿个字符,目前收纳超过16W个字符)。注意UCS只是一个标准,规定了码点与字符的一一对应关系,但没有定义如何存储在计算机中。

规定Unicode字符存储方式的工作由UTF(Unicode Transformation Format)完成,应用最多的方案是UTF-16和UTF-8。UTF-16使用两个字节表示一个字符,Windows, MacOS, Java平台默认的字符编码方案都是UTF-16。由于有两个字节,便存在大端和小端两种方案的区分。只有ASCII字符的文件,使用UTF-16编码存在空间浪费严重的现象(浪费50%的存储),由Ken Thompson(C语言发明人)和Robe Pike(Go语言发明人)提出的UTF-8编码方案很快流行起来。UTF-8是单字节流,不存在字节序问题,也不需要BOM。目前UTF-8是web通行标准。

对应关系

USC-2的取值范围是U+0000~U+FFFF,与UTF-8的对应关系如下:

unicode码点(十六进制)UTF-8(二进制)
0000 0000-0000 007F0xxxxxxx
0000 0080-0000 07FF110xxxxx 10xxxxxx
0000 0800-0000 FFFF1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

从编码可以看出,与二进制相比,浪费了很多空间。不过这也没办法,可显示的字符更容易阅读和理解,人类很难抗拒这个诱惑。

UTF-8转换规则为: 1. 如果某字节第一位是 0 ,那么判定为 ASCII 字节,除了 0 外余下的 7 位是 ASCII 码,所以 UTF-8 是兼容 ASCII 码的; 2. 如果第一个字节是 1 ,那么连续的几个 “1” 代表从这个字符开始,后面连续的几个字节其实是一个字位,且后面的字节都要以10开头。

了解如上规则,我们的程序便可轻松的处理UTF-8编码的字节流。例如要找出“中”的UTF-8编码,则可以这样处理(注意文件是UTF-8编码):

也可以写出针对UTF-8编码的strlen函数:

了解其原理,乱码不再困惑和迷茫。

参考

  1. https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/asciiBin.html
  2. http://www.unicode.org/faq/utf_bom.html#BOM
  3. https://my.oschina.net/goal/blog/195749
  4. http://mp.weixin.qq.com/s/2H6LZME03pUFNWBLNl0izw
  5. https://www.lifewire.com/file-linux-command-unix-command-4097142

Comments

开发者头条说道:

感谢分享!已推荐到《开发者头条》:https://toutiao.io/posts/pg41zk 欢迎点赞支持!
欢迎订阅《tlanyan》https://toutiao.io/subjects/314520

发表评论

Scroll Up