0

关于投票
Unicode编码
问题一:

使用Windows记事本的“另存为”,可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件,Windows是怎样识别编码方式的呢?

我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节,分别是FF、FE(Unicode),FE、FF(Unicode big endian),EF、BB、BF(UTF-8)。但这些标记是基于什么标准呢?

问题二:
最近在网上看到一个ConvertUTF.c,实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式,我原来就了解。但这个程序让我有些糊涂,想不起来UTF-16和UCS2有什么关系。

查了查相关资料,总算将这些问题弄清楚了,顺带也了解了一些Unicode的细节。写成一篇文章,送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂,但要求读者知道什么是字节,什么是十六进制。

0、big endian和little endian

big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时,究竟是将6C写在前面,还是将49写在前面?如果将6C写在前面,就是big endian。还是将49写在前面,就是little endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开,由此曾发生过六次叛乱,其中一个皇帝送了命,另一个丢了王位。

我们一般将endian翻译成“字节序”,将big endian和little endian称作“大尾”和“小尾”。

1、字符编码、内码,顺带介绍汉字编码

字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码,为了处理汉字,程序员设计了用于简体中文的GB2312和用于繁体中文的big5。

GB2312(1980年)一共收录了7445个字符,包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7,低字节从A1-FE,占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号,它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030,对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。

从ASCII、GB2312、GBK到GB18030,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

有的中文Windows的缺省内码还是GBK,可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符,普通人是很难用到的,通常我们还是用GBK指代中文Windows内码。

这里还有一些细节:

  • GB2312的原文还是区位码,从区位码到内码,需要在高字节和低字节上分别加上A0。

  • 在DBCS中,GB内码的存储格式始终是big endian,即高位在前。

  • GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析:在读取DBCS字符流时,只要遇到高位为1的字节,就可以将下两个字节作为一个双字节编码,而不用管低字节的高位是什么。

2、Unicode、UCS和UTF

前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容(更准确地说,是与ISO-8859-1兼容),与GB码不兼容。例如“汉”字的Unicode编码是6C49,而GB码是BABA。

Unicode也是一种字符编码方法,不过它是由国际组织设计,可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set",简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载:历史上存在两个试图独立设计Unicode的组织,即国际标准化组织(ISO)和一个软件制造商的协会(unicode.org)。ISO开发了ISO 10646项目,Unicode协会开发了Unicode项目。

在1991年前后,双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果,并为创立一个单一编码表而协同工作。从Unicode2.0开始,Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在,并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是10646-3:2003。

UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码,是由UTF(UCS Transformation Format)规范规定的,常见的UTF规范包括UTF-8、UTF-7、UTF-16。

IETF的RFC2781和RFC3629以RFC的一贯风格,清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

3、UCS-2、UCS-4、BMP

UCS有两种格式:UCS-2和UCS-4。顾名思义,UCS-2就是用两个字节编码,UCS-4就是用4个字节(实际上只用了31位,最高位必须为0)编码。下面让我们做一些简单的数学游戏:

UCS-2有2^16=65536个码位,UCS-4有2^31=2147483648个码位。

UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为256行 (rows),每行包含256个cells。当然同一行的cells只是最后一个字节不同,其余都相同。

group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中,高两个字节为0的码位被称作BMP。

将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节,就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。

4、UTF编码

UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下:

UCS-2编码(16进制) UTF-8 字节流(二进制)
0000 - 007F 0xxxxxxx
0080 - 07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx

例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间,所以肯定要用3字节模板了:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 110001 001001, 用这个比特流依次代替模板中的x,得到:11100110 10110001 10001001,即E6 B1 89。

读者可以用记事本测试一下我们的编码是否正确。

UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码,UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码,定义了一个算法。不过由于实际使用的UCS2,或者UCS4的BMP必然小于0x10000,所以就目前而言,可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案,UTF-16却要用于实际的传输,所以就不得不考虑字节序的问题。

5、UTF的字节序和BOM

UTF-8以字节为编码单元,没有字节序的问题。UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是“奎”还是“乙”?

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表,而是Byte Order Mark。BOM是一个有点小聪明的想法:

在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前,先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF(读者可以用我们前面介绍的编码方法验证一下)。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

6、进一步的参考资料

本文主要参考的资料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

  1. "Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
  2. "Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
系统分类: 消费电子
用户分类: 多媒体处理
标签: 无标签
来源: 无分类
发表评论 阅读全文(317) | 回复(0)

0

关于投票
JPEG文件格式解析
 

微处理机中的存放顺序有正序(big endian)和逆序(little endian)之分。正序存放就是高字节存放在前低字节在后,而逆序存放就是低字节在前高字节在后。例如,十六进制数为A02B,正序存放就是A02B,逆序存放就是2BA0。摩托罗拉(Motorola)公司的微处理器使用正序存放,而英特尔(Intel)公司的微处理器使用逆序。JPEG文件中的字节是按照正序排列的。


JPEG委员会在制定JPEG标准时,定义了许多标记(marker)用来区分和识别图像数据及其相关信息,但笔者没有找到JPEG委员会对JPEG文件交换格式的明确定义。直到1998年12月从分析网上具体的JPG图像来看,使用比较广泛的还是JPEG文件交换格式(JPEG File Interchange Format,JFIF)本号为1.02。这是1992年9月由在C-Cube Microsystems公司工作的Eric Hamilton提出的。此外还有TIFF JPEG等格式,但由于这种格式比较复杂,因此大多数应用程序都支持JFIF文件交换格式。

JPEG文件使用的颜色空间是CCIR 601推荐标准进行的彩色空间(参看第7章)。在这个彩色空间中,每个分量、每个像素的电平规定为255级,用8位代码表示。从RGB转换成YCbCr空间时,使用下面的精确的转换关系:

       Y = 256 * E'y

      Cb = 256 * [E'Cb] + 128

      Cr = 256 * [E'Cr] + 128
其中亮度电平E'y和色差电平E'Cb和E'Cb分别是CCIR 601定义的参数。由于E'y的范围是0~1,E'Cb和E'Cb的范围是-0.5~+0.5,因此Y, Cb和Cr的最大值必须要箝到255。于是RGB和YCbCr之间的转换关系需要按照下面的方法计算。

(1) 从RGB转换成YCbCr

YCbCr(256级)分量可直接从用8位表示的RGB分量计算得到:

       Y =   0.299 R + 0.587 G  + 0.114 B

     Cb = - 0.1687R - 0.3313G  + 0.5   B + 128

    Cr = 0.5 R - 0.4187G - 0.0813 B + 128

需要注意的是不是所有图像文件格式都按照R0,G0,B0,…… Rn,Gn,Bn的次序存储样本数据,因此在RGB文件转换成JFIF文件时需要首先验证RGB的次序。

(2) 从YCbCr转换成RGB

RGB分量可直接从YCbCr(256级)分量计算得到:

     R = Y                 + 1.402 (Cr-128)

      G = Y - 0.34414 (Cb-128) - 0.71414 (Cr-128)

      B = Y + 1.772 (Cb-128)

在JFIF文件格式中,图像样本的存放顺序是从左到右和从上到下。这就是说JFIF文件中的第一个图像样本是图像左上角的样本。

2 文件结构

JFIF文件格式直接使用JPEG标准为应用程序定义的许多标记,因此JFIF格式成了事实上JPEG文件交换格式标准。JPEG的每个标记都是由2个字节组成,其前一个字节是固定值0xFF。每个标记之前还可以添加数目不限的0xFF填充字节(fill byte)。下面是其中的8个标记:

  1. SOI  0xD8            图像开始
  2. APP0 0xE0            JFIF应用数据块
  3. APPn 0xE1 - 0xEF    其他的应用数据块(n, 1~15)
  4. DQT  0xDB           量化表
  5. SOF0 0xC0            帧开始
  6. DHT  0xC4           霍夫曼(Huffman)表
  7. SOS  0xDA           扫描线开始
  8. EOI  0xD9            图像结束

为使读者对JPEG定义的标记一目了然,现将JPEG的标记码列于表6-05,并保留英文解释。

表6-05 JPEG定义的标记

Symbol

(符号)

Code Assignment

(标记代码)

Description

(说明)

Start Of Frame markers, non-hierarchical Huffman coding

SOF0

0xFFC0

Baseline DCT

SOF1

0xFFC1

Extended sequential DCT

SOF2

0xFFC2

Progressive DCT

SOF3

0xFFC3

Spatial (sequential) lossless

Start Of Frame markers, hierarchical Huffman coding

SOF5

0xFFC5

Differential sequential DCT

SOF6

0xFFC6

Differential progressive DCT

SOF7

0xFFC7

Differential spatial lossless

Start Of Frame markers, non-hierarchical arithmetic coding

JPG

0xFFC8

Reserved for JPEG extensions

SOF9

0xFFC9

Extended sequential DCT

SOF10

0xFFCA

Progressive DCT

SOF11

0xFFCB

Spatial (sequential) Lossless

Start Of Frame markers, hierarchical arithmetic coding

SOF13

0xFFCD

Differential sequential DCT

SOF14

0xFFCE

Differential progressive DCT

SOF15

0xFFCF

Differential spatial Lossless

Huffman table specification

DHT

0xFFC4

Define Huffman table(s)

arithmetic coding conditioning specification

DAC

0xFFCC

Define arithmetic conditioning table

Restart interval termination

RSTm

0xFFD0~0xFFD7

Restart with modulo 8 counter m

Other marker

SOI

0xFFD8

Start of image

EOI

0xFFD9

End of image

SOS

0xFFDA

Start of scan

DQT

0xFFDB

Define quantization table(s)

DNL

0xFFDC

Define number of lines

DRI

0xFFDD

Define restart interval

DHP

0xFFDE

Define hierarchical progression

EXP

0xFFDF

Expand reference image(s)

APPn

0xFFE0~0xFFEF

Reserved for application use

JPGn

0xFFF0~0xFFFD

Reserved for JPEG extension

COM

0xFFFE

Comment

Reserved markers

TEM

0xFF01

For temporary use in arithmetic coding

RES

0xFF02~0xFFBF

Reserved

JPEG文件由下面的8个部分组成:

(1) 图像开始SOI(Start of Image)标记

(2) APP0标记(Marker)

① APP0长度(length)

② 标识符(identifier)

③ 版本号(version)

④ X和Y的密度单位(units=0:无单位;units=1:点数/英寸;units=2:点数/厘米)

⑤ X方向像素密度(X density)

⑥ Y方向像素密度(Y density)

⑦ 缩略图水平像素数目(thumbnail horizontal pixels)

⑧ 缩略图垂直像素数目(thumbnail vertical pixels)

⑨ 缩略图RGB位图(thumbnail RGB bitmap)

(3) APPn标记(Markers),其中n=1~15(任选)

① APPn长度(length)

② 由于详细信息(application specific information)

(4) 一个或者多个量化表DQT(difine quantization table)

① 量化表长度(quantization table length)

② 量化表数目(quantization table number)

③ 量化表(quantization table)

(5) 帧图像开始SOF0(Start of Frame)

① 帧开始长度(start of frame length)

② 精度(precision),每个颜色分量每个像素的位数(bits per pixel per color component)

③ 图像高度(image height)

④ 图像宽度(image width)

⑤ 颜色分量数(number of color components)

⑥ 对每个颜色分量(for each component)

    • ID
    • 垂直方向的样本因子(vertical sample factor)
    • 水平方向的样本因子(horizontal sample factor)
    • 量化表号(quantization table#)

(6) 一个或者多个霍夫曼表DHT(Difine Huffman Table)

① 霍夫曼表的长度(Huffman table length)

② 类型、AC或者DC(Type, AC or DC)

③ 索引(Index)

④ 位表(bits table)

⑤ 值表(value table)

(7) 扫描开始SOS(Start of Scan)

① 扫描开始长度(start of scan length)

② 颜色分量数(number of color components)

③ 每个颜色分量

    • ID
    • 交流系数表号(AC table #)
    • 直流系数表号(DC table #)

④ 压缩图像数据(compressed image data)

(8) 图像结束EOI(End of Image)

表6-06表示了APP0域的详细结构。有兴趣的读者可通过UltraEdit或者PC TOOLS等工具软件打开一个JPG图像文件,对APP0的结构进行分析和验证。

表6-06 JFIF格式中APP0域的详细结构

偏移

长度

内容

块的名称

说明

0

2 byte

0xFFD8

(Start of Image,SOI)

图像开始

2

2 byte

0xFFE0

APP0(JFIF application segment)

JFIF应用数据块

4

2 bytes

 

length of APP0 block

APP0块的长度

6

5 bytes

 

"JFIF"+"0"

识别APP0标记

11

1 byte

 

<Major version>

主要版本号(如版本1.02中的1)

12

1 byte

 

<Minor version>

次要版本号(如版本1.02中的02)

13

1 byte

 

<Units for the X
and Y densities>

X和Y的密度单位

units=0:无单位

units=1:点数/英寸

units=2:点数/厘米

14

2 bytes

 

<Xdensity>

水平方向像素密度

16

2 bytes

 

<Ydensity>

垂直方向像素密度

18

1 byte

 

<Xthumbnail>

缩略图水平像素数目

19

1 byte

 

<Ythumbnail>

缩略图垂直像素数目

 

3n

 

< Thumbnail RGB bitmap>

缩略RGB位图(n为缩略图的像素数)

     

Optional JFIF extension APP0 marker segment(s)

任选的JFIF扩展APP0标记段

 

……