J2ME平台PNG图像压缩、解压与加密技术 收藏新一篇: java图书资源下载
在J2ME平台上PNG图片格式几乎成为了标准，无数台手持设备上运行的J2ME程序几乎都选用PNG来显示图像，包括大量的手机游戏以及手机应用，所以对PNG文件格式的了解，可以更有效的减少Jar Size，保护自有知识产权。
CoCoMo曾经对PNG文件进行过一段时间的研究，包括图像压缩、解压以及加解密等，现将研究心得记录如下：
PNG文件格式：
PNG文件格式分为PNG-24和PNG-8，其最大的区别是PNG-24是用24位来保存一个像素值，是真彩色，而PNG-8是用8位索引值来在调色盘中索引一个颜色，因为一个索引值的最大上限为2的8次方既128，故调色盘中颜色数最多为128种，所以该文件格式又被叫做PNG-8 128仿色。
PNG-24因为其图片容量过大，而且在Nokia和Moto等某些机型上创建图片失败和显示不正确等异常时有发生，有时还会严重拖慢显示速度，故并不常用，CoCoMo认为这些异常和平台底层的图像解压不无关系。不过该格式最大的优点是可以保存Alpha通道，同事也曾有过利用该图片格式实现Alpha混合的先例，想来随着技术的发展，手机硬件平台的提升，Alpha混合一定会被广泛的应用，到那时该格式的最大优势才会真正发挥。
PNG-8文件是目前广泛应用的PNG图像格式，其主要有六大块组成：
1.文件头
2.IHDR块
3.PLTE块
4.tRNS块
5.IDAT块
6.文件尾
这六大块按顺序排列，也就是说IDAT块永远是在PLTE块之后，期间也会有许多其他的区块用来描述信息，例如图像的最后修改时间是多少，图像的创建者是谁等，不过这些区块的信息对我们来说都是可有可无的描述信息，故压缩时一般先向这些区块开刀。
数据块：
除了文件头，其中四大数据块和文件尾都是由统一的数据块文件结构描述的：
Chunk Length: 4byte
Chunk Type: 4byte
Chunk Data: Chunk Length的长度
Chunk CRC: 4byte
例如IHDR块的数据长度为13，既
Chunk Length = 13
Chunk Type = "IHDR"
文件头：
用来标示PNG文件，为固定的64个字节：0x89504e47 0x0d0a1a0a
IHDR块：
用来描述图像的基本信息，其格式为：
图像宽： 4byte
图像高： 4byte
图像色深： 4byte
颜色类型： 1byte
压缩方法： 1byte
滤波方法： 1byte
扫描方法： 1byte
曾经有人问过我，撒叫滤波方法和扫描方法，汗，说实话我也不知道，不过我们是在做手机游戏，不是在搞图形学不是嘛。
PLTE块：
这个就是传说中放置调色盘数据的地方啦，其格式为：
循环
RED： 1byte
GREEN：1byte
BLUE： 1byte
END
循环长度嘛，不就是Chunk Length / 3的长度嘛，而且Chunk Length一定为3的倍数。
tRNS块：
这个块时有时无，主要是看你是否使用了透明色。该区块的格式为：
循环
if(对应调色盘颜色非透明)
0xFF： 1byte
else
0x00： 1byte
END
循环长度为调色盘的颜色数，相当于调色盘颜色表的一个对应表，标识该颜色是否透明，0xFF不透明，0x00透明。故如果用UltraEdit查看PNG文件的二进制编码，如果看到一大片FF，一般就是tRNS区块啦，因为一个PNG文件一般只有一个透明色。
IDAT块：
这个就是存放图像数据的地方啦，这里要注意的是一个PNG文件可能有多个IDAT区块，而其他三大区块只可能有一个。
IDAT区块是经过压缩的，所以数据不可读，压缩算法一般为LZ77滑动窗口算法，如果硬要看里面的数据的话，用zlib库也是可以的，CoCoMo当年就见过Windows Mobile上的帝国时代巨变态的用zlib库压缩和解压该区块来进一步减少PNG文件大小，真是寸K寸金啊。
IEND块：
该区块虽然也按照数据块的结构，但Chunk Data是没有的，所以是固定的96个字节：0x00000000 0x49454e44 0xae426082
PNG图像压缩：
了解了PNG的文件结构，压缩就有的放矢了。压缩有6个级别，可以根据需要选择。
Level1：读取PNG文件，将除六大块之外的所有区块都过滤掉
Level2：文件头是固定的0x89504e47 0x0d0a1a0a，文件尾是固定的0x00000000 0x49454e44 0xae426082，去掉！
Level3：每个区块的Chunk Type我们是否需要呢？很明显，我们自己写的压缩格式自己应该清楚是按照什么样的顺序，去掉！
Level4：每个区块的Chunk Length我们是否需要呢？
IHDR块：定长13个字节，明显不需要，去掉。
PLTE块：最多128个颜色，为撒要用4byte来记录区块长度而不是用1byte来记录颜色数呢？
tRNS块：既然有颜色数，tRNS又是调色盘颜色表的对应表，既数量与颜色数相同，为撒还需要呢？
IDAT块：我想这个是唯一需要4byte来记录长度的区块。
Level5：每个区块的Chunk CRC是否需要呢？
因为计算CRC需要一些时间，但对于字节较少的区块一般可以忽略不计，所以对于这个问题还是由程序员自己决定吧。对于CRC的计算可以参看CoCoMo的另一篇Blog“PNG文件的CRC码计算”
Level6：每个区块我们是否要原封不动的保存期数据呢？
IHDR块：除了宽、高、色深是需要的，后面那4byte的信息是固定的0x03000000
PLTE块：为撒要用3byte来表示RGB而不是2byte的565格式？压缩方法可以参看CoCoMo的另一篇Blog“关于PNG图像压缩的一点感悟”
tRNS块：我想tRNS块是冗余最多的区块了吧，大段大段的0xFF明显没有必要，一般的PNG文件只有一个透明色，为撒要用对应表的方法而不是一个索引来记录到底哪个是透明色呢？由于颜色数最多128，所以只需1byte就可以代替tRNS那么多0xFF啦。
IDAT块：么想法，如果你够变态，把zlib加进来吧！
PNG图像解压：
创建了自定义的文件，J2ME端读取后，就面临解压的问题了。我们可以利用此函数来创建Image：
static Image
createImage(byte[] imageData, int imageOffset, int imageLength)
前提是传入的imageData与PNG未被压缩前的一致。因为PNG文件格式是固定的，所以读取自定义的压缩文件后，开始将那些默认的数据再添加进去，实现解压的目的。下面就开始解压之旅吧!
首先要创建一个ByteArrayOutputStream out，
1.写入文件头：
out.writeInt(0x89504e47);
out.writeInt(0x0d0a1a0a);
2.写入IHDR块
out.writeInt(13);
out.writeInt(0x49484452); //0x49484452为Chunk Type "IHDR"
out.writeInt(width);
out.writeInt(height);
out.writeByte(depth);
out.writeInt(0x03000000); //压缩时舍掉的4byte，默认0x03000000
out.writeInt(crc);
其他区块方法一致，故略过。。。
3.写入文件尾
out.writeInt(0x00000000);
out.writeInt(0x49454e44);
out.writeInt(0xae426082);
4.转换成数组，创建Image
byte[] pngBuffer = out.toByteArray();
Image image = Image.createImage(pngBuffer, 0, pngBuffer.length);
哈哈，大功告成。这里注意如果中途数据写入有错误，经常会出现创建Image失败的异常，而且非常不好调试，不过只要自定的压缩格式定下来后，对应的创建Image的函数只要写一次，以后基本不会出问题哈。
PNG图像加解密：
很多人都担心自己辛苦创作的漂亮的美术图片很easy就被别人拿到了，究其原因是由于PNG文件格式是固定的，稍微了解的人用UltraEdit很容易就能找到IHDR，PLTE等标识了。CoCoMo就经常看GameLoft的图像文件，哈哈。一般是2byte的Length，然后紧接着图片数据，都放在一个文件里，直接拷贝2进制然后粘贴到一个新文件里就是一幅图。后来的加密技术会把PNG分块，例如前100个字节一块，紧接着1K一块，最后剩余字节一块，然后把块顺序打乱，用2byte来记录总长度，1byte记录顺序，但是这并没有从根本上消除IHDR，IEND这些显眼的定位标识，好像在对破解者说：嘿，看，我就在这里！
现在了解了之前的压缩和解压技术，这个问题也就迎刃而解了，因为Chunk Length，Chunk Type和Chunk CRC这些东西都消失了，甚至连数据块本身的数据都修改了，我可以按照ImageWidth、ImageHeight、ImageDepth的顺序写数据，也可以倒过来写。我想再牛的PNG分析器也是无能为力的吧，唯一可以定位的就只有IDAT区块了，不过就算得到该区块的数据，也应该是一张黑白图。
不过在加解密的领域真是道高一尺，魔高一丈，CoCoMo很希望和各位共同探讨，共同提高！