1. 将字符串进行Deflate压缩
2. 将压缩后的结果再进行Base64编码

那么服务器端，需要进行上述流程的反过程。问题是，由于这是个开放接口，客户端可以使用各种不同的平台进行开发，如JS、Java、Ruby、PHP等。好在，大多数语言都是基于zlib包装了自己的相关API，那么也算是实现标准了。窘迫的事情时，NodeJS里面zlib的实现是在0.6以后加入的，我们使用的技术仍然是0.4版本的。

迫于时间有限，切换到0.6或者实现zlib的binding都是不靠谱的，于是我打开了万能的Github。果然功夫不负有心人，找到了Deflate的纯JS实现——RawDeflate。顿时对作者的崇拜之心油然而生。殊不知，悲剧就是从这里开始的。

Base64算法

为了测试有效性，我用JS做了客户端编码工作，然后用Ruby实现了服务器端解码工作。代码如下:

• 被我修改过的deflate.js
• JS编码脚本,v1
• Ruby解码脚本,v1

这里只把编码脚本和解码脚本贴出来，其他的已经在上面给出了Gist链接。

编码脚本, v1

var RawDeflate = require("./deflate"),
    Buffer = require("buffer").Buffer,
    fs = require("fs");

function encode(str) {
  return new Buffer(RawDeflate.deflate(str)).toString("base64");
}

console.log(encode("hello, world!"));
fs.writeFileSync("data.txt", encode("hello, world!"));

解码脚本，v1

require 'base64'
require 'zlib'

def decode(str)
  Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(Base64.decode64(str))
end

str = File.open("data.txt", "r") do |data|
  data.readlines().join()
end

p decode(str)

运行的结果是空串哦，亲！也就是说Ruby竟然不能解出来。Ruby是直接在Zlib上进行包装的，那么其他的语言PHP、Python什么的也应该是同样的结果。

好吧，难道我JS的算法有误差？那么和Ruby的算法进行对比以下吧⋯⋯

Ruby的测试脚本，算出的每个步骤都进行md5：

require 'base64'
require 'zlib'
require 'digest/md5'

def deflate(str)
  Zlib::Deflate.new(nil, -Zlib::MAX_WBITS).deflate(str, Zlib::FINISH)
end

def base64(str)
  Base64.encode64(str)
end

def md5(str)
  s = Digest::MD5.hexdigest(str)
end

def encode(str)
  base64(deflate(str))
end

def decode(str)
  Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(Base64.decode64(str))
end

str = 'hello, world'

p "Test Base64"
p base64(str)
p md5(base64(str))

p "Test Deflate"
p deflate(str)
p md5(deflate(str))

p "Test Encode Defalte and Base64"
p encode(str)
p md5(encode(str))

p "Test Decode Deflate and Base64"
p decode(encode(str))

运行发现，Ruby自己处理自己压缩出来的东西毫无问题。那么JS呢？

var Base64 = require("./b64"),
    RawDeflate = require("./deflate"),
    Buffer = require("buffer").Buffer,
    crypto = require("crypto");

function decode (str) {
  return RawDeflate.inflate(new Buffer(str, "base64").toString());
}

function md5 (str) {
  return crypto.createHash("md5").update(str).digest("hex");
}

function base64 (str) {
  return new Buffer(str).toString("base64");
}

function deflate (str) {
  return RawDeflate.deflate(str);
}

function encode (str) {
  return base64(deflate(str));
}

var str = "hello, world";
console.log("Testing string: " + str);

console.log("Base64 Test");
console.log(base64(str));
console.log(md5(base64(str)));

console.log("Defalte Test");
console.log(deflate(str));
console.log(md5(deflate(str)));

console.log("Test Encode");
console.log(encode(str));
console.log(md5(encode(str)));

console.log("Test Decode");
console.log(decode(encode(str)));

好吧，JS的算法自己处理自己的结果也是正确的。那么比较以下两边各个步骤的md5，可以发现几个现象：

• 仅仅Base64后MD5便不一致
• 仅仅Deflate后MD5一致
• Deflate后再Base64,结果MD5不一致

那么就是NodeJS的Base64这么算可能不对了，这时我已经凌乱了，算了，干脆找个JS的Base64实现吧。我的大神啊，原来RawDeflate的作者自己也写了个Base64的实现，我觉得这里面有阴谋⋯⋯

用上这位大神的Base64，同时我也发现了RawDeflate里面有一个使用实例。例子里面在Deflate之前，把字符串进行了Base64.utob操作。但是我们用的测试字符是“hello,world”貌似没有非ACSII字符。

那么我们新的编码脚本如下：

var RawDeflate = require("./deflate"),
    Buffer = require("buffer").Buffer,
    fs = require("fs"),
    Base64 = require("./base64");

function encode(str) {
  return Base64.toBase64(RawDeflate.deflate(Base64.utob(str)));
}

console.log(encode("hello, world!"));
fs.writeFileSync("data.txt", encode("hello, world!"));

我们仍然使用之前的解码脚本，结果竟然通过了！ruby得到了“hello,world“！

其中原理不解，有待高人解答，但是灾难还没有结束哦。

RFC1951、RFC1950和RFC1951

因为对方服务器目前使用的是JAVA，那么我必须用JAVA测试才能OK。

JAVA的代码如下，只贴出核心代码吧：

InputStream in = new InflaterInputStream(new Base64InputStream(new FileInputStream(compressed)));

第一次试验的结果是，无法解压的，想哭啊，得到“unknown compression method”的错误。

我开始质疑JAVA的实现了。虽然也是zlib的前缀，但是InflaterInputStream这个类的JavaDoc里却没有写清楚它对应的算法。

我们知道，HTTP传输里面经常会用到gzip、deflate来压缩内容，只用在header里面写明“Content-encoding”。Web服务器和浏览器其实都是相当默契的。好吧，我必须承认，浏览器不愧是Web里面最复杂的软件。因为它handle了太多的东西。

RFC1950是zlib算法，RFC1951是deflate算法，RFC1952是Gzip算法。那么他们是三个独立的算法么？

我以为是，其实不是！

在HTTP 1.1的定义里面，也就是RFC2616是这么定义delfate传输压缩的：

deflate – The “zlib” format defined in RFC 1950 [31] in combination with the “deflate” compression mechanism described in RFC 1951 [29].

原来zlib和deflate是同时使用的！zlib仅仅作为一种容器格式，来承载通过deflate算法压缩的内容。就像AVI其实是个视频容器格式，里面的压缩算法可以是XVID也可以H.262！

回来想想RawDeflate的主页上也仅仅说明是RFC1951的实现，而且人家是”Raw“Deflate，Raw！看来是我自己不懂啊⋯⋯

跟我一样苦逼的人还是不少的，看这个帖子，有一个回复已经给出了JAVA里面的解决方案。

如果要解决单纯使用Deflate压缩的文件，必须传入一个自定义Inflater。

InputStream in = new InflaterInputStream(conn.getInputStream()), new Inflater(true));

更新了JAVA脚本之后，的确问题解决了。顺手把其他语言解码方案也试验出来了。基本上，除了JAVA需要，其他实现都不需要进行额外的判断，所以JAVA实在不是一个敏捷语言啊⋯⋯

Ruby解码实现

require 'base64'
require 'zlib'

def decode(str)
  Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(Base64.decode64(str))
end

File.open("data.txt", "r") do |data|
  str = data.readlines
  p decode str.join
end

Python解码实现

Python在压缩的时候，想得到纯粹的Deflate流也是需要额外的加工的，详见此处：http://stackoverflow.com/questions/1089662/python-inflate-and-deflate-implementations。

Python的解码的实现也很直白：

import zlib
import base64

str = ""
with open("data.txt") as data:
    for line in data:
        print line
        str += line

def decode_base64_and_inflate(str):
    decoded_data = base64.b64decode( str )
    return zlib.decompress( decoded_data , -zlib.MAX_WBITS)

print decode_base64_and_inflate(str)

PHP解码实现

PHP一定要使用gzinflate才能解压纯Deflate流，gzuncompress是用来解压HTTP采用“deflate”方式压缩的数据的！

$data = file_get_contents("data.txt");

echo $data;
echo gzinflate(base64_decode($data));

// this command will throw an exception: data error
// echo gzuncompress(base64_decode($data));

JAVA实现

JAVA实现好累啊，这么罗嗦。还需要一个额外的一个JAR进行Base64操作。这里用的是Apache的Common Codec。

//http://stackoverflow.com/questions/3932117/handling-http-contentencoding-deflate

import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.util.zip.DataFormatException;
import java.util.zip.Inflater;
import java.util.zip.InflaterInputStream;
import java.util.zip.ZipException;

import org.apache.commons.codec.binary.Base64InputStream;

public class Inflate {

    public static void inflate(File compressed, OutputStream out) throws IOException {
        InputStream in = new InflaterInputStream(new Base64InputStream(new FileInputStream(compressed)), new Inflater(true));
        shovelInToOut(in, out);
        in.close();
        out.close();
    }

    /**
     * Shovels all data from an input stream to an output stream.
     */
    private static void shovelInToOut(InputStream in, OutputStream out) throws IOException {
//    The following code should be working but it produces strange suffix like "[B@13fcf0ce" now and then
//        byte[] buffer = new byte[1000];
//        int len;
//        while((len = in.read(buffer)) > 0) {
//            out.write(buffer, 0, len);
//            System.out.println(buffer);
//        }

        String line;
        InputStreamReader isr = new InputStreamReader(in);
        BufferedReader br = new BufferedReader(isr);
        while((line = br.readLine()) != null) {
            out.write(line.getBytes());
        }
    }

    /**
     * Main method to test it all.
     */
    public static void main(String[] args) throws IOException, DataFormatException {
        File compressed = new File("data.txt");
        try {
            inflate(compressed, System.out);
        } catch(ZipException e) {
            System.out.println(e.getMessage());
            throw e;
        }
    }

}

总结

编码问题总是一个挥之不去的阴影！

分析一下我这里的案例，其实是要做以下这些事情（原站点简称A，新站点简称B）：

1. 制作A在B下的镜像
2. 修改B下面的镜像Wordpress中域名设置
3. 对A站相关地址进行转向到B站域名
4. 清理A站的旧文件
5. 在A站和B站上同时发出公告，安抚、告知用户

制作站点镜像

开头很重要，如果你的站点无时无刻有访问量并产生数据，你面临两种选择：1、临时关闭站点，挂出维护通知 2、站点切换后再灌入差量数据。所幸，Wordpress站点往往基本没有实时数据，我的做法是没有关闭原站，而是直接复制数据的。

假设你可以登陆你的服务器，那么直接远程SSH就可以完成对文件的复制，即将wordpress站点的根目录直接复制到新位置。如果不能，那么就通过FTP慢慢拖吧⋯⋯

至于数据库部分，如果安装了phpMyAdmin，可以登陆到管理后台，直接选中数据库，然后在Operation选项卡中有Copy database的功能。

否则就得登陆mysql客户端，执行mysqldump了：

mysqldump [db1] -u root -ppassword --add-drop-table | mysql [db2] -u root -ppassword

切换域名

到这个时候，如果的B站点域名指向和主机配置都正确，访问B站应该被转向了A站，因为B站内部的wordpress设置的域名还是A站的。

切换域名分两方面：

• WordPress配置内部的域名设置
• 文章内容里面的链接内容

对于前者，有两种办法，一种是直接登陆MYSQL，用SQL修改wp-options表的两条纪录，即siteurl和home的option_value。

UPDATE  `wp`.`wp_options` SET  `option_value` =  'new_site_url' WHERE  `wp_options`.`option_name` ='home';
UPDATE  `wp`.`wp_options` SET  `option_value` =  'new_wordpress_url' WHERE  `wp_options`.`option_name` ='siteurl';

或者修改B站下面的wp_config.php，加入如下两句：

define('WP_SITEURL', 'new_wordpress_url');
define('WP_HOME', 'new_site_url');

对A站的地址进行转向

不少注重SEO的同学应该会单行A域名的PR值突然下降，那么我们可以设置nginx或者Apache的主机配置文件对以往链接进行304转向，将伤害降到尽可能小。

server {
    listen 80;
    server_name www.siteB.com;

    index index.php index.html;
    root /var/www/siteB;

    location / {
        error_page 404 = /index.php?q=$uri;
		rewrite ^/(\d+)/(\d+)/(.*)$ http://siteB$request_uri permanent;
    }

}

注意替换rewrite规则中的域名。详细文档：http://wiki.nginx.org/HttpRewriteModule#rewrite。

rewrite后面接受的第一个参数是url中path部分的正则匹配，这个正则应该按照之前wordpress的permanent链接的模式来写，最后一个参数permanent表示是304永久重定向。

注意，如果你是将Wordpress程序在同一个域名中迁移，例如从http://siteA.com/blog/迁移到http://siteA.com/，那么你可以尝试nginx的try_files规则：http://wiki.nginx.org/HttpCoreModule#try_files。

有一篇文章专门降到了利用这个指令来进行同域名不同虚拟目录的迁移：http://michaelshadle.com/2009/03/19/finally-using-nginxs-try-files-directive。

对于文章内部的链接数据，则要再次登陆MYSQL控制台或phpMyAdmin进行操作了。

UPDATE wp_posts SET guid = replace(guid, 'http://www.siteA.com','http://www.siteB.com');
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.siteA.com', 'http://www.siteB.com');

清理旧文件

登陆FTP或者SSH执行文件删除吧，不过个人建议不要删除，把所有文件都备份到另一个目录，带迁移成功后的一两个月之后再考虑是否删除。这样可以避免突发事件时的尴尬。

通知用户

好吧， 在两边都贴上大大的告示吧，以免用户感到困惑⋯⋯

Next…

我更新了另外一篇文章来阐述node里面的一些新加入crypto相关的API：http://pagetalks.com/2012/01/18/more-about-crypto-module-in-nodejs.html

好吧，抱怨完了之后，我们说说现在还有“玩头”的canvas。想必大家都已经看过N多canvas的例子，不管是canvas做的动画还是游戏，都显得十分理想。按下F12，你却发现这些例子的代码是十分的庞大的，证明要操控canvas做一些“有实用性”的事情，是很有难度的。

毕竟，Canvas的API只提供了画点、画线、画圆、画正方形之类的基本接口，简陋的让人难以接受。这个时候的Canvas跟Flash是完全没有可比性的，Flash的Tween、Sprite之类的类已经封装的非常完美，其暴露给开发者的API已经高于Canvas的那些API太多太多。

但另一方面，Canvas也给我们了“制作”Flash的机会。毕竟Flash的底层无非也就是画点、画线的方法。

在这里，我想介绍一下几个比较好的针对Canvas的脚本库。在实际工程中，是绝对救星。

Cake.js

Cake.js是一个非常有魅力的库。首先，它解决了几个让你十分头疼的问题：

• Canvas内部没有对象的概念，没法针对某个图形或形状进行监听等操作
• 浏览器之间的复杂兼容性
• Canvas缺乏动画操作API
• Canvas和SVG不能互转

Cake.js很好了解决了以上所有问题。它不仅提供了Circle、Rectangle之类的基础对象，而且这些对象能够如同DOM对象一样进行监听等操作。其提供了较为高效的动画函数，如同Flash里的TweenLite。
更有趣的是，Cake.js提供了一个SVGParser，支持从SVG绘制Canvas！

如果你要用canvas制作例如游戏之类的高度交互的应用，那么你要么用cake.js，要么自己实现一份cake.js。

大家可以到这里去看看cake.js的一些演示：http://glimr.rubyforge.org/cake/canvas.html

Processing.js

Processing是一个很有名的数据可视化语言，之前的浏览器解决方案一直是利用java applet技术，可惜applet尴尬的局面至今没有能够缓解，所以java applet并不是一个很好像大众分发的技术方案。

但是某人（jQuery的作者之一）实现一个JS版的Processing.js。准确的说应该是一个Processing语言的JS解析器，然后利用canvas展示。

传承了Processing的所有优点。如果你已有Processing的脚本，你是可以直接无痛迁移到Canvas上的。

对于比较了解Processing的朋友，这个库你是绝对需要的。

Pre3D

有的同学可能已经迫不及待用Canvas做3D了。可是Canvas的3D Context的标准都没有，WebGL也还是少数浏览器的特权。退而求其次，就是用2D来模拟3D了。这里面的大部分原理就是坐标的矩阵变幻了，对于Canvas来说，这些操作全部用JS来实现，效率肯定比WebGL之类的C所写的原生3D API低好几个数量级的。但是这是目前唯一可行的方案。

所以这个库的名字叫做“Pre3D”，意味Canvas的3D时代还为来临，是3D的前期。

若是准备做3D图形的展示，这个库可以让你事半功倍；倘若是要做游戏，这个库也是爱莫能助的。

限于技术限制，Pre3D没法追踪你创建的虚拟对象，你无法与它们进行交互。你能有的仅仅是对Camera对象进行rotate、translate之类的操作。

但是这些对于制作出类似CanvasMol应用是错错有余的。

依旧蛋疼

即使你克服了一切利用Canvas来做游戏，你却发现你的游戏在有些浏览器下跑的很慢，在有些浏览器下完全无法使用。

想退回利用DOM进行游戏对象的操作？现在已被正式，canvas对于多个游戏对象的操作也许好于直接操作DOM对象(via link)。

好吧，对于刚刚定稿的HTML5我们要耐心，耐心，再耐心。

Read More

• http://whereisthefold.com/
• http://browsersize.googlelabs.com/

Just enter the URL of a webpage you want to test and that is all. So if you care about web accessibility, you have to check it out:
URL: http://wave.webaim.org/

Read More

Read More

Read More

In this article, I’ve rounded up 10 simple and light weight cms solutions. All of these systems were built with simplicity and ease-of-use in mind.

Read More