标签归档:UTF-8

[原] php 5读取非UTF-8编码的文件或网页乱码的解决

php 5的流读取函数好像默认编码是UTF-8,以前在php 4里直接file_get_contents()读取gb2312编码的正常,到了5就乱码了。网上的解决办法说抓取后用iconv()转码。看后我就觉得不对劲:一个是不一定编译了iconv库,更大的问题是编码都跟流转换的时候有关(如果用了iconv实际上php转了两次码:流 -> UTF-8 -> GB2312):这不是白忙乎了吗?

仔细看了下php的文档(不知道大家都是怎么写代码的,其实文档上很清楚啊),上面关于fopen()及file_get_contents()都提到了“默认是UTF-8,但是用户可以用stream_default_encoding()或者用户自定义上下文属性改变编码”(If unicode semantics are enabled, the default encoding of the read data is UTF-8. You can specify a different encoding by creating a custom context or by changing the default using stream_default_encoding().)。于是用stream_default_encoding(‘gb2312’);测试:但是faint的是,这个函数不存在?!似乎php 6才支持。不过天无绝人之路,还有“用户自定义上下文属性”可以用。

经过更仔细的看文档,最后解决了这个问题:

[原]php处理base64编码和Unicode客户端交互的问题

最近才对编码问题真正深入研究。因为我碰到了这个问题:客户端传过来的是对UTF-16的base64编码,而php没有办法正确解码。
有关编码,可以先看看这篇文章:字符,字节和编码
关于UTF-8和UTF-16,可以参考:谈谈Unicode编码,简要解释UCS、UTF、BMP、BOM等名词
有关URL的base64处理,可以参考这篇:通过 URL 传递 base64 编码参数的问题
摘录如下:

一般情况下,URL 中的参数应使用 url 编码规则,即把参数字符串中除了 -_. 之外的所有非字母数字字符都将被替换成百分号(%)后跟两位十六进制数,空格则编码为加号(+)。但是对于带有中文的参数来说,这种编码会使编码后的字符串变得很长。如果希望有短一点的方式对参数编码,可以采用 base64 编码方式对字符串进行编码,但是 base64 编码方式不能处理 JavaScript 中的中文,因为 JavaScript 中的中文都是以 UTF-16 方式保存的。而 base64 只能处理单字节字符,所以不能直接用 base64 对带有中文的 JavaScript 字符串进行编码。但是可以通过 utf.js 这个程序中提供的 utf16to8 来将 UTF-16 编码的中文先转化为 UTF-8 方式,然后再进行 base64 编码。这样编码后的字符串,在传递到服务器端后可以直接通过 base64_decode 解码成 UTF-8 的中文字符串。但是还有个问题需要注意。base64 编码中使用了加号(+),而 + 在 URL 传递时会被当成空格,因此必须要将 base64 编码后的字符串中的加号替换成 %2B 才能当作 URL 参数进行传递。否则在服务器端解码后就会出错。

不过,我对上述的“而 base64 只能处理单字节字符”有疑问,这是base64的标准规定,还是php的缺陷?
如果是php的缺陷,我想应该能写一个针对UTF-16的base64解码函数。这样就不需要客户端来进行UTF16转成UTF8了。

补充:
按照RFC2045的定义,Base64被定义为:Base64内容传送编码被设计用来把任意序列的8位字节描述为一种不易被人直接识别的形式。(The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.)
上面第二篇摘录如下:

UTF-8以字节为编码单元,没有字节序的问题。UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是“奎”还是“乙”?

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表,而是Byte Order Mark。BOM是一个有点小聪明的想法:

在UCS编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前,先传输字符”ZERO WIDTH NO-BREAK SPACE”。

这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little-Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被称作BOM。

UTF-8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF(读者可以用我们前面介绍的编码方法验证一下)。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

也就是说,base64编码必须针对单字节。从这个角度说,是不能对UTF-16的字串进行base64编码操作的。难怪php解码后得到的结果不一致。原来问题不是出在php上。

我又看了客户端base64编码部分的代码,确实是客户端的问题。客户端用了“(const BYTE*)sSrcBuf ”把UTF-16的双字节强制转为BYTE流之后进行base64编码,结果是错误的。难怪我解码以后英文字符之间都有莫名奇妙的“空格”(实际是“00”,但是记事本看网页源代码上的“00”显示成空格)。
实际上是这样的:比如“ABC”,UTF-8字节流是“41 42 43”。而UTF-16则是“41 00 42 00 43 00”,所以“(const BYTE*)sSrcBuf ”之后,“00”就被作为单独的一个字节进行了转码,所以解码以后就还原为UTF-8的字节流“41 00 42 00 43 00”,这时候跟初始的“41 42 43”已经不一致了(print的时候只能打出“A”)。难怪我的SQL会报出“ERROR: unterminated quoted string at or near “‘A” at character”的错,因为数据库读取SQL读到“00”就认为结束了。
这时候我冒出一个想法,要是服务器端解码以后再强制把字节流当做UTF-16转为UTF-8,结果不就一样了吗?
事实证明我的想法是正确的:

最后还有一个问题,UTF-16的BOM不一定是FF FE,也可能是FE FF。这怎么办?要是有ASCII字符还好办,两个两个的找,看“00”是在前还是在后。要是双字节都有内容呢?举上面文章的例子:“奎”的Unicode编码是594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是“奎”还是“乙”?
这个问题单纯改服务器端php没有办法解决。最终的解决办法只有两个:
1)如上面文章所说,客户端UTF-16先转成UTF-8再base64编码,再提交;显示的时候转回UTF-16
2)客户端可以基于UTF-16的字节流base64编码,但是提交的时候要带上“BOM”,即指明是“FFFE”,还是“FEFF”

当然,如果能确定客户端的Unicode的BOM方式,上面的2)也可以不用。
直接在服务器端加上BOM标记进行转码即可。
好像Windows下都是FFFE的,所以可以直接用这个:

[原]php用UTF-8编码总结

前几天说的PostgreSQL ERROR原来是php文件没有UTF-8编码导致的问题。
以前说过如果JS文件不是UTF8会在IE有bug,所以JS代码也要用UTF-8。
还有数据库也都要用UTF-8。
php用UTF-8总结:
1) php文件本身必须是UTF-8编码。不像Java会生成class文件,避免这个问题。
2) php要输出头:header(“Content-Type: text/html; charset=UTF-8”);
3) meta标签无所谓,有header所有浏览器就会按header来解析
4) 所有外围都得用UTF8,包括数据库、*.js、*.css(CSS影响倒不大)
5) 最后,php本身不是Unicode的,所有substr之类的函数得改成mb_substr(需要装mbstring扩展);或者用iconv转码(基本上的linux都装了,没装的话download、tar、make、make install,很简单的)
特别郁闷的:
文件系统函数不支持UTF-8!

听说php6已经内置Unicode支持,以后试一下。

[原] IE在UTF-8下解析JavaScript的bug

莫名其妙的脚本问题,脚本肯定没有写错,在IE中就是报错,在Firefox中一切正常:页面是UTF-8的,脚本用了:

插入页面。
(略去若干抓狂文字。。。。。。)
bianbian.js是ANSI编码的,用记事本保存为UTF-8编码,错误没有了。我觉得是IE的bug:页面是UTF-8编码的,为什么一定要求引用的其他文件也是UTF-8?
下次遇到IE下脚本很奇怪的错误不如看看JavaScript脚本和页面的编码是不是一致。

[原]解决qmail+iGenus webmail中文UTF-8乱码

最近帮忙解决了一个问题(下面的全凭回忆输入,可能拼写上有问题):很古老的qmail+iGenus webmail系统,邮件若是UTF-8编码则显示乱码(缺省编码为GB2312)。主要解决办法就是利用iconv进行转码:
先<?php phpinfo();?>看看有没有iconv模块,如果没有,需要重新编译php(如果iconv系统里没有装,得先安装iconv:去 http://www.gnu.org/software/libiconv/ 下载,
./configure,make,make install),编译php的时候加上 –with-iconv
如果php是静态模块方式和apache绑定的,还得把apache重新编译一下:
./configure –activate-module=src/modules/php4/libphp4.a,make clean,make,make install

然后打开iGenus include目录下的Fun_inc.php,找到Decode_mime()函数,在B和Q解码以后加上

还有一个地方是正文的编码,打开include目录下的Prev_inc.php,找到Decode_text()函数,为了防止出现错误,复制一下Decode_text(),比如Decode_text_my(),并增加一个参数:$Charset。在函数内解析完数据准备写到文件之前转码:

打开iGenus主目录下的prev.php,找到调用Decode_text()的两个地方,改成Decode_text_my(),并增加传递一个参数:$Charset

总结:我看的那个iGenus版本php写得很是糟糕,在那个上面改东西有一种想死的冲动……

[原] 解决UltraEdit在UTF-8编码上的bug

我一直喜欢用UltraEdit,包括写JavaScript、HTML、python、C、JSP等等。不过UltraEdit在UTF-8的处理上有个奇怪的bug。不信你可以试一下:在记事本里输入

保存,比如test.jsp。上面是很正常的一个JSP文件,现在用UltraEdit打开,你发现什么了?
我试了各种各样版本的UltraEdit,中文都是乱码。这是怎么回事呢?
后来我想了一下,用记事本保存的文件默认是ANSI格式的,也就是我们的test.jsp实际并不是UTF-8格式的;而第一行的“charset=UTF-8”只是告诉java我们输出的是UTF-8格式。可怜的UltraEdit看了这行字以为文件也是UTF-8格式的,所以显示都是乱码。我觉得很搞笑,文件格式当然要根据实际文件存储格式来确定,怎么可以反过来呢?所以我觉得是UltraEdit的bug,并写信给UltraEdit。他们的效率真高,我第二天早上就收到回信了,并解决了我这个问题(虽然我觉得他们不默认提供这个设置真是搞笑)。冲着他们的效率,我决定以后买个正版。。。。嗯,跑题了

解决办法就是打开UltraEdit安装路径下的Uedit32.ini(如果没有这个文件,那说明你的UltraEdit版本的ini不是放在安装路径下的,得去C:\Documents and Settings\(登录用户名,默认是Administrator)\Application Data\IDMComp\UltraEdit里面找一下),在[Settings]里加上一句“Detect UTF-8 String=0”即可(bianbian补充:在UltraEdit某版本之后,这个字符串改成了“Auto Detect UTF-8 String=0”;你可以两个都试一下,或者都填上去),意思是禁止UltraEdit检测可能标记UTF-8的字符串,这个选项在“配置”里是没有的(不然我也不会去找他们了,呵呵)。我也建议他们以后在配置里加上这个选项,他们说会考虑,不知道现在的版本里是否已经有了,呵呵。附信件:

Dear Yuelinniao,

Thanks for your message. If you don’t want the charset declaration to be
used to determine whether or not a file is in UTF-8 format there is a
setting you can add to your uedit32.ini file to help with this. If you
open the uedit32.ini file you may add this under the [Settings] section:

Detect UTF-8 String = 0

This will prevent the referenced line from determining if a file is
recognized as being in UTF-8 format. I believe this will help.

Thanks, Troy

bianbian wrote:

> Dear support,
>
> I write to report a bug, which is making me inconvenient.
>
> When I edit a jsp file, first line is like this:
> <%@page language="java" contentType="text/html;charset=UTF-8">
> ~~~~~~
> but the file is saved on disk in ANSI format. Ultraedit maybe thinks
> the file is in UTF-8 format, and all the Chinese words of the file is
> in a state of disorder.
>
> When I take the property “Auto recognize UTF-8 format” off, the file
> is showed correctly. But when I edit another really UTF-8 format file(
> the file
> saved on disk in UTF-8 format), it is wrong again.
>
> So maybe there is a bug when Ultraedit recognizing UTF-8 format (not
> depending on the really format saved on disk)?
>
> Sorry for my poor English.
>
> Best wishes.
> Yours,
> yuelinniao