iterparse和unicode

似乎xml.etree.celementtree.iterparse()并不意识到:
....打印Elem.Text
...
Trackback(最近的最新电话):
文件" ",第1行,<模块>
文件" ",第64行,在__ITER__
UnicenCodeError:" ASCII"编解码器无法在位置编码字符
6-15:序列不在范围内(128)
我是错误地使用它还是当前不支持Unicode?
乔治

# 回答1


8月21日,上午8:36,乔治·萨基斯(George Sakkis)<乔治·萨克(George.Sak)...
...打印Elem.Text
...
Trackback(最近的最新电话):
文件" ",第1行,<模块>
文件" ",第64行,在__ITER__
UnicenCodeError:" ASCII"编解码器无法在位置编码字符
6-15:序列不在范围内(128)
我是错误地使用它还是当前不支持Unicode?
嗨,乔治,
无论如何,我都不是XML大师,但据我了解,您会
需要将文本编码到UTF-8中,并预处类似' 版本=" 1.0" encoding =" utf-8" standalone =" yes"?>'.出现
成为XML的方式,而不是元素的问题.
例如.
....打印elem.tag,reter(elem.text)
...
名称u'\ u03a0 \ u03b1'
数字'01234567'
包装器无
hth,
约翰
# 回答2


乔治·萨基斯(George Sakkis)在2008-08-20周三15:36 -0700上写道:
...打印Elem.Text
...
Trackback(最近的最新电话):
文件" ",第1行,<模块>
文件" ",第64行,在__ITER__
UnicenCodeError:" ASCII"编解码器无法在位置编码字符
6-15:序列不在范围内(128)
我是错误地使用它还是当前不支持Unicode?
乔治
-http://mail.python.org/mailman/listinfo/python-list
正如iterparse所期望的一个实际文件作为输入一样,使用Unicode字符串为
有问题.如果要使用iterparse,最简单的方法是
在将字符串插入到Stringio对象中之前,请编码您的字符串,如:
•对于事件,elem在iterparse(stringio(s.encode('utf8'))中):
....打印Elem.Text
...
如果使用UTF-8编码,则不必担心 位如前所述,因为它是XML的默认值.
如果您广泛使用Unicode,则应考虑使用LXML,
哪个实现与ElementTree相同的接口,但处理Unicode
更好(尽管它也不会在上面没有先行的示例
编码字符串):http://codespeak.net/lxml/parsing.ht...nicode-sintrings
您可能还会发现目标解析器界面更多地接受
Unicode比IterParse,尽管它需要不同的解析接口:http://codespeak.net/lxml/parsing.ht...rser-interface
- -
John Krukoff
土地所有权担保公司
# 回答3


谢谢你们的建议.我做了更多实验
了解Iterparse在三个维度方面的行为:
一个.编码是否在标题中声明(如果有)?
b.文本ASCII可以编码(即在范围内(128))?
C.传递的文件对象的read()方法返回str或un iCode
(例如,codecs.s.open(f,encoding ='utf8'))?
如果我误解了实际发生的事情,请随时纠正我.
正如约翰·克鲁科夫(John Krukoff)提到的那样,省略编码等同于
对于所有其他组合,编码=" UTF-8".这离开了(b)和(c).
如果文本节点是ASCII i-ipodable,iterparse()将其返回为字节
字符串,不论已声明的编码和输入文件的
read()返回类型.
(c)仅当文本节点不可用ASCII i-Enode时才与之相关.在
如果基础文件的read()
在匹配的编码中返回字节(或至少是兼容的)
使用)已声明为标题中的编码(或隐含的UTF8).
传递一个文件对象,其read()返回Unicode字符
隐式编码它们为ASCII,该ASCII升级了UnicenCodeError
由于文本节点不可用ASCII编码.
有趣的是,元素文本成功后属性
解析不一定具有相同的类型,即全部是str或全部
Unicode.我从Beautifutsoup移植了一些文本提取代码(
将所有文本处理为Unicode),我很惊讶地发现
xml.etree返回的文本类型也不固定,即使在同一中
文件.尽管这不是错误,但收集的字节和
来自同一来源的Unicode字符串使我有些不安.
乔治
# 回答4


乔治·萨基斯(George Sakkis)写道:
iterparse解析XML文档. XML文档是编码的流
字符,而不是Unicode字符的流.
# 回答5


乔治·萨基斯(George Sakkis)写道:
花时间研究不确定的行为是毫无意义的.等
解析器期望字节流,因为这就是XML文件.如果你
传递其他任何内容,ET实施可能会尝试将其转换
字节字符串的事情,运行游戏"流氓"或做其他事情
它发现合适.
如果您不关心记忆和执行性能,则有
大量的工具包可以保证您始终获得Unicode字符串.
# 回答6


8月21日,1:48*am,fredrik lundh <弗雷德...@pythonware.comwrote:
如果您不关心记忆和执行性能,则有
大量的工具包可以保证您始终获得Unicode字符串.
只要记录下来,两种方法都可以使用
案例.目前,我在
ElementTree是"所有字符串都可以是Unicode字符串,也可以是8位
仅包含US-ASCII的字符串." [1],这很模棱两可;
至少我会读它,因为"所有字符串都是Unicode或所有字符串都是8位
字符串",不是同一树中两者的潜在混合物.
问候,
乔治
[1] http://effbot.org/zone/element.htm
# 回答7


乔治·萨基斯(George Sakkis)写道:
如果您不关心内存和执行性能,则有很多工具包可以保证您始终获得Unicode字符串.

只要记录下来,两种方法都可以使用
案例.目前,我发现有关您的唯一参考 nicode in
ElementTree是"所有字符串都可以是Unicode字符串,也可以是8位
仅包含US-ASCII的字符串." [1],这很模棱两可
在py2.x中,它不是歧义
兼容的.无需感到"不安". :)
Stefan

# 回答8


乔治·萨基斯(George Sakkis)写道:
...打印Elem.Text
...
Trackback(最近的最新电话):
文件" ",第1行,<模块>
文件" ",第64行,在__ITER__
UnicenCodeError:" ASCII"编解码器无法在位置编码字符
6-15:序列不在范围内(128)
我是错误地使用它还是当前不支持Unicode?
如果您想从Python Unicode字符串中解析XML,则可以使用LXML.Etree.
XML规范允许运输协议和其他来源提供
外部编码信息. LXML支持Python Unicode类型
传输并读取Unicode字符串的内部字节序列.
需要明确的是,这并不意味着解析发生在Unicode处
角色级别.解析XML是关于解析字节,而不是字符.
Stefan
# 回答9


8月24日,1:12 AM,Stefan Behnel 在py2.x中,它不是歧义
兼容的.无需感到"不安". :)
这取决于您所说的"兼容";例如你不能安全地做
[字符串中的S s.decode('utf8')]如果将字符串混合在一起
与Unicode.
乔治
# 回答10


乔治·萨基斯(George Sakkis)写道:
您为什么要通过图书馆来解码字符串
返回解码字符串?
如果您打算写"编码",您确实可以安全地做
只要返回所有字符串
通过ET实施.
# 回答11


8月25日,4:45*PM,Fredrik Lundh 您为什么要通过图书馆来解码字符串
返回解码字符串?
如果您打算写"编码",您确实可以安全地做
只要返回所有字符串
通过ET实施.
我回答了一个普遍的断言:"在2.x ascii字节中
字符串和Unicode字符串是兼容的,而不是专门
ET返回的字符串.
乔治
# 回答12


乔治·萨基斯(George Sakkis)写道:
我回答了一个普遍的断言:"在2.x ascii字节中
字符串和Unicode字符串是兼容的,而不是专门
ET返回的字符串.
该断言是在ET的背景下做出的.必须单一侧面
将主题更改为"赢"论点是非常la脚的.
如果您真的打算写"解码",那么您选择了一个相当愚蠢的
支持您对ET不返回Unicode的投诉的示例 - 您
示例确实适用于字节字符串(它们是否包含纯ASCII
是否),但根本不适合任意Unicode字符串,因为
解码已经被解码的东西几乎没有意义(
解释了为什么在3.0中删除该方法).
trac eback(最近的最新电话): 文件" ",第1行,<模块> attributeError:'str'对象没有属性'decode' 您确定您了解Unicode字符串和 编码字符串?
# 回答13

8月27日,上午5:42,弗雷德里克·伦德(Fredrik Lundh)<弗雷德(Fred)...@pythonware.comwrote: 该断言是在ET的背景下做出的. 必须单一侧面 将主题更改为"赢"论点是非常la脚的. 我以Stefan的评论为一般性声明,而不是在 等. 感觉到此时需要保持"防御" ET的需要是, 借你的话,很la脚. 问题是,用户可能会很高兴地使用ET并将"解码"调用 只要文件恰好是ASCII,返回的字节字符串, 不知道ET也可能返回Unicode. 然后几周后 几个月/年,一个非ASCII文件进来,该程序中断了. 目前 我担心,这是一个文档问题,仅此而已. 乔治

标签: python

添加新评论