之前写过《打包修改过的文件的批处理》，现在这个批处理脚本已经过多次修改，增加了很多功能，新脚本代码如下:

@echo off
:: 网站更新文件打包程序
:: 作者: Mr.Lodar http://lodar.net/

:: 版本历史:
::
:: v2.4  2011年01月11日  随机临时目录
::                       防止多个批处理同时运行时产生冲突
:: v2.3  2011年01月11日  自动配置7-Zip安装目录
::                       自动检测7-Zip的安装目录，不需要再手工配置路径
:: v2.2  2010年12月03日  增加PATH环境变量设置
::                       在系统环境变量未加入7-Zip时不用复制程序文件到当前目录
:: v2.1  2010年11月16日  增加批打包支持 - 多个目录同时拖放并分别打包
::                       增加判断有修改的文件时才打包，不再生成空压缩包
:: v2.0  2010年11月16日  新增拖放打包支持 - 将目录拖放到脚本文件上自动打包
::                       (为了支持快速批打包，拖放模式只默认打包当天修改的文件)
:: v1.0  2010年06月某日  初始版本，实现了文件排除及默认值设置

:: 拖放到图标上执行的时候程序启动路径为用户目录
:: 如: "C:\Documents and Settings\User"
:: 这里把当前目录设置回批处理脚本所在目录
cd /d %~dp0

:: 检索7-Zip安装目录
for /f "tokens=2*" %%i in (
	'REG QUERY "HKLM\SOFTWARE\7-Zip" ^| find /i "Path"'
) do set "SevenZipPath=%%j"

:: 设置7-Zzip路径
SET PATH=%PATH%;%SevenZipPath%

:START
:: 设置临时目录:
set TEMP=temp_%random%

if not @%1@==@@ (
	set FROM=%~n1
) else (
	set /P FROM=源文件目录^(默认为www^):
	set /P TO=导出压缩包文件名^(默认为%FROM%-update-%date:~0,4%%date:~5,2%%date:~8,2%^):
	set /P DAY=修改时间^(m-d-y，默认为今天{%date:~5,5%-%date:~0,4%}^):
)

:: 设置变量默认值
if @%FROM%@==@@ set FROM=www
if @%TO%@==@@ set TO=%FROM%-update-%date:~0,4%%date:~5,2%%date:~8,2%
if @%DAY%@==@@ set DAY=%date:~5,5%-%date:~0,4%

:: 将要打包的文件复制到临时文件夹，将排除文件列表(excludelist.txt)中的文件排除在外
xcopy %FROM% %TEMP% /S /Y /I /D:%DAY% /EXCLUDE:excludelist.txt

IF EXIST %TEMP% (
	:: 使用7z命令行程序进行打包
	7z a -t7z %TO%.7z .\%TEMP%\*

	:: 删除临时文件
	rmdir /S /Q %TEMP%

	echo 文件已打包到 %TO%.7z
) else (
	echo %~n1 中没有需要打包的文件
)

:: 重置变量，防止默认值被设置为上次使用的值
set FROM=
set TO=
set DAY=
set TEMP=

:: 如果有更多目录要打包，则继续重新打包其它目录
if not @%2@==@@ shift && goto START

echo.

if @%1@==@@ (
	echo 打完收工! 按任意键退出...
	pause>nul
) else (
	echo 打完收工! 一会就退出...
	ping 127.0.0.1 -n 3 >nul
)

提示: 不要忘了 excludelist.txt 哦，参见之前的那篇文章《打包修改过的文件的批处理》。

前言

WordPress 从 2.x 升级到了 3.0.1，又恰逢更换了主机，从原来Windows的主机切换到了Linux主机上。

惨剧

某天在后台发现有插件可以更新了，于是点了自动更新，然后杯具的事情发生了，自动更新失败，以为是权限问题，登上FTP，到处查看修改权限，无果，于是念叨这主机是不是有问题，不能通过它访问网络？是不是差劲了点？然后手动上传覆盖了好几个插件的更新……

再过了几天，发现模板不支持3.0的菜单功能，于是换了模板，加入菜单，又发现了问题，新建菜单可以成功，但是不能修改，每次修改都失败……

随即要添加文章，新的问题又来了，新添的文章会自动生成固定链接，因为觉得固定链接生成的不是很好，想修改掉，结果也不能修改……

这下可让我烦起来了，想想肯定是哪里出问题了，静下心想了想，后台凡是Ajax的操作均无响应，并且数据也没有更新，之前出问题的部分都涉及Ajax，是不是这里出问题了?

上帝保佑

马上开启Firefox，用Firedebug查看XHR数据，发现admin-ajax.php返回HTTP响应头为

HTTP/1.1 500 Internal Server Error

很明显，后台程序运行出错了，WP本身应该不会烦这么低级的错误，我又没改过后台的代码，那么应该是插件引起问题无疑了，在wp-config.php文件中激活调试

define('WP_DEBUG', true);

然后在错误日志文件中找到了一些与插件文件相关的错误，将这些插件逐个禁用/启用排查问题，结果发现只要将“Wordpress Thread Comment”插件(作者:偶爱偶家)禁用之后这些Ajax操作就都正常了，所以确定该问题是由“Wordpress Thread Comment”插件导致

PS: 今天(2011年1月8日)升级及添加了些插件，发现又出了这个问题，这次查出来是“All in One SEO Pack”这个插件导致，抱着试试看的态度重新启用“Wordpress Thread Comment”插件，发现又可以用了……

结局

就这样，之前所有的问题(包括自动更新的问题)就都解决了，不兼容插件惹的祸啊~ 差点错怪主机提供商了，汗~~

问题描述：

有时候装了一些开机自启动的程序，在系统启动的时候有些就会在系统托盘区添加一个图标方便操作，有些情况下开机以后发现图标只显示了一部分，还有一些没有显示出来，字体注销重新登录后能显示出来，但是重启计算机以后问题依旧，是个非常奇怪的问题，居然是UPnP设备发现服务造成的。

解决方法：

控制面板的管理工具里面打开“服务”，或者在“开始”→“运行”（WinKey+R）中输入“service.msc”（不带引号） ，找到名称为“SSDP Discovery Service”的服务（即UPnP设备发现服务），选择右键→属性，启动类型改为“已禁用”，然后停止该服务，然后重新启动计算机，你会发现一切正常了。

问题描述：

这种情况通常出现在Java程序、Gtk程序之类非Windows原生的程序(Native App)中，比如OpenOffice.org的菜单栏、FreeMind的菜单栏、还有基于QT库的Vidalia的系统托盘通知区图标的弹出菜单等，原因是因为安装了第三方主题等使系统菜单字体设置成8号“Tahoma”适合英文显示的字体却影响了汉字的显示效果。

解决方法：

桌面右键→属性，切换到外观选项卡，点击“高级”按钮，在弹出的对话框中的项目中选择“菜单”，然后调整字体大小，一般中文字体设为9较为合适，推荐使用9号“Tahoma”字体，如果其他项目字体显示有问题也可以到这里更改为9号”Tahoma”，或者索性把所有的字体全部改成9号”Tahoma”，当然，也可以使用你自己喜欢的字体。

问题描述：
使用 nosoap_client 类创建了一个客户端 SOAP 对象，然后从 $client->call 方法传回UTF-8编码的中文数据时，所有的中文数据均显示为问号（nusoap 版本为 0.9.5）

问题原因：
nusoap_client 的 decode_utf8 属性默认设置为 true，导致默认对UTF-8数据进行转码，在 nusoap 中的具体调用过程如下：

class.soapclient.php 中的 nusoap_client 的 parseResponse 在解析返回的数据时使用了 nusoap_parser 类

		$parser = new nusoap_parser($data, $this->xml_encoding, $this->operation, $this->decode_utf8);

class.soap_parser.php 中 soap_parser 类的 character_data 方法中又调用了utf8_decode进行了转码

		if ($this->xml_encoding=='UTF-8'){
			// TODO: add an option to disable this for folks who want
			// raw UTF-8 that, e.g., might not map to iso-8859-1
			// TODO: this can also be handled with xml_parser_set_option($this->parser, XML_OPTION_TARGET_ENCODING, "ISO-8859-1");
			if($this->decode_utf8){
				$data = utf8_decode($data);
			}
		}

解决方法：
在使用 $client = new nusoap_client() 创建了对象之后马上设置 decode_utf8 为 false;

设置方法如下：

$client->decode_utf8 = false;

或

$client->decodeUTF8(false);

补充：
又遇到一则因服务端输出信息编码不匹配，导致 NuSOAP XML Parser 以’ISO-8859-1’编码解析而出错的问题，NuSOAP 库相关部分代码在 class.nusoap_base.php 中，具体位置如下：

    /**
	* charset encoding for outgoing messages
	*
	* @var      string
	* @access   public
	*/
    var $soap_defencoding = 'ISO-8859-1';
	//var $soap_defencoding = 'UTF-8';

解决方法:

$client->soap_defencoding = 'utf-8';	# 仅比上述问题增加该项设置
$client->xml_encoding = 'utf-8';	# 默认值
$client->decode_utf8 = false;

参考链接:
http://blog.csdn.net/mynamesucks/archive/2006/05/26/756480.aspx
http://lhx1026.javaeye.com/blog/506092
http://plog.longwin.com.tw/programming/2010/03/16/php-soap-nusoap-client-2010