EXIF格式分析及通过XML处理
随着数码相机的普及，EXIF已经被大多数图像处理软件所支持。虽然我做的是一个小玩意儿（见《人个信息助理之我的相册》）但毕竟也是用于图像处理的，虽然目前支持JPEG文件格式，但是还不支持EXIF。
那么，什么是EXIF呢？EXIF是Exchangeable image file format的缩写，即“可交换图像文件格式”，它是由日本电子与信息技术工业协会（JEITA）所制定的一项标准，用于实现在不同的软件或设备之间交流图像数据，典型的应用就是数码相机直接连接打印机打印照片。当然，EXIF中还包含了很丰富的信息，从中可以知道这个数码照片是用什么相机拍的，拍摄时用的光圈、速度、ISO等。而且最新版本的EXIF还支持音频格式文件。
关于EXIF的最权威文档资料当然是JEITA的标准规范[1]，目前最新的版本是2.2。不过JEITA的网站上虽然提供了两个语言版本（日语和英语，并且JEITA声明以日文版为准）的规范文档，但是需要收费的。还好通过GOOGLE还是找到了一个英文版的。
EXIF只提供对两种图像文件格式的支持：TIFF[2]和JPEG[3,4]。其中对不压缩图像使用TIFF格式，对压缩图像使用JPEG格式。本文主要讨论JPEG格式。
我们知道JPEG文件格式是通过所谓的Marker Segments来记录图像的相关信息的，这种方式具有非常好的灵活性和可扩充性，较之早年的PCX，GIF，BMP等采用固定格式文件头记录的方式要好很多（PCX原先是为16色图像设计的，在256色图像出现后，就破坏了原先的格式定义，将调色板续在文件尾部；而GIF虽然内部也有分段机制，后来被扩充为实现动画功能，但仍然是采用固定格式的文件头记录基本信息），而EXIF就是利用了这一点。
JPEG文件中的每一个Marker Segments都是以一个WORD类型的数值开始（注意：这个数值记录在文件中时是高位字节在前，低位字节在后，将在后面介绍这个字节顺序的问题），这个数值即所谓的Marker，每个Marker代表着相应的Segment的意义，如果这个Segment有内容（即长度大于0，是否有内容视具体Marker而定），接下来的一个WORD类型的数值就是这个Segment的长度（这个数值的字节顺序与Marker相同），至于Segment的具体内容，则根据Marker的不同有不同的定义。如FFD8这个Marker叫做SOI，表示图像的开始，这个段是没有内容的；如FFE0则是APP0，即应用程序段0，属于可自定义的数据，它已经被用于JFIF[4]，这个段则是有内容的，接下来的一个WORD就是段长度，段内容的定义是由JFIF规范所定义。
EXIF也是一种扩展定义，类似于JFIF，它使用了APP1和APP2这两个Marker Segments。之所以要用两个Marker是因为如前面所说，Segment的长度是用一个WORD来表示，即最大不超过64K。因为EXIF支持一种被称为Flashpix的无损图像格式，其数据很可能超过64K，所以用了APP2，其中APP2可以有多个，不过因为对Flashpix的支持属于EXIF的扩展功能（在规范文档的附录F中说明[1]），通常很少用到，本文不作讨论。
EXIF定义的APP1段是一个标准的JPEG Marker Segment，如表1所示。其中的APP1 Marker的值为FFE1，Length为这个段的长度，其值包括Length本身所占的两个字节，但不包括Marker所占的两个字节。段中剩下的部分便是EXIF数据。
EXIF数据的格式定义也很简单，如表2所示。它包括两个部分：EXIF头和TIFF头。EXIF头由六个字节组成，其内容为一个长度为4的ASCIIZ（以NULL结尾的ASCII）字符串，加一个字节的0（用于使数据按WORD对齐），而这个ASCIIZ串内容就是“Exif”。而TIFF头则是采用了标准的TIFF文件格式的定义（TIFF同样是一种定义灵活的文件格式，在某种程度上说是太灵活了），这样可以让JPEG和TIFF两种格式中的EXIF信息可以以一致的方法进行处理。
起始
长度(Bytes)
内容
0x00
2
APP1 Marker(0xFFE1)
0x02
2
Length
0x04
Length - 2
EXIF Data
表1：APP1段格式定义
起始
长度(Bytes)
内容
0x00
6
EXIF Header
0x06
APP1 Length - 8
TIFF Header
表2：EXIF格式定义
起始
长度(Bytes)
内容
0x00
2
Byte order
0x02
2
Flag(0x2A)
0x04
4
The offset of the first IFD
表3：TIFF Image File Header格式定义
TIFF Header[2]包括两个部分：Image File Header和IFD（Image File Directory）链表。其中Image File Header的定义如表3所示。其中Byte order用于说明此TIFF文件所采用的字节顺序，用两个字符表示，有两种选择，分别是：II和MM（这个MM跟美眉无关J），其中II是指采用Intel字节顺序，而MM是指采用Motolora字节顺序（见下面的说明）。Flag是TIFF文件格式的标志，总是为0x002A，即十进制数42。最后一个DWORD是指向第一个IFD的起始位置，其偏移量的计算起点是TIFF Header的起点，即如果第一个IFD是紧接着Image File Header的话，这一项的值就为8（Image File Header的大小）。
关于字节顺序的说明：
字节顺序是可交换文件格式中，特别需要注意的一个问题。所谓“可交换文件格式”就是说这种文件格式可以在各种不同的软硬件平台下被正确地解读。字节顺序问题的起因在于硬件上。
在CPU发展的早期（8位CPU的时代），由于指令集的丰富，许多8位CPU都可以处理16位数据，当然都是分两次进行的，这时就出现的字节顺序的问题：是先处理高位字节还是先处理低位字节？不同的CPU厂商采用不同的选择！以Intel, Zilog等公司为代表的CPU厂商是采用先低后高的方式，即低位地址保存低位字节的数据；而以Motolora（它可不止是做手机，它曾经是世界上最大的电子产品制造商）则是采用先高后低的方式，与通常人的阅读顺序一致。对应的硬件就是采用Intel架构的IBM PC及其兼容机上运行的软件都是采用Intel顺序的，而采用由IBM，Motolora，Apple共同设计的Power PC芯片的Apple Mac则是采用Motolora顺序的。
现在，字节顺序问题不只出现在图像格式上，由于Unicode字符集（UCS）也是采用了16位（UCS-2）或32位（UCS-4）来表示一个字符，所以也面临着字节顺序的问题。
另外，按照各自字节顺序的特点，Intel的字节顺序也叫做little-endian，而Motolora的字节顺序就叫做big-endian。
图1：IFD链表结构
IFD是一个链表结构，如图1所示，在每个IFD的末尾包含一个指向下一个IFD的偏移量（同样是从TIFF Header算起），如果这个偏移量为0，则表示已经到了链表的末尾。EXIF只使用了两个TIFF IFD，分别被称作IFD0和IFD1，但定义了三个自己的IFD：EXIF IFD, GPS IFD, Interoperability IFD，它们的结构与标准TIFF IFD相同，但不是记录于TIFF的IFD链表中，而是作为IFD0的扩展记录的。
(待续)
