微軟文本格式為何常跑掉？揭開 OOXML 格式大祕辛

微軟 Office 是不少人文本處理必備的程序，深獲不少人喜愛。但一旦用其他文本軟體開啟微軟 Office 的文件檔案 OOXML，卻常會出現問題，導致版面亂掉。日前文件基金會（The Document Foundation，縮寫 TDF）暨 LibreOffice 的創辦人 Italo Vignoli 訪台，在 COSCUP2017 開源人年會上開講，其後又假摩茲工寮發布專題演說，其中披露了許多鮮為人知的 OOXML 祕辛。

筆者先前在《Office 軟體到底該用哪個？各家格式標準為何？》該文粗淺提過辦公文件交換性與可閱讀性的課題，就像過去文房四寶跟紙張並無綁定廠牌，好的數位文件檔案格式也應該是如此。更進一步地，Italo Vignoli 在會中提到「interoperability」互通性的重要。

「interoperability」這個英文字拆解開來是 inter、operate、ability 的組合，意思是互用性或「互操作性」。舊時代可能認為文件印出來或簡報過一次就沒事了，印出紙本的原始檔案格式是啥沒關係；然而現在數位文件不只是一次性的「工作檔」功能，更有網路流傳與共同作業的需要。也就是說不單單只是筆者前文提到的交換性（exchange），更重要的是交換後，兩方要都要能無礙閱讀、可進行作業，才稱得上有互用性，良好的互用性就是更能一起工作，降低雙方成本。 一個互用性良好的檔案格式標準，可讓任何軟體都能正確使用（例如 wav、jpg、png、pdf 等，用哪個程序打開，呈現出來都一樣）。

（Source：Italo Vignoli CC BY 4.0）

互用性的基石有賴真正的開放文件標準、使用自由字形、跨平台軟體，文件標準的重要性不言而喻。深入比較文件基金會的 ODF 與 Microsoft 公司的 OOXML 時，會發現 OOXML 不具備真正符合「標準」意含的東西，其最關鍵的，是真正的標準不該對過去非標準的東西有相容性。

假想這種狀況。你買了電器要把插頭插到插座，如果發現得面對同一標準下，竟然包含了兩孔（平頭）、三孔（平頭）、兩孔（圓頭），電壓 220V、110V、100V 等不同規格，插頭即便可以插進去，卻還如履薄冰，操心電壓是否不同而產生危險，這種東西肯定不會叫標準。一個真正的新標準就是要割捨過去各種龐雜的規格而只使用一種，就像秦始皇施行書同文、車同軌政策，如果為了相容性把一堆不同軌距的軌道通通納入新標準繼續使用，這種「標準」稱不上標準。

遠古時代書寫不統一，同一件公告要用三種寫法各刻一遍。（Source：Italo Vignoli CC BY 4.0）

讓我們來實際看看 OOXML 的實際狀況。首先一個標準多半會以其他標準為基石，OOXML 也不例外，它採用了 Dublin Core 圖書原始資料國際標準，ODF 也是。然而，OOXML 只有使用這個，而 ODT 還採用了 XLS:FO、SVG、MathML、XLink、SMIL、XForms 等開放標準。那啥是 Dublin Core 呢？就是記載一份文件的標題、創建者、主題、描述、發行者、日期、類型、格式、語言、許可權等資訊，所以你可以發現 OOXML 的表格、排版樣規、圖片、數學描述式、超連結等等都跟現今通用標準大不同。跟當前標準不同的還有語言代碼，ISO639 國際標準是語言名縮寫的標準，例如 English=EN、華語是 ZH 等，然而 OOXML 卻有自己特有的編號，跟 ISO639 不互通，這導致 OOXML 會跟照 ISO639 標準製作的軟體有衝突。

更進一步我們來看顏色好了。在 ODF 裡面，不管是試算表、文件、簡報等等，紅色的代碼都是 #FF0000，然而 OOXML 呢？

竟然自家都不統一，甚至更誇張的是，顏色的色碼定義也都非標準，反而 SVG 傻傻地照標準色碼來實做。

（Source：Italo Vignoli CC BY 4.0）

這意味著如果你要寫一個 script 來批次改一大堆 OOXML 檔案，或者說要做大量分析（比如公文處理狀況統計），你會遇到很多麻煩。

我們接下去看。身為一個標準，正確性自然要有相當的講究，然而在月曆部分，OOXML 的規格卻有閏年蟲的錯誤。如果你的祖父生於 1900 年 3 月 1 日，OOXML 會把他的生日變到 2 月 29 日去。更進一步，OOXML 也不管其他曆法，例如猶太歷、回教歷，甚至東亞的農曆，只考慮西曆，這也就算了，更糟糕的是，OOXML 不會管操作系統的地區設定，Networkdays 函式永遠把周六、周日當成一周的最後兩天，然而猶太人、越南人、葡萄牙人、日本人、英國人等把周日當一周中的第一天，埃及人把周六當成一周的第一天。這導致很多問題，尤其對以色列與泛阿拉伯國家的使用者非常困擾，對於虔誠的基督徒、天主教徒來說，主日變成 7 天的末日也難以接受吧？

閏年蟲問題。（Source：Italo Vignoli CC BY 4.0）

再來看圖像問題，ISO / IEC 8632 是電腦圖像原始檔案標準（cgm），是描述一張圖片的原始檔（metafile），裡面可能含有向量圖、點陣圖與純文字，當辦公文件檔裡面要嵌入一張圖片時，需要附有一個 metadata 檔，然而 OOXML 卻是推薦自家 Windows Metafiles or Enhanced Metafiles 而不是 ISO / IEC 8632 或 W3C 標準的 SVG，這是在公開標準里暗藏私家規格，這有如你買了一包標準 A4 影印紙，卻發現只有特定牌子的墨水才能列印一樣荒謬。說到開放向量圖檔方面又有衝突了，ODF 採用 W3C 標準的 SVG，這是當今網路向量圖檔標準，以 XML 描述繪圖指令或嵌入點陣圖 ；而 OOXML 的 DrawingML 則是定義出 VML 這個不相容於 SVG 的規格，該規格在 1998 年提交給 W3C 後從未被贊同，甚至 Microsoft 自家瀏覽器在 IE 10 時也棄用，只剩下 OOXML 在用。

同樣類似的，MathML 不但是 W3C 描述數學式的標準，還是 ISO / IEC 26300 的標準（後來的 ODF），後起的 OOXML 的 Math 格式則故意做跟 W3C 的 MathML 有衝突且不互通。

更深入地剝開檔案格式的面紗，說到檔案格式，就會有複雜度的問題，不管是 ODF 或 OOXML 的檔案，核心都是 XML 檔，XML 的特色就是透明，人類可以方便閱讀的檔案，跟 XML 檔相對的是二進位格式檔案，二進位儲存的資料雖然檔案小，但只有機器看得懂人類看不懂。乍看之下，ODF 與 OOXML 核心都是 XML 檔應該差不多吧？其實不然。Vignoli 把同一篇文章輸入 LibreOffice 與 MS Office，使用一模一樣的編排，交叉存成 ODF 或 OOXML 格式，有驚人的發現。

讀者可以自己做實驗，ODF 的 odt、odp、ods 等以及 OOXML 的 docx 、pptx 、xlsx 等，都是 zip 檔，解壓縮以後可以看到其 xml 檔。

同樣用這篇文章輸入。（Source：Italo Vignoli CC BY 4.0）

會得到相差懸殊的行數與檔案大小。（Source：Italo Vignoli CC BY 4.0）

這邊可以發現不管用那一個軟體，輸出的 ODF 檔都小非常多，其次，單看檔案格式，OOXML 會有爆量的行數。ODF 兩百多行就描述清楚的東西，OOXML 要大到一萬多行！這究竟是為何？此外不管 OOXML 或 ODF，只要是 MS Office 存的，一定都會比較大，MacOS 版 MS Office 存出來尤其巨大。

用更簡單的測試方法，例如一個文件檔裡面只有「To be, or not to be, this is the question.」的內容測試文書軟體，odt 裡面會是類似這樣的內容（為方便閱讀理解有簡化過）。

（Source：Italo Vignoli CC BY 4.0）

docx 裡面則是如此的內容。

先垂直再水平看。（Source：Italo Vignoli CC BY 4.0）

是的，docx 的基本資料單位不是段落，而是「一個字加一個空白」，這可能是 MS Office 編排定位精準的秘密，然而你可能要傻眼了，如果要寫一個軟體來剖析大量的 docx 檔，收集大數據資料時（例如政府開放資料、公文等），你應該會寫到撞牆；不寫軟體也罷，只是閱讀可以吧？然而我們人類要讀的話非常困難，這完全違反了 XML 的設計精神──透明的人類可讀性，哪天核彈攻擊把世界所有軟體公司都摧毀了，僅存的人類還是可以看懂一個良好的 XML 檔，寫出呈現的軟體。

下面筆者再放上實際測試文章的結果，odt 可以快速找到文章本文在哪裡，而 docx 則把本文拆得支離破碎。

XML of ODT（LibreOffice）。

為了美觀，背後做了非常沒有效率的事情。圖為 XML of DOCX（MS Office 2016）。（Source：Italo Vignoli CC BY 4.0）

除此之外，Vignoli 還做了很多測試，發現 MS Office不管是存 OOXML 甚至存 ODF 時，還會偷偷塞不明的東西甚至是二進位格式內容（ODF 只有內嵌外部圖片與物件才用二進位格式），或把 ODF 本來設計的良好閱讀格式也弄得支離破碎（留意看「Suspendisse at mauris eget」開始的段落 ），人類難以閱讀，也對第三方軟體的判讀造成困擾。

ODF 本來良好的內文段落被拆散。圖為 XML of ODT（MS Office 2013）。（Source：Italo Vignoli CC BY 4.0）

OOXML 為何有這樣藏起來的巨大複雜度？有兩個原因，首先，當初審議 OpenXML 的 ECMA 國際組織就表示過，從一開始 OOXML 的設計就是忠實地把 Microsoft 公司私家定義的 doc、ppt、xls 二進位格式轉成 XML 格式，這表示並沒有依照 XML 的特性最佳化，而其私有格式內含的額外非標準元件也含在內，例如 ActiveX 等等（過時，且容易用來攻擊）；第二個原因是 Bill Gates 在 1998 年留下的備忘錄，提到「不能讓其他瀏覽器可完美呈現 MS Office 文件，只能讓自家公司專屬 IE 可正確呈現」（雖然現在 IE 已中止發展），現在的狀況可以說 Microsoft 延續 Gates 的精神，使「現代的 MS Office 存出的 OOXML 檔」刻意做成第三方軟體不好完善地解讀、呈現，而這顯現 OOXML 號稱開放標準的荒謬。

摘自 PX02991.pdf。

也就是說 Microsoft 為了企業利益，不惜製造「巴別塔」，辦公文件越是混亂不互通（包含不同代 MS Office 存出的 OOXML 檔），越是有利於 Microsoft 公司，可是這樣不互通、格式不穩定不利於消費者，巴別塔就意味著巨大的資訊交換成本。但這都什麼時代了，大家上網用不同的瀏覽器讀一樣的 html5 頁面，用不同的影片軟體看藍光、DVD、mp4 ；不同的播放器放 aac、ogg、mp3；用不同的軟硬體修圖，製作 png、jpg 等；用不同的軟體製作 epub、pdf，為什麼獨獨辦公文件軟體就要被搞成巴別塔？

檔案內越是有巨大且隱匿的複雜度，就越難找到其中有問題的代碼，也就是說就越容易被黑客暗藏攻擊。

（Source：Italo Vignoli CC BY 4.0）

從 2011 年 Symantec 公司的統計資料可以看到，Office 檔案的病毒破壞案例之多，某些時候甚至多於執行檔病毒，Office 檔案里除了真正的文件資料，還有很多冗餘擾亂第三方軟體解讀的代碼，病毒就可以藏在這溫床中，不易追查到。試想，除了可執行檔以外，各種資料檔案格式中，長期以來為什麼就是 MS Office 的檔案最會中毒呢？（雖然 PDF 也不遑多讓，但其漏洞是因為可以夾藏檔案，包含有毒 docx 檔）是否這樣龐雜的檔案格式促成了病毒製造者與防毒公司的雙贏？

最後我們可以發現要作 open data 用或要廣為傳布的文件時，OOXML 真的有太多互通性、安全性、可檢閱性的疑慮，所以採用一個標準必須非常審慎。

（首圖來源：pixabay）

如需獲取更多資訊，請關注微信公眾賬號：Technews科技新報

維基媒體協會理事、開源碼軟體創作者、音樂人，關心開放原碼軟硬體的發展，以及在創作上的應用。

未經許可，任何媒體、網站或個人不得複製、轉載、或以其他方式使用本網站的內容，違者必究。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！