{ yeah : 必须哒 } No place to place should record our youth?

29Jun/110

利用dns隧道免费上网

Posted by ofeng

大多数机场、酒店之类场所,当你输入一个网址比如www.google.com时,会弹出一个页面要你输入帐号密码才能上网。这个时候DNS能正确解析,但是上网要付费认证。

可以通过DNS隧道来实现免费上网。具体做法是:

(1)找一个支持DNS解析的域名,现在这类免费域名很多,比如tk的、co.cc的。假设该域名是abc123.tk。

(2)在tk的注册机构里,设置abc123.tk的NS服务器为你自己的主机(最好是Linux VPS),例如:
abc123.tk.     IN  NS  ns.abc123.tk.
ns.abc123.tk.  IN  A   74.81.81.81

(3)在74.81.81.81上,以root身份运行一个Perl脚本(这个脚本来自Dan Kaminsky的OzymanDNS包):
./nomde.pl -i 0.0.0.0 abc123.tk
上述脚本会侦听在UDP 53端口,接受DNS请求,并且只解析abc123.tk域。

(4)在客户机上(要求有ssh,最好是Linux系统),运行如下命令:
ssh -ND 7070 -o ProxyCommand=”./droute.pl sshdns.abc123.tk” user@localhost
上述ssh命令,-ND 7070表示在本机打开7070的socks 5代理端口。droute.pl是DNS隧道的客户端工具,同样来自于OzymanDNS包。sshdns是固定的主机名,加在域名abc123.tk前面。user是你在74.81.81.81上的登录名字,@localhost是固定的,不需要改(因为隧道过去后,就是74.81.81.81本机)。

运行上述ssh命令后,会提示输入密码。输入正确密码后,就和远程主机建立了ssh连接,获取到一个SSH终端。并且,在本机打开了7070的socks 5代理端口。配置浏览器使用这个代理端口,开始享受免费冲浪吧!

转自:http://www.nsbeta.info/archives/96

Tagged as: , No Comments
23Jun/110

lsof 命令详解

Posted by ofeng

lsof全名list opened files,也就是列举系统中已经被打开的文件。我们都知道,linux环境中,任何事物都是文件,设备是文件,目录是文件,甚至sockets也是文件。所以,用好lsof命令,对日常的linux管理非常有帮助。以下的说明,大部分内容来自lsof的manual文档。我所做的只是在中文翻译的基础上,进行简单的分类说明,并列举最常用的参数。 

一、输出说明
lsof是linux最常用的命令之一,通常的输出格式为:

引用
COMMAND     PID   USER   FD      TYPE     DEVICE     SIZE       NODE NAME

常见包括如下几个字段:更多的可见manual。
1、COMMAND
默认以9个字符长度显示的命令名称。可使用+c参数指定显示的宽度,若+c后跟的参数为零,则显示命令的全名
2、PID:进程的ID号
3、PPID
父进程的IP号,默认不显示,当使用-R参数可打开。
4、PGID
进程组的ID编号,默认也不会显示,当使用-g参数时可打开。
5、USER
命令的执行UID或系统中登陆的用户名称。默认显示为用户名,当使用-l参数时,可显示UID。
6、FD
是文件的File Descriptor number,或者如下的内容:
(这里很难翻译对应的意思,保留英文)

引用
cwd  current working directory;
Lnn  library references (AIX);
jld  jail directory (FreeBSD);
ltx  shared library text (code and data);
Mxx  hex memory-mapped type number xx.
m86  DOS Merge mapped file;
mem  memory-mapped file;
mmap memory-mapped device;
pd   parent directory;
rtd  root directory;
tr   kernel trace file (OpenBSD);
txt  program text (code and data);
v86  VP/ix mapped file;

文件的File Descriptor number显示模式有:

引用
r for read access;
w for write access;
u for read and write access;
N for a Solaris NFS lock of unknown type;
r for read lock on part of the file;
R for a read lock on the entire file;
w for a write lock on part of the file;
W for a write lock on the entire file;
u for a read and write lock of any length;
U for a lock of unknown type;
x for an SCO OpenServer Xenix lock on part  of the file;
X  for an SCO OpenServer Xenix lock on the entire file;
space if there is no lock.

7、TYPE

引用
IPv4 IPv4的包;
IPv6 使用IPv6格式的包,即使地址是IPv4的,也会显示为IPv6,而映射到IPv6的地址;
DIR 目录
LINK 链接文件

详情请看manual中更多的注释。
8、DEVICE
使用character special、block special表示的设备号
9、SIZE
文件的大小,如果不能用大小表示的,会留空。使用-s参数控制。
10、NODE
本地文件的node码,或者协议,如TCP等
11、NAME
挂载点和文件的全路径(链接会被解析为实际路径),或者连接双方的地址和端口、状态等

二、参数
1、不带额外参数运行

lsof path/filename

显示已打开该目录或文件的所有进程信息

lsof `which httpd`

显示指定命令的信息
2、参见参数
-c w 显示以w开头命令的已打开文件的信息

lsof -c sshd

-p PID 显示指定PID已打开文件的信息

lsof -p 4401

+d dir 依照文件夹dir来搜寻,但不会打开子目录

lsof +d /root

+D dir 打开dir文件夹以及其子目录搜寻

lsof +D /root/

-d s 以FD列的信息进行匹配,可使用3-10,表示范围,3,10表示某些值

lsof -d 3-10

-u 显示某用户的已经打开的文件(或该用户执行程序已经打开的文件)

lsof -u root
lsof -u 0

◎可配合正规表达式使用
表示不包括root用户的信息:

lsof -u ^root

-i 监听指定的协议、端口、主机等的网络信息,格式为:

引用
[46][proto][@host|addr][:svc_list|port_list]

例如:

lsof -i tcp@192.168.228.244为防备电子邮件地址收集器,这个 E-mail 地址被隐藏,你的浏览器必须支持 Javascript 才可看到这个邮件地址
lsof -i:22

还可以使用一些参数控制显示结果:

引用
-l 禁止将userID转换为登陆名称,即显示UID
-n 禁止将IP地址转换为hostname主机文件
-P 不显示端口名称

-g s 从PGID列进行匹配

lsof -g 3-10

3、其他参数
+f 所有路径参数都必须是文件系统,否则不能执行
-f 所有路径参数都将作为普通的文件,例如:"-f -- /"中的/,只会匹配单个/路径,而不会是根目录中的所有文件
+f和-f后都应加上“--”表终结符:

lsof -f -- /

+L/-L 打开或关闭文件的连结数计算,当+L没有指定时,所有的连结数都会显示(默认);若+L后指定数字,则只要连结数小于该数字的信息会显示;连结数会显示在NLINK列。
例如:+L1将显示没有unlinked的文件信息;+aL1,则显示指定文件系统所有unlinked的文件信息
-L 默认参数,其后不能跟数字,将不显示连结数信息

lsof +L1

-t 仅打印进程,方便shell脚本调用

lsof -t -c sshd

-F 指定输出那个列,可通过lsof -F?查看
-r 不断执行lsof命令,默认每15秒间隔执行一次
+r 也是不断执行lsof命令,但直到没有接受到文件信息,则停止

Tagged as: No Comments
14Jun/110

BMP、JPG等六种常用图形文件的结构

Posted by ofeng

bmp文件

bmp(bitmap的缩写)文件格式是windows本身的位图文件格式,所谓本身是指windows内部存储位图即采用这种格式。一个.bmp格式的文件通常有.bmp的扩展名,但有一些是以.rle为扩展名的,rle的意思是行程长度编码(runlengthencoding)。这样的文件意味着其使用的数据压缩方法是.bmp格式文件支持的两种rle方法中的一种。

bmp文件可用每象素1、4、8、16或24位来编码颜色信息,这个位数称作图象的颜色深度,它决定了图象所含的最大颜色数。一幅1-bpp(位每象素,bitperpixel)的图象只能有两种颜色。而一幅24-bpp的图象可以有超过16兆种不同的颜色。

下一页的图说明了一个典型.bmp文件的结构。它是以256色也就是8-bpp为例的,文件被分成四个主要的部分:一个位图文件头,一个位图信息头,一个色表和位图数据本身。位图文件头包含关于这个文件的信息。如从哪里开始是位图数据的定位信息,位图信息头含有关于这幅图象的信息,例如以象素为单位的宽度和高度。色表中有图象颜色的rgb值。对显示卡来说,如果它不能一次显示超过256种颜色,读取和显示.bmp文件的程序能够把这些rgb值转换到显示卡的调色板来产生准确的颜色。

bmp文件的位图数据格式依赖于编码每个象素颜色所用的位数。对于一个256色的图象来说,每个象素占用文件中位图数据部分的一个字节。象素的值不是rgb颜色值,而是文件中色表的一个索引。所以在色表中如果第一个r/g/b值是255/0/0,那么象素值为0表示它是鲜红色,象素值按从左到右的顺序存储,通常从最后一行开始。所以在一个256色的文件中,位图数据中第一个字节就是图象左下角的象素的颜色索引,第二个就是它右边的那个象素的颜色索引。如果位图数据中每行的字节数是奇数,就要在每行都加一个附加的字节来调整位图数据边界为16位的整数倍。

并不是所有的bmp文件结构都象表中所列的那样,例如16和24-bpp,文件就没有色表,象素值直接表示rgb值,另外文件私有部分的内部存储格式也是可以变化的。例如,在16和256色.bmp文件中的位图数据采用rle算法来压缩,这种算法用颜色加象素个数来取代一串颜色相同的序列,而且,windows还支持os/2下的.bmp文件,尽管它使用了不同的位图信息头和色表格式。

pcx文件

.pcx是在pc上成为位图文件存储标准的第一种图象文件格式。它最早出现在zsoft公司的paintbrush软件包中,在80年代早期授权给微软与其产品捆绑发行,而后转变为microsoftpaintbrush,并成为windows的一部分。虽然使用这种格式的人在减少,但这种带有.pcx扩展名的文件在今天仍是十分常见的。

pcx文件分为三部分,依次为:pcx文件头,位图数据和一个可选的色表。文件头长达128个字节,分为几个域,包括图象的尺寸和每个象素颜色的编码位数。位图数据用一种简单的rle算法压缩,最后的可选色表有256个rgb值,pcx格式最初是为cga和ega来设计的,后来经过修改也支持vga和真彩色显示卡,现在pcx图象可以用1、4、8或24-bpp来对颜色数据进行编码。

tiff文件

pcx格式是所有位图文件格式中最简单的,而tiff(taggedimagefileformat)则是最难的一种。

tiff文件含有.tif的扩展名。它以8字节长的图象文件头开始(ifh),这个文件头中最重要的成员是一个指向名为图象文件目录(ifd)的数据结构的指针。ifd是一个名为标记(tag)的用于区分一个或多个可变长度数据块的表,标记中含有关于图象的信息。tiff文件格式定义70多种不同类型的标记,有的用来存放以象素为单位的图象宽度和高度,有的用来存放色表(如果需要的话),当然还必须有用来存放位图数据的标记,一个tiff格式文件完全为它的标记所决定,而且这种文件结构极易扩展,因为你要附加一些特征只须增加一些额外的标记。

究竟是什么使tiff文件如此复杂?一方面,要写一种能够识别所用不同标记的软件非常困难。大多数tiff的阅读程序只能识别一部分标记,所以会出现这种情况:有时一个应用程序创建的tiff文件,另一个应用程序却不能使用。创建tiff文件的程序还可能会在文件中加一些只有它自己认识的标记,虽然tiff的阅读程序可以跳过那些它们不认得的标记,但这样做总是有可能影响到图象的质量。

另一方面,一个tiff文件可以包含多个图象,每个图象都有自己的ifd和一系列标记。tiff文件中的位图数据可能会用好几种方法来压缩,所以一个完备的tiff阅读程序应该有rle解压缩程序,lzw解压缩程序和其他一些算法的解压缩程序。然而更糟的是使用lzw的解码必须得到unisys公司的同意,且通常是需要付版税的。所以即使是一些相当不错的tiff阅读程序在它们遇到lzw算法压缩的图象时也是无能为力的。

尽管tiff是那么的复杂,但仍是一种最好的跨平台格式。因为它非常灵活,无论在视觉上还是其他方面,都能把任何图象编码成二进制形式而不丢失任何属性。

gif文件

当许多图象方面的权威一想到lzw的时候,他们也会想到gif(graphicsinterchangeformat,读作jiff)这是一种常用的跨平台的位图文件格式,最初为compuserve公司所创。gif文件通常带有.gif的扩展名,而且在compuseve上大量存在。

gif文件的结构取决于它属于哪一个版本,目前的两种版本分别是gif87a和gif89a,前者较简单。无论是哪个版本,它都以一个长13字节的文件头开始,文件头中包含判定此文件是gif文件的标记、版本号和其他的一些信息。如果这个文件只有一幅图象,文件头后紧跟一个全局色表来定义图象中的颜色。如果含有多幅图象(gif和tiff格式一样,允许在一个文件里编码多个图象),那么全局色表就被各个图象自带的局部色表所替代。

在gif87a文件中,文件头和全局色表之后是图象,它可能会是头尾相接的一串图象中的第一个,每个图象由三部分组成,一个10字节长的图象描述,一个可选的局部色表和位图数据。为有效利用空间,位图数据用lzw算法来压缩。

gif89a结构与此类似,但它还包括可选的扩展块来存放每个图象的附加信息。gif89a详细定义了四种扩展块:图象控制扩展块,它用来描述图象怎样被显示(例如,显示是应该象一个透明物去覆盖上一个图象,还是简单的替换它);简单文本扩展块,它包含显示在图象中的文本;注释扩展块,它以ascii文本形式存放注释;应用扩展块,它存放生成该文件的应用程序的私有数据。这些扩展块可以出现在文件中全局色表的任何地方。

gif最显著的优点是它的广泛使用和它的紧密性。但它有两个弱点,一个是用gif格式存放的文件最多只能含有256种颜色。另一个可能更重要,就是那些使用了gif格式的软件开发者必须征得compuserve的同意,他们每卖出一个拷贝都要向compuserve付版税。这个政策是compuserve仿效unisys公司作出的,它抑制了那些程序员在他的图象应用程序中支持gif文件。

png文件

png(portablenetworkgraphic,发音做ping)文件格式是作为gif的替代品开发的,它能够避免使用gif文件所遇到的常见问题。它从gif那里继承了许多特征,而且支持真彩色图象。更重要的是,在压缩位图数据时它采用了一种颇受好评的lz77算法的一个变种,lz77则是lzw的前身,而且可以免费使用。由于篇幅所限,在这里就不花时间来具体讨论png格式了。

jpeg文件

jpeg(jointphotographicexpertsgroup,发音做jay-peg)文件格式最初由c-cubemicrosystems推出,是为了提供一种存储深度位象素的有效方法,例如对于照片扫描,颜色很多而且差别细微(有时也不细微)。jpeg和这里讨论的其他格式的最大区别是jpeg使用一种有损压缩算法,无损压缩算法能在解压后准确再现压缩前的图象,而有损压缩则牺牲了一部分的图象数据来达到较高的压缩率。但是这种损失很小以至于人们很难察觉。

jpeg图象压缩是一个复杂的过程,经常需要专门的硬件来帮助。首先图象以象素为单位分成8*8的块。然后,每个块分三个步骤被压缩。第一步使用dct(discretecosinetransform)离散余弦变换把8*8的象素矩阵变成8*8的频率(也就是颜色改变的速度)矩阵。第二步对频率矩阵中的值用量化矩阵进行量化,滤掉那些总体上对图象不重要的部分。第三步,也就是最后一步,对量化后的频率矩阵使用无损压缩。

因为被量化后的频率矩阵缺了许多高频信息,通常能被压缩到一半甚至更少。无损压缩一般根本不能压缩真正的照片图象,所以50%的压缩率已是相当不错了,但另一方面,无损压缩能把一些图象文件尺寸减少90%,这样的图象文件就不适合用jpeg来压缩。

jpeg的有损部分产生在第二步,量化矩阵的值越高,从图象中丢掉的信息就越多,从而压缩率就越高,可是同时图象的质量就越差。在jpeg压缩时可以选择一个量化因子,这个因子的值决定了量化矩阵中的数值。理想的量化因子要在压缩率和图象质量间达到平衡,所以对不同的图象要选择不同的量化因子,通常要经过若干次尝试后方可确定。

Tagged as: , , No Comments
14Jun/110

GIF文件格式说明

Posted by ofeng

1. 概述

GIF(Graphics Interchange Format,图形交换格式)文件是由 CompuServe公司开发的图形文件格式,版权所有,任何商业目的使用均须 CompuServe公司授权。
GIF图象是基于颜色列表的(存储的数据是该点的颜色对应于颜色列表的索引值),最多只支持8位(256色)。GIF文件内部分成许多存储块,用来存储多幅图象或者是决定图象表现行为的控制块,用以实现动画和交互式应用。GIF文件还通过LZW压缩算法压缩图象数据来减少图象尺寸(关于LZW算法和GIF数据压缩>>...)。

2. GIF文件存储结构

GIF文件内部是按块划分的,包括控制块( Control Block )和数据块(Data Sub-blocks)两种。控制块是控制数据块行为的,根据不同的控制块包含一些不同的控制参数;数据块只包含一些8-bit的字符流,由它前面的控制块来决定它的功能,每个数据块大小从0到255个字节,数据块的第一个字节指出这个数据块大小(字节数),计算数据块的大小时不包括这个字节,所以一个空的数据块有一个字节,那就是数据块的大小0x00。下表是一个数据块的结构:

BYTE 7 6 5 4 3 2 1 0 BIT
0 块大小 Block Size - 块大小,不包括这个这个字节(不计算块大小自身)
1 Data Values - 块数据,8-bit的字符串
2
...
254
255

一个GIF文件的结构可分为文件头(File Header)、GIF数据流(GIF Data Stream)和文件终结器(Trailer)三个部分。文件头包含GIF文件署名(Signature)和版本号(Version);GIF数据流由控制标识符、图象块(Image Block)和其他的一些扩展块组成;文件终结器只有一个值为0x3B的字符(';')表示文件结束。下表显示了一个GIF文件的组成结构:

GIF署名 文件头
版本号
逻辑屏幕标识符 GIF数据流
全局颜色列表
...
图象标识符 图象块
图象局部颜色列表图
基于颜色列表的图象数据
...
GIF结尾 文件结尾

下面就具体介绍各个部分:

文件头部分(Header)

GIF署名(Signature)和版本号(Version)

GIF署名用来确认一个文件是否是GIF格式的文件,这一部分由三个字符组成:"GIF";文件版本号也是由三个字节组成,可以为"87a"或"89a".具体描述见下表:

BYTE 7 6 5 4 3 2 1 0 BIT
1 'G' GIF文件标识
2 'I'
3 'F'
4 '8' GIF文件版本号:87a - 1987年5月
89a - 1989年7月
5 '7'或'9'
6 'a'

GIF数据流部分(GIF Data Stream)

逻辑屏幕标识符(Logical Screen Descriptor)

这一部分由7个字节组成,定义了GIF图象的大小(Logical Screen Width & Height)、颜色深度(Color Bits)、背景色(Blackground Color Index)以及有无全局颜色列表(Global Color Table)和颜色列表的索引数(Index Count),具体描述见下表:

BYTE 7 6 5 4 3 2 1 0 BIT
1 逻辑屏幕宽度 像素数,定义GIF图象的宽度
2
3 逻辑屏幕高度 像素数,定义GIF图象的高度
4
5 m cr s pixel
6 背景色 背景颜色(在全局颜色列表中的索引,如果没有全局颜色列表,该值没有意义)
7 像素宽高比 像素宽高比(Pixel Aspect Radio)

m - 全局颜色列表标志(Global Color Table Flag),当置位时表示有全局颜色列表,pixel值有意义.
cr - 颜色深度(Color ResoluTion),cr+1确定图象的颜色深度.
s - 分类标志(Sort Flag),如果置位表示全局颜色列表分类排列.
pixel - 全局颜色列表大小,pixel+1确定颜色列表的索引数(2的pixel+1次方).

全局颜色列表(Global Color Table)

全局颜色列表必须紧跟在逻辑屏幕标识符后面,每个颜色列表索引条目由三个字节组成,按R、G、B的顺序排列。

BYTE 7 6 5 4 3 2 1 0 BIT
1 索引1的红色值
2 索引1的绿色值
3 索引1的蓝色值
4 索引2的红色值
5 索引2的绿色值
6 索引2的蓝色值
7 ...
图象标识符(Image Descriptor)

一个GIF文件内可以包含多幅图象,一幅图象结束之后紧接着下是一幅图象的标识符,图象标识符以0x2C(',')字符开始,定义紧接着它的图象的性质,包括图象相对于逻辑屏幕边界的偏移量、图象大小以及有无局部颜色列表和颜色列表大小,由10个字节组成:

BYTE 7 6 5 4 3 2 1 0 BIT
1 0 0 1 0 1 1 0 0 图象标识符开始,固定值为','
2 X方向偏移量 必须限定在逻辑屏幕尺寸范围内
3
4 Y方向偏移量
5
6 图象宽度
7
8 图象高度
9
10 m i s r pixel m - 局部颜色列表标志(Local Color Table Flag)
置位时标识紧接在图象标识符之后有一个局部颜色列表,供紧跟在它之后的一幅图象使用;值否时使用全局颜色列表,忽略pixel值。
i - 交织标志(Interlace Flag),置位时图象数据使用交织方式排列,否则使用顺序排列。
s - 分类标志(Sort Flag),如果置位表示紧跟着的局部颜色列表分类排列.
r - 保留,必须初始化为0.
pixel - 局部颜色列表大小(Size of Local Color Table),pixel+1就为颜色列表的位数
局部颜色列表(Local Color Table)

如果上面的局部颜色列表标志置位的话,则需要在这里(紧跟在图象标识符之后)定义一个局部颜色列表以供紧接着它的图象使用,注意使用前应线保存原来的颜色列表,使用结束之后回复原来保存的全局颜色列表。如果一个GIF文件即没有提供全局颜色列表,也没有提供局部颜色列表,可以自己创建一个颜色列表,或使用系统的颜色列表。局部颜色列表的排列方式和全局颜色列表一样:RGBRGB......

基于颜色列表的图象数据(Table-Based Image Data)

由两部分组成:LZW编码长度(LZW Minimum Code Size)和图象数据(Image Data)。

BYTE 7 6 5 4 3 2 1 0 BIT
1 LZW编码长度 LZW编码初始码表大小的位数,详细描述见LZW编码...
... 图象数据,由一个或几个数据块(Data Sub-blocks)组成
数据块
...

GIF图象数据使用了LZW压缩算法(详细介绍请看后面的『LZW算法和GIF数据压缩』),大大减小了图象数据的大小。图象数据在压缩前有两种排列格式:连续的和交织的(由图象标识符的交织标志控制)。连续方式按从左到右、从上到下的顺序排列图象的光栅数据;交织图象按下面的方法处理光栅数据:

创建四个通道(pass)保存数据,每个通道提取不同行的数据:
第一通道(Pass 1)提取从第0行开始每隔8行的数据;
第二通道(Pass 2)提取从第4行开始每隔8行的数据;
第三通道(Pass 3)提取从第2行开始每隔4行的数据;
第四通道(Pass 4)提取从第1行开始每隔2行的数据;

下面的例子演示了提取交织图象数据的顺序:

通道1 通道2 通道3 通道4
0  -------------------------------------------------------- 1
1 -------------------------------------------------------- 4
2  -------------------------------------------------------- 3
3  -------------------------------------------------------- 4
4  -------------------------------------------------------- 2
5  -------------------------------------------------------- 4
6  -------------------------------------------------------- 3
7  -------------------------------------------------------- 4
8  -------------------------------------------------------- 1
9  -------------------------------------------------------- 4
10 -------------------------------------------------------- 3
11 -------------------------------------------------------- 4
12 -------------------------------------------------------- 2
13 -------------------------------------------------------- 4
14 -------------------------------------------------------- 3
15 -------------------------------------------------------- 4
16 -------------------------------------------------------- 1
17 -------------------------------------------------------- 4
18 -------------------------------------------------------- 3
19 -------------------------------------------------------- 4
20 -------------------------------------------------------- 2
图形控制扩展(Graphic Control Extension)

这一部分是可选的(需要89a版本),可以放在一个图象块(图象标识符)或文本扩展块的前面,用来控制跟在它后面的第一个图象(或文本)的渲染(Render)形式,组成结构如下:

BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标识 Extension Introducer - 标识这是一个扩展块,固定值0x21
2 图形控制扩展标签 Graphic Control Label - 标识这是一个图形控制扩展块,固定值0xF9
3 块大小 Block Size - 不包括块终结器,固定值4
4 保留 处置方法 i t i - 用户输入标志;t - 透明色标志。
5 延迟时间 Delay Time - 单位1/100秒,如果值不为1,表示暂停规定的时间后再继续往下处理数据流
6
7 透明色索引 Transparent Color Index - 透明色索引值
8 块终结器 Block Terminator - 标识块终结,固定值0

处置方法(Disposal Method):指出处置图形的方法,当值为:
0 - 不使用处置方法
1 - 不处置图形,把图形从当前位置移去
2 - 回复到背景色
3 - 回复到先前状态
4-7 - 自定义
用户输入标志(Use Input Flag):指出是否期待用户有输入之后才继续进行下去,置位表示期待,值否表示不期待。用户输入可以是按回车键、鼠标点击等,可以和延迟时间一起使用,在设置的延迟时间内用户有输入则马上继续进行,或者没有输入直到延迟时间到达而继续
透明颜色标志(Transparent Color Flag):置位表示使用透明颜色

注释扩展(Comment Extension)

这一部分是可选的(需要89a版本),可以用来记录图形、版权、描述等任何的非图形和控制的纯文本数据(7-bit ASCII字符),注释扩展并不影响对图象数据流的处理,解码器完全可以忽略它。存放位置可以是数据流的任何地方,最好不要妨碍控制和数据块,推荐放在数据流的开始或结尾。具体组成:

BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标识 Extension Introducer - 标识这是一个扩展块,固定值0x21
2 注释块标签 Comment Label - 标识这是一个注释块,固定值0xFE
... Comment Data - 一个或多个数据块(Data Sub-Blocks)组成
注释块
...
块终结器 Block Terminator - 标识注释块结束,固定值0
图形文本扩展(Plain Text Extension)

这一部分是可选的(需要89a版本),用来绘制一个简单的文本图象,这一部分由用来绘制的纯文本数据(7-bit ASCII字符)和控制绘制的参数等组成。绘制文本借助于一个文本框(Text Grid)来定义边界,在文本框中划分多个单元格,每个字符占用一个单元,绘制时按从左到右、从上到下的顺序依次进行,直到最后一个字符或者占满整个文本框(之后的字符将被忽略,因此定义文本框的大小时应该注意到是否可以容纳整个文本),绘制文本的颜色索引使用全局颜色列表,没有则可以使用一个已经保存的前一个颜色列表。另外,图形文本扩展块也属于图形块(Graphic Rendering Block),可以在它前面定义图形控制扩展对它的表现形式进一步修改。图形文本扩展的组成:

BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标识 Extension Introducer - 标识这是一个扩展块,固定值0x21
2 图形控制扩展标签 Plain Text Label - 标识这是一个图形文本扩展块,固定值0x01
3 块大小 Block Size - 块大小,固定值12
4 文本框左边界位置 Text Glid Left Posotion - 像素值,文本框离逻辑屏幕的左边界距离
5
6 文本框上边界位置 Text Glid Top Posotion - 像素值,文本框离逻辑屏幕的上边界距离
7
8 文本框高度 Text Glid Width -像素值
9
10 文本框高度 Text Glid Height - 像素值
11
12 字符单元格宽度 Character Cell Width - 像素值,单个单元格宽度
13 字符单元格高度 Character Cell Height- 像素值,单个单元格高度
14 文本前景色索引 Text Foreground Color Index - 前景色在全局颜色列表中的索引
15 文本背景色索引 Text Blackground Color Index - 背景色在全局颜色列表中的索引
N ... Plain Text Data - 一个或多个数据块(Data Sub-Blocks)组成,保存要在显示的字符串。
文本数据块
...
N+1 块终结 Block Terminator - 标识注释块结束,固定值0

推荐:1.由于文本的字体(Font)和尺寸(Size)没有定义,解码器应该根据情况选择最合适的;
2.如果一个字符的值小于0x20或大于0xF7,则这个字符被推荐显示为一个空格(0x20);
3.为了兼容性,最好定义字符单元格的大小为8x8或8x16(宽度x高度)。

应用程序扩展(Application Extension)

这是提供给应用程序自己使用的(需要89a版本),应用程序可以在这里定义自己的标识、信息等,组成:

BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标识 Extension Introducer - 标识这是一个扩展块,固定值0x21
2 图形控制扩展标签 Application Extension Label - 标识这是一个应用程序扩展块,固定值0xFF
3 块大小 Block Size - 块大小,固定值11
4 应用程序标识符 Application Identifier - 用来鉴别应用程序自身的标识(8个连续ASCII字符)
5
6
7
8
9
10
11
12 应用程序鉴别码 Application Authentication Code - 应用程序定义的特殊标识码(3个连续ASCII字符)
13
14
N ... 应用程序自定义数据块 - 一个或多个数据块(Data Sub-Blocks)组成,保存应用程序自己定义的数据
应用程序数据
...
N+1 块终结器 lock Terminator - 标识注释块结束,固定值0

文件结尾部分

文件终结器(Trailer)

这一部分只有一个值为0的字节,标识一个GIF文件结束.

BYTE 7 6 5 4 3 2 1 0
1 文件终结 GIF Trailer - 标识GIF文件结束,固定值0x3B
Tagged as: No Comments
14Jun/110

LZW算法和GIF数据压缩

Posted by ofeng

可变长度编码的LZW压缩算法(Variable-Length_Code LZW Compression),是从LZW(Lempel Ziv Compression)压缩算法演变过来的,通过压缩原始数据的重复部分来达到减少文件大小的目的。

标准的LZW压缩原理:

先来解释一下几个基本概念:
LZW压缩有三个重要的对象:数据流(CharStream)、编码流(CodeStream)和编译表(String Table)。在编码时,数据流是输入对象(图象的光栅数据序列),编码流就是输出对象(经过压缩运算的编码数据);在解码时,编码流则是输入对象,数据流是输出对象;而编译表是在编码和解码时都须要用借助的对象。

字符(Character):最基础的数据元素,在文本文件中就是一个字节,在光栅数据中就是一个像素的颜色在指定的颜色列表中的索引值;
字符串(String):由几个连续的字符组成;
前缀(Prefix):也是一个字符串,不过通常用在另一个字符的前面,而且它的长度可以为0;
(Root):单个长度的字符串;
编码(Code):一个数字,按照固定长度(编码长度)从编码流中取出,编译表的映射值;
图案:一个字符串,按不定长度从数据流中读出,映射到编译表条目.

LZW压缩的原理:提取原始图象数据中的不同图案,基于这些图案创建一个编译表,然后用编译表中的图案索引来替代原始光栅数据中的相应图案,减少原始数据大小。看起来和调色板图象的实现原理差不多,但是应该注意到的是,我们这里的编译表不是事先创建好的,而是根据原始图象数据动态创建的,解码时还要从已编码的数据中还原出原来的编译表(GIF文件中是不携带编译表信息的),为了更好理解编解码原理,我们来看看具体的处理过程:

编码器(Compressor)

编码数据,第一步,初始化一个编译表,假设这个编译表的大小是12位的,也就是最多有4096个单位,另外假设我们有32个不同的字符(也可以认为图象的每个像素最多有32种颜色),表示为a,b,c,d,e...,初始化编译表:第0项为a,第1项为b,第2项为c...一直到第31项,我们把这32项就称为根。

开始编译,先定义一个前缀对象Current Prefix,记为[.c.],现在它是空的,然后定义一个当前字符串Current String,标记为[.c.]k,[.c.]就为Current Prefix,k就为当前读取字符。现在来读取数据流的第一个字符,假如为p,那么Current String就等于[.c.]p(由于[.c.]为空,实际上值就等于p),现在在编译表中查找有没有Current String的值,由于p就是一个根字符,我们已经初始了32个根索引,当然可以找到,把p设为Current Prefix的值,不做任何事继续读取下一个字符,假设为q,Current String就等于[.c.]q(也就是pq),看看在编译表中有没有该值,当然。没有,这时我们要做下面的事情:将Current String的值(也就是pq)添加到编译表的第32项,把Current Prefix的值(也就是p)在编译表中的索引输出到编码流,修改Current Prefix为当前读取的字符(也就是q)。继续往下读,如果在编译表中可以查找到Current String的值([.c.]k),则把Current String的值([.c.]k)赋予Current Prefix;如果查找不到,则添加Current String的值([.c.]k)到编译表,把Current Prefix的值([.c.])在编译表中所对应的索引输出到编码流,同时修改Current Prefix为k ,这样一直循环下去直到数据流结束。伪代码看起来就像下面这样:

编码器伪代码

Initialize String Table;
[.c.] = Empty;
[.c.]k = First Character in CharStream;
while ([.c.]k != EOF )
{
if ( [.c.]k is in the StringTable)
{
[.c.] = [.c.]k;
}
else
{
add [.c.]k to the StringTable;
Output the Index of [.c.] in the StringTable to the CodeStream;
[.c.] = k;
}
[.c.]k = Next Character in CharStream;
}
Output the Index of [.c.] in the StringTable to the CodeStream;

来看一个具体的例子,我们有一个字母表a,b,c,d.有一个输入的字符流abacaba。现在来初始化编译表:#0=a,#1=b,#2=c,#3=d.现在开始读取第一个字符a,[.c.]a=a,可以在在编译表中找到,修改[.c.]=a;不做任何事继续读取第二个字符b,[.c.]b=ab,在编译表中不能找,那么添加[.c.]b到编译表:#4=ab,同时输出[.c.](也就是a)的索引#0到编码流,修改[.c.]=b;读下一个字符a,[.c.]a=ba,在编译表中不能找到:添加编译表#5=ba,输出[.c.]的索引#1到编码流,修改[.c.]=a;读下一个字符c,[.c.]c=ac,在编译表中不能找到:添加编译表#6=ac,输出[.c.]的索引#0到编码流,修改[.c.]=c;读下一个字符a,[.c.]c=ca,在编译表中不能找到:添加编译表#7=ca,输出[.c.]的索引#2到编码流,修改[.c.]=a;读下一个字符b,[.c.]b=ab,编译表的#4=ab,修改[.c.]=ab;读取最后一个字符a,[.c.]a=aba,在编译表中不能找到:添加编译表#8=aba,输出[.c.]的索引#4到编码流,修改[.c.]=a;好了,现在没有数据了,输出[.c.]的值a的索引#0到编码流,这样最后的输出结果就是:#0#1#0#2#4#0.

解码器(Decompressor)

好了,现在来看看解码数据。数据的解码,其实就是数据编码的逆向过程,要从已经编译的数据(编码流)中找出编译表,然后对照编译表还原图象的光栅数据。

首先,还是要初始化编译表。GIF文件的图象数据的第一个字节存储的就是LZW编码的编码大小(一般等于图象的位数),根据编码大小,初始化编译表的根条目(从0到2的编码大小次方),然后定义一个当前编码Current Code,记作

[/code]

,定义一个Old Code,记作[old]。读取第一个编码到

1

;读取下一个编码到

1

所对应的字符串到数据流,然后把[old]所对应的字符(串)当成前缀prefix [...],当前编码

1

,读下一个编码;我们来看看在编译表中找不到该编码的情况,回想一下编码情况:如果数据流中有一个p[...]p[...]pq这样的字符串,p[...]在编译表中而p[...]p不在,编译器将输出p[...]的索引而添加p[...]p到编译表,下一个字符串p[...]p就可以在编译表中找到了,而p[...]pq不在编译表中,同样将输出p[...]p的索引值而添加p[...]pq到编译表,这样看来,解码器总比编码器<strong>『</strong>慢一步』,当我们遇到p[...]p所对应的索引时,我们不知到该索引对应的字符串(在解码器的编译表中还没有该索引,事实上,这个索引将在下一步添加),这时需要用猜测法:现在假设上面的p[...]所对应的索引值是#58,那么上面的字符串经过编译之后是#58#59,我们在解码器中读到#59时,编译表的最大索引只有#58,#59所对应的字符串就等于#58所对应的字符串(也就是p[...])加上这个字符串的第一个字符(也就是p),也就是p[...]p。事实上,这种猜测法是很准确(有点不好理解,仔细想一想吧)。上面的解码过程用伪代码表示就像下面这样:
<table border="1" cellspacing="3" cellpadding="0" width="100%" bgcolor="#c0c0c0"><caption>解码器伪代码</caption>
<tbody>
<tr>
<td width="100%">
<blockquote>
Initialize String Table;
1

to the CharStream;
[old] = 1

= Next Code in the CodeStream;
while (1

is in the StringTable)
{
Output the String for 1

所对应的字符串
[...] = translation for [old]; // [old]所对应的字符串
k = first character of translation for 1

所对应的字符串的第一个字符
add [...]k to the StringTable;
[old] = 1

;
}
1

= Next Code in the CodeStream;

GIF数据压缩

下面是GIF文件的图象数据结构:

BYTE 7 6 5 4 3 2 1 0 BIT
1 编码长度 LZW Code Size - LZW压缩的编码长度,也就是要压缩的数据的位数
... 数据块
块大小 数据块,如果需要可重复多次
编码数据
... 数据块
块终结器 一个图象的数据编码结束,固定值0

把光栅数据序列(数据流)压缩成GIF文件的图象数据(字符流)可以按下面的步骤进行:
1.定义编码长度
GIF图象数据的第一个字节就是编码长度(Code Size),这个值是指要表现一个像素所需要的最小位数,通常就等于图象的色深;
2.压缩数据
通过LZW压缩算法将图象的光栅数据流压缩成GIF的编码数据流。这里使用的LZW压缩算法是从标准的LZW压缩算法演变过来的,它们之间有如下的差别:
[1]GIF文件定义了一个编码大小(Clear Code),这个值等于2的『编码长度』次方,在从新开始一个编译表(编译表溢出)时均须输出该值,解码器遇到该值时意味着要从新初始化一个编译表;
[2]在一个图象的编码数据结束之前(也就是在块终结器的前面),需要输出一个Clear Code+1的值,解码器在遇到该值时就意味着GIF文件的一个图象数据流的结束;
[3]第一个可用到的编译表索引值是Clear Code+2(从0到Clear Code-1是根索引,再上去两个不可使用,新的索引从Clare Code+2开始添加);
[4]GIF输出的编码流是不定长的,每个编码的大小从Code Size + 1位到12位,编码的最大值就是4095(编译表需要定义的索引数就是4096),当编码所须的位数超过当前的位数时就把当前位数加1,这就需要在编码或解码时注意到编码长度的改变。
3.编译成字节序列
因为GIF输出的编码流是不定长的,这就需要把它们编译成固定的8-bit长度的字符流,编译顺序是从右往左。下面是一个具体例子:编译5位长度编码到8位字符

0 b b b a a a a a
1 d c c c c c b b
2 e e e e d d d d
3 g g f f f f f e
4 h h h h h g g g
...
N

打包

前面讲过,一个GIF的数据块的大小从0到255个字节,第一个字节是这个数据块的大小(字节数),这就需要将编译编后的码数据打包成一个或几个大小不大于255个字节的数据包。然后写入图象数据块中。

Tagged as: , No Comments
17May/110

测试一下wiz

Posted by ofeng

测试一下wiz

通过 Wiz 发布
Filed under: 技术日志 No Comments
3May/110

Ubuntu笔记本内置鼠标(触摸板)的禁用

Posted by ofeng

以下是禁用触摸板的方法。

禁用触摸板用:sudo rmmod psmouse 或是 sudo modprobe -r psmouse

启用触摸板用:sudo modprobe psmouse

不过这种方法只适用于当前 关机后再开机就没用了 还得再次输入命令

一般情况下,是使用synaptics触摸板驱动。

最直接的方法,就是卸载synaptics驱动。

sudo apt-get autoremove synaptics

但是如果一旦需要使用触摸板,还要把驱动装上,太麻烦了。

还有一种比较简单的方法。

编辑xorg.conf文件:

sudo vi /etc/X11/xorg.conf
Section "InputDevice"
Identifier "Synaptics Touchpad"
Driver "synaptics"
Option "SendCoreEvents" "true"
Option "Device" "/dev/psaux"
Option "Protocol" "auto-dev"
Option "HorizEdgeScroll" "0"
Option "SHMConfig" "on"
EndSection

添加 Option "SHMConfig" "on" 这行内容

SHMConfig on 表明开启触摸板的参数设置权限

命令:synclient touchpadoff=1 --关闭触摸板

命令:synclient touchpadoff=0 --开启触摸板

自己写一个关闭触摸板命令的sh文件,加入到自启动栏目中,就万事大吉了

23Mar/110

ImageMagick 的php扩展 imagick段错误解决

Posted by alacner

imagick 是 PHP 下针对 ImageMagick 这个强大软件包的 API 接口,如果你在编译 ImageMagick 的时候将 IMAGEMAGICK_JPEG2000 编译进去了,你的 PHP 在启用 MagickWand 模块后会发生段错误,无法正常使用 PHP。

解决方法也就显而易见,在通过 源码安装的时候加上配置 --without-jp2,即:
./configure --without-jp2,安装即可。

3Mar/110

Support NginxWiki-20110303.chm to download

Posted by alacner

Nginx more and more popular, but official wiki have too much time to chm[NginxWiki-20090731.chm], so I compiled the latest sync to the wiki into chm, available to the offline-read students who needed.

Download:
NginxWiki-20110303.chm.tar.gz

10Feb/110

【转】设置自动重连的ssh代理通道

Posted by alacner

我目前常用的翻墙办法就是拿ssh搭个代理通道,然后chrome + switch!插件一起配合,这就算翻墙了。这法子只要拿个机器跑一小脚本,比如:

ssh -D 7070 -qnN [username]@[server]

但是ssh通道如果闲置了一段时间,就会自动断连,等我需要用到代理的时候往往又得蛋疼的重新跑一遍,非常麻烦。所以我刻苦学习前辈的经验,找到一个解决办法,在mac或linux下都可使用,分享如下:

  • 把ssh配置为免密码登录,这个一搜一大把,略过不提
  • 在/etc/inittab的最后一行加上:

    tunl:345:respawn:/usr/bin/ssh -D 7070 -qnN [username]@[server] > /dev/null 2>&1

  • 让修改的inittab马上生效

    sudo init q

然后这个ssh通道就会自动重连了。

【转自:Volcano】

Filed under: 技术日志 No Comments