URL= http://woodpecker.org.cn/diveintopython3/xml.html
你的位置: Home ‣ Dive Into Python 3 ‣
難度等級: ♦♦♦♦♢
XML
? In the archonship of Aristaechmus, Draco enacted his ordinances. ?
— Aristotle
‣ 顯示目錄
這本書的大部分章節都是以樣例代碼為中心的。但是XML這章不是；它以數據為中心。最常見的XML應用為“聚合訂閱(syndication feeds)”，它用來展示博客，論壇或者其他會經常更新的網站的最新內容。大多數的博客軟件都會在新文章，新的討論區，或者新博文發布的時候自動生成和更新feed。我們可以通過“訂閱(subscribe)”feed來關注它們，還可以使用專門的“feed聚合工具(feed aggregator)”，比如Google Reader。
以下的XML數據是我們這一章中要用到的。它是一個feed — 更確切地說是一個Atom聚合feed
跳過該代碼清單
<?xml version='1.0' encoding='utf-8'?>
<feed xmlns='http://www.w3.org/2005/Atom' xml:lang='en'>
<title>dive into mark</title>
<subtitle>currently between addictions</subtitle>
<id>tag:diveintomark.org,2001-07-29:/</id>
<updated>2009-03-27T21:56:07Z</updated>
<link rel='alternate' type='text/html' />
<link rel='self' type='application/atom+xml' />
<entry>
<author>
<name>Mark</name>
<uri>http://diveintomark.org/</uri>
</author>
<title>Dive into history, 2009 edition</title>
<link rel='alternate' type='text/html'
/>
<id>tag:diveintomark.org,2009-03-27:/archives/20090327172042</id>
<updated>2009-03-27T21:56:07Z</updated>
<published>2009-03-27T17:20:42Z</published>
<category scheme='http://diveintomark.org' term='diveintopython'/>
<category scheme='http://diveintomark.org' term='docbook'/>
<category scheme='http://diveintomark.org' term='html'/>
<summary type='html'>Putting an entire chapter on one page sounds
bloated, but consider this &mdash; my longest chapter so far
would be 75 printed pages, and it loads in under 5 seconds&hellip;
On dialup.</summary>
</entry>
<entry>
<author>
<name>Mark</name>
<uri>http://diveintomark.org/</uri>
</author>
<title>Accessibility is a harsh mistress</title>
<link rel='alternate' type='text/html'
/>
<id>tag:diveintomark.org,2009-03-21:/archives/20090321200928</id>
<updated>2009-03-22T01:05:37Z</updated>
<published>2009-03-21T20:09:28Z</published>
<category scheme='http://diveintomark.org' term='accessibility'/>
<summary type='html'>The accessibility orthodoxy does not permit people to
question the value of features that are rarely useful and rarely used.</summary>
</entry>
<entry>
<author>
<name>Mark</name>
</author>
<title>A gentle introduction to video encoding, part 1: container formats</title>
<link rel='alternate' type='text/html'
/>
<id>tag:diveintomark.org,2008-12-18:/archives/20081218155422</id>
<updated>2009-01-11T19:39:22Z</updated>
<published>2008-12-18T15:54:22Z</published>
<category scheme='http://diveintomark.org' term='asf'/>
<category scheme='http://diveintomark.org' term='avi'/>
<category scheme='http://diveintomark.org' term='encoding'/>
<category scheme='http://diveintomark.org' term='flv'/>
<category scheme='http://diveintomark.org' term='GIVE'/>
<category scheme='http://diveintomark.org' term='mp4'/>
<category scheme='http://diveintomark.org' term='ogg'/>
<category scheme='http://diveintomark.org' term='video'/>
<summary type='html'>These notes will eventually become part of a
tech talk on video encoding.</summary>
</entry>
</feed>
⁂
5分鐘XML速成#
如果你已經了解XML，可以跳過這一部分。
XML是一種描述層次結構化數據的通用方法。XML文檔包含由起始和結束標簽(tag)分隔的一個或多個元素(element)。以下也是一個完整的(雖然空洞)XML文件：
<foo> ①
</foo> ②
| ① | 這是foo元素的起始標簽。 |
| ② | 這是foo元素對應的結束標簽。就如寫作、數學或者代碼中需要平衡括號一樣，每一個起始標簽必須有對應的結束標簽來閉合（匹配）。 |
元素可以嵌套到任意層次。位于foo中的元素bar可以被稱作其子元素。
<foo>
<bar></bar>
</foo>
XML文檔中的第一個元素叫做根元素(root element)。并且每份XML文檔只能有一個根元素。以下不是一個XML文檔，因為它存在兩個“根元素”。
<foo></foo>
<bar></bar>
元素可以有其屬性(attribute)，它們是一些名字-值(name-value)對。屬性由空格分隔列舉在元素的起始標簽中。一個元素中屬性名不能重復。屬性值必須用引號包圍起來。單引號、雙引號都是可以。
<foo lang='en'> ①
<bar id='papayawhip' lang="fr"></bar> ②
</foo>
| ① | foo元素有一個叫做lang的屬性。lang的值為en |
| ② | bar元素則有兩個屬性，分別為id和lang。其中lang屬性的值為fr。它不會與foo的那個屬性產生沖突。每個元素都其獨立的屬性集。 |
如果元素有多個屬性，書寫的順序并不重要。元素的屬性是一個無序的鍵-值對集，跟Python中的列表對象一樣。另外，元素中屬性的個數是沒有限制的。
元素可以有其文本內容(text content)
<foo lang='en'>
<bar lang='fr'>PapayaWhip</bar>
</foo>
如果某一元素既沒有文本內容，也沒有子元素，它也叫做空元素。
<foo></foo>
表達空元素有一種簡潔的方法。通過在起始標簽的尾部添加/字符，我們可以省略結束標簽。上一個例子中的XML文檔可以寫成這樣：
<foo/>
就像Python函數可以在不同的模塊(modules)中聲明一樣，也可以在不同的名字空間(namespace)中聲明XML元素。XML文檔的名字空間通常看起來像URL。我們可以通過聲明xmlns來定義默認名字空間。名字空間聲明跟元素屬性看起來很相似，但是它們的作用是不一樣的。
<feed xmlns='http://www.w3.org/2005/Atom'> ①
<title>dive into mark</title> ②
</feed>
| ① | feed元素處在名字空間http://www.w3.org/2005/Atom中。 |
| ② | title元素也是。名字空間聲明不僅會作用于當前聲明它的元素，還會影響到該元素的所有子元素。 |
也可以通過xmlns:prefix聲明來定義一個名字空間并取其名為prefix。然后該名字空間中的每個元素都必須顯式地使用這個前綴(prefix)來聲明。
<atom:feed xmlns:atom='http://www.w3.org/2005/Atom'> ①
<atom:title>dive into mark</atom:title> ②
</atom:feed>
| ① | feed元素屬于名字空間http://www.w3.org/2005/Atom。 |
| ② | title元素也在那個名字空間。 |
對于XML解析器而言，以上兩個XML文檔是一樣的。名字空間 + 元素名 = XML標識。前綴只是用來引用名字空間的，所以對于解析器來說，這些前綴名(atom:)其實無關緊要的。名字空間相同，元素名相同，屬性（或者沒有屬性）相同，每個元素的文本內容相同，則XML文檔相同。
最后，在根元素之前，字符編碼信息可以出現在XML文檔的第一行。（這里存在一個兩難的局面(catch-22)，直觀上來說，解析XML文檔需要這些編碼信息，而這些信息又存在于XML文檔中，如果你對XML如何解決此問題有興趣，請參閱XML規范中 F 章節）
<?xml version='1.0' encoding='utf-8'?>
現在我們已經知道足夠多的XML知識，可以開始探險了！
⁂
Atom Feed的結構#
想像一下網絡上的博客，或者互聯網上任何需要頻繁更新的網站，比如CNN.com。該站點有一個標題(“CNN.com”)，一個子標題(“Breaking News, U.S., World, Weather, Entertainment & Video News”)，包含上次更新的日期(“updated 12:43 p.m. EDT, Sat May 16, 2009”)，還有在不同時期發布的文章的列表。每一篇文章也有自己的標題，第一次發布的日期（如果曾經修訂過或者改正過某個輸入錯誤，或許也有一個上次更新的日期），并且每篇文章有自己唯一的URL。
Atom聚合格式被設計成可以包含所有這些信息的標準格式。我的博客無論在設計，主題還是讀者上都與CNN.com大不相同，但是它們的基本結構是相同的。CNN.com能做的事情，我的博客也能做…
每一個Atom訂閱都共享著一個根元素：即在名字空間http://www.w3.org/2005/Atom中的元素feed。
跳過該代碼清單
| ① | http://www.w3.org/2005/Atom表示名字空間Atom。 |
| ② | 每一個元素都可以包含xml:lang屬性，它用來聲明該元素及其子元素使用的語言。在當前樣例中，xml:lang在根元素中被聲明了一次，也就意味著，整個feed都使用英文。 |
描述Atom feed自身的一些信息在根元素feed的子元素中被聲明。
跳過該代碼清單
| ① | 該行表示這個feed的標題為dive into mark。 |
| ② | 這一行表示子標題為currently between addictions。 |
| ③ | 每一個feed都要有一個全局唯一標識符(globally unique identifier)。想要知道如何創建它，請查閱RFC 4151。 |
| ④ | 表示當前feed上次更新的時間為March 27, 2009, at 21:56 GMT。通常來說，它與最近一篇文章最后一次被修改的時間是一樣的。 |
| ⑤ | 事情開始變得有趣了…link元素沒有文本內容，但是它有三個屬性：rel，type和href。rel元素的值能告訴我們鏈接的類型；rel='alternate'表示這個鏈接指向當前feed的另外一個版本。type='text/html'表示鏈接的目標是一個HTML頁面。然后目標地址在href屬性中指出。 |
現在我們知道這個feed上一更新是在on March 27, 2009，它是為一個叫做“dive into mark”的站點準備的，并且站點的地址為http://diveintomark.org/。
☞在有一些XML文檔中，元素的排列順序是有意義的，但是Atom feed中不需要這樣做。
feed級的元數據后邊就是最近文章的列表了。單獨的一篇文章就像這樣：
跳過該代碼清單
| ① | author元素指示文章的作者：一個叫做Mark的伙計，并且我們可以在http://diveintomark.org/找到他的事跡。（這就像是feed元素里的備用鏈接，但是沒有規定一定要這樣。許多網絡日志由多個作者完成，他們都有自己的個人主頁。） |
| ② | title元素給出這篇文章的標題，即“Dive into history, 2009 edition”。 |
| ③ | 如feed元素中的備用鏈接一樣，link元素給出這篇文章的HTML版本地址。 |
| ④ | 每個條目也像feed一樣，需要一個唯一的標識。 |
| ⑤ | 每個條目有兩個日期與其相關：第一次發布日期(published)和上次修改日期(updated)。 |
| ⑥ | 條目可以屬于任意多個類別。這篇文章被歸類到diveintopython，docbook，和html。 |
| ⑦ | summary元素中有這篇文章的概要性描述。（還有一個元素這里沒有展示出來，即content，我們可以把整篇文章的內容都放在里邊。）當前樣例中，summary元素含有一個Atom特有的type='html'屬性，它用來告知這份概要為HTML格式，而非純文本。這非常重要，因為概要內容中包含了HTML中特有的實體（—和…），它們不應該以純文本直接顯示，正確的形式應該為“—”和“…”。 |
| ⑧ | 最后就是entry元素的結束標記了，它指示文章元數據的結尾。 |
⁂
解析XML#
Python可以使用幾種不同的方式解析XML文檔。它包含了DOM和SAX解析器，但是我們焦點將放在另外一個叫做ElementTree的庫上邊。
跳過該代碼清單
| ① | ElementTree屬于Python標準庫的一部分，它的位置為xml.etree.ElementTree。 |
| ② | parse()函數是ElementTree庫的主要入口，它使用文件名或者流對象作為參數。parse()函數會立即解析完整個文檔。如果內存資源緊張，也可以增量式地解析XML文檔 |
| ③ | parse()函數會返回一個能代表整篇文檔的對象。這不是根元素。要獲得根元素的引用可以調用getroot()方法。 |
| ④ | 如預期的那樣，根元素即http://www.w3.org/2005/Atom名字空間中的feed。該字符串表示再次重申了非常重要的一點：XML元素由名字空間和標簽名（也稱作本地名(local name)）組成。這篇文檔中的每個元素都在名字空間Atom中，所以根元素被表示為{http://www.w3.org/2005/Atom}feed。 |
☞ElementTree使用{namespace}localname來表達XML元素。我們將會在ElementTree的API中多次見到這種形式。
元素即列表#
在ElementTree API中，元素的行為就像列表一樣。列表中的項即該元素的子元素。
跳過該代碼清單
# continued from the previous example
>>> root.tag ① '{http://www.w3.org/2005/Atom}feed' >>> len(root) ② 8 >>> for child in root: ③ ... print(child) ④ ... <Element {http://www.w3.org/2005/Atom}title at e2b5d0> <Element {http://www.w3.org/2005/Atom}subtitle at e2b4e0> <Element {http://www.w3.org/2005/Atom}id at e2b6c0> <Element {http://www.w3.org/2005/Atom}updated at e2b6f0> <Element {http://www.w3.org/2005/Atom}link at e2b4b0> <Element {http://www.w3.org/2005/Atom}entry at e2b720> <Element {http://www.w3.org/2005/Atom}entry at e2b510> <Element {http://www.w3.org/2005/Atom}entry at e2b750>
| ① | 緊接前一例子，根元素為{http://www.w3.org/2005/Atom}feed。 |
| ② | 根元素的“長度”即子元素的個數。 |
| ③ | 我們可以像使用迭代器一樣來遍歷其子元素。 |
| ④ | 從輸出可以看到，根元素總共有8個子元素：所有feed級的元數據（title，subtitle，id，updated和link），還有緊接著的三個entry元素。 |
也許你已經注意到了，但我還是想要指出來：該列表只包含直接子元素。每一個entry元素都有其子元素，但是并沒有包括在這個列表中。這些子元素本可以包括在entry元素的列表中，但是確實不屬于feed的子元素。但是，無論這些元素嵌套的層次有多深，總是有辦法定位到它們的；在這章的后續部分我們會介紹兩種方法。
屬性即字典#
XML不只是元素的集合；每一個元素還有其屬性集。一旦獲取了某個元素的引用，我們可以像操作Python的字典一樣輕松獲取到其屬性。
跳過該代碼清單
| ① | attrib是一個代表元素屬性的字典。這個地方原來的標記語言是這樣描述的：<feed xmlns='http://www.w3.org/2005/Atom' xml:lang='en'>。前綴xml:指示一個內置的名字空間，每一個XML不需要聲明就可以使用它。 |
| ② | 第五個子元素 — 以0為起始的列表中即[4] — 為元素link。 |
| ③ | link元素有三個屬性：href，type，和rel。 |
| ④ | 第四個子元素 — [3] — 為updated。 |
| ⑤ | 元素updated沒有子元素，所以.attrib是一個空的字典對象。 |
⁂
在XML文檔中查找結點#
到目前為止，我們已經“自頂向下“地從根元素開始，一直到其子元素，走完了整個文檔。但是許多情況下我們需要找到XML中特定的元素。Etree也能完成這項工作。
跳過該代碼清單
| ① | findfall()方法查找匹配特定格式的子元素。（關于查詢的格式稍后會講到。） |
| ② | 每個元素 — 包括根元素及其子元素 — 都有findall()方法。它會找到所有匹配的子元素。但是為什么沒有看到任何結果呢？也許不太明顯，這個查詢只會搜索其子元素。由于根元素feed中不存在任何叫做feed的子元素，所以查詢的結果為一個空的列表。 |
| ③ | 這個結果也許也在你的意料之外。在這篇文檔中確實存在author元素；事實上總共有三個（每個entry元素中都有一個）。但是那些author元素不是根元素的直接子元素。我們可以在任意嵌套層次中查找author元素，但是查詢的格式會有些不同。 |
跳過該代碼清單
| ① | 為了方便，對象tree（調用etree.parse()的返回值）中的一些方法是根元素中這些方法的鏡像。在這里，如果調用tree.getroot().findall()，則返回值是一樣的。 |
| ② | 也許有些意外，這個查詢請求也沒有找到文檔中的author元素。為什么沒有呢？因為它只是tree.getroot().findall('{http://www.w3.org/2005/Atom}author')的一種簡潔表示，即“查詢所有是根元素的子元素的author”。因為這些author是entry元素的子元素，所以查詢沒有找到任何匹配的。 |
find()方法用來返回第一個匹配到的元素。當我們認為只會有一個匹配，或者有多個匹配但我們只關心第一個的時候，這個方法是很有用的。
跳過該代碼清單
| ① | 在前一樣例中已經看到。這一句返回所有的atom:entry元素。 |
| ② | find()方法使用ElementTree作為參數，返回第一個匹配到的元素。 |
| ③ | 在entries[0]中沒有叫做foo的元素，所以返回值為None。 |
☞可逮住你了，在這里find()方法非常容易被誤解。在布爾上下文中，如果ElementTree元素對象不包含子元素，其值則會被認為是False（即如果len(element)等于0）。這就意味著if element.find('...')并非在測試是否find()方法找到了匹配項；這條語句是在測試匹配到的元素是否包含子元素！想要測試find()方法是否返回了一個元素，則需使用if element.find('...') is not None。
也可以在所有派生(descendant)元素中搜索，即任意嵌套層次的子元素，孫子元素等…
跳過該代碼清單
>>> all_links = tree.findall('//{http://www.w3.org/2005/Atom}link') ① >>> all_links [<Element {http://www.w3.org/2005/Atom}link at e181b0>, <Element {http://www.w3.org/2005/Atom}link at e2b570>, <Element {http://www.w3.org/2005/Atom}link at e2b480>, <Element {http://www.w3.org/2005/Atom}link at e2b5a0>] >>> all_links[0].attrib ② {'href': 'http://diveintomark.org/',
'type': 'text/html',
'rel': 'alternate'} >>> all_links[1].attrib ③ {'href': 'http://diveintomark.org/archives/2009/03/27/dive-into-history-2009-edition',
'type': 'text/html',
'rel': 'alternate'} >>> all_links[2].attrib {'href': 'http://diveintomark.org/archives/2009/03/21/accessibility-is-a-harsh-mistress',
'type': 'text/html',
'rel': 'alternate'} >>> all_links[3].attrib {'href': 'http://diveintomark.org/archives/2008/12/18/give-part-1-container-formats',
'type': 'text/html',
'rel': 'alternate'}
| ① | //{http://www.w3.org/2005/Atom}link與前一樣例很相似，除了開頭的兩條斜線。這兩條斜線告訴findall()方法“不要只在直接子元素中查找；查找的范圍可以是任意嵌套層次”。 |
| ② | 查詢到的第一個結果是根元素的直接子元素。從它的屬性中可以看出，它是一個指向該feed的HTML版本的備用鏈接。 |
| ③ | 其他的三個結果分別是低一級的備用鏈接。每一個entry都有單獨一個link子元素，由于在查詢語句前的兩條斜線的作用，我們也能定位到他們。 |
總的來說，ElementTree的findall()方法是其一個非常強大的特性，但是它的查詢語言卻讓人有些出乎意料。官方描述它為“有限的XPath支持。”XPath是一種用于查詢XML文檔的W3C標準。對于基礎地查詢來說，ElementTree與XPath語法上足夠相似，但是如果已經會XPath的話，它們之間的差異可能會使你感到不快。現在，我們來看一看另外一個第三方XML庫，它擴展了ElementTree的API以提供對XPath的全面支持。
⁂
深入lxml#
lxml是一個開源的第三方庫，以流行的libxml2 解析器為基礎開發。提供了與ElementTree完全兼容的API，并且擴展它以提供了對XPath 1.0的全面支持，以及改進了一些其他精巧的細節。提供Windows的安裝程序；Linux用戶推薦使用特定發行版自帶的工具比如yum或者apt-get從它們的程序庫中安裝預編譯好了的二進制文件。要不然，你就得手工安裝他們了。
跳過該代碼清單
| ① | 導入lxml以后，可以發現它與內置的ElementTree庫提供相同的API。 |
| ② | parse()函數：與ElementTree相同。 |
| ③ | getroot()方法：相同。 |
| ④ | findall()方法：完全相同。 |
對于大型的XML文檔，lxml明顯比內置的ElementTree快了許多。如果現在只用到了ElementTree的API，并且想要使用其最快的實現(implementation)，我們可以嘗試導入lxml，并且將內置的ElementTree作為備用。
try:
from lxml import etree
except ImportError:
import xml.etree.ElementTree as etree
但是lxml不只是一個更快速的ElementTree。它的findall()方法能夠支持更加復雜的表達式。
跳過該代碼清單
| ① | 在這個樣例中，我使用了import lxml.etree（而非from lxml import etree），以強調這些特性只限于lxml。 |
| ② | 這一句在整個文檔范圍內搜索名字空間Atom中具有href屬性的所有元素。在查詢語句開頭的//表示“搜索的范圍為整個文檔（不只是根元素的子元素）。” {http://www.w3.org/2005/Atom}指示“搜索范圍僅在名字空間Atom中。” * 表示“任意本地名(local name)的元素。” [@href]表示“含有href屬性。” |
| ③ | 該查詢找出所有包含href屬性并且其值為http://diveintomark.org/的Atom元素。 |
| ④ | 在簡單的字符串格式化后（要不然這條復合查詢語句會變得特別長），它搜索名字空間Atom中包含uri元素作為子元素的author元素。該條語句只返回了第一個和第二個entry元素中的author元素。最后一個entry元素中的author只包含有name屬性，沒有uri。 |
仍然不夠用？lxml也集成了對任意XPath 1.0表達式的支持。我們不會深入講解XPath的語法；那可能需要一整本書！但是我會給你展示它是如何集成到lxml去的。
跳過該代碼清單
| ① | 要查詢名字空間中的元素，首先需要定義一個名字空間前綴映射。它就是一個Python字典對象。 |
| ② | 這就是一個XPath查詢請求。這個XPath表達式目的在于搜索category元素，并且該元素包含有值為accessibility的term屬性。但是那并不是查詢的結果。請看查詢字符串的尾端；是否注意到了/..這一塊？它的意思是，“然后返回已經找到的category元素的父元素。”所以這條XPath查詢語句會找到所有包含<category term='accessibility'>作為子元素的條目。 |
| ③ | xpath()函數返回一個ElementTree對象列表。在這篇文檔中，只有一個category元素，并且它的term屬性值為accessibility。 |
| ④ | XPath表達式并不總是會返回一個元素列表。技術上說，一個解析了的XML文檔的DOM模型并不包含元素；它只包含結點(node)。依據它們的類型，結點可以是元素，屬性，甚至是文本內容。XPath查詢的結果是一個結點列表。當前查詢返回一個文本結點列表：title元素(atom:title)的文本內容(text())，并且title元素必須是當前元素的子元素(./)。 |
⁂
生成XML#
Python對XML的支持不只限于解析已存在的文檔。我們也可以從頭來創建XML文檔。
跳過該代碼清單
| ① | 實例化Element類來創建一個新元素。可以將元素的名字（名字空間 + 本地名）作為其第一個參數。當前語句在Atom名字空間中創建一個feed元素。它將會成為我們文檔的根元素。 |
| ② | 將屬性名和值構成的字典對象傳遞給attrib參數，這樣就可以給新創建的元素添加屬性。請注意，屬性名應該使用標準的ElementTree格式，{namespace}localname。 |
| ③ | 在任何時候，我們可以使用ElementTree的tostring()函數序列化任意元素（還有它的子元素）。 |
這種序列化結果有使你感到意外嗎？技術上說，ElementTree使用的序列化方法是精確的，但卻不是最理想的。在本章開頭給出的XML樣例文檔中定義了一個默認名字空間(default namespace)(xmlns='http://www.w3.org/2005/Atom')。對于每個元素都在同一個名字空間中的文檔 — 比如Atom feeds — 定義默認的名字空間非常有用，因為只需要聲明一次名字空間，然后在聲明每個元素的時候只需要使用其本地名即可(<feed>，<link>，<entry>)。除非想要定義另外一個名字空間中的元素，否則沒有必要使用前綴。
對于XML解析器來說，它不會“注意”到使用默認名字空間和使用前綴名字空間的XML文檔之間有什么不同。當前序列化結果的DOM為：
<ns0:feed xmlns:ns0='http://www.w3.org/2005/Atom' xml:lang='en'/>
與下列序列化的DOM是一模一樣的：
<feed xmlns='http://www.w3.org/2005/Atom' xml:lang='en'/>
實際上唯一不同的只是第二個序列化短了幾個字符長度。如果我們改動整個樣例feed，使每一個起始和結束標簽都有一個ns0:前綴，這將為每個起始標簽增加 4 個字符 × 79 個標簽 + 4 個名字空間聲明本身用到的字符，總共320個字符。假設我們使用UTF-8編碼，那將是320個額外的字節。（使用gzip壓縮以后，大小可以降到21個字節，但是，21個字節也是字節。）也許對個人來說這算不了什么，但是對于像Atom feed這樣的東西，只要稍有改變就有可能被下載上千次，每一個請求節約的幾個字節就會迅速累加起來。
內置的ElementTree庫沒有提供細粒度地對序列化時名字空間內的元素的控制，但是lxml有這樣的功能。
跳過該代碼清單
| ① | 首先，定義一個用于名字空間映射的字典對象。其值為名字空間；字典中的鍵即為所需要的前綴。使用None作為前綴來定義默認的名字空間。 |
| ② | 現在我們可以在創建元素的時候，給lxml專有的nsmap參數傳值，并且lxml會參照我們所定義的名字空間前綴。 |
| ③ | 如所預期的那樣，該序列化使用Atom作為默認的名字空間，并且在聲明feed元素的時候沒有使用名字空間前綴。 |
| ④ | 啊噢… 我們忘了加上xml:lang屬性。我們可以使用set()方法來隨時給元素添加所需屬性。該方法使用兩個參數：標準ElementTree格式的屬性名，然后，屬性值。（該方法不是lxml特有的。在該樣例中，只有nsmap參數是lxml特有的，它用來控制序列化輸出時名字空間的前綴。） |
難道每個XML文檔只能有一個元素嗎？當然不了。我們可以創建子元素。
跳過該代碼清單
| ① | 給已有元素創建子元素，我們需要實例化SubElement類。它只要求兩個參數，父元素（即該樣例中的new_feed）和子元素的名字。由于該子元素會從父元素那兒繼承名字空間的映射關系，所以這里不需要再聲明名字空間前綴。 |
| ② | 我們也可以傳遞屬性字典給它。字典的鍵即屬性名；值為屬性的值。 |
| ③ | 如預期的那樣，新創建的title元素在Atom名字空間中，并且它作為子元素插入到feed元素中。由于title元素沒有文件內容，也沒有其子元素，所以lxml將其序列化為一個空元素（使用/>）。 |
| ④ | 設定元素的文本內容，只需要設定其.text屬性。 |
| ⑤ | 當前title元素序列化的時候就使用了其文本內容。任何包含了<或者&符號的內容在序列化的時候需要被轉義。lxml會自動處理轉義。 |
☞你也許也想要看一看xmlwitch，它也是用來生成XML的另外一個第三方庫。它大量地使用了with語句來使生成的XML代碼更具可讀性。
⁂
解析破損的XML#
XML規范文檔中指出，要求所有遵循XML規范的解析器使用“嚴厲的(draconian)錯誤處理”。即，當它們在XML文檔中檢測到任何編排良好性(wellformedness)錯誤的時候，應當立即停止解析。編排良好性錯誤包括不匹配的起始和結束標簽，未定義的實體(entity)，非法的Unicode字符，還有一些只有內行才懂的規則(esoteric rules)。這與其他的常見格式，比如HTML，形成了鮮明的對比 — 即使忘記了封閉HTML標簽，或者在屬性值中忘了轉義&字符，我們的瀏覽器也不會停止渲染一個Web頁面。（通常大家認為HTML沒有錯誤處理機制，這是一個常見的誤解。HTML的錯誤處理實際上被很好的定義了，但是它比“遇見第一個錯誤即停止”這種機制要復雜得多。）
一些人（包括我自己）認為XML的設計者強制實行這種嚴格的錯誤處理本身是一個失誤。請不要誤解我；我當然能看到簡化錯誤處理機制的優勢。但是在現實中，“編排良好性”這種構想比乍聽上去更加復雜，特別是對XML（比如Atom feeds）這種發布在網絡上，通過HTTP傳播的文檔。早在1997年XML就標準化了這種嚴厲的錯誤處理，盡管XML已經非常成熟，研究一直表明，網絡上相當一部分的Atom feeds仍然存在著編排完整性錯誤。
所以，從理論上和實際應用兩種角度來看，我有理由“不惜任何代價”來解析XML文檔，即，當遇到編排良好性錯誤時，不會中斷解析操作。如果你認為你也需要這樣做，lxml可以助你一臂之力。
以下是一個破損的XML文檔的片斷。其中的編排良好性錯誤已經被高亮標出來了。
<?xml version='1.0' encoding='utf-8'?>
<feed xmlns='http://www.w3.org/2005/Atom' xml:lang='en'>
<title>dive into …</title>
...
</feed>
因為實體…并沒有在XML中被定義，所以這算作一個錯誤。（它在HTML中被定義。）如果我們嘗試使用默認的設置來解析該破損的feed，lxml會因為這個未定義的實體而停下來。
>>> import lxml.etree >>> tree = lxml.etree.parse('examples/feed-broken.xml') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "lxml.etree.pyx", line 2693, in lxml.etree.parse (src/lxml/lxml.etree.c:52591) File "parser.pxi", line 1478, in lxml.etree._parseDocument (src/lxml/lxml.etree.c:75665) File "parser.pxi", line 1507, in lxml.etree._parseDocumentFromURL (src/lxml/lxml.etree.c:75993) File "parser.pxi", line 1407, in lxml.etree._parseDocFromFile (src/lxml/lxml.etree.c:75002) File "parser.pxi", line 965, in lxml.etree._BaseParser._parseDocFromFile (src/lxml/lxml.etree.c:72023) File "parser.pxi", line 539, in lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:67830) File "parser.pxi", line 625, in lxml.etree._handleParseResult (src/lxml/lxml.etree.c:68877) File "parser.pxi", line 565, in lxml.etree._raiseParseError (src/lxml/lxml.etree.c:68125) lxml.etree.XMLSyntaxError: Entity 'hellip' not defined, line 3, column 28 為了解析該破損的XML文檔，忽略它的編排良好性錯誤，我們需要創建一個自定義的XML解析器。
跳過該代碼清單
| ① | 實例化lxml.etree.XMLParser類來創建一個自定義的解析器。它可以使用許多不同的命名參數。在此，我們感興趣的為recover參數。當它的值被設為True，XML解析器會盡力嘗試從編排良好性錯誤中“恢復”。 |
| ② | 為使用自定的解析器來處理XML文檔，將對象parser作為第二個參數傳遞給parse()函數。注意，lxml沒有因為那個未定義的…實體而拋出異常。 |
| ③ | 解析器會記錄它所遇到的所有編排良好性錯誤。（無論它是否被設置為需要從錯誤中恢復，這個記錄總會存在。） |
| ④ | 由于不知道如果處理該未定義的…實體，解析器默認會將其省略掉。title元素的文本內容變成了'dive into '。 |
| ⑤ | 從序列化的結果可以看出，實體…并沒有被移到其他地方去；它就是被省略了。 |
在此，必須反復強調，這種“可恢復的”XML解析器沒有互用性(interoperability)保證。另一個不同的解析器可能就會認為…來自HTML，然后將其替換為&hellip;。這樣“更好”嗎？也許吧。這樣“更正確”嗎？不，兩種處理方法都不正確。正確的行為（根據XML規范）應該是終止解析操作。如果你已經決定不按規范來，你得自己負責。
⁂
進一步閱讀#
☜ ☞
© 2001–9 Mark Pilgrim