從 HTML 開始談起     民國 92 年 4 月 3 日

前言

199x 年知名的瀏覽器公司網景（Netscape）與微軟（Microsoft）發生了一場瀏覽器市場中激烈的爭奪戰，同時也爆發了網際網路上的一些技術規格制訂戰。雖然最後的結果微軟挾既有作業系統市場的優勢取得勝利，但是這場戰爭卻為人們留下了許多值得討論的議題 -- 為何一個可以閱覽 HTML 文件的瀏覽器可以引發兩大公司之間的競爭？HTML 文件與瀏覽器之間的背後到底隱藏多少的技術？以及這些技術對於未來 IT 產業又將透露出怎樣的訊息？本文中，筆者將引領您以程式設計師的角度一起探討所謂的 HTML 文件以及環繞在周圍的技術與應用。

HTML 是一個包含文件顯示格式的文件

HTML 在很多書籍中都描述為『一種使用超鏈結標籤語言（HyperText Mark up Language ）的文件』也就是說使用者可以在文件中以標籤的方式，注記所展示的文件實際所在的位置，或者是文件顯示的樣式。沒錯！！這是一個正確的說法。只是這樣的說帖是站在一般使用者的角度來看的！？然而，站在程式設計師的角度 HTML 文件則又是怎樣的一回事呢！？同樣是一樣文字檔案，它與 RTF（Rich Text Format）、Word、Text 檔案有何不同？？表 1. 顯示一個 RTF 檔案的內容，讀者可以注意到 \par 為首的字串是每一行文字的開始，而字串 \cf1 與 \cf0 所包裹的文字，則顯示為紅色，這種以『\』為前導字元（lead code）作為格式判定的方法，與 HTML 中以 、 等標籤作為格式判定的方法，其實並沒有兩樣，只是到了後來 Word 將文件中其他的資源，例如圖形、聲音等，全部都可以引入檔案之中而已。所以我們可以得到一個結論，就是其實 HTML 是一個除了本文之外，還包含顯示格式的文件。這個結論重要嗎？當然重要，我們在稍後的章節中，將會再提到這一點！？現在，我們將焦點放在瀏覽器上！！既然 HTML 文件中包含了顯示格式，瀏覽器要如何在一堆文字字串中區分什麼是本文？什麼是格式設定標籤呢？

Parser 為瀏覽器提供了解析 HTML 的機制

從上一個小節中我們很清楚的瞭解到一個重要的訊息，那就是瀏覽器必須能夠區分出 HTML 文件中哪些是本文？哪些是格式標籤？還有這些格式標籤中所影響的範圍？圖 1. 顯示了一個筆者利用微軟 IE 所附的的 HTML Parser 對於『Programmer 深度論壇』這個網頁，所進行的網頁分析，圖中讀者可以很清楚的看到 HTML 文件已經被解析成特定的資料結構，這樣一來這些資訊已經可以提供瀏覽器顯示文件了。（微軟的 HTML Parser 是一個 ActiveX 元件，讀者可以自行在程式中加入這項服務，使得您的程式可以具有 HTML 分析的能力）不過這個服務在很多應用之中是不夠的，例如筆者想進行 HTML 語法檢查時，微軟的 HTML Parser 會因為預設容錯機制，會經常讓筆者找不到錯誤所在。因此筆者需要另尋一個 Parser 來作這樣的事情。

圖1

圖2

圖3

圖4

XML 文件的處理

除了 HTML 之外， 另一種廣為網際網路所流傳的文件格式是從 SGML 所延伸而來的 XML(eXtensible Markup Language，可延伸性標記語言) 這種與 HTML 同樣是文字檔案的文件格式，除了一樣使用標籤外，更進一步可以嚴格定義文件格式（此處所謂的文件格式指的是，文件內容格式，而非顯示用的格式）我們可以使用包含許多相關標準如 XML Schema、XSLT（XSL Transformations）、DOM（Document Object Model）、Xpath（XML Path Language） 等來詮釋以及檢驗文件的結構與正確性。不過同樣的我們不論使用哪一種標準來定義 XML 文件，對於 XML 的分析與應用，我們還是需要 Parser 來協助進行這件事情。圖 5. 是筆者使用微軟的 XML Parser 所撰寫的 XML Document 編輯器的畫面，其中使用者可以任意新增、刪除、更名節點，以及存放節點內容為文字、圖形、或者任意檔案。（微軟的 XML Parser 採 DOM 的驗證標準，為 ActiveX 元件，使用者同樣可以安裝在自己的程式中，使之成為具有 XML 分析能力的應用程式）（另一種廣為流傳使用的 XML 工具，XML Spy 也是使用微軟的解析器）不過 XML 是一個不含顯示格式的文件，如果直接以瀏覽器 閱覽則僅會顯示其樹狀結構，如圖 6. 所示。

圖5

圖6

圖7

XML 之所以繼 HTML 之後廣為網際網路所流傳的緣故，在於它的嚴格結構化的文字檔型態，非常適合跨越平台進行資料的交換與系統的整合。因此幾乎各平台之間如 Windows、Linux、Java 都有支援 DOM 標準的 XML 解析器。而且隨著瀏覽器的支援，我們除了可以對於 XML 資料上處理之外，甚至還可以對 XML 文件瀏覽時的視覺上進行處理。XSL （Extensible Stylesheet Language ）與 CSS（Cascading Style Sheets）兩種稿本語言是瀏覽器對於 XML 視覺上詮釋的一種語言，藉由套用這兩種稿本語言，則如圖 6. 的 XML 檔案，可以顯示成如圖 7. 的模樣，不但有較漂亮的外觀，還可以作出索引的效果。

圖 8. 所示是由筆者所撰寫的『XSL Converter』原理是藉由之前所提的 HTML 解析器，來處理由畫面右方的 XML 檔案區所拖拉過來，而插入 HTML 中由筆者所定義，含有 XML 節點路徑資訊的特殊標籤 並且將之顯示到畫面之上，如圖中黃底紅字 所顯示的部分（微軟所提供的解析器會因為容錯的緣故，會略過由筆者所定義的特殊標籤。）然後經過轉換，產生可供瀏覽器閱覽圖 8. 中 XML 文件的 XSL 文件，而如圖 9. 所示，是最後藉由預覽的功能，我們可以看到該 XML 文件最終所表現出來的樣子。請注意圖 7. 與圖 10. 之間所展示的是同一份 XML 文件，不但它們之間所展現的風格不同，而且隨著 XSL 所設計的內容不同，我們可以增加或者是隱藏 XML 文件中的資訊。這個在以 XML 為基礎的應用是個很重要的人機介面應用的技術。

圖8

圖9

圖10

從解析器到直譯器

從上面的章節中我們可以清楚的瞭解到，不管我們要處理的對向是 HTML 或者是 XML 都需要解析器先將文字型態的檔案，轉換成特定的資料結構後，再進行下一步的工作。而同樣的動作對於直譯器而言也是一樣的。（這裡所謂的直譯器指的是以 VB Script 或者是 Java Script 為主以文字命令直接作為執行的依據，而非目的檔（Object File）、二進位執行檔（Exceuteion File）或者是批次檔 。因此對於稿本（Script）程式而言，並沒有所謂的編譯動作。） 先將稿本文字程式轉換成稿本執行引擎所需要的資料結構，例如命令的辨識、參數、以及變數的宣告等（詳細請參見拙著『如何以物件導向中多型的技術實作稿本引擎』一文）然後再交由稿本引擎執行。 所以在瀏覽器之中對於稿本語言的支援，便有賴於是否提供對該稿本進行解譯的能力！？例如：Netscape 的並不支援 VB Script 而 IE 則同時支援 VB 及 Java 兩種稿本。

稿本語言的使用，在近年有日漸增多的趨勢。不單是在 Web Service 上的應用，而且在一般的應用程式中都加入對稿本語言的支援。 主要是希望能夠增加對於應用程式的彈性，以避免應用程式之中因為存在過多客製化的規格，進而影響產品的適用範圍。特別是在 Work Flow 以及 Supply Chain 等應用領域中容易看到這樣的例子。不過在這些解決方案（Solution）中由於大多採用現成的稿本直譯器，因此在使用上應注意使用的稿本命令的版本應與直譯器版本保持一致性。否則很容易出現命令不相符，或者是需要進行稿本版本轉換的手續。

現在我們可以從上面的討論中可以試著描繪一下瀏覽器的功能方塊圖了，圖 11.是筆者所描繪 IE Browser 的範例。其中 Browser 藉由 HTTP 的常駐程式取得網際網路上的文件，並由文件型態中決定是否直接顯示（HTML）或者交由適當的解譯器 VB Script Parser、Java Script Parser、XML Parser 等解譯後，傳給執行引擎執行。當然這是一張簡圖，許多功能並未列舉出來，不過相信讀者以經知道如何去實作一個瀏覽器了。

圖11

結論

HTML 的出現已經有非常長的時間，之所以歷久不衰，主要是因為它的文字檔案型態為各作業平台所接受，這對於系統整合的工作而言是項重要的一環。特別是當 XML 以及相關技術的出現更將此類的應用推向了極致。例如 BzTalk、Message Queue Server 中便大量的使用到 HTML、XML、 SOAP 等技術，而這些技術對於絕大的程式設計師而言，卻沒有多大驚人的門檻，但是卻可以整合許多的應用到我們的系統之中，並且使之更具彈性及多樣化。因此我們可以得到一個結論，『追溯今日許多的新技術，其實都是源自於原先對於 HTML 應用的衍生，因此，我們在不斷追求新的技術同時，其實也可以回過頭來探尋它的根源，並且從探尋的過程中，除了體驗先人對於技術研發的思考脈絡，並且藉此重新去觸發設計師靈感與創意！！』

參考資料

Rich Text Format (RTF) Version 1.5 Specification