PHP对GB编码动态转UTF-8几种方法评测

PHP对GB编码动态转UTF-8几种方法评测(5)          if ($intGB > $intCode) $intStart = $intMid;
         else $intEnd = $intMid;
       }
       $intOffset = 2 + 4 * ($intStart - 1);
       fseek($fileGBU, $intOffset);
       $strBuf = fread($fileGBU, 2);
       $intCode = ord($strBuf{0}) + 256 * ord($strBuf{1});
       if ($intGB == $intCode) {
         $strBuf = fread($fileGBU, 2);
         $intCodeU = ord($strBuf{0}) + 256 * ord($strBuf{1});
         $strRet .= u2utf8($intCodeU);
       } else {
         $strRet .= \"??\";
       }
       $i++;
   } else {
       $strRet .= $strGB{$i};
   }
 }
 return $strRet;
}
把其加到原来的测评程序，对三种方法同时测评2次得到数据（精确到3位小数，单位：秒）：

MySQL方法：0.125
文本文件方法：10.873
二进制文件折半法：0.106

MySQL方法：0.102
文本文件方法：10.677
二进制文件折半法：0.092

可见二进制文件折半法还比MySQL法略有优势。但是上述测评都是对短的地理位置进行转码，如果对较长的文本转码又如何呢？我找来5个Blog的RSS 2.0文件，都是GB2312编码。测评三种方法对5个文件编码耗费的时间，2次测量数据如下（精确到3位小数，单位：秒）：

MySQL方法：7.206
文本文件方法：0.772
二进制文件折半法：5.022

MySQL方法：7.440
文本文件方法：0.766
二进制文件折半法：5.055

可见对长的文本是用文本文件的方法最优，因为转码对照表读入内存后，转码就可以很高效了。既然如此，我们还可以尝试改进一下，把文本文件方法改为：转码对照表从二进制文件gbu.dat读入内存，而不是文本文件。测评数据如下（精度和单位同上）：

从文本文件读入对照表：0.766
从二进制文件读入对照表：0.831

从文本文件读入对照表：0.774
从二进制文件读入对照表：0.833

表明这次改进失败了，从文本文件读入转码对照表更高效。

总结：用PHP对GB编码到UTF-8编码的动态转换，如果每次转换的文本很小，适宜用二进制文件结合折半法转换；如果每次转换的文本较大，适宜用文本文件存储转码对照表，并在转换前一次性把对照表读入内存。