作者归档:Neil

等等,你可能误解nodejs了–通俗的概括nodejs的真相

最近刚把产品从cpp平台迁移到nodejs平台了.  很多以前关于nodejs的观念被颠覆了. 这里分享出来, 欢迎大家批评指正.

"nodejs是做服务器端开发的, 它一定和web相关,几乎是用来做网站开发的."  这是我之前一直的观念.  相信这可能也是很多人对nodejs的初步认识吧.  但后来我才发现, 我可能错了.

第一个问题:  nodejs到底是什么?

http://nodejs.org/ 官方主页上有一段解释: "Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices."

我们注意其中的几个关键字:  nodejs是一个平台,  它构建在chrome的v8引擎之上,  能简易的构建快速,可扩展的网络应用程序.......

这里官方用的"网络应用程序",  整个描述没有提到"web", "server" 等等概念.  这段话的描述中, 有两个是重点, 第一,就是chrome的v8引擎.  第二, 是事件驱动的非阻塞io模型.   把握住这两点,  我觉得就算掌握了nodejs的真谛了.

这么说吧,  举个例子, 类比来说,  概念上, nodejs相当于.net,   jvm 或者 python.   它是一个运行平台, 只不过它运行的是javascript语言而已.   类似地,  .net一般运行C#, vb等编译过后的il.  而jvm一般运行java编译成的字节码,  python一般运行python语言.

你可能要问, 那么nodejs是不是也能实现 .net等等这些平台的功能呢.  比如写个窗口桌面程序, 做socket网络通信, 以及访问磁盘文件等等.

恩, 这些问题的答案都是肯定的.

nodejs核心主要是由两部分组成的:

第一, 是v8引擎, 它负责把javascript代码解释成本地的二进制代码运行.

第二, 是libuv,  类似windows上的窗口消息机制, 它主要负责订阅和处理系统的各种内核消息. 而且它也实现了消息循环(是不是很耳熟? 没错, 这个几乎就和windows 的窗口消息循环是一个概念.).  它的前身是linux上的libev, 专门封装linux上的内核消息机制.  后来nodejs重写了它, 并在windows上使用iocp技术重新实现了一遍.  所以nodejs现在能跨平台运行在windows上了.

 

nodejs其实就是libuv的一个应用而已.

你自己写程序也可以集成libuv进来, 这样你的c++程序就有了消息循环了. 不再是简单main函数了. 你可以订阅系统的事件, 然后当事件发生时, 系统会调用你的回调函数, 就跟windows上的button click事件一样方便. 而且是跨平台的哦. 是不是很酷.    你几乎可以订阅所有的系统事件,  比如socket事件, 文件读写事件等等.

nodejs简单的说只是把javascript解释成c++的回调, 并挂在libuv消息循环上, 等待处理.  这样就实现了非阻塞的异步处理机制.

那么为什么是javascript而不是其他的语言.  很简单, 因为javascript的闭包.  这非常适合做回调函数.  因为我们一般都希望当回调发生时, 它能记住它原来所在的上下文.  这就是闭包最好的应用场景.

这里有libuv的详细介绍 http://nikhilm.github.io/uvbook/.

好像扯远了,  说nodejs的, 怎么扯到libuv了.  很简单, 因为 nodejs只是libuv的一个应用.  先了解libuv才能了解nodejs的实质和前世今生.

我们再回来说nodejs.

从另一个角度看,   上面的工作都分别由v8和libuv做了.  那么nodejs到底做了什么呢?   我们先看一下nodejs的文档: http://nodejs.org/api/

对了,除了用javascript封装libuv框架之外,   nodejs就是实现了这些api 功能.  这些api大部分是用javascript写的, 也有一部分是c++写的.

这是nodejs官方的仓库, https://github.com/joyent  其中有很多nodejs的插件. 有了这些nodejs就可以实现非常丰富的功能了.

作为结尾, 写一个简单的nodejs 常规helloworld 程序.

//test.js

//=================

console.log("hello world!")

//=================

存成test.js.  然后运行: node test.js

就能看到效果了.

怎么样,  看起来是不是很像python的感觉.  但是用的是javascript哦.  用这个代替python, 是不是爽死了.

就到这吧.  关于libuv, 关于nodejs插件.  等等话题, 希望能跟大家沟通交流.

欢迎大家访问我的独立博客: http://byNeil.com

 

7z文件格式及其源码的分析

本文是一个系列. 主要是分享我最近一年做7z文件开发的经验. 主要包括7z官方源码的结构分析, 以及7z文件格式的分析. 其中涉及到7z源码结构的各个细节, 以及7z文件格式的具体细节. 本文适合对象: 想要了解学习7z源码的开发人员, 想要了解7z文件格式细节, 做7z文件压缩器和解压器的开发人员, 以及其他压缩文件爱好者等等.

目前7z的最新稳定版是9.20, 而9.30版本还在alpha版本. 所以本文是基于其9.20版本.  我将尽可能详细的描述所有细节, 但到目前为止我了解到的细节大概能到八成到九成的样子. 也不是百分百.  希望能和大家共同讨论学习.  这些信息足以开发一个工业级别的高兼容性的7z压缩器和解压器了.

本文首发在我的个人独立博客  http://byNeil.com 以及博客园.  欢迎大家浏览我的独立博客, 留言交流. 转载请注明出处链接. 本人保留一切权利.  但本人不对使用本文提供的代码造成的损失负责.

好了, 憋死我了, 前面的客套话终于说完了.  有人可能要问, 为什么要分析7z文件格式? 这个不是开放的吗? 为什么我前面说我只了解到八,九成, 而不是百分百呢?

我先来解释这几个问题, 这能说明本文的必要性, 以及看下去的必要性.  首先7z的确是开放的. 但他的格式说明非常简单, 简直是简陋. 简单的一个txt文件,寥寥几十行算不上说明的符号, 对复杂的7z格式来说, 简直就是天书.( 后面分析7z源码的时候会详细说道这一点. )  所以如果你接到老板的一个通知:"我们要做7z兼容的压缩解压器" 的时候, 你就要崩溃了.  因为相对于zip这些经过标准化的文件格式来说, 7z几乎就是一个黑洞.(zip有标准化的 spec, 里面有详细到字节级别的说明).   所以我分析7z格式可以说有一半是通过阅读源码逆向推测出文件格式的, 再经过反复和源码对比测试证明其正确性的.  所以我只能说了解到了八九成, 而不是百分百.

先分享一些有用的链接:

7z的官方主页: http://www.7-zip.org/  (它托管在sourceforge的虚拟机上, 本来能打开的, 但是前一段时间开始被墙了, 我实在想不到墙它的理由, 可能是被sourceforge主机上其他的网站拖累的吧,你懂的).

这是sourceforge上7z的论坛: http://sourceforge.net/p/sevenzip/discussion/45797  . 论坛比较活跃, 每天都有新帖. 而且7z作者也在上面每天亲自回帖.  由于作者是俄罗斯人, 所以时区跟我们差的不多.  一般留言4个小时左右,  作者就能回复吧. 我问过几个问题, 都是这样的. 当然也有些帖子作者懒得回, 那就另当别论了. 呵呵.

7z的官方中文镜像: http://sparanoid.com/lab/7z/    这个不需要翻墙.  是官方给出的中文版链接. 值得信赖. 上面的内容基本和官方主页保持一致.

 

我们先从几个概念开始吧 :    7z软件 和7z文件.   7z文件指的是一种后缀名为.7z的文件.    7z软件指的是作者开发的生成和操作7z文件的工具.  但是现在7z软件已经发展到不光支持7z格式的文件了, 还能额外的生成和编辑另外几十种文件格式了. 其中包括我们熟知的zip格式, rar格式, iso格式等等,  也包括一些不可思议的格式, 比如: CAB, CHM, CPIO, CramFS, DEB, DMG, FAT . 看眼花了吧.  好吧, 本文主要讨论 7z文件格式, 以及7z软件中主要和7z文件相关的功能. 当然也会粗略的涉及到其他的一些有用的功能,  比如如何给7z软件写插件, 让他支持我们自己定义的文件格式.

 

再来几个概念.  说到压缩文件, 一般会遇到两个概念,   一个是 "Compress"(压缩) 和"Archive" (存档).    "存档" 这个词个人觉得不好理解. 我个人把 "Archive" 叫做 "打包".

举个例子,  比如有一堆毛巾,  每一条毛巾代表一个文件.    "Compress"(压缩)的意思就是把毛巾里面的水拧干, 达到压缩的目的.  而"Archive"(打包) 的意思就是把这些毛巾包成一个大包, 便于运输.     所以你可能想到了, 要运输一堆这样的毛巾可能有两种方法: 第一种: 先把每条毛巾拧干并折成方块(压缩), 再把这些方块组合成一个大包(打包).  第二种, 先把这些毛巾包成一个大包(打包),  然后再把这个大包拧干.    凭经验你可能已经意识到, 前一种方法比较好处理, 而且压缩比比较大.  后一种方法就弱一点了.

对了, 前一种就是先压缩后打包的方式. 7z, zip 和rar等就是用的这种方法.   后一种就是先打包, 后压缩的方法. 常见的tar.gz的文件就是用这种方法的. 先用tar打包, 在用gz压缩.

 

对于7z 我们再具体解释一下 "压缩" 和 "打包" 的概念.

 

7z 文件格式严格的说是一种"打包"的格式,  它规定了打包的方法.   而"压缩"的任务是由不同的算法完成的.    "压缩算法"负责把毛巾里的水拧干. 具体来讲就是把一个文件按照一定规则变小.  压缩算法一般只能处理单个文件, 对于多个文件, 只能单个文件压缩, 然后再打包.

(当然,前面也说到了, 第二种方法就是先把文件打包, 然后再压缩. tar.gz就是这样的. tar工具就是简单的把所有的文件首尾相接, 变成一个大文件, 然后再用压缩算法一次压缩的.  这个不是本文的讨论对象, 所以以后就不提了.)

 

7z默认使用的是lzma压缩算法.   单个文件会先用lzma压缩算法压缩,  然后7z负责把压缩过后的文件打包.   (这个跟zip类似, zip文件也是打包格式, 它默认使用deflate算法压缩.)  7z还支持封装其他几种压缩算法, 比如: Lzma2, ppmd, bzip2和deflate.

这些压缩算法在7z里面都有源码,  也不是本文要讨论的重点.  我们将重点讨论7z的打包格式. 就是介绍7z具体是怎样把压缩过后的文件封装打包的.  期间也会夹杂介绍其中一些算法.  后面如果有时间, 我会再单独介绍这些算法的具体实现.

终于把前期准备介绍完了,   有点繁琐.

下一篇我们将开始具体分析介绍7z的源码.    完成之后, 我会把第二篇的链接更新到这里. 当然你也可以在我的博客中搜索到.

大家多多支持哦.

 

 

 

 

 

 

 

 

 

 

 

记一次艰苦卓绝的Discuz x3 论坛升级过程

首先吐槽一下discuz 的官方论坛. 你要想下载到正确版本的discuz实在不容易找到. 有兴趣自己去看吧. 就是因为这个原因, 我本来想要安装x2.5版本(那时x3 还是Beta版本), 结果不小心下载成了x2.  也就是不久前, x3才发布正式版.   我最近想要安装几个插件,和皮肤, 但是打开插件中心, 发现我所有的插件都安装不了, 说我的版本不支持.

我确信是x2.5 的插件, 语言版本也没问题(我一直以为自己的论坛是x2.5), 这就奇怪了. 我也觉得discuz不会有这么明显的bug啊.网上搜了很多,都说是版本不对, 请仔细核对版本. 这问题一直困然了我很久.  当时没有紧急的需求,也就放下了.

直到今天, 我想安装插件和皮肤, 我决定把这个安装不了插件的问题搞定. 最终还是要核对版本, 我突然想到好像在别人的论坛下面看到过 类似 "x2.5" 的版权申明(就是在论坛首页的下面声明的).  再看看我自己的是 "x2", 所以我猜测可能是我的版本安装错了.  所以本地搭建php环境(wamp server), 去discuz官方仔细找到2.5的下载地址. 本地安装.  证实我的猜测是对的. 我的论坛装错了.  现在查件中心绝大部分插件和皮肤都只支持2.5和3, 所以要想装查件, 只能升级了.

我的论坛已经有很多用户和数据了, 不能重装, 现在只能选择升级了. 好吧, 要升就直接升到最新x3吧.  好在官方的升级脚本还是比较详细的, 而且我也相信discuz的实力, 官方说支持从x2直接升到x3.

为了确保万无一失, 我先把服务器上的文件和数据库都备份到本地的php环境. 在本地"预升级"一次.  按照官方给的步骤,很简单就完成了.  打开页面看了一下,也没有发现问题. 放心了. 现在可以正式升级了.

第一步: 备份服务器的所有文件 和 数据库.

按照官方的说明把文件都拷贝上去: http://www.discuz.net/thread-3265731-1-1.html

因为我是用root身份登录到vps上去的,  所以拷贝上去的文件都是属于root的,  nginx 运行所使用的"www"用户是没有权限访问的. 所以要把权限都改对了,进入网站的根目录:

chown www -R *
chgrp www -R *

 

把网站的文件都改到 用户 "www" 用户的名下.

此时可以开始升级了. 运行: http://xxxxxxxx.com/install/update.php

问题出现了, 刚才预升级的时候, 这里就可以点下一步升级了. 但是此时提示 :

"请先升级 UCenter 到 1.6.0 以上版本。如果使用为Discuz! X自带UCenter,请先下载 UCenter 1.6.0, 在 utilities 目录下找到对应的升级程序,复制或上传到 Discuz! X 的 uc_server 目录下,运行该程序进行升级"

(当时没顾上截图)

什么? ucenter版本不对?  不可能啊, 我已经预升级一次了.  不会啊.   于是把服务器上的文件和数据库都恢复到升级前的状态, 进ucenter看, 发现版本号的确是1.6.  所以没问题.

然后又重复官方的教程.

最后运行: http://xxxxxxxx.com/install/update.php.   还是出现一样的提示.

反复按照官方的教程做了三次, 到这都是这个提示, 我确信我没有哪一步做错了. 这就奇怪了.

于是打开update.php文件, 找到这个提示的位置:

1

是这里在比版本号.

上面的code是我改过的, $oldversion 这个变量是我加的, 就是想把版本号显示出来, 看看到底是多少.

重新运行:  http://xxxxxxxx.com/install/update.php.

发现显示出来的版本号是空白. 什么也没有.

继续追踪: "uc_check_version" 函数, 因为版本号是从这的出来的.

搜索到uc_client/client.php

function uc_check_version() {
	$return = uc_api_post('version', 'check', array());
	$data = uc_unserialize($return);
	return is_array($data) ? $data : $return;
}

到了这里还是看不出来.

还是把服务器恢复原样, 和本地比看有什么却别.

恢复服务器文件和数据.

问题出在ucenter, 当然打开后台ucenter看看.

赫然发现: 通信失败

2

 

我很清楚的记得,  原来这里是绿色的通信成功的.

难道是因为和ucenter的通信失败了,  才导致update.php 文件获得ucenter的版本号失败, 所以导致我升级不成功的?

想到这里, 就要跟踪为啥通信会失败了.   (百度搜ucenter 通信失败, 很多人都说是论坛和ucenter之间的设置不一致导致的. 我也反复确认了很多次,设置没有问题.)

我们打开chrome的调试面板, 找到检查通信失败的地址:

点击左侧的 "应用管理", 会发现下面这一条ajax的调用:

3

把这个地址在浏览器中打开:

4

 

发现他果然返回了通信失败的字样.

从上面的url 我们依次找到: uc_server/control/admin/app.php 文件, 并定位到 onping函数:

5

图中可以看到我注掉的调试代码, 都是我自己加的,为了跟踪代码的流程. 我发现流程是 进入了 "else" 块, 然后出来之后 $status就是空白.  下面在判断如果status是1表示成功. 否则就是失败.

我在本地成功的环境下, 重现类似的场景, 发现也是进入了else块, 但是出来的时候 status是1.

那就继续追踪 test_api() 这个函数.

搜索 "test_api", 发现有两处定义, 分别在uc_client\model\misc.php  和 \uc_server\model\app.php.

第一处是空实现, 所以只能看第二处了.

	function test_api($url, $ip = '') {
		echo "in test pi".'<br>';
		$this->base->load('misc');
		if(!$ip) {
			$ip = $_ENV['misc']->get_host_by_url($url);
		}
                echo "line1:".$ip."<br>";
		if($ip < 0) {
			return FALSE;
		}
		echo "line2:".$ip."<br>";
		echo "line3:".$url."<br>";
		$ret = $_ENV['misc']->dfopen($url, 0, '', '', 1, $ip);
		echo "line4 ret value is:".$ret."<br>";
		return $ret;
	}

 

上面, 我加了一些调试代码.

发现 $ret是空白.

那就是dfopen的问题了.

搜索dfopen. 他有多处实现, 但是有两处比较可疑:

\uc_client\model\misc.php 和 \uc_server\model\misc.php

我现在两个实现的入口处都设置echo语句. 发现时走的第二处.

于是进一步跟踪第二处实现:

	function dfopen($url, $limit = 0, $post = '', $cookie = '', $bysocket = FALSE	, $ip = '', $timeout = 15, $block = TRUE, $encodetype  = 'URLENCODE') {
		echo "server model misc dfopen:"."<br>";
		//error_log("[uc_server]\r\nurl: $url\r\npost: $post\r\n\r\n", 3, 'c:/log/php_fopen.txt');
		$return = '';
		$matches = parse_url($url);
		$host = $matches['host'];

............

		if(function_exists('fsockopen')) {
			echo "server model misc dfopen:fsockopen"."<br>";
			$fp = @fsockopen(($ip ? $ip : $host), $port, $errno, $errstr, $timeout);
		} elseif (function_exists('pfsockopen')) {
			echo "server model misc dfopen:pfsockopen"."<br>";
			$fp = @pfsockopen(($ip ? $ip : $host), $port, $errno, $errstr, $timeout);
		} else {
			echo "server model misc dfopen:false"."<br>";
			$fp = false;
		}

................

 

我加了一些调试语句在里面.

当加到这里的时候,  想到,是不是 服务器的fsockopen函数被禁用了呢. 于是就没再继续加了. 赶快试. 上传文件, 刷新url.

果然输出了 "server model misc dfopen:false"

 

我擦, 原来是 fsockopen函数被禁用了啊.  赶快上传php的探针,  发现fsockopen果然被禁用了.

6

我这是才想起来,  前几天更换vps的时候, 没注意, 可能忘了打开fsockopen 函数了.

赶快去服务器:/usr/local/php/etc 中 打开php.ini  找到disable_functions这一行. 从中把fsockopen和pfsockopen都删掉.

然后重启php:  service php-fpm restart

然后刷新上面的url, 返回通信成功了.

好了,现在再回到开头.

把文件还原成升级前的样子, 再按照官方说明, 升级文件.

运行: http://xxxxxxxx.com/install/update.php

这次终于正常了, 显示准备完成,可以升级.

后面就比较顺利了. 自动升级数据库, 然后手动去吧缓存更新一下. 就好了.

就到这.

其中还省略了无数的弯路啊.

再次证明一个真理,  看似复杂的问题, 一定是由一个比较愚蠢的原因造成的.

 

导入用户信息到discuz ucenter.

上一篇帖子: 直接导入帖子到Discuz 论坛数据库. 结束时说要写一篇导入用户的帖子, 一直没时间, 但是咱不能做太监,不是? 所以今天赶快补上. 在做discuz整合或者迁移是, 很多人可能遇到相同的问题, 就是用户数据怎么导入到discuz中.

discuz 的用户数据其实是存在 ucenter中的. ucenter是什么? 自己百度去. 简单的说, ucenter 就是discuz各个产品之间共享数据的媒介. 所以我们只需要导入到ucenter的表中就可以了.

同样通过上一篇文章中提到的比较方法,  我们发现用户数据时存在 pre_ucenter_members 这一张表中的.  欢迎大家交流心得, 访问我的独立博客 http://byNeil.com  .下面解释一下这个表的列的含义:

1. username:  用户名, 就是用户登录输的用户名.

2. password: 密码, 这个当然不是明文的密码, 至于怎么生成的, 后面再说. password hash = Md5(Md5(password) + salt);

3. email: 就是用户的email, 明文

4. regdate: 是一个int值, linux的时间戳,表示用户的注册时间.

5. salt: 盐.  这个比较有意思, 是为了增加用户密码的安全性的.  这个salt是一个 6位长的字符串, 它本身是注册时随机产生的.  它的作用就是用来混在密码一起产生密码的hash值的.  password hash = Md5(Md5(password) + salt);

 

有了这几列的意思, 导入就简单多了.  如果你知道原来用户的密码(不太可能, 除非是国内某著名网站明文存密码),  或者知道用户密码的 MD5值,  就可以用自己生成的salt来 为用户导入密码了.  这样用户就能用原来的密码登陆新网站了.   如果不知道, 那只有重置所有用户的密码.

具体code就不写了, 各个语言不一样, 自己琢磨.

 

 

 

 

翻译一篇很好的理解deflate算法的文章

最近做压缩算法. 用到了deflate压缩算法,  找了很多资料,  这篇文章算是讲的比较易懂的, 这篇文章不长,但却浅显易懂, 基本上涵盖了我想要知道的所有要点. 翻译出来, 留存.    可能对正在学习或者准备学习deflate算法的童鞋有所帮助.

先说一下deflate算法吧.  deflate是zip压缩文件的默认算法.   其实deflate现在不光用在zip文件中, 在7z, xz等其他的压缩文件中都用.   实际上deflate只是一种压缩数据流的算法. 任何需要流式压缩的地方都可以用.          deflate 还有微型改进版本deflate64. "微型改进型" 这个名词是我发明的, 为什么这么说, 因为改进实在太小了, 而性能提高也非常小. 以至于大名鼎鼎的开源zlib库到现在都不支持deflate64.      http://zlib.net/zlib_faq.html#faq40

开始正题, 原文地址: http://zlib.net/feldspar.html ,  我尽量按照原文直译,但是有些地方实在没必要就简单意译了. 有需要想交流的童鞋欢迎访问我的独立博客留言交流: http://byNeil.com

==========================华丽的分割线====================

Deflate 算法的介绍

作者: Antaeus Feldspar   feldspar@netcom.com

在理解deflate之前, 先理解它的两个组成算法非常重要: Huffman 编码 和 LZ77压缩

Huffman 编码

Huffman编码是一种前缀编码, 你其实知道, 但你可能不觉得. 比如打电话时, 从拨号开始, 你按下一串号码, 或许是5781112 或者别的号码. 一串号码就就能到达另一部特定的电话.  (翻译: 这个比方太罗嗦,本来不想翻译过来的.)

(这一段就不翻译了,没有实际内容.) Now suppose you're in an office setting with an internal switchboard, as many large companies do. All other phones within the bank only require five numbers to dial, instead of seven -- that's because it's expected that you'll be calling those numbers more often. You may still need to call other numbers, though -- so all of those numbers have a `9' added to the front.

...这就是前缀编码. 每一个你想要指定的元素都有一个由数字组成的代码. 由于每个代码都不可能是另外一个代码的前缀, 所以当你输入的时候,不会有歧义.

Huffman 编码是由一个特定算法生成的前缀编码. (翻译: 后面简单介绍如何生成Huffman编码, 都是教课书上的内容, 不翻译了, 自己看图, 直接跳过:) Here, instead of each code being a series of numbers between 0 and 9, each code is a series of bits, either 0 or 1. Instead of each code representing a phone, each code represents an element in a specific ``alphabet'' (such as the set of ASCII characters, which is the primary but not the only use of Huffman coding in DEFLATE).

A Huffman algorithm starts by assembling the elements of the ``alphabet,'' each one being assigned a ``weight'' -- a number that represents its relative frequency within the data to be compressed. These weights may be guessed at beforehand, or they may be measured exactly from passes through the data, or some combination of the two. In any case, the elements are selected two at a time, the elements with the lowest weights being chosen. The two elements are made to be leaf nodes of a node with two branches (I really hope you know nodes and trees...) Anyway, suppose we had a set of elements and weights that looked like this:

A 16
B 32
C 32
D 8
E 8
We would pick D and E first, and make them branches of a single node -- one being the `0' branch, and one the `1' branch.

( )
0 / \ 1
D E

...... (翻译中间省略无数废话,  都是在介绍怎么生成huffman树, 这个上过课的人都知道, 所以就不翻译了, 细节非常繁琐. 下面直接从 课本上没有的另一个算法 Lz77开始:)

LZ77 压缩
LZ77压缩算法靠查找重复的序列. 这里使用术语:"滑动窗口", 它的意思是:在任何的数据点上, 都记录了在此之前的字符. 32k的滑动窗口表示压缩器(解压器)能记录前32768个字符. 当下一个需要压缩的字符序列能够在滑动窗口中找到, 这个序列会被两个数字代替: 一个是距离,表示这个序列在窗口中的起始位置离窗口的距离, 一个是长度, 字符串的长度.

我觉得 看 比 说 更容易. 我们看看一些高压缩比的数据:

Blah blah blah blah blah!

字符流开始于: `B,' `l,' `a,' `h,' ` ,' and `b.' , 看看接下来的5个字符:

vvvvv
Blah blah blah blah blah!
^^^^^
接下来的5个字符正好和已经在数据流中的字符串相等, 而且刚好在当前数据点的前5个字符开始. 在这个case中,我们可以在数据流中输出特殊的字符, 一个长度数字 和一个距离数字.
目前数据是:
Blah blah b
压缩后的格式是:
Blah b[D=5,L=5]
压缩还能继续增加, 尽管要利用其全部的优势需要压缩器方面的智慧. 对比这两个相同的字符串, 对比它们各自的下一个字符,都是'l', 所以,我们可以把长度更新为6, 而不仅仅是5. 如果我们继续比较,发现下一个, 下下一个, 下下下一个都是一样的. 尽管前面的字符换已经延伸覆盖到了后面的字符串(需要压缩的字符串).
最终我们发现, 有18个字符相等. 当我们解压的时候, 当读到长度和距离对时, 我们并不知道这18个字符将会是什么. 但是如果我们把已有的字符放回去, 我们就知道更多. 而这有会让更多的字符放回去, 或者知道任何长度大于距离的数据对都会不断的重复数据. 所以解压器就可以这样做.
最终我们的高压缩性的数据能压缩成如下的样子:
Blah b[D=5, L=18]!
联合起来(翻译: 指的是把huffman编码和 lz77压缩算法联合起来用):
deflate 压缩器在怎样压缩数据上有非常大的灵活性. 程序员必须处理设计聪明的算法所面临的问题以做出正确的选择. 但是压缩器的确有一些选择.
压缩器有三种压缩模型:
1. 不压缩数据, 对于已经压缩过的数据,这是一个明智的选择. 这样的数据会会稍稍增加, 但是会小于在其上再应用一种压缩算法.
2. 压缩, 先用Lz77, 然后用huffman编码. 在这个模型中压缩的树是Deflate 规范规定定义的, 所以不需要额外的空间来存储这个树.
3. 压缩, 先用LZ77, 然后用huffman编码. 压缩树是由压缩器生成的, 并与数据一起存储.

数据被分割成不同的块, 每个块使用单一的压缩模式. 如过压缩器要在这三种压缩模式中相互切换, 必须先结束当前的块, 重新开始一个新的块.

关于Lz77和huffman如何一起工作的细节需要更进一步的检查. 一旦原始数据被转换成了字符和长度距离对组成的串, 这些数据必须由huffman编码表示.
尽管这不是一个标砖术语, 把开始读数据的点叫"拨号音", 毕竟在我们的类推中, 拨号音的确是我们指定一个电话的的拨号的开始点. 所以我们把这个起始点叫"拨号音". 在起始点之后, 只可能有三种元素能出现:字符, 长度距离对, 或者是块的结束标志. 因为我们必须能够区分它是什么. 所有可能的字符(字面量), 表示可能长度的区域, 以及特殊的块结束标记都被合并到同一个字母表中. 这个字母表就是huffman树的基础. 距离不需要包含在字母表中, 因为它只能出现在长度的后面. 一点字面量被解压, 或者长度距离对解压出来, 我们就开始了另一个拨号音, 重新开始读取. 当然,如果遇到块结束标志的话, 就会开始另外一个块,或者到达了压缩数据的末尾.
长度或者距离的编码实际上可以是: 一个基地址,后面跟上额外的bits(整数的形式,表示基地址后面的偏移),

可能deflate规范中最难理解的部分就是当数据时被特殊的树压缩的时候, 树与数据一起的压缩方式.
树 通过 编码长度(codelengths)来传输, 正如前面讨论的. 代码长度被全部放在一个由0到15之间的数字组成的序列中(huffman树种,代码长度必须不大于15, 这是最复杂部分, 而不是怎样约束元素的顺序).

并不是所有的元素都必须有一个代码长度. 如果字母表的最后的那些元素代码长度都是0, 他们能并且应该被忽略. 由于每个字母表中元素的个数都会被传输, 所以这两个字母表会被链接成单一的序列.

一旦编码长度序列组合完成,  它会被一种叫做 run-length 的压缩方式压缩. 当一行中的多个元素拥有一样的代码长度(常常是0) 的时候, 特殊的符号会用来表示这个长度的元素的个数.  现在这个序列式0到18之间的数字组成的了(可能带有额外的位组成修改基地址的值).

huffman 树就是为这个0到18的字母表创建的.

huffman树需要包含在数据中, 当然.  正如其他的huffman树一样, 它会被记录代码长度的形式包含进来.   然而, 它们的顺序不是 0, 1, 2, 3, 4 ... 16, 17, 18. 而是一个特殊的顺序:16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15.  这背后的逻辑是:越靠近序列末尾的代码,越可能是长度为0. 如果它们的确是0, 就能被省略掉. 直接记录的元素的个数也会包含在数据中.

这些就是我觉得在deflate 规范中的难点. 多花时间读规范,应该能帮助了解. 有任何别的问题请联系: - Antaeus Feldspar ( feldspar@netcom.com)

 

 

======================分割线 完==================

 

 

 

python 通过 MySQLdb 链接mysql 数据库的编码问题

python 通过 MySQLdb 链接mysql

mysql使用的是 utf8编码,出现乱码。

解决方法:

conn = MySQLdb.connect (host = "localhost", user = "root", passwd = "", db = "aaa", charset="utf8")

db = MySQLdb.connect(host=DB_HOST, user=DB_USER, passwd=DB_PASS, db=DB_NAME, charset="utf8", use_unicode=True)

 

http://stackoverflow.com/questions/9154998/python-encoding-mysql

压缩大文件,中间算法出错, 用日志解决.

在做一个压缩算法, 压缩一个200M的文件,  大概压到50M左右的时候, 数据开始不对了.

由于这个算法是从别人的算法改写过来的, 这个咋调试呢.

方法是在 关键函数 的 关键地方把主要值打印到日志中,  确保两边的打印都是对应的, 然后对比两个日志. 用文本比较工具可以快速找到问题.

这看起来可能觉得比较复杂, 其实找准关键点, 找起来还是蛮快的.

 

java 二位数组和c# 二位数组的声明不一样

 

java:

int[][]  arr = new int[5][6];

java 可以同时指定两个维度的长度.

 

c# 只能这样

int[][]  arr = new int[5][];

c# 只能指定第一维的长度.

 

但是java也支持像c#一样的写法, 只指定一维的长度:

int[][]  arr = new int[5][];

 

其实c#有自己的的二维数组数据结构:

int[,] arr = new int[5,6];

注意中间有逗号.

 

通过.htaccess 的rewriterule 新旧网站的无缝转换,不丢权重

举个例子,  本来有个 A.com 的网站,  做了一定的人气, 有了权重.  因为人流量上升, 这个时候想更换网站程序, 比如做成一个论坛社区.

很简单想到的就是把 A.com 直接指向新的网站就行了.  但是这样, 以前的A.com 的所有的外链都失效了. 对权重非常不利.

主要目标有两个, 第一不丢失以前的外链.  第二让A.com的权重完全转到新的论坛.

我们可以这样实现.  1. 保留原网站, 这是为了确保, 外链都有效.  2, 把 A.com  重定向到  bbs.A.com

这里有一个问题,就是如果把A.com 重定向到了bbs.A.com了, 外链怎么保持呢. 原来的外链都是 http://a.com/abc/def.php 这种形式的.

这个时候想到的就是有条件的重定向,  当用户直接访问A.com的时候, 重定向到bbs.A.con.  如果用户是通过这种形式 http://a.com/abc/def.php 访问的网站,  则不重定向, 让它依然有效.

思路就是检测请求的uri, 如果没有uri 就直接重定向. 如果有uri 则不重定向.

这在php中很容易实现. 但是为了执行效率, 我决定改写.htaccess文件来实现.

在.htaccess 文件的最开始, 插入一下代码


RewriteCond %{REQUEST_URI} =/     #直接输入a.com访问的话,uri不是空,而是斜线:'/'
RewriteCond %{QUERY_STRING} ^$    #正则表达式 ^和$ 放在一起,表示空,之所以加上Querystring,是防止用户这样访问: a.com/?id=124
RewriteRule .* http://bbs.a.com [R=301,L] #重定向到新网址


搞定.

希望大家多多交流.