EXIF格式分析及通过XML处理
猛禽[Mental Studio](个人专栏)(BLOG)
http://mental.8gua.me
随着数码相机的普及，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<
span>头和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的扩展记录的。
|
起始
|
长度(Bytes)
|
内容
|
|
0x00
|
2
|
Number of Directory Entries(Count)
|
|
0x02
|
12 * Count
|
Directory Entries
|
|
2 + 12 * Count
|
4
|
Offset of next IFD
|
表4：IFD格式定义
每个IFD由三个部分组成，如表4所示，包括：Number of Directory Entries，Directory Entries和Offset of next IFD。其中Number of Directory Entries指定在Directory Entries中包含多少个Entry。Directory Entries是一个数组，包含若干个Directory Entry。最后的Offset of next IFD即是下个IFD所在的位置，如果此项为0，则表示这是链表中的最后一个IFD。
|
起始
|
长度(Bytes)
|
内容
|
|
0x00
|
2
|
Tag
|
|
0x02
|
2
|
Type
|
|
0x04
|
4
|
Size
|
|
0x08
|
4
|
Value
|
表5：IFD Entry格式定义
IFD Entry是一个12字节长的结构，如表5所示。正如TIFF的名称所说的那样：A tag-based file format for storing and interchanging raster images[2]。所有的IFD Entry都是通过Tag来标识的，每一个Tag都是一个WORD类型的数值，每个数值有其特定的含义。如0x0131这个Tag表示此Entry记录的是生成此TIFF文件的软件名等。具体每个Tag的含义可能查阅TIFF的规范文档[2]。EXIF只用到了其中部分Tag，另外还扩充了三个Tag用于链接EXIF的三个扩充IFD，这些在EXIF的规范文档中有说明[1]。
IFD Entry中的Type是指明此Entry中记录的数据类型，TIFF规范只定义了五种类型，EXIF增加了三种。各类型说明如表6所示：
|
Type
|
类型
|
Size
|
Value
|
|
1
|
BYTE
|
1
|
字节数据，Size一般为1
如果Size大于4，则Value为其位置
|
|
2
|
ASCII
|
n
|
一个ASCIIZ的字符串，Size为串长度，包括结尾的NULL字符
Size小于等于4则直接存放在Value中
Size大于4，则在Value中指定其位置
|
|
3
|
SHORT
|
1
|
无符号短整数，Size一般也为1
如果Size大于2，则Value为其位置
|
|
4
|
LONG
|
1
|
无符号长整数，Size一般也是1
|
|
5
|
RATIONAL
|
1
|
有理数，TIFF是用分数的形式来表达，用了两个LONG类型的数据，前一个LONG为分子，后一个LONG为分母，Size一般也是1。
因为一个RATIONAL类型包含两个LONG，无法记录在Value中，所以Value中记录的是这个RATIONAL数所在的位置（从TIFF Header开始的偏移）
|
|
以上为TIFF定义的类型，以下为EXIF扩展定义类型
|
|
7
|
UNDEFINED
|
n
|
任意的字节数据，根据具体情况定义
Size小于等于4则直接存放在Value中
Size大于4，则在Value中指定其位置
|
|
9
|
SLONG
|
1
|
有符号长整数，与LONG类似，以2的补码形式表示
|
|
10
|
SRATIONAL
|
1
|
有符号有理数，与RATIONAL类似，不过是用两个SLONG来表示
|
表6：Type定义
关于Value的内容有一点要注意的是，它可能是数据本身，也可能是数据存放位置的偏移，这取决于Type和Size的大小。数据存放位置都是从TIFF Header开始计算的偏移量。
有一点要注意的是：EXIF的三个扩充IFD Tag也是LONG类型，它记录的是相应IFD的起始位置（从TIFF Header开始的偏移）。在扩充IFD中用到的Tag全部是EXIF重新定义的。
下面是一个典型的EXIF JPEG文件格式分析结果（源文件为一张用Nikon CoolPixel 775相机拍摄的照片，所用的EXIF版本是2.1，与2.2版差别不大）：
JPEG SOI : FF D8 // 图片起始
JPEG APP1: FF E1
APP1 Size : 1C 45 // 注意：前面这三个WORD都是big endian的
EXIF Flag : ‘Exif’, 0, 0
TIFF Header:
Byte Order: ‘II’
Flag : 2A 00
IFD0 offset : 08 00 00 00
Entries Count : 0B 00 // 11
IFD Entry :
Tag : 0E 01 // Image Description 图像说明
Type : 02 00 // ASCII
Size : 0B 00 00 00
Value : 92 00 00 00 // from TIFF Header
IFD Entry:
Tag : 0F 01 // Make 制造
Type : 02 00
Size : 06 00 00 00
Value: B2 00 00 00
IFD Entry:
Tag : 10 01 // Model 型号
Type : 02 00
Size : 05 00 00 00
Value: CA 00 00 00
…
IFD Entry:
Tag : 69 87 // EXIF IFD
Type : 04 00 // LONG
Size : 01 00 00 00
Value: 1C 01 00 00 // Offset of EXIF IFD
END of IFD0
IFD1 Offset : 18 03 00 00
… // 存放IFD的Value数据
EXIF IFD :
Entries Count : 18 00
IFD Entry :
Tag : 9A 82 // Exposure time
…
END of EXIF IFD
Next IFD : 00 00 00 00 // 按标准IFD链表约定，表示没有后继IFD
… // 存放EXIF IFD的Value数据
IFD1 : // EXIF中用于存放缩略图
Entries Count : 06 00
IFD Entry :
Tag : 03 01
…
END of IFD1
Next IFD : 00 00 00 00 // EXIF只用到两个TIFF IFD
… // Thumbnail etc.
// end of TIFF header
// 其它JPEG Marker segments
JPEG EOI : FF D9 // 图片结束
对EXIF格式的分析，至此基本上告一个段落了。从分析结果上可以看出，EXIF是一种非常灵活的格式，具有非常好的可扩充性，要想较好地处理其中的相关数据也是比较麻烦的。
其困难主要在于几个方面：
1、对于每种不同的IFD Entry Type，需要用不同的方法获取数据，特别是对于数据长度不同时，可能采用不同的数据存储方式，而IFD Entry的数量又可能很多，每个Entry根据Tag不同又有不同的意义
2、EXIF IFD是作为TIFF IFD的子链表形式存在（因为EXIF的IFD里定义了不同于TIFF标准的Tag，要保持与标准的TIFF格式互用，必须这样做），使得原来的链表结构变成了树形结构
3、Tag的种类和数量非常之大，在EXIF规范里定义了各个Tag的支持级别（见[1]4.6.8），光是JPEG格式下必须支持的Tag就有十几个，TIFF格式更多，再加上可选支持的Tag，有几十上百个，并且还存在未来继续扩充的可能
4、对于可支持不同语言的软件来说，同一个Tag的意义要用每一种支持的语言表达一次，如果将这部分处理写入代码，对于增加新的语言支持会带来不必要的麻烦
为了解决这些困难，必须要找到一个同样是非常灵活的处理方法来处理EXIF数据。而XML正是这样一种方法。从前面的分析结果可以看出，EXIF的数据记录方式是层层嵌套的树形结构，是非常适合用XML的，因为XML也是这样的树形结构。
通过定义一套XML标签，然后将EXIF数据转换成XML文档，可以最大限度地保留EXIF数据的原始内容及结构。并且作为一种通用格式，XML可以很方便地进行再处理，比如：通过XSLT进行转换，使之成为HTML或其它便于显示的格式；或者将此XML传递给其它软件作进一步处理等。
对于前面说到的困难，XML都很好地解决：
1、不同类型的问题，通过转换为XML，将所有的Value都转换成字符串，便于统一处理
2、XML本来就是树形结构，可以在转换的时候方便地通过调整节点位置，使各IFD统一处理
3、可以将所有的Tag原样导出到XML中，在以后对XML的处理时再根据Tag进行处理，比如通过修改XSL文件实现对新增Tag的支持
4、同样是对XML处理时才需要面对具体的Tag，比如为不同的语言提供相应的XSL文件即可
下面的代码片断(Borland C++ Builder)实现了从EXIF数据到XML的转换：
//---------------------------------------------------------------------------#include typedef struct {WORD EntryTag;WORD EntryType;DWORD EntrySize;DWORD EntryValue;} TIFDEntry;#include //---------------------------------------------------------------------------BYTE * __fastcall TExifXML::GetIFD(_di_IXMLNode aNode, BYTE * aTIFFHeader, int aPosition, AnsiString aName){_di_IXMLNode pIFD = aNode->AddChild( "IFD" );if ( aName != "" )pIFD->Attributes["name"] = aName;BYTE * p = aTIFFHeader + aPosition;WORD nWord;memcpy( &nWord, p, sizeof ( nWord ) );p += sizeof ( nWord );_di_IXMLNode pChild = pIFD->AddChild( "Count" );pChild->Text = Format( "0x%X", ARRAYOFCONST( ( ( int )nWord ) ) );TIFDEntry ent;_di_IXMLNode pEntry;BYTE * pTemp;for ( int i = nWord; i > 0; --i ){memcpy( &ent, p, sizeof ( ent ) );p += sizeof ( ent );pEntry = pIFD->AddChild( "Entry" );pChild = pEntry->AddChild( "Tag" );pChild->Text = Format( "0x%X", ARRAYOFCONST( ( ( int )ent.EntryTag ) ) );pChild = pEntry->AddChild( "Type" );pChild->Text = IntToStr( ent.EntryType );pChild = pEntry->AddChild( "Size" );pChild->Text = Format( "0x%X", ARRAYOFCONST( ( ( int )ent.EntrySize ) ) );pChild = pEntry->AddChild( "Value" );switch ( ent.EntryType ) {case 1 : // BYTEif ( ent.EntrySize == 1 )pChild->Text = Format( "0x%.02X", ARRAYOFCONST( ( ( int )( BYTE )ent.EntryValue ) ) );elsethrow Exception( "Unsupported!" );break;case 2 : // ASCIIif ( ent.EntrySize <= 4 )pChild->Text = reinterpret_cast( &ent.EntryValue );elsepChild->Text = reinterpret_cast( aTIFFHeader + ent.EntryValue );break;case 3 : // SHORTif ( ent.EntrySize == 1 )pChild->Text = Format( "0x%.04X", ARRAYOFCONST( ( ( int )( WORD )ent.EntryValue ) ) );elsethrow Exception( "Unsupported!" );break;case 5 : // RATIONALpChild->Text = FloatToStr( *reinterpret_cast( aTIFFHeader + ent.EntryValue )/ ( double )( *reinterpret_cast( aTIFFHeader + ent.EntryValue + sizeof ( DWORD ) ) ) );break;case 7 : // UNDEFINEDif ( ent.EntrySize <= 4 )pTemp = reinterpret_cast( &ent.EntryValue );elsepTemp = aTIFFHeader + ent.EntryValue;pChild->Text = "";for ( int j = 0; j < ( int )ent.EntrySize; ++j ){pChild->Text = pChild->Text+ Format( " 0x%.02X", ARRAYOFCONST( ( ( int )( BYTE )( *pTemp ) ) ) );pTemp++;if ( j % 16 == 15 )pChild->Text = pChild->Text + "rn";}break;case 9 : // SLONGif ( ent.EntrySize == 1 )pChild->Text = IntToStr( ent.EntryValue );elsethrow Exception( "Unsupported!" );break;case 10: // SRATIONALpChild->Text = FloatToStr( *reinterpret_cast( aTIFFHeader + ent.EntryValue )/ ( double )( *reinterpret_cast( aTIFFHeader + ent.EntryValue + sizeof ( int ) ) ) );break;default: // LONG & other unknown typepChild->Text = Format( "0x%.08X", ARRAYOFCONST( ( ( int )ent.EntryValue ) ) );break;}switch ( ent.EntryTag ) {case 0x8769 : // Exif IFDGetIFD( aNode, aTIFFHeader, ent.EntryValue, "EXIF" );break;case 0x8805 : // GPS IFDGetIFD( aNode, aTIFFHeader, ent.EntryValue, "GPS" );break;case 0xA005 : // Interoperability IFDGetIFD( aNode, aTIFFHeader, ent.EntryValue, "InterOp" );break;}}return p;}//---------------------------------------------------------------------------void __fastcall TExifXML::GetTIFFHeader(_di_IXMLNode aNode, BYTE * aTIFFHeader){BYTE * p = aTIFFHeader;char sByteOrder[3];memcpy( sByteOrder, p, 2 );p += 2;sByteOrder[2] = 0;_di_IXMLNode pChild = aNode->AddChild( "ByteOrder" );pChild->Text = sByteOrder;WORD nFlag;memcpy( &nFlag, p, sizeof ( nFlag ) );p += sizeof ( nFlag );pChild = aNode->AddChild( "Flag" );pChild->Text = Format( "0x%.04X", ARRAYOFCONST( ( ( int )nFlag ) ) );DWORD nPointer;memcpy( &nPointer, p, sizeof ( nPointer ) );int i = 0;while ( nPointer > 0 ){p = GetIFD( aNode, aTIFFHeader, nPointer, AnsiString( "IFD" ) + IntToStr( i++ ) );if ( !p )break;memcpy( &nPointer, p, sizeof ( n
Pointer ) );}}//---------------------------------------------------------------------------int __fastcall TExifXML::LoadFromStream(TStream * aStream){if ( !FXMLDoc )throw Exception( "XMLDoc property is null!" );TMauto_ptr ms( new TMemoryStream( ) );ms->CopyFrom( aStream, aStream->Size );ms->Seek( 0, soFromBeginning );FXMLDoc->FileName = "";FXMLDoc->Active = true;FXMLDoc->Version = "1.0";FXMLDoc->Encoding = "GB2312";_di_IXMLNode pNode = FXMLDoc->AddChild( "ExifAPP1" );_di_IXMLNode pChild = pNode->AddChild( "ExifID" );char sExifID[6];ms->Read( sExifID, 6 );pChild->Text = sExifID;pChild = pNode->AddChild( "TIFFHeader" );BYTE * pHeader = static_cast( ms->Memory ) + ( int )ms->Position;GetTIFFHeader( pChild, pHeader );return ms->Size;}
其中FXMLDoc是一个TXMLDocument控件，用于生成XML。LoadFromStream方法读入的内容为JPEG APP1这个Marker Segment的内容（注意，不是JPEG文件）。GetTIFFHeader方法用于读出TIFFHeader的内容，包括Image File Header和IFD链表。GetIFD则是用于解读IFD的具体内容，其中包括对EXIF的三个扩充IFD的递归解读，并且其中包含了将各种数据类型转换为字符串的部分，特别是对不定长的UNDEFINED类型的处理（其结果见下面转换后的XML）。
转换后的XML大致如下：
<?xml version="1.0" encoding="GB2312"?><ExifAPP1><ExifID>Exif</ExifID><TIFFHeader><ByteOrder>II</ByteOrder><Flag>0x002A</Flag><IFD name="IFD0"><Count>0xB</Count><Entry><Tag>0x10E</Tag><Type>2</Type><Size>0xB</Size><Value> </Value></Entry><Entry><Tag>0x10F</Tag><Type>2</Type><Size>0x6</Size><Value>NIKON</Value></Entry><Entry><Tag>0x110</Tag><Type>2</Type><Size>0x5</Size><Value>E775</Value></Entry>...<Entry><Tag>0x8769</Tag><Type>4</Type><Size>0x1</Size><Value>0x0000011C</Value></Entry></IFD><IFD name="EXIF"><Count>0x18</Count>...<Entry><Tag>0x9000</Tag><Type>7</Type><Size>0x4</Size><Value> 0x30 0x32 0x31 0x30</Value></Entry>...<Entry><Tag>0x9286</Tag><Type>7</Type><Size>0x7D</Size><Value> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20</Value></Entry>...<Entry><Tag>0xA005</Tag><Type>4</Type><Size>0x1</Size><Value>0x00000376</Value></Entry>...</IFD><IFD name="InterOp"><Count>0x2</Count><Entry><Tag>0x1</Tag><Type>2</Type><Size>0x4</Size><Value>R98</Value></Entry><Entry><Tag>0x2</Tag><Type>7</Type><Size>0x4</Size><Value> 0x30 0x31 0x30 0x30</Value></Entry></IFD><IFD name="IFD1"><Count>0x6</Count><Entry><Tag>0x103</Tag><Type>3</Type><Size>0x1</Size><Value>0x0006</Value></Entry>...</IFD></TIFFHeader></ExifAPP1>
有了这个XML就可以很方便地进行下一步处理了，比如用下面这个XSL文件对上面这个XML进行转换：
<?xml version="1.0" encoding="GB2312" ?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/TR/WD-xsl"><xsl:template match="/"><xsl:for-each select="ExifAPP1/TIFFHeader/IFD/Entry"><xsl:choose><xsl:when test="Tag[.='0x10F']">制造商=<xsl:value-of select="Value" /></xsl:when><xsl:when test="Tag[.='0x110']">型号=<xsl:value-of select="Value" /></xsl:when></xsl:choose></xsl:for-each></xsl:template></xsl:stylesheet>
即可得出下面的结果：
制造商=NIKON
型号=E775
以后不论是增加Tag还是要改语言，只要修改这个XSL文件即可实现，完全不用修改EXIF处理部分的程序代码，非常的灵活方便。
[Mental Studio]猛禽
参考文献：
[1] JEITA CP-3451. Exchangeable image file format for digital still cameras:Exif Version 2.2. JEITA(Japan Electronics & Information Technolog Industries Association). April, 2002.
[2] Aldus Corporation. TIFF Revision 6.0 Final – June 3,1992.
[3] Gregory K.Wallace. The JPEG Still Picture Compression Standard.Communications of the ACM. April, 1991.
[4] Eric Hamilton. JPEG File Interchange Format Version 1.02. C-Cube Microsystem. September 1, 1992.
