XML 與 BOM

電腦的系統中, 有分 big endian format 和 little endian format。

big endian format 代表高位元在前面，littlt endian format則相反。

以例子說明: "中"這個字的 unicode 是 \u4E2D, 若採用 big endian format 則存成 4E2D,
若採用 littlt endian format 則存成 2D4E。

在 XML 檔案開頭可以用 BOM 標誌來判斷內容是 big or little endian format。

轉貼參考資料中的表格如下：

Bytes	Encoding Form
00 00 FE FF	UTF-32, big-endian
FF FE 00 00	UTF-32, little-endian
FE FF	UTF-16, big-endian
FF FE	UTF-16, little-endian
EF BB BF	UTF-8

上表顯示出只有 UTF-32 及 UTF-16 使用 BOM 才有實際意義。在 UTF-8 中則只是當成標示。

在 sun jdk 1.4 中，若 parser 到有 BOM 之 xml 檔，則會發生 org.xml.sax.SAXParseException 。所以要盡量避免使用到有 BOM 開頭的 xml 檔，或是使用 Xerces-J 之 XML Parse。

而在 jdk 1.5 中，則沒有此問題。

參考資料：http://www.unicode.org/unicode/faq/utf_bom.html#BOM

利用 XSLT 來維護程式所需的文件

在公司開發了一套 Socket Interface Server，可以針對不同的服務與交易動態運作之程式。核心程式是利用讀取 XML 設定檔的方式來判斷輸出入格式。

在開發之前，由於是與舊系統的界接程式，所以有許多本不同的規格書（每種服務有不同的規格書）。

現在遇到的問題在於，這些介面程式經常為了新需求而必須更動輸出入格式，除了更改這些設定檔之外，還必須動手去維護這些規格書的文件。

其實，程式中會讀取的 XML 設定檔已經明確的定義了這些輸出入格式，為何要做這些同步文件的動作呢？

所以，我就將 XML 加了一堆說明標籤，說明文字。然後寫了一個 XSL 檔案透過 XSLT 來轉換格式成為可讀性更高的 HTML 格式。

我還蠻喜歡這樣的成果，因為不用去擔心沒有更新到文件，交接下去也更完整。還有一個好處是，這些檔案必須放在 CVS 之類之版本控制伺服器上(因為程式必須靠此設定檔運作)。我們可以利用版本控制的優點，得知文件進化的過程。

XSLT: Firefox 不支援 disable-output-escaping 之解法...

Firefox 並不支援 disable-output-escaping 屬性，所以無法顯示HTML的效果。
據說 Firefox 團隊宣稱他們已依照 W3C 的規格正確實作，不當成是 bug，也就不會去修改。

為了解決此問題，必須依賴 java script 的功能來轉換，將內容當成是 html 的內容。
如下：

to_decode.innerHTML = to_decode.textContent;