web开发很诱人，但是总是无法沉下心来，因为web开发的技术更新速度实在太快了。

最近又开始弄我的老本行了，呵呵。重拾对编解码的研究。做底层能能经得住时间的考验，不会被时代抛弃。

关于jpeg的格式，参考文章分析的非常好！在这里感谢作者了。

我们拿奶茶这张照片来分析好了，希望东哥理解。嘿嘿~

1. 用vi软件打开： vim -b naicha.jpeg

2. 然后换成16进制式：:%!xxd

3. 另存为txt：:w naicha.txt

分析：

ffd8

这是SOI部分，固定值0xFFD8，标记了图像的开始。2字节。

ffe0 0010 4a46 4946 0001 0101 0060  0060 0000

这是APP0部分，即应用程序保留标记0。以0XFFE0开始。0010表示接下来的字段的总长度，这里是16个字节。固定值0x4A46494600，即字符串“JFIF0”，占用了5个字节。0101表示JFIF的版本号为1.1。01占用了一个字节，表示密度单位，这里是点数/英寸。0060 0060 分别代表X和Y方向的像素密度。

ffdb 0043 000a 0707 0807 060a  .`.....C........0000020: 0808 080b 0a0a 0b0e 1810 0e0d 0d0e 1d15  ................0000030: 1611 1823 1f25 2422 1f22 2126 2b37 2f26  ...#.%$"."!&+7/&0000040: 2934 2921 2230 4131 3439 3b3e 3e3e 252e  )4)!"0A149;>>>%.0000050: 4449 433c 4837 3d3e 3bff db00 4301 0a0b  DIC
    
     ;...C...0000060: 0b0e 0d0e 1c10 101c 3b28 2228 3b3b 3b3b  ........;("(;;;;0000070: 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b  ;;;;;;;;;;;;;;;;0000080: 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b  ;;;;;;;;;;;;;;;;0000090: 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b 3b3b
    

这是DQT部分，定义量化表。0043表示接下来字段的总长度，这里是67个字节。00表示精度为8位，量化表ID为0。表项：67-2=65个字节。

ffc0  ;;;;;;;;;;;;;;..00000a0: 0011 0801 4801 9b03 0122 0002 1101 0311 01

这是SOF0部分，标识了帧图像的开始，0011表示数据长度为17个字节。08表示每个数据样本的位数为8位。0148换成十进制为328（高，像素），019B换成十进制为411（宽，像素），表示图像大小为411*328。03表示颜色分量为YCbCr。

ff c400 1f00 0001 0501 0101 0101 0100 0000 0000 0000 0001 0203 0405 0607 0809 0a0b

这是DHT部分，也就是哈夫曼表。001f表示数据长度为31个字节。00表示DC直流和哈夫曼ID。

ff da00 0c03 0100 0211 0311 003f 00ce

SOS部分，扫描开始。000c表示数据长度为12个字节。03表示颜色分量数为YCbCr。01表示颜色分量ID，00表示直流/交流系数表号。此处有些疑问。

ffd9

这是EOI部分，表示图像结束。

由于在JPEG文件中0xFF具有标志性的意思，所以在压缩数据流(真正的图像信息)中出现0xFF，就需要作特别处理。具体方法是，在数据0xFF后添加一个没有意义的0x00。换句话说，如果在图像数据流中遇到0xFF，应该检测其紧接着的字符，如果是

1）0x00，则表示0xFF是图像流的组成部分，需要进行译码；

2）0xD9，则与0xFF组成标记EOI，则图像流结束，同时图像文件结束；

3）0xD0~0xD7,则组成RSTn标记，则要忽视整个RSTn标记，即不对当前0xFF和紧接的0xDn两个字节进行译码，并按RST标记的规则调整译码变量；

3）0xFF，则忽视当前0xFF，对后一个0xFF再作判断；

4）其他数值，则忽视当前0xFF，并保留紧接的此数值用于译码。

参考：

http://blog.csdn.net/lpt19832003/article/details/1713718

http://www.douban.com/note/144074400/