自己编译的python2.5居然不支持解析以gb2312形式编码的xml文件

[Darren Lee]

Hi 各位和limodou，

我在一个服务器上需要使用python解析xml文件，但是由于其python版本是2.3版本的 ，所以自己编译了一个
python 2。5版本，编译参数如下：
./configure --prefix=/home/cpro/httpd/python --enable-shared
make && make install
vi ~/.bash_profile 加入 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/
cpro/httpd/python/lib

照理说python2.5应该是支持gb2312编码格式的，但是使用python xml 库时出现一下错误：
xml.parsers.expat.ExpatError: unknown encoding: line 1, column 30
也就是说不支持gb2312。。。。。

[zhaowei]

我印象中，python自带的库就是不支持gb2312的xml解析的吧

2008/7/25 Darren Lee <liya...@gmail.com>:

[wangmao]

很抱歉，我看不过去了，所以虽然我不是limodou还是来回答了。另外提醒你一下，你指定了limodou，别人都会不好意思回答的，至少我只这样的。

2008/7/25 Darren Lee <liya...@gmail.com>

你看看手册里面http://docs.python.org/lib/module-xml.parsers.expat.html的xml.parsers.expat.ParserCreate,很明显它是支持指定encoding的。你也许是使用了其它的库，间接得使用了xml.parsers.expat,不过根据你给出的消息我只能给你这个回到。
另外如果你觉得研究那些库如何设定encoding非常麻烦，我建议你写个脚本把它们编码转换成utf8，然后你就不用考虑那么多了。现在提倡utf8啊。

也就是说不支持gb2312。。。。。

[Yingbo Qiu]

用 libxml2 or 基于它封装的 lxml

[Darren Lee]

谢谢。我来提供点更详细的信息吧。

python lib 库能找到gb2312的文件：

cp...@zjm-testing-ecom513.zjm.baidu.com:/home/cpro/httpd/python/lib/
python2.5/encodings]$ ls | grep gb
gb18030.py
gb18030.pyc
gb18030.pyo
gb2312.py
gb2312.pyc
gbk.py
gbk.pyc
gbk.pyo


xml文件如下：
<?xml version="1.0" encoding="gb2312"?>
<site_info>
<sign1>3673230672</sign1>
<sign2>3660067230</sign2>
<cuint1>171092</cuint1>
<cuint2>128</cuint2>
</site_info>


用的python 自带的minidom 举个例子（其实使用xml.etree.ElementTree也不会出现同样的错误），演示如下：
>>> import xml.dom.minidom
>>> dom = xml.dom.minidom.parse("small.xml")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/cpro/httpd/python//lib/python2.5/xml/dom/minidom.py",
line 1913, in parse
return expatbuilder.parse(file)
File "/home/cpro/httpd/python//lib/python2.5/xml/dom/
expatbuilder.py", line 924, in parse
result = builder.parseFile(fp)
File "/home/cpro/httpd/python//lib/python2.5/xml/dom/
expatbuilder.py", line 207, in parseFile
parser.Parse(buffer, 0)

xml.parsers.expat.ExpatError: unknown encoding: line 1, column 30

另外，我在自己本机mac osx 上操作时(这个系统自带python2.5),可以正常解析gb2312的东西

另外，本人不想使用libxml2，想直接使用ElementTree，因为用它很容易把xml文件解析成python 自带的dict数据类型，这样
我就可以用django的模板语言中直接操作该dict了

谢谢
欢迎大家不吝赐教

On 7月25日, 上午11时18分, wangmao <lwm3...@gmail.com> wrote:
> 很抱歉，我看不过去了，所以虽然我不是limodou还是来回答了。另外提醒你一下，你指定了limodou，别人都会不好意思回答的，至少我只这样的。

> 2008/7/25 Darren Lee <liyang...@gmail.com>

>
> > Hi 各位和limodou，
>
> > 我在一个服务器上需要使用python解析xml文件，但是由于其python版本是2.3版本的 ，所以自己编译了一个
> > python 2。5版本，编译参数如下：
> > ./configure --prefix=/home/cpro/httpd/python --enable-shared
> > make && make install
> > vi ~/.bash_profile 加入 export
> > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/
> > cpro/httpd/python/lib
>
> > 照理说python2.5应该是支持gb2312编码格式的，但是使用python xml 库时出现一下错误：
> > xml.parsers.expat.ExpatError: unknown encoding: line 1, column 30
>
> 你看看手册里面http://docs.python.org/lib/module-xml.parsers.expat.html
> 的xml.parsers.expat.ParserCreate,很明显它是支持指定encoding的。你也许是使用了其它的库，间接得使用了
> xml.parsers.expat,不过根据你给出的消息我只能给你这个回到。
> 另外如果你觉得研究那些库如何设定encoding非常麻烦，我建议你写个脚本把它们编码转换成utf8，然后你就不用考虑那么多了。现在提倡utf8啊。

> **
>
>
>
> > 也就是说不支持gb2312。。。。。

[Yingbo Qiu]

python2.5 支持 gb2312 or gb18030 说的是它支持字符串到unicode的转换

但处理 xml 包的这部分，并不能处理 GB 编码的 XML.

lxml 是一个 python 的对 libxml2 的封装，我记得是有兼容 ElementTree 接口的

[kernel1983]

把gb2312转成unicode, 再把unicode转成utf8, 然后把转换好的代码送到你要送的地方去处理

多写两行代码罢了

[kernel1983]

utf8strng = gb2312string.decode('gb2312').encode('utf8')

其实也可以写成一行的

[Yingbo Qiu]

2008/7/25 kernel1983 <kerne...@gmail.com>:

> utf8strng = gb2312string.decode('gb2312').encode('utf8')
>
> 其实也可以写成一行的
>
> On 7月25日, 下午6时25分, kernel1983 <kernel1...@gmail.com> wrote:
>> 把gb2312转成unicode, 再把unicode转成utf8, 然后把转换好的代码送到你要送的地方去处理

我想问题的核心可能是，他要处理的 XML 文档有 UTF-8 编码的，也有 GB2312 编码的

[Jiahua Huang]

2008/7/25 Darren Lee <liya...@gmail.com>:
> 照理说python2.5应该是支持gb2312编码格式的

OT: 请不要再使用 gb2312,

拜微软所赐，国内的 gb2312 实际上都是 gb18030。

而 python 的 gb2312 并没有"微软化"为 gb18030 的别名，
python 的 gb2312 对付"微软化"的 gb2312 (其实是 gb18030) 会出错的。

坚持不改的话，就迁就微软也做别名吧
import encodings; encodings.aliases.aliases['gb2312']='gb18030'

[Jiahua Huang]

2008/7/25 Yingbo Qiu <qiuy...@gmail.com>:

> 我想问题的核心可能是，他要处理的 XML 文档有 UTF-8 编码的，也有 GB2312 编码的
>

恩，虽说建议统一 utf8,
可还是有人混杂 gb，
gnome.org 上的中文网页就曾经头部 utf8,文章正文却有 gb18030

[Her0]

其实微软使用的是gbk。18030是后来国标进行的标准化兼容gbk和gb2312。很多电脑在18030标准刚执行的时候都是在预装的系统gbk的
情况下提供18030语言包！微软本身没有什么错吧？xpsp2以后就都是18030了吧？只是有大量的的老电脑还在继续使用gbk。
用gb18030处理gbk的文件没有问题不是微软自作聪明的默认！要怪也只能怪国家标准化工作者拿工资不干活。

On Jul 25, 7:20 pm, "Jiahua Huang" <jhuangjia...@gmail.com> wrote:
> 2008/7/25 Darren Lee <liyang...@gmail.com>:

[Jiahua Huang]

2008/7/25 Her0 <react...@gmail.com>:
> 用gb18030处理gbk的文件没有问题不是微软自作聪明的默认！要怪也只能怪国家标准化工作者拿工资不干活。

不，你理解错了。

gbk 是 gb2312 的超集， gb18030 是 gbk 的超集，
这里的问题不是你以为的向下兼容性，

而是 微软改掉了 gb2312 和 gbk，
微软的 gb2312 和 gbk 都是映射到 gb18030 的。

因为微软的 gb2312 超过了真正 gb2312 的字符集，
许多人就将超出 gb2312 范围的 gb18030 内容也标设为 gb2312,
还以为自己没问题。

但是到了非微软的地方，他们的"gb2312"文件就会出错了。

[Zoom.Quiet]

2008/7/25 Her0 <react...@gmail.com>:

> 其实微软使用的是gbk。18030是后来国标进行的标准化兼容gbk和gb2312。很多电脑在18030标准刚执行的时候都是在预装的系统gbk的
> 情况下提供18030语言包！微软本身没有什么错吧？xpsp2以后就都是18030了吧？只是有大量的的老电脑还在继续使用gbk。
> 用gb18030处理gbk的文件没有问题不是微软自作聪明的默认！要怪也只能怪国家标准化工作者拿工资不干活。
>

非常接近事实的8卦:
http://blog.cathayan.org/item/1000

其实要怪只能怪标准化化官员的家属都是M＄用户，天天唠叨也只好先迁就了...

> On Jul 25, 7:20 pm, "Jiahua Huang" <jhuangjia...@gmail.com> wrote:
>> 2008/7/25 Darren Lee <liyang...@gmail.com>:
>>
>> > 照理说python2.5应该是支持gb2312编码格式的
>>
>> OT: 请不要再使用 gb2312,
>>
>> 拜微软所赐，国内的 gb2312 实际上都是 gb18030。
>>
>> 而 python 的 gb2312 并没有"微软化"为 gb18030 的别名，
>> python 的 gb2312 对付"微软化"的 gb2312 (其实是 gb18030) 会出错的。
>>
>> 坚持不改的话，就迁就微软也做别名吧
>> import encodings; encodings.aliases.aliases['gb2312']='gb18030'

--

http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''

[Her0]

gb是国标必须执行的阿！特别是一些军工政府的采购项目你用utf8是没问题。可不符合国家标准。

在说utf8多浪费空间阿！我的观点，让你的系统支持utf8。但是还是采用gb18030吧用18030没有在简体中文领域不会有编码问题。不浪费空
间。符合标准！至于这个xml解析库的问题我想人家出库的人既然了解到了18030当然就不需要画蛇添脚的再弄些gbk gb2312了阿！本质上
gb2312是gbk的子集。gbk是18030的子集。支持了18030你就只需要在系统中定义别名就ok了！

支持但不使用utf8。 支持国家标准，节约信息资源。来大家一起喊口号！望了说了utf是gbk的超集，但是码长都变了可别以为可以用utf8别名取
代一串gb标准哦！那样是肯定不行的

On Jul 25, 7:22 pm, "Jiahua Huang" <jhuangjia...@gmail.com> wrote:
> 2008/7/25 Yingbo Qiu <qiuyin...@gmail.com>:

[Jiahua Huang]

2008/7/25 Her0 <react...@gmail.com>:
> gb是国标必须执行的阿！特别是一些军工政府的采购项目你用utf8是没问题。可不符合国家标准。

是说必须满足 gb18030 字符集，
没说编码不能是 unicode。

像国家去年弄的超大字符集字库就也是 unicode 的。

gb18030 编码的字符集只到 unicode3.0，
我国香港的字就没有包含在我国国标里边，
所以 gb18030 作为我国编码是不堪用的。

[Darren Lee]

各位，想不到我的帖子会引来这么大家激烈的讨论。

其实我的问题很简单，为什么同样的xml文件，用相同的方法，mac osx 可以解析，而我自己编译的python 2.5不可以解析（注意我是在
linux服务器上编译的）

linux的版本为：REDHAT 的 AS4
内核版本为：2.6.9-52bs #2 SMP Fri Jan 26 13:34:38 CST 2007 x86_64 x86_64
x86_64 GNU/Linux
在bash里输入env 的结果如下：
LANG=en_US

我知道转换为utf8 可以很省事，不过公司内部用的就是gbk编码，因为gbk省硬盘空间。

[Her0]

翻了一个错误！我查了详细的资料！原来我一直错了！这个错误犯的值得！今天晚上完全弄清楚了！

UTF8并不算是一种电脑编码，而是一种储存和传送的格式。
套用官方网站的首句话『UTF-8 stands for Unicode Transformation Format-8. It is an
octet (8-bit) lossless encoding of Unicode characters.』，由于UTF也适用于编码UCS，
故亦可称为『UCS transformation formats (UTF)』

　　UTF8是以8bits即1Bytes为编码的最基本单位，当然也可以有基于16bits和32bits的形式，分别称为UTF16和UTF32，
但目前用得不多，而UTF8则被广泛应用在文件储存和网络传输中。

UCS-4 是一个更大的尚未填充完全的31位字符集，加上恒为0的首位，共需占据32位，即4字节。理论上最多能表示
2,147,483,648(2的31次方)个字符，完全可以涵盖一切语言所用的符号。

目前通用的实现方式是 UTF-16小尾序（BOM）、UTF-16大尾序（BOM）和 UTF-8。在微软公司Windows XP操作系统附带的记
事本中，"另存为"对话框可以选择的四种编码方式除去非 Unicode 编码的 ANSI 外，其余三种"Unicode"、"Unicode
big endian"和"UTF-8"即分别对应这三种实现方式。

以UTF8格式储存的文件档首标识为EF BB BF

目前辅助平面的工作主要集中在第二和第三平面的中日韩统一表意文字中，因此包括GBK、GB18030、Big5等简体中文、正体中文、日文、韩语以及
越南字喃的各种编码与 Unicode 的协调性被重点关注。考虑到 Unicode 最终要涵盖所有的字符，从某种意义而言，这些编码方式也可视作
Unicode 的出现于其之前的既成事实的实现方式，如同ASCII及其扩展Latin-1一样，后两者的字符在16位 Unicode 编码空间中
的编码第一字节各位全为0，第二字节编码与原编码完全一致。但上述东亚语言编码与 Unicode 编码的对应关系要复杂得多。

在非 Unicode 环境下，由于不同国家和地区采用的字符集不一致，很可能出现无法正常显示所有字符的情况。微软公司使用了代码页
（Codepage）转换表的技术来过渡性的部分解决这一问题，即通过指定的转换表将非 Unicode 的字符编码转换为同一字符对应的系统内部使用
的 Unicode 编码。可以在"语言与区域设置"中选择一个代码页作为非 Unicode 编码所采用的默认编码方式，如936为简体中文
GBK，950为正体中文Big5（皆指PC上使用的）。在这种情况下，一些非英语的欧洲语言编写的软件和文档很可能出现乱码。而将代码页设置为相应语
言中文处理又会出现问题，这一情况无法避免。从根本上说，完全采用统一编码才是解决之道，但目前上无法做到这一点。

代码页技术现在广泛为各种平台所采用。UTF-7 的代码页是65000，UTF-8 的代码页是65001。

XML及其子集HTML采用UTF-8作为标准字集，理论上我们可以在各种支持XML标准的浏览器上显示任何地区文字的网页，只要电脑本身安装有合适的
字体即可。可以利用&#nnn;的格式显示特定的字符。nnn代表该字符的十进制 Unicode 代码。如果采用十六进制代码，在编码之前加上x字符
即可。但部分旧版本的浏览器可能无法识别十六进制代码。


On Jul 25, 6:31 pm, "Yingbo Qiu" <qiuyin...@gmail.com> wrote:
> 2008/7/25 kernel1983 <kernel1...@gmail.com>:

[Her0]

Macintosh机和PC机上对字节顺序的理解是不一致的。这时同一字节流可能会被解释为不同内容，如编码为 U+594E 的字符"奎"同编码为
U+4E59 的"乙"就可能发生混淆。所以编码统一用utf8吧就没有utf16那么多麻烦了！ 字符集用gb18030是和unicode兼容的。
首位0自动识别！

参与讨论我才学的透彻嘛！我可能所最不怕犯错的maillist用户了。可能有大侠会觉得恼火。嘿嘿

[Darren Lee]

刚在fedora 8 下用了一下，发现也不可以....，相当奇怪。
我用c 语言版本的libxml2 的dom方式是可以正常解析这些gb2312编码的xml文件的阿

[Her0]

还没明白吗？和你的encoding设置没关系！你的问题和你的编辑器设置有关！如果使用utf16就可能所mac和x86的字节序列的问题！

huang同学正解！不过对微软这个问题上可能真的不是微软的错。

[Darren Lee]

无论用了什么编辑器，
最后我都使用了iconv 进行了编码转换，转成了gb2312了。。。。。。。

[MuSheng]

我的習慣是載入python後統一轉成unicode，具體化保存到文件時用GB18030。
不過，對於跨中文平台處理還更麻煩，正在頭痛中，暫時還找不到用純python的解決辦法。

[Darren Lee]

OK,那我就按照这种方式做吧,也就是用string.decode("string").encode()来转成utf8在内存后再做操作?
不过一个小问题:
由于xml文件头里面声明了encoding='gb2312',我虽然把字符编码转成了utf8,是不是我还需要用正则把gb2312 替
换成utf-8吗?还是有参数可以忽略xml的头信息,强制指定编码类型呢?

[Kevin wu]

为何不直接统一的使用UTF-8的格式呢？

On 7月25日, 下午6时25分, kernel1983 <kernel1...@gmail.com> wrote:

[Jiahua Huang]

2008/7/26 Kevin wu <Eric.W...@gmail.com>:
> 为何不直接统一的使用UTF-8的格式呢？
>
她/他公司内部要求 gb

[yuting cui]

我看不下去了...
xml.parsers.expat用的是expat...
就像前面Yingbo Qiu说的那样...这个不支持gb2312编码...
Python库参考手册ParserCreate说明文档里白纸黑字写着"Expat doesn't support as many
encodings as Python does, and its repertoire of encodings can't be
extended; it supports UTF-8, UTF-16, ISO-8859-1 (Latin1), and
ASCII."都没人理...
听说可以用4Suite试试 ( http://sourceforge.net/projects/foursuite )

[maple]

s.decode('gb2312').encode('utf-8').replace('gb2312', 'utf-8')

[Darren Lee]

Good answer