支付宝给出来的示例代码,里面采用的是GBK编码,使用Zend Studio打开以后中文全是乱码.我先是用写字板打开,然后拷贝到记事本中,然后再拷贝到Zend Studio中,这样就实现了将原有代码拷贝过来.

我是直接使用的原有代码,包括各种函数,都是示例代码中所给的,所以遇到的第一个问题就是乱码问题.我仔细的都了源码,按照计算机执行的顺序,一步步往下读,发现了一个问题:

function charset_encode($input,$_output_charset ,$_input_charset ="GBK" ) {

$output = "";

if(!isset($_output_charset) )$_output_charset  = $this->parameter['_input_charset '];

if($_input_charset == $_output_charset || $input ==null) {

$output = $input;

} elseif (function_exists("mb_convert_encoding")){

$output = mb_convert_encoding($input,$_output_charset,$_input_charset);

} elseif(function_exists("iconv")) {

$output = iconv($_input_charset,$_output_charset,$input);

} else die("sorry, you have no libs support for charset change.");

return $output;

}

就是这个函数,找到它以后,在最后一句设置了一个断点,使用Zend Studio进行debug，在这里我发现了，我从drupal中读取出来的字符串，经过这个函数处理以后，就变成了乱码了。

这个发现虽然很小，但是找到了问题的所在。我把整个模块文件改造成了GBK编码，传递到支付宝的字符串恢复了正常，但是模块在后台中的配置出现了乱码。但是我发现，在模块中，使用t函数，里面使用英文，然后再翻译成中文的方式可以解决这个后台问题。而在这个时候，我对从drupal中传到这个模块的字符串作了处理，charset_encode，就是使用的这个函数。那么现在整个问题就解决了，我只需要使用GBK编码的形式来编写这个模块就可以了。而对从drupal中传递到这个模块中的数据作一次转换。

但是觉得这种方式，不够地道，因为drupal中，所有的模块都是采用UTF-8的格式，如果我的模块采用GBK的话，有点别扭。

我很快想到了，如果模块本身采用UTF-8格式，我只需要反转一下函数charset_encode就可以了，两者之间是对称的。所以我决定，模块本身仍然采用UTF-8的形式。

尽管没有采用GBK的形式，但是中间的替换过程没有白费，因为它至少证明了问题时可解得，而且找到了解决的办法。

当然，这个时候还学习了mb_convert_encoding和iconv这两个函数，也算知道PHP中编码之间是如何转换的了。