分析一下我这里的案例，其实是要做以下这些事情（原站点简称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

站点的原来规模是一个SupeSite＋DZ＋XSpace＋UC的组合，虽然采用了开源代码，但在程序上进行了包括模板定制在内的大规模改动。对方没有IT支持，所以我们的沟通成本也很大。整体来说，是一个不大不小的事情。

这个事情的开端是比较痛苦的，他们站点的所有备份文件我都没有，等要到了FTP、DB的备份，时间也过了一天。可想而知，如果这些资料一开始就准备得当，转换是可以在30分钟内完成的平滑过度。对于一个具有一定规模的站点来说，这节省下来的时间是相当宝贵的。这样证明，企业专有的ADMIN还是很重要的。

排除非人为因素，关于系统的过度，Comsenz有很详细的介绍：

http://faq.comsenz.com/viewnews-539

http://faq.comsenz.com/viewnews-504

对于租用虚拟主机的用户，这些内容已经够了，但是Linode是VPS，我们可以用更简单的方法……

该任务有两种思路可以完成它：
1、架设全新的系统，然后恢复数据库以及相关文件（头像、附件等等）
2、拷贝以前的系统文件，恢复数据库，修改相关参数

由于我手上没有以前系统的版本信息，我无法下载相应的程序，而且我也不知道我们之前到底更改了哪些系统代码；所以采取了第二种思路。

更改域名指向

我们首先应该把域名转向给更改了，因为这个是需要时间刷新的，所以最好放在一开始完成。A记录和泛解都应该指向新的IP。

某些服务商是可以提供WEB在线打包的，那么你的站点可以很迅速的把自己打包为压缩文件，之后通过远程服务器对传文件。登陆到VPS之后，用wget命令取得了原来FTP上的压缩包。
wget可以实现很复杂的下载操作，而利用远程服务器获取FTP上的文件只是杀鸡用牛刀。
详细内容可以通过man查询，或是看看这里：http://airwave.blog.hexun.com/4162966_d.html

如果你无法快速拿到原站点的打包，你可以尝试FTP对传，也就是利用FlashFXP打开两个远程FTP，左右对传。总之，尽量避免传送到你的工作站再上传到新服务器，对于动辄上G的FTP备份，这个办法太脑残了。

至于数据库，得到SQL文件之后，可以上传到VPS，登陆mysql的命令行，用source命令导入。当然还有一些适合生产环境的方法，可是对于大多数使用此类开源系统的企业，短短几秒钟的数据库备份时间应该不会产生太大影响。

至此，还算比较顺利。

确保Zend正常

待DNS已经更新了我的域名解析之后，我打开浏览器进行调试，结果发现它提示我没有ZEND：

Attention:Zend Optimizer not Installed

In order to run this software,please install the latest version of freely available Zend Optimizer
您的服务器尚未正确安装运行本软件所需的 Zend Optimizer 软件，请与空间提供商联系。

自己服务器上应该配置了Zend才对，可是为会这样呢？

在Google上找不到什么有用的内容，我直接进入Comsenz的论坛进行搜索了，果真我不是第一个吃螃蟹的人：

http://www.discuz.net/search.php?searchid=2561&orderby=lastpost&ascdesc=desc&searchsubmit=yes

总结一下关于Zend的安装问题：
1、phpinfo出现zend的图表不代表zend被正确配置，需要后面出现详细的zend参数才行

2、注意php和zend的版本对应，zend的安装包里有很多种版本

3、php.ini需要配置正确
参考http://bbs.zendchina.net/viewthread.php?tid=41，该文档是zend的官方文档。

http://www.xinlei.org/article/jishu/415.htm有相关参数的解释

主要设置如下两个参数：
zend_optimizer.optimization_level=15
zend_extension=”/usr/local/Zend/lib/ZendOptimizer.so”

切忌将zend_Optimizer.encoder_loader设置为0，此选项默认为1，这意味着会开启zend的加密解密功能。SupeSite的程序都是经过加密的，所以需要开启zend的解密。（这也是配置zend的主要目的）

4、保证zend的文件夹具有可执行权限
我用root登陆进行的配置，所以没有遇到问题；如果是非root，应该要chmod设置一下。

调整Gzip

接下来打开浏览器，首页是显示到一半浏览器突然自己刷新然后提示：无法显示您尝试查看的页面，因为它使用了无效或者不支持的压缩格式。

这个就比较郁闷了，这个应该是gzip的问题，我的服务器在PHP上已经设置了zlib的压缩。是否是需要禁用supesite的gzip？

在文件里面搜索gzip的选项：

目录下有这么多文件包含gzip，但是很显然只会在一些config文件里面才会有用。
你需要检查这些文件：bbs_settings.cache.php、cache_settings.php、config.cache.php。确保里面的gzipcompress均为0。

再看看系统的配置文件

再测试一下，已经能够正常显示了。就在我以为已经大功告成了的时候，我竟然发现登陆的时候会提示无法链接到数据库！

这就让我郁闷了，因为config.php的数据库信息已经被我更改过了，怎么会无法链接了。再次求助Comsenz的官方论坛，果然我还不是第一个吃螃蟹的人：

http://www.discuz.net/viewthread.php?tid=1370988&highlight=%CA%FD%BE%DD%BF%E2%2B%C7%A8%D2%C6

原因很简单，就是由于是几个组件的整合，你需要更改每个组件的配置文件。
动手搜索文件名包含“config”的文件，需要修改的有三个：
一个是uc的config.ins.php，一个是dz的config.inc.php、最后是ss的config.php。

这些配置文件里面，数据库用户名、数据库密码、数据库名称都是必填的。你还要确保后面的一些域名和IP地址的设置都是正确的，否则整套系统无法整合起来。

修改完后，刷新一下页面，已经可以正常登陆了。其他功能也正常了。

修复死链

这个问题在更换域名之后就会出现。参考了一些网友的意见：http://www.xlbbs.cn/bbs/redirect.php?tid=2685&goto=lastpost。
我发现官方提供了相应的工具来修复：

http://www.discuz.net/thread-618077-1-1.html

注意执行需要事先登陆为管理员，使用完毕候请删除该脚本。
最后一点问题也清除了～呵呵

总结

• 珍惜生命，善用搜索
• 确保你考虑到了所有可能性，尤其是在配置文件的问题上
• 不能忽视日常备份

伟大（而麻烦）的JSP

第一种方法大概就是写一个过滤器：

package com.filter;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServlet;

public class PageEncodingFilter extends HttpServlet implements Filter {

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
request.setCharacterEncoding("UTF-8");
chain.doFilter(request, response);
}

public void init(FilterConfig arg0) throws ServletException {

}

public PageEncodingFilter() {
super();
}

public void destroy() {
super.destroy();
}

public void init() throws ServletException {
}
} 

并设置web.xml文档：

<filter>
<filter-name>PageEncodingFilter</filter-name>
<filter-class>com.filter.PageEncodingFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>PageEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

还有一个escape()编码转换的方法：
在前台传输之前，用JS进行转换:

function enCode(chineseStr) {
        return escape(chineseStr,'utf-8');
}

后台将数据作为普通字符串再进行解码为正常中文：

String XXX= getUrlParameter(unescape(request.getQueryString()),"XXX");

//如此获得的XXX即为解码后的正确的中文

public String getUrlParameter(String str,String targetstr){

          String[] stringarray = str.split("&") ;

            for(int i=0;i
平民PHP
PHP的方法是Blueidea里面的版主指点的，在这里共享一下。其思想主要是在传送之前转换编码：
$send = iconv("UTF-8","GB2312//IGNORE",$data)
就是这样把UTF8转换为了GB2312，PHP我爱你！

这里的“//IGNORE"是为了让PHP忽略该函数转换“—”的错误。

不过这里必须指出该函数需要libiconv的库。类似的还有mbstring库的mb_convert_encoding();

如果你倒霉到环境里什么库都没有，那么手写JSP部分的那个函数吧……
M$的ASP
Gb2312编码页面中加入
 <%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%><%Session.CodePage=936%>
<%Response.charset = "BG2312"%>
utf-8编码页面中加入
<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
<%Session.CodePage=65001%>
<%Response.charset = "utf-8"%>
另附一些常用的codepage：

<%@ codepage=65001%> UTF-8
<%@ codepage=936%> 简体中文
<%@ codepage=950%> 繁体中文
<%@ codepage=437 %> 美国/加拿大英语
<%@ codepage=932 %> 日文
<%@ codepage=949 %> 韩文
<%@ codepage=866 %> 俄文

]]>
			http://pagetalks.com/2008/10/22/irritating-charset.html/feed
		0