對XML 進行 parse 時的Invalid Unicode character (0x0) 分析

XML 在搜尋引擎的低端起到了非常重要的作用，可是由於相當多數的網路上的Rss feed或者XML feed都是直接從資料庫檔案生成的，因此極有可能包含有一些非常字元，而這些字元在XML進行Parse的時候就會帶來 Invalid Unicode character (0x0) 這樣的錯誤或者是org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x0) was found，如何解決這樣的錯誤？

先看看Unicode的一些基礎知識：

Unicode 最初設計是作為一種固定寬度的 16 位字元編碼。在 Java 程式語言中，基本資料型別 char 初衷是透過提供一種簡單的、能夠包含任何字元的資料型別來充分利用這種設計的優點。不過，現在看來，16 位編碼的所有 65,536 個字元並不能完全表示全世界所有正在使用或曾經使用的字元。於是，Unicode 標準已擴充套件到包含多達 1,112,064 個字元。那些超出原來的 16 位限制的字元被稱作增補字元。Unicode 標準 2.0 版是第一個包含啟用增補字元設計的版本，但是，直到 3.1 版才收入第一批增補字符集。由於 J2SE 的 5.0 版必須支援 Unicode 標準 4.0 版，因此它必須支援增補字元。

對增補字元的支援也可能會成為東亞市場的一個普遍商業要求。政府應用程式會需要這些增補字元，以正確表示一些包含罕見中文字元的姓名。出版應用程式可能會需要這些增補字元，以表示所有的古代字元和變體字元。中國政府要求支援 GB18030（一種對整個 Unicode 字符集進行編碼的字元編碼標準），因此，如果是 Unicode 3.1 版或更新版本，則將包括增補字元。臺灣標準 CNS-11643 包含的許多字元在 Unicode 3.1 中列為增補字元。香港政府定義了一種針對粵語的字符集，其中的一些字元是 Unicode 中的增補字元。最後，日本的一些供應商正計劃利用增補字元空間中大量的專用空間收入 50,000 多個日文漢字字元變體，以便從其專有系統遷移至基於 Java 平臺的解決方案。

因此，Java 平臺不僅需要支援增補字元，而且必須使應用程式能夠方便地做到這一點。由於增補字元打破了 Java 程式語言的基礎設計構想，而且可能要求對程式設計模型進行根本性的修改，因此，Java Community Process 召集了一個專家組，以期找到一個適當的解決方案。該小組被稱為 JSR-204 專家組，使用 Unicode 增補字元支援的 Java 技術規範請求的編號。從技術上來說，該專家組的決定僅適用於 J2SE 平臺，但是由於 Java 2 平臺企業版 (J2EE) 處於 J2SE 平臺的最上層，因此它可以直接受益，我們期望 Java 2 平臺袖珍版 (J2ME) 的配置也採用相同的設計方法。

不過，在瞭解 JSR-204 專家組確定的解決方案之前，我們需要先理解一些術語。

程式碼點、字元編碼方案、UTF-16：這些是指什麼？

不幸的是，引入增補字元使字元模型變得更加複雜了。在過去，我們可以簡單地說“字元”，在一個基於 Unicode 的環境（例如 Java 平臺）中，假定字元有 16 位，而現在我們需要更多的術語。我們會盡量介紹得相對簡單一些 — 如需瞭解所有詳細的討論資訊，您可以閱讀 Unicode 標準第 2 章或 Unicode 技術報告 17“字元編碼模型”。Unicode 專業人士可略過所有介紹直接參閱本部分中的最後定義。

字元是抽象的最小文字單位。它沒有固定的形狀（可能是一個字形），而且沒有值。“A”是一個字元，“