关于 iconv UCS-2 中文乱码问题
2013-08-01 15:16
274 查看
//unicode ---> gb2312
function unescape($str) {
$str = rawurldecode($str);
preg_match_all("/(?:%u.{4})|.{4};|\d+;|.+/u",$str,$r);
$ar = $r[0];
//print_r($ar);
foreach($ar as $k=>$v) {
if(substr($v,0,2) == "%u")
$ar[$k] = iconv("ucs-2","gb2312",pack("h4",substr($v,-4)));
elseif(substr($v,0,3) == "")
$ar[$k] = iconv("ucs-2","gb2312",pack("h4",substr($v,3,-1)));
elseif(substr($v,0,2) == "") {
//echo substr($v,2,-1)."<br>";
$ar[$k] = iconv("ucs-2","gb2312",pack("n",substr($v,2,-1)));
}
}
return join("",$ar);
}
今天有用户反馈,表单系统用户提交的数据中文会乱码。测试发现问题出在 iconv 转换上。
iconv('UCS-2', 'GBK', '中文')
Google 搜索发现,原因是 Linux 服务器上 UCS-2 编码方式与 Winodws 不一致。
于是,我改成 iconv('UCS-2BE', 'GBK', '中文') 试试,中文正常了。
比较奇怪的是,本地使用 UCS-2BE 居然也能正常显示,另外,化龙巷上也是 Linux 服务器,并没有设置也能正常处理。
以下是有关两个平台 UCS-2 编码的潜规则:
1, UCS-2 不等于 UTF-16。 UTF-16 每个字节使用 ASCII 字符范围编码,而 UCS-2 对每个字节的编码可以超出 ASCII 字符范围。UCS-2 和 UTF-16 对每个字符至多占两个字节,但是他们的编码是不一样的。
2, 对于 UCS-2, windows 下默认是 UCS-2LE。用 MultibyteToWidechar(或者A2W)生成的是 UCS-2LE 的 unicode。windows记事本可以将文本保存为 UCS-2BE,相当于多了层转换。
3, 对于 UCS-2, linux 下默认是 UCS-2BE。用iconv(指定UCS-2)来转换生成的是 UCS-2BE 的 unicode。如果转换windows平台过来的 UCS-2, 需要指定 UCS-2LE。
4, 鉴于windows和linux等多个平台对 UCS-2 的理解不同(UCS-2LE,UCS-2BE)。MS 主张 unicode 有个引导标志(UCS-2LE FFFE, UCS-2BE FEFF),以表明下面的字符是 unicode 并且判别 big-endian 或 little-endian。 所以从 windows 平台过来的数据发现有这个前缀,不用慌张。
5, linux 的编码输出,比如从文件输出,从 printf 输出,需要控制台做适当的编码匹配(如果编码不匹配,一般和该程序编译时的编码有若干关系),而控制台的转换输入需要查看当前的系统编码。比如控制台当前的编码是 UTF-8, 那么 UTF-8 编码的东西能正确显示,GBK 就不能;同样,当前编码是 GBK, 就能显示 GBK 编码,后来的系统应该更智能的处理好更多的转换了。不过通过 putty 等终端还是需要设置好终端的编码转换以解除乱码的烦恼。
function unescape($str) {
$str = rawurldecode($str);
preg_match_all("/(?:%u.{4})|.{4};|\d+;|.+/u",$str,$r);
$ar = $r[0];
//print_r($ar);
foreach($ar as $k=>$v) {
if(substr($v,0,2) == "%u")
$ar[$k] = iconv("ucs-2","gb2312",pack("h4",substr($v,-4)));
elseif(substr($v,0,3) == "")
$ar[$k] = iconv("ucs-2","gb2312",pack("h4",substr($v,3,-1)));
elseif(substr($v,0,2) == "") {
//echo substr($v,2,-1)."<br>";
$ar[$k] = iconv("ucs-2","gb2312",pack("n",substr($v,2,-1)));
}
}
return join("",$ar);
}
今天有用户反馈,表单系统用户提交的数据中文会乱码。测试发现问题出在 iconv 转换上。
iconv('UCS-2', 'GBK', '中文')
Google 搜索发现,原因是 Linux 服务器上 UCS-2 编码方式与 Winodws 不一致。
于是,我改成 iconv('UCS-2BE', 'GBK', '中文') 试试,中文正常了。
比较奇怪的是,本地使用 UCS-2BE 居然也能正常显示,另外,化龙巷上也是 Linux 服务器,并没有设置也能正常处理。
以下是有关两个平台 UCS-2 编码的潜规则:
1, UCS-2 不等于 UTF-16。 UTF-16 每个字节使用 ASCII 字符范围编码,而 UCS-2 对每个字节的编码可以超出 ASCII 字符范围。UCS-2 和 UTF-16 对每个字符至多占两个字节,但是他们的编码是不一样的。
2, 对于 UCS-2, windows 下默认是 UCS-2LE。用 MultibyteToWidechar(或者A2W)生成的是 UCS-2LE 的 unicode。windows记事本可以将文本保存为 UCS-2BE,相当于多了层转换。
3, 对于 UCS-2, linux 下默认是 UCS-2BE。用iconv(指定UCS-2)来转换生成的是 UCS-2BE 的 unicode。如果转换windows平台过来的 UCS-2, 需要指定 UCS-2LE。
4, 鉴于windows和linux等多个平台对 UCS-2 的理解不同(UCS-2LE,UCS-2BE)。MS 主张 unicode 有个引导标志(UCS-2LE FFFE, UCS-2BE FEFF),以表明下面的字符是 unicode 并且判别 big-endian 或 little-endian。 所以从 windows 平台过来的数据发现有这个前缀,不用慌张。
5, linux 的编码输出,比如从文件输出,从 printf 输出,需要控制台做适当的编码匹配(如果编码不匹配,一般和该程序编译时的编码有若干关系),而控制台的转换输入需要查看当前的系统编码。比如控制台当前的编码是 UTF-8, 那么 UTF-8 编码的东西能正确显示,GBK 就不能;同样,当前编码是 GBK, 就能显示 GBK 编码,后来的系统应该更智能的处理好更多的转换了。不过通过 putty 等终端还是需要设置好终端的编码转换以解除乱码的烦恼。
相关文章推荐
- 关于 iconv UCS-2 中文乱码问题
- php 读取xml的方法 (iconv解决中文乱码问题)
- 关于JFreeChart中的中文乱码问题(转)
- 关于使用IDEA读取txt文件出现中文乱码的问题
- 关于IntelliJ IDEA 控制台中文乱码问题
- 关于PD4ML解决中文乱码的问题
- 关于中文乱码问题的补充,主要正对URL参数有中文的问题。
- 关于java中文乱码问题一些解决方案和经验
- 关于mysql数据库插入数据,不能插入中文和出现中文乱码问题
- 关于J2EE程序servlet中中文乱码问题,jsp页面编码格式的选择
- 关于asp.net中文乱码的问题
- 关于VS控制台输出中文乱码问题
- 关于mysql导入中文乱码问题的理解
- 关于 server.urlencode 中文乱码的问题 asp 和 .net 都说明一下
- 关于jquery ajax 异步请求 中文乱码问题。
- 关于Mysql中文乱码问题该如何解决(乱码问题完美解决方案)
- 关于C++Builder调用MySQL数据库中文乱码问题
- 关于redhat enterprise linux 6.4下oracle11g中文乱码问题总结
- 关于eclipse中java程序中文备注为乱码的问题
- 关于web项目部署到云平台上get方式进行参数传输是中文乱码的问题