1.概述
~~~~~~~~

　　GIF(Graphics Interchange Format，圖形交換格式)文件是由 CompuServe公司開(kāi)發(fā)的圖形文件格式，版權(quán)所有，任何商業(yè)目的使用均須 CompuServe公司授權(quán)。
　　GIF圖象是基于顏色列表的（存儲(chǔ)的數(shù)據(jù)是該點(diǎn)的顏色對(duì)應(yīng)于顏色列表的索引值），最多只支持8位（256色）。GIF文件內(nèi)部分成許多存儲(chǔ)塊，用來(lái)存儲(chǔ)多幅圖象或者是決定圖象表現(xiàn)行為的控制塊，用以實(shí)現(xiàn)動(dòng)畫(huà)和交互式應(yīng)用。GIF文件還通過(guò)LZW壓縮算法壓縮圖象數(shù)據(jù)來(lái)減少圖象尺寸（關(guān)于LZW算法和GIF數(shù)據(jù)壓縮>>...）。

2.GIF文件存儲(chǔ)結(jié)構(gòu)
~~~~~~~~~~~~~~~~~~~

　　GIF文件內(nèi)部是按塊劃分的，包括控制塊（ Control Block ）和數(shù)據(jù)塊（Data Sub-blocks）兩種。控制塊是控制數(shù)據(jù)塊行為的，根據(jù)不同的控制塊包含一些不同的控制參數(shù)；數(shù)據(jù)塊只包含一些8-bit的字符流，由它前面的控制塊來(lái)決定它的功能，每個(gè)數(shù)據(jù)塊大小從0到255個(gè)字節(jié)，數(shù)據(jù)塊的第一個(gè)字節(jié)指出這個(gè)數(shù)據(jù)塊大小（字節(jié)數(shù)），計(jì)算數(shù)據(jù)塊的大小時(shí)不包括這個(gè)字節(jié)，所以一個(gè)空的數(shù)據(jù)塊有一個(gè)字節(jié)，那就是數(shù)據(jù)塊的大小0x00。下表是一個(gè)數(shù)據(jù)塊的結(jié)構(gòu)：

　　一個(gè)GIF文件的結(jié)構(gòu)可分為文件頭(File Header)、GIF數(shù)據(jù)流(GIF Data Stream)和文件終結(jié)器(Trailer)三個(gè)部分。文件頭包含GIF文件署名(Signature)和版本號(hào)(Version)；GIF數(shù)據(jù)流由控制標(biāo)識(shí)符、圖象塊(Image Block)和其他的一些擴(kuò)展塊組成；文件終結(jié)器只有一個(gè)值為0x3B的字符（';'）表示文件結(jié)束。下表顯示了一個(gè)GIF文件的組成結(jié)構(gòu)：

　　下面就具體介紹各個(gè)部分:

文件頭部分(Header)
~~~~~~~~~~~~~~~~~

GIF署名(Signature)和版本號(hào)(Version)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GIF署名用來(lái)確認(rèn)一個(gè)文件是否是GIF格式的文件，這一部分由三個(gè)字符組成："GIF";文件版本號(hào)也是由三個(gè)字節(jié)組成,可以為"87a"或"89a".具體描述見(jiàn)下表:

GIF數(shù)據(jù)流部分(GIF Data Stream)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

邏輯屏幕標(biāo)識(shí)符(Logical Screen Descriptor)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
這一部分由7個(gè)字節(jié)組成，定義了GIF圖象的大小(Logical Screen Width & Height)、顏色深度(Color Bits)、背景色(Blackground Color Index)以及有無(wú)全局顏色列表(Global Color Table)和顏色列表的索引數(shù)(Index Count)，具體描述見(jiàn)下表：

m - 全局顏色列表標(biāo)志(Global Color Table Flag)，當(dāng)置位時(shí)表示有全局顏色列表，pixel值有意義.
cr - 顏色深度(Color ResoluTion)，cr+1確定圖象的顏色深度.
s - 分類(lèi)標(biāo)志(Sort Flag)，如果置位表示全局顏色列表分類(lèi)排列.
pixel - 全局顏色列表大小，pixel+1確定顏色列表的索引數(shù)（2的pixel+1次方）.

全局顏色列表(Global Color Table)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
全局顏色列表必須緊跟在邏輯屏幕標(biāo)識(shí)符后面，每個(gè)顏色列表索引條目由三個(gè)字節(jié)組成，按R、G、B的順序排列。

圖象標(biāo)識(shí)符(Image Descriptor)
~~~~~~~~~~~~~~~~~~~~~~~~~
一個(gè)GIF文件內(nèi)可以包含多幅圖象，一幅圖象結(jié)束之后緊接著下是一幅圖象的標(biāo)識(shí)符，圖象標(biāo)識(shí)符以0x2C(',')字符開(kāi)始，定義緊接著它的圖象的性質(zhì)，包括圖象相對(duì)于邏輯屏幕邊界的偏移量、圖象大小以及有無(wú)局部顏色列表和顏色列表大小，由10個(gè)字節(jié)組成：

局部顏色列表(Local Color Table)
~~~~~~~~~~~~~~~~~~~~~~~~~~
如果上面的局部顏色列表標(biāo)志置位的話(huà)，則需要在這里（緊跟在圖象標(biāo)識(shí)符之后）定義一個(gè)局部顏色列表以供緊接著它的圖象使用，注意使用前應(yīng)線(xiàn)保存原來(lái)的顏色列表，使用結(jié)束之后回復(fù)原來(lái)保存的全局顏色列表。如果一個(gè)GIF文件即沒(méi)有提供全局顏色列表，也沒(méi)有提供局部顏色列表，可以自己創(chuàng)建一個(gè)顏色列表，或使用系統(tǒng)的顏色列表。局部顏色列表的排列方式和全局顏色列表一樣：RGBRGB......

基于顏色列表的圖象數(shù)據(jù)(Table-Based Image Data)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
由兩部分組成：LZW編碼長(zhǎng)度(LZW Minimum Code Size)和圖象數(shù)據(jù)(Image Data)。

GIF圖象數(shù)據(jù)使用了LZW壓縮算法（詳細(xì)介紹請(qǐng)看后面的『LZW算法和GIF數(shù)據(jù)壓縮』），大大減小了圖象數(shù)據(jù)的大小。圖象數(shù)據(jù)在壓縮前有兩種排列格式：連續(xù)的和交織的(由圖象標(biāo)識(shí)符的交織標(biāo)志控制)。連續(xù)方式按從左到右、從上到下的順序排列圖象的光柵數(shù)據(jù)；交織圖象按下面的方法處理光柵數(shù)據(jù)：

創(chuàng)建四個(gè)通道(pass)保存數(shù)據(jù)，每個(gè)通道提取不同行的數(shù)據(jù)：
第一通道(Pass 1)提取從第0行開(kāi)始每隔8行的數(shù)據(jù)；
第二通道(Pass 2)提取從第4行開(kāi)始每隔8行的數(shù)據(jù)；
第三通道(Pass 3)提取從第2行開(kāi)始每隔4行的數(shù)據(jù)；
第四通道(Pass 4)提取從第1行開(kāi)始每隔2行的數(shù)據(jù)；

下面的例子演示了提取交織圖象數(shù)據(jù)的順序：

圖形控制擴(kuò)展(Graphic Control Extension)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
這一部分是可選的（需要89a版本），可以放在一個(gè)圖象塊(圖象標(biāo)識(shí)符)或文本擴(kuò)展塊的前面，用來(lái)控制跟在它后面的第一個(gè)圖象（或文本）的渲染(Render)形式，組成結(jié)構(gòu)如下：

處置方法(Disposal Method)：指出處置圖形的方法，當(dāng)值為：
                        0 - 不使用處置方法
                        1 - 不處置圖形，把圖形從當(dāng)前位置移去
                        2 - 回復(fù)到背景色
                        3 - 回復(fù)到先前狀態(tài)
                      4-7 - 自定義
用戶(hù)輸入標(biāo)志(Use Input Flag)：指出是否期待用戶(hù)有輸入之后才繼續(xù)進(jìn)行下去，置位表示期待，值否表示不期待。用戶(hù)輸入可以是按回車(chē)鍵、鼠標(biāo)點(diǎn)擊等，可以和延遲時(shí)間一起使用，在設(shè)置的延遲時(shí)間內(nèi)用戶(hù)有輸入則馬上繼續(xù)進(jìn)行，或者沒(méi)有輸入直到延遲時(shí)間到達(dá)而繼續(xù)
透明顏色標(biāo)志(Transparent Color Flag)：置位表示使用透明顏色

注釋擴(kuò)展(Comment Extension)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
這一部分是可選的（需要89a版本），可以用來(lái)記錄圖形、版權(quán)、描述等任何的非圖形和控制的純文本數(shù)據(jù)(7-bit ASCII字符)，注釋擴(kuò)展并不影響對(duì)圖象數(shù)據(jù)流的處理，解碼器完全可以忽略它。存放位置可以是數(shù)據(jù)流的任何地方，最好不要妨礙控制和數(shù)據(jù)塊，推薦放在數(shù)據(jù)流的開(kāi)始或結(jié)尾。具體組成：

圖形文本擴(kuò)展(Plain Text Extension)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

這一部分是可選的（需要89a版本），用來(lái)繪制一個(gè)簡(jiǎn)單的文本圖象，這一部分由用來(lái)繪制的純文本數(shù)據(jù)（7-bit ASCII字符）和控制繪制的參數(shù)等組成。繪制文本借助于一個(gè)文本框（Text Grid）來(lái)定義邊界，在文本框中劃分多個(gè)單元格，每個(gè)字符占用一個(gè)單元，繪制時(shí)按從左到右、從上到下的順序依次進(jìn)行，直到最后一個(gè)字符或者占滿(mǎn)整個(gè)文本框（之后的字符將被忽略，因此定義文本框的大小時(shí)應(yīng)該注意到是否可以容納整個(gè)文本），繪制文本的顏色索引使用全局顏色列表，沒(méi)有則可以使用一個(gè)已經(jīng)保存的前一個(gè)顏色列表。另外，圖形文本擴(kuò)展塊也屬于圖形塊(Graphic Rendering Block)，可以在它前面定義圖形控制擴(kuò)展對(duì)它的表現(xiàn)形式進(jìn)一步修改。圖形文本擴(kuò)展的組成：

推薦：1.由于文本的字體(Font)和尺寸(Size)沒(méi)有定義，解碼器應(yīng)該根據(jù)情況選擇最合適的；
2.如果一個(gè)字符的值小于0x20或大于0xF7，則這個(gè)字符被推薦顯示為一個(gè)空格(0x20)；
3.為了兼容性，最好定義字符單元格的大小為8x8或8x16（寬度x高度）。

應(yīng)用程序擴(kuò)展(Application Extension)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

這是提供給應(yīng)用程序自己使用的（需要89a版本），應(yīng)用程序可以在這里定義自己的標(biāo)識(shí)、信息等，組成：

文件結(jié)尾部分
~~~~~~~~~~~

文件終結(jié)器(Trailer)
~~~~~~~~~~~~~~~~

這一部分只有一個(gè)值為0的字節(jié)，標(biāo)識(shí)一個(gè)GIF文件結(jié)束.

2.LZW算法和GIF數(shù)據(jù)壓縮
~~~~~~~~~~~~~~~~~~~~~~~~~~~

　　GIF文件的圖象數(shù)據(jù)使用了可變長(zhǎng)度編碼的LZW壓縮算法(Variable-Length_Code LZW Compression)，這是從LZW(Lempel Ziv Compression)壓縮算法演變過(guò)來(lái)的，通過(guò)壓縮原始數(shù)據(jù)的重復(fù)部分來(lái)達(dá)到減少文件大小的目的。

標(biāo)準(zhǔn)的LZW壓縮原理：
~~~~~~~~~~~~~~~~~~
先來(lái)解釋一下幾個(gè)基本概念：
　　LZW壓縮有三個(gè)重要的對(duì)象：數(shù)據(jù)流(CharStream)、編碼流(CodeStream)和編譯表(String Table)。在編碼時(shí)，數(shù)據(jù)流是輸入對(duì)象（圖象的光柵數(shù)據(jù)序列），編碼流就是輸出對(duì)象（經(jīng)過(guò)壓縮運(yùn)算的編碼數(shù)據(jù)）；在解碼時(shí)，編碼流則是輸入對(duì)象，數(shù)據(jù)流是輸出對(duì)象；而編譯表是在編碼和解碼時(shí)都須要用借助的對(duì)象。

字符(Character)：最基礎(chǔ)的數(shù)據(jù)元素，在文本文件中就是一個(gè)字節(jié)，在光柵數(shù)據(jù)中就是一個(gè)像素的顏色在指定的顏色列表中的索引值；
字符串(String)：由幾個(gè)連續(xù)的字符組成；
前綴(Prefix)：也是一個(gè)字符串，不過(guò)通常用在另一個(gè)字符的前面，而且它的長(zhǎng)度可以為0；
根(Root)：?jiǎn)蝹€(gè)長(zhǎng)度的字符串；
編碼(Code)：一個(gè)數(shù)字，按照固定長(zhǎng)度（編碼長(zhǎng)度）從編碼流中取出，編譯表的映射值；
圖案：一個(gè)字符串，按不定長(zhǎng)度從數(shù)據(jù)流中讀出,映射到編譯表?xiàng)l目.

　　LZW壓縮的原理：提取原始圖象數(shù)據(jù)中的不同圖案，基于這些圖案創(chuàng)建一個(gè)編譯表，然后用編譯表中的圖案索引來(lái)替代原始光柵數(shù)據(jù)中的相應(yīng)圖案，減少原始數(shù)據(jù)大小。看起來(lái)和調(diào)色板圖象的實(shí)現(xiàn)原理差不多，但是應(yīng)該注意到的是，我們這里的編譯表不是事先創(chuàng)建好的，而是根據(jù)原始圖象數(shù)據(jù)動(dòng)態(tài)創(chuàng)建的，解碼時(shí)還要從已編碼的數(shù)據(jù)中還原出原來(lái)的編譯表（GIF文件中是不攜帶編譯表信息的），為了更好理解編解碼原理，我們來(lái)看看具體的處理過(guò)程：

編碼器(Compressor)
~~~~~~~~~~~~~~~~

　　編碼數(shù)據(jù)，第一步，初始化一個(gè)編譯表，假設(shè)這個(gè)編譯表的大小是12位的，也就是最多有4096個(gè)單位，另外假設(shè)我們有32個(gè)不同的字符（也可以認(rèn)為圖象的每個(gè)像素最多有32種顏色），表示為a，b，c，d，e...，初始化編譯表：第0項(xiàng)為a，第1項(xiàng)為b，第2項(xiàng)為c...一直到第31項(xiàng)，我們把這32項(xiàng)就稱(chēng)為根。
　　開(kāi)始編譯，先定義一個(gè)前綴對(duì)象Current Prefix，記為[.c.]，現(xiàn)在它是空的，然后定義一個(gè)當(dāng)前字符串Current String，標(biāo)記為[.c.]k，[.c.]就為Current Prefix，k就為當(dāng)前讀取字符。現(xiàn)在來(lái)讀取數(shù)據(jù)流的第一個(gè)字符，假如為p，那么Current String就等于[.c.]p（由于[.c.]為空，實(shí)際上值就等于p），現(xiàn)在在編譯表中查找有沒(méi)有Current String的值，由于p就是一個(gè)根字符，我們已經(jīng)初始了32個(gè)根索引，當(dāng)然可以找到，把p設(shè)為Current Prefix的值，不做任何事繼續(xù)讀取下一個(gè)字符，假設(shè)為q，Current String就等于[.c.]q（也就是pq），看看在編譯表中有沒(méi)有該值，當(dāng)然。沒(méi)有，這時(shí)我們要做下面的事情：將Current String的值（也就是pq）添加到編譯表的第32項(xiàng)，把Current Prefix的值（也就是p）在編譯表中的索引輸出到編碼流，修改Current Prefix為當(dāng)前讀取的字符（也就是q）。繼續(xù)往下讀，如果在編譯表中可以查找到Current String的值([.c.]k)，則把Current String的值([.c.]k)賦予Current Prefix；如果查找不到，則添加Current String的值([.c.]k)到編譯表，把Current Prefix的值([.c.])在編譯表中所對(duì)應(yīng)的索引輸出到編碼流，同時(shí)修改Current Prefix為k ，這樣一直循環(huán)下去直到數(shù)據(jù)流結(jié)束。偽代碼看起來(lái)就像下面這樣：

來(lái)看一個(gè)具體的例子,我們有一個(gè)字母表a，b，c，d.有一個(gè)輸入的字符流abacaba。現(xiàn)在來(lái)初始化編譯表：#0=a,#1=b,#2=c,#3=d.現(xiàn)在開(kāi)始讀取第一個(gè)字符a，[.c.]a=a，可以在在編譯表中找到，修改[.c.]=a;不做任何事繼續(xù)讀取第二個(gè)字符b，[.c.]b=ab，在編譯表中不能找，那么添加[.c.]b到編譯表：#4=ab，同時(shí)輸出[.c.]（也就是a）的索引#0到編碼流，修改[.c.]=b；讀下一個(gè)字符a，[.c.]a=ba，在編譯表中不能找到：添加編譯表#5=ba，輸出[.c.]的索引#1到編碼流，修改[.c.]=a；讀下一個(gè)字符c，[.c.]c=ac，在編譯表中不能找到：添加編譯表#6=ac，輸出[.c.]的索引#0到編碼流，修改[.c.]=c；讀下一個(gè)字符a，[.c.]c=ca，在編譯表中不能找到：添加編譯表#7=ca，輸出[.c.]的索引#2到編碼流，修改[.c.]=a；讀下一個(gè)字符b，[.c.]b=ab，編譯表的#4=ab，修改[.c.]=ab；讀取最后一個(gè)字符a，[.c.]a=aba，在編譯表中不能找到：添加編譯表#8=aba，輸出[.c.]的索引#4到編碼流，修改[.c.]=a；好了，現(xiàn)在沒(méi)有數(shù)據(jù)了，輸出[.c.]的值a的索引#0到編碼流，這樣最后的輸出結(jié)果就是：#0#1#0#2#4#0.

解碼器(Decompressor)
~~~~~~~~~~~~~~~~~~

　　好了，現(xiàn)在來(lái)看看解碼數(shù)據(jù)。數(shù)據(jù)的解碼，其實(shí)就是數(shù)據(jù)編碼的逆向過(guò)程，要從已經(jīng)編譯的數(shù)據(jù)（編碼流）中找出編譯表，然后對(duì)照編譯表還原圖象的光柵數(shù)據(jù)。
　　首先，還是要初始化編譯表。GIF文件的圖象數(shù)據(jù)的第一個(gè)字節(jié)存儲(chǔ)的就是LZW編碼的編碼大小（一般等于圖象的位數(shù)），根據(jù)編碼大小，初始化編譯表的根條目（從0到2的編碼大小次方），然后定義一個(gè)當(dāng)前編碼Current Code，記作[code]，定義一個(gè)Old Code，記作[old]。讀取第一個(gè)編碼到[code]，這是一個(gè)根編碼，在編譯表中可以找到，把該編碼所對(duì)應(yīng)的字符輸出到數(shù)據(jù)流，[old]=[code]；讀取下一個(gè)編碼到[code]，這就有兩種情況：在編譯表中有或沒(méi)有該編碼，我們先來(lái)看第一種情況：先輸出當(dāng)前編碼[code]所對(duì)應(yīng)的字符串到數(shù)據(jù)流，然后把[old]所對(duì)應(yīng)的字符（串）當(dāng)成前綴prefix [...]，當(dāng)前編碼[code]所對(duì)應(yīng)的字符串的第一個(gè)字符當(dāng)成k，組合起來(lái)當(dāng)前字符串Current String就為[...]k，把[...]k添加到編譯表，修改[old]=[code]，讀下一個(gè)編碼；我們來(lái)看看在編譯表中找不到該編碼的情況，回想一下編碼情況：如果數(shù)據(jù)流中有一個(gè)p[...]p[...]pq這樣的字符串，p[...]在編譯表中而p[...]p不在，編譯器將輸出p[...]的索引而添加p[...]p到編譯表，下一個(gè)字符串p[...]p就可以在編譯表中找到了，而p[...]pq不在編譯表中，同樣將輸出p[...]p的索引值而添加p[...]pq到編譯表，這樣看來(lái)，解碼器總比編碼器『慢一步』，當(dāng)我們遇到p[...]p所對(duì)應(yīng)的索引時(shí)，我們不知到該索引對(duì)應(yīng)的字符串（在解碼器的編譯表中還沒(méi)有該索引，事實(shí)上，這個(gè)索引將在下一步添加），這時(shí)需要用猜測(cè)法：現(xiàn)在假設(shè)上面的p[...]所對(duì)應(yīng)的索引值是#58，那么上面的字符串經(jīng)過(guò)編譯之后是#58#59，我們?cè)诮獯a器中讀到#59時(shí)，編譯表的最大索引只有#58，#59所對(duì)應(yīng)的字符串就等于#58所對(duì)應(yīng)的字符串(也就是p[...])加上這個(gè)字符串的第一個(gè)字符(也就是p)，也就是p[...]p。事實(shí)上，這種猜測(cè)法是很準(zhǔn)確（有點(diǎn)不好理解，仔細(xì)想一想吧）。上面的解碼過(guò)程用偽代碼表示就像下面這樣：

GIF數(shù)據(jù)壓縮
~~~~~~~~~~~

下面是GIF文件的圖象數(shù)據(jù)結(jié)構(gòu)：

把光柵數(shù)據(jù)序列（數(shù)據(jù)流）壓縮成GIF文件的圖象數(shù)據(jù)（字符流）可以按下面的步驟進(jìn)行：
1.定義編碼長(zhǎng)度
GIF圖象數(shù)據(jù)的第一個(gè)字節(jié)就是編碼長(zhǎng)度(Code Size)，這個(gè)值是指要表現(xiàn)一個(gè)像素所需要的最小位數(shù)，通常就等于圖象的色深；
2.壓縮數(shù)據(jù)
通過(guò)LZW壓縮算法將圖象的光柵數(shù)據(jù)流壓縮成GIF的編碼數(shù)據(jù)流。這里使用的LZW壓縮算法是從標(biāo)準(zhǔn)的LZW壓縮算法演變過(guò)來(lái)的，它們之間有如下的差別：
　　[1]GIF文件定義了一個(gè)編碼大小(Clear Code)，這個(gè)值等于2的『編碼長(zhǎng)度』次方，在從新開(kāi)始一個(gè)編譯表（編譯表溢出）時(shí)均須輸出該值，解碼器遇到該值時(shí)意味著要從新初始化一個(gè)編譯表；
　　[2]在一個(gè)圖象的編碼數(shù)據(jù)結(jié)束之前（也就是在塊終結(jié)器的前面），需要輸出一個(gè)Clear Code+1的值，解碼器在遇到該值時(shí)就意味著GIF文件的一個(gè)圖象數(shù)據(jù)流的結(jié)束；
　　[3]第一個(gè)可用到的編譯表索引值是Clear Code+2（從0到Clear Code-1是根索引，再上去兩個(gè)不可使用，新的索引從Clare Code+2開(kāi)始添加）；
　　[4]GIF輸出的編碼流是不定長(zhǎng)的，每個(gè)編碼的大小從Code Size + 1位到12位，編碼的最大值就是4095（編譯表需要定義的索引數(shù)就是4096），當(dāng)編碼所須的位數(shù)超過(guò)當(dāng)前的位數(shù)時(shí)就把當(dāng)前位數(shù)加1，這就需要在編碼或解碼時(shí)注意到編碼長(zhǎng)度的改變。
3.編譯成字節(jié)序列
因?yàn)镚IF輸出的編碼流是不定長(zhǎng)的，這就需要把它們編譯成固定的8-bit長(zhǎng)度的字符流，編譯順序是從右往左。下面是一個(gè)具體例子：編譯5位長(zhǎng)度編碼到8位字符

　
4.打包
　　前面講過(guò)，一個(gè)GIF的數(shù)據(jù)塊的大小從0到255個(gè)字節(jié)，第一個(gè)字節(jié)是這個(gè)數(shù)據(jù)塊的大小（字節(jié)數(shù)），這就需要將編譯編后的碼數(shù)據(jù)打包成一個(gè)或幾個(gè)大小不大于255個(gè)字節(jié)的數(shù)據(jù)包。然后寫(xiě)入圖象數(shù)據(jù)塊中。

〈完〉