設計及製作一文件保護與講解錄製之應用系統-以PDF和TXT文件為例

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

設計及製作一文件保護與

講解錄製之應用系統-以 PDF 和 TXT 文件為例

Design and Implementation of a Mechanism for

Document Protection and Recording – Using PDF and TXT

documents as examples

研 究 生：林倫譽

指導教授：陳登吉 教授

設計及製作一文件保護與講解錄製之應用系統-

以 PDF 和 TXT 文件為例

Design and Implementation of a Mechanism for Document Protection

and Recording – Using PDF and TXT documents as examples

研 究 生：林倫譽 Student：Lun-Yu Lin

指導教授：陳登吉 Advisor：Dr. Deng-Jyi Chen

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

July 2008

Hsinchu, Taiwan, Republic of China

i

設計及製作一文件保護與

講解錄製之應用系統

學生：林倫譽 指導教授：陳登吉 博士

國立交通大學資訊工程學系碩士班

摘要

隨著資訊發達、網際網路的便捷，文件原始作者(content creator)可以輕 易地將自己製作的文件，透過網路在平台上分享知識；讀者(content reader) 亦可透過網路，輕易取得該文件來閱讀、複製、列印、甚至是編輯，這對文件原 始作者的智慧財產權是一重大打擊。因此，我們頇思考如何對文件原始作者分享 的文件作保護，以維護文件原始作者該有的權益。 許多關切這個議題的公司：如微軟，從 Microsoft Office 2003 版本開始 提供文件保護的機制，稱作IRM(Information Right Management)的文件加 密管理[4][5]。每位使用者或群組根據文件原始作者定義的存取層級，賦予使 用權限：讀取、變更或完全控制；Adobe 在 2006 年 12 月發佈 Adobe LiveCycle Policy Server 7.2[8]，對於 Adobe Acrobat 文件播放器權限控管的生命週期 從文件建立直到歸檔與銷毀，之中透過發送與協同合作方式來持續保護並控管文 件。 不論是微軟或者Adobe，都僅針對自己發展的文件作保護，對於文件原始 作者而言是一大負擔，因為必頇學習各種不同的文件保護方式。因此本研究的首 要目標，便是提供一文件保護機制，來保護各種不同類型的文件，讓文件原始作 者僅需熟悉一種簡易的操作模式，即可做出對文件的限制，達到智慧財產權的保 護。 另外，現有的文件播放器，並無提供講解錄製的功能，對於以文字為主的文 件而言，會使讀者在閱讀時不易掌握內文重點。因此本研究另一個研究重點，就 是提供文件的多媒體講解錄製功能，讓讀者在閱讀文件時，可在第一時間了解文 件的重點所在。

ii

Design and Implementation of a Mechanism

for Document Protection and Recording

Student: Lun-Yu Lin Advisor: Dr. Deng-Jyi Chen

Department of Computer Science and Information Engineering

National Chiao Tung University

Abstract

With the convenience of the Internet, content creators can share their knowledge easily with document they have made through the Internet. Content readers can also read, copy, print, even edit any documents what he wants easily by way of the Internet. This is a great challenge on content creator's intellectual property rights. In order to protect the property rights for content creators, we must face the issue of document protection.

Companies such as Microsoft and Adobe have taken actions on this issue. For example, Microsoft office provides a mechanism for document protection starting from version 2003, called Information Rights Management[4][5]. According to permission levels defined by content creators, individuals and group users are assigned to some access rights such as reading, changing, or full control. The Adobe company released the product - Adobe LiveCycle Policy Server 7.2 [8] - in December, 2006. For Adobe Acrobat's access control management, Adobe LiveCycle Policy Server provides to monitor the whole lifecycle from every document which is established or destroyed.

Since Microsoft and Adobe use the mechanism for document protection only working on their own products. This will create burdens for content creators because they must learn different ways of setting for different document formats (i.e., doc or pdf). For this reason, the first objective of my thesis study is to provide a mechanism for document protection that can be applied to all kinds of document formats.

The second objective of my thesis study is to provide document narration recording capability for the document under consideration. Through this extension feature, document readers can enhance the document’s capability to incorporate multimedia narration during the presentation mode.

iii

誌謝

首先感謝我的指導教授陳登吉老師，老師無論在課業、或研究上，每當我遇 到問題與挫折時，都會耐心的指導我，並給予我實質的建議與方向。即便在研究 的過程中受到飽受打擊，甚至得重新開始，老師依舊對我有信心，也給了我更多 的鼓勵，讓我能順利的走下去，我由衷地感謝老師。 再來要感謝的是一群在實驗室為研究而努力的同學們，能夠在課業上相互扶 持，有問題大家一起討論解決；當研究上遇到瓶頸時，這些好同學能給我很多建 議，讓我能夠完成這項研究。 最後我要感謝在背後默默支持我的家人與朋友們，打從我決定轉科系、跨入 資訊方面的知識領域，家人就不斷地給予我正面的鼓勵，也相信我一定可以做得 很好；朋友們也時常噓寒問暖，了解我的近況，分享我的心事，做個專職的傾聽 者。有了支持我的家人與朋友，讓我更堅決自己所要走的路，並能義無反顧的做 下去。

iv

表目錄

表 1、PDF 版本的演進 ... 3

表 2、PDF 軟體列表 ... 16

表 3、Data reference atom 欄位說明 ... 21

表 4、Reference data 欄位說明 ... 22

v

圖目錄

圖 1、PDF 檔案格式架構 ... 4 圖 2、DES-EEE3 加密法 ... 5 圖 3、DES-EDE3 加密法 ... 6 圖 4、DES-EEE2 加密法 ... 6 圖 5、DES-EDE2 加密法 ... 6 圖 6、Microsoft 文件控管流程 ... 9 圖 7、權限畫面設定 ... 9 圖 8、新增保全策略 ... 10 圖 9、選擇使用密碼保護 ... 10 圖 10、輸入策略名稱與說明 ... 11 圖 11、設定保全密碼 ... 11 圖 12、再次確認保全密碼 ... 12 圖 13、確認設定資訊 ... 12 圖 14、套用保全策略 ... 13 圖 15、輸入密碼 ... 13 圖 16、允許閱讀文件 ... 14 圖 17、講解手錄製工具之介面 ... 17 圖 18、文件保護與講解錄製的運作機制 ... 18 圖 19、BST 檔案格式架構 ... 21 圖 20、文件編碼器運作流程... 22 圖 21、文件解碼器運作流程... 24 圖 22、場景的 XML 描述檔 ... 25 圖 23、文件的 XML 描述檔 ... 25 圖 24、專案的 XML 描述檔 ... 26 圖 25、文件解析模組運作流程... 26 圖 26、系統架構... 28 圖 27、製作端、閱讀端與 Server side 三者之間的關係 ... 30 圖 28、文件保護流程... 31 圖 29、文件多媒體講解錄製流程... 32 圖 30、文件編碼器的演算法流程... 34 圖 31、文件解碼過程... 37

圖 32、文件解析模組套用 Observer Design Pattern 的運作方式 ... 38

圖 33、文件解析模組之 sequence diagram ... 39

圖 34、文件裁切結果，左至右、上至下依序為裁切 60 列、90 列、120 列、及 150 列... 44

vi 圖 35、文件解析模組之內容協調... 45 圖 36、將協調好的素材在講解錄製工具的顯示區域中呈現... 46 圖 37、未裁切(左)與裁切後(右)的文件顯示 ... 46 圖 38、不同延展方式的呈現效果... 47 圖 39、文件保護操作步驟... 49 圖 40、選擇文件發佈位置(以學習平台為例) ... 50 圖 41、輸入學習平台的帳號密碼... 50 圖 42、匯入要編碼轉換的原始文件 ... 51 圖 43、設定文件資訊... 52 圖 44、設定 DRM 驗證資訊與使用權限 ... 53 圖 45、新增 DRM 帳戶 ... 54 圖 46、將編碼後的文件上傳過程 ... 54 圖 47、將編碼過的文件放置在學習平台供讀者觀看... 55 圖 48、讀者從學習平台開啟一份受保護的文件... 55 圖 49、輸入帳號密碼供 DRM server 驗證 ... 56 圖 50、使用文件播放器閱讀文件... 56 圖 51、文件多媒體講解錄製操作步驟... 57 圖 52、啟動錄製模式... 57 圖 53、透過講解錄製工具來解說文件重點... 58 圖 54、發佈講解錄製完畢的文件內容 ... 58 圖 55、錄製完畢所產生的文件講解檔... 59

vii

目錄

摘要... i Abstract ... ii 誌謝... iii 表目錄... iv 圖目錄... v 目錄... vii 一、 緒論... 1 1.1 研究動機 ... 1 1.2 研究目標 ... 1 1.3 研究方法與步驟 ... 2 1.4 相關名詞解釋與研究範圍 ... 3 1.5 章節說明 ... 6 二、 相關研究與探討... 8 2.1 文件控管流程... 8 2.1.1 Microsoft 文件控管流程 ... 8 2.1.2 Adobe 文件控管流程 ... 9 2.1.3 使用上的問題... 15 2.2 相關工具介紹... 15 2.2.1 XPDF 函式庫 ... 15 2.2.2 智勝國際科技公司講解手... 16 三、 系統需求分析... 18 3.1 文件保護與講解錄製的運作機制... 18 3.2 文件編碼器... 20 3.2.1 BST 檔案格式 ... 20 3.2.2 文件編碼器運作流程... 22 3.3 文件解碼器... 23 3.3.1 文件解碼器需求分析... 23 3.3.2 文件解碼器運作流程... 23 3.4 文件解析模組功能需求分析... 24 3.5 文件講解錄製模組需求分析... 24 3.5.1 XML 描述檔 ... 25 3.5.2 文件講解錄製模組運作流程... 26 四、 系統架構與流程... 28 4.1 系統架構... 28 4.2 文件保護流程... 30

viii 4.3 文件講解錄製流程... 32 五、 系統設計與實作... 33 5.1 文件編碼器的實作... 33 5.2 文件解碼器的實作... 36 5.3 文件解析模組的實作... 38 5.4 文件講解錄製模組之內容協調... 42 六、 應用範例... 49 6.1 文件保護的操作方式... 49 6.1.1 製作端... 50 6.1.2 閱讀端... 55 6.2 文件講解錄製的使用說明... 57 七、 結論與未來展望... 60 7.1 總結... 60 7.2 未來展望... 61 參考文獻及資料... 62

1

一、 緒論

1.1 研究動機

隨著網路的普及，越來越多的文件原始作者會將自己製作好的電子文件，利 用網路這個媒介發佈出去，供讀者閱讀觀看；在許多的場合，例如：會議、辦公 室、講堂，主講者都會利用電子文件來做呈現、講授、及教學，電子化的程度不 可同日而語，因此我們必頇站在文件原始作者的角度來思考，提供一個控管與保 護的機制，讓文件原始作者的智慧財產權達到一個完整的保護。 然而，現今的文件類型眾多，如：doc、pdf 等，加上發展這些文件的公司， 如：Microsoft、Adobe，它們僅針對自己發展的文件實現控管與保護的機制， 使得文件原始作者必頇了解各種文件保護的設定方式，造成文件原始作者在使用 上的負擔。所以本研究第一個研究動機，就是提供一文件保護機制，不論何種類 型的文件，文件原始作者都可以使用一貫的作法來讓自己製作好的原始文件獲得 保護。

另外，現有的文件播放器( 如：Adobe Acrobat、Microsoft Notepad、 Microsoft Office Word )，並無提供文件講解錄製的功能。想像一個情境，當 主講人開啟一份文件準備講授其中的內文重點，而對於底下的聽眾，會因眼前密 密麻麻的文字而對這次演說失去興趣，這對於主講人是多麼大的打擊。所以本研 究的另一個研究動機，就是提供多媒體講解錄製的能力，讓讀者或聽眾可以快速 掌握內文重點。

1.2 研究目標

本研究共有兩大目標：「文件保護」與「文件多媒體講解錄製」。在「文件保 護」的部分，本研究針對各種類型的文件，如：pdf、txt，使用相同的文件保護 機制。讓文件原始作者一來只需了解一種文件保護的設定方式；二來僅需熟悉一 種簡易的操作模式，即可做出對文件的限制，達到智慧財產權的保護。 在「文件多媒體講解錄製」這部分，本研究會與智勝國際科技公司的講解錄 製工具：『講解手』作配合。針對一份靜態文件，透過讀者利用虛擬畫筆對文件 畫記重點、以及聲音講授文件內容的同步錄製方式，達到重點的解說。錄製完成 後的文件，有利讀者在往後閱讀時，可以快速地掌握內文重點。 由於文件的類型不勝枚舉，本研究會以pdf 與 txt 文件為實驗對象，說明文 件保護的運作機制與方法。其中pdf 具有「跨平台」、「開放標準」、「可將其他類

2 型的文件轉換成pdf 文件」；而 txt 是由 ASCII 交換碼字元組成，為一文字檔， 可攜性高，和pdf 皆為使用者廣泛使用的對象，因而採用。

1.3

研究方法與步驟

本研究在「文件保護」這方面，由於現有的文件的類型不計其數，因此本研 究會透過pdf 和 txt 這兩種文件作為實驗對象，來說明文件保護的機制是如何運 作，並且說明該文件保護機制是可以套用在各種類型的文件；針對「文件的多媒 體講解錄製」，首先，需了解智勝國際科技公司的講解錄製工具─『講解手』如 何運作，並進一步與該錄製工具作配合。研究的方法與步驟大略分為下列幾點： (a). 了解與評估現存系統： 針對文件保護的運作流程，著手找尋現有的文件保護系統，了解其使用 方法與運作過程，經過整理分析之後，衍伸出本研究在文件保護與講解 錄製系統之設計方式與運作機制。 (b). 了解文件格式： 針對本系統的實驗對象pdf 與 txt，研究其檔案格式，並製作出文件播 放器。 (c). 分析系統的需求： 依據本研究所規劃的文件保護與講解錄製系統的運作機制，分析所需要 的功能模組，及模組間的溝通方式；接著分析智勝國際科技公司的講解 錄製工具對資料的處理方式，設計一功能模組與講解錄製工具作溝通。 (d). 架構與流程的說明： 接著介紹本研究的系統架構，以及文件保護與文件多媒體講解錄製的系 統運作流程。 (e). 系統實作： 依照所分析的系統需求，與實驗對象，建置開發環境與工具，並著手實 作出各個模組，進而完成整個系統。 (f). 應用實例與結論： 接下來會逐步說明本系統如何將文件原始作者製作好的文件，利用本研 究所擬訂的保護機制，達成文件保護的功效。另外，當讀者在閱讀這份 受保護的文件時，可以透過錄製模式，對內文做重點的畫記，以及利用 聲音講解文件內容，錄製完畢產生的文件講解檔，有利讀者在往後閱讀 時，更容易掌握內文重點。在最後一個章節，會總結本研究在文件保護 規劃上的彈性，使用上對文件原始作者所提供的安全性、便利性，以及 文件講解錄製所賦予文件額外的能力。

3

1.4 相關名詞解釋與研究範圍

本研究根據1.2 節所提出的研究目標，提供相關名詞及參考範圍，茲描述 如下： (a). 個人電腦上多媒體講解錄製工具—智勝國際科技公司講解手：[12] 將一份匯入的簡報，利用畫筆、聲音的同步錄製。錄製過程中，產生主 講者操作畫筆的描述檔、簡報轉換後的素材檔、與講解過程中的聲音檔 案。錄製完成後，產生一份簡報的講解檔，當中富含生動的多媒體講解 錄製內容之呈現。

(b). PDF 檔案格式—Portable Document Format：[11]

PDF 為 Portable Document Format 的簡稱，稱作「便攜式文件格 式」，是由Adobe 公司在 1993 年用於文件交換所發展出來的文件格 式，共歷經八個版本號(v1.0-v1.7)。 表 1、PDF 版本的演進 年份 版本號 播放器版本 1993 PDF 1.0 Acrobat 1.0 1994 PDF 1.1 Acrobat 2.0 1996 PDF 1.2 Acrobat 3.0 1999 PDF 1.3 Acrobat 4.0 2001 PDF 1.4 Acrobat 5.0 2003 PDF 1.5 Acrobat 6.0 2005 PDF 1.6 Acrobat 7.0 2006 PDF 1.7 Acrobat 8.0 它的優點在於跨平台、能保留文件原有格式(Layout)、開放標準、能 免版稅(Royalty-free)的讓程式設計師自由開發 PDF 相容軟體。PDF 的最新版本在2007 年 12 月成為 ISO 32000 國際標準。以下簡單介 紹PDF 檔案格式：

4 圖 1、PDF 檔案格式架構 PDF 檔案格式由四個部分所組成： 1) Header 用來記錄PDF 的版本號，如：%PDF-1.7，就代表這份文件是最 新版本。 2) Body 一份PDF 文件，當中的文字、影像、表格、聲音、圖形等多媒體 內容，都是以物件(object)的形式存在此區段，物件之間亦可以相 互參照。當需要解析某一頁的內容時，只要找到相對應的物件，利 用一些解碼、解密的方式，即可正常顯示內容。當然，在這解析的 過程中，就需要查詢Cross-reference table，來找到物件。 3) Cross-reference table 此區段記錄著PDF 文件中每一個物件所在，所記錄的資訊包含： 物件編號、物件在檔案中的位址、物件的偏移量(offset)等。 4) Trailer 此區段用來記錄整份文件的屬性：如檔案大小、Cross-reference table 的起始位址等。 (c). TXT 檔案格式： TXT 檔案格式是以文字檔的形式儲存，意即檔案中僅包含為人所能辨 識閱讀的ASCII 交換碼字元，可攜性高。

5 (d). 內容協調(Content Adaptation)：[13] 內容格式的轉換與協調，為適應不同顯示裝置的特性所做的額外處理， 使讀者可以達到較佳的觀看品質。本研究會針對文件的多媒體講解錄製 使用內容協調的技術，並在第三章的系統需求分析說明其原因；以及第 五章的系統設計與實作說明實作方式。

(e). DRM 數位版權管理(Digital Rights Management)：[10]

提供給出版者用於控制對數位內容存取的限制，數位內容包括軟體、音 樂、電影等，透過數位版權管理的方式，使用者若未經授權，是無法使 用該數位內容。而本研究所提出的文件保護機制，會配合智勝國際科技 公司所建置的DRM server，來提供完整的文件追蹤與管理 (f). 演算法介紹：ZIP、AES、Triple DES：[1][2][3] 在第二章相關研究與探討的最後會提出本研究的系統設計概念，當中需 要一些現有演算法來作配合，因此本研究利用上述三者為實作的對象， 這在第五章系統設計與實作會詳細說明，以下先做簡單的名詞介紹： 1) ZIP 為一種壓縮文件與資料夾的檔案格式，其副檔名為「.zip」。 使用ZIP 格式中所定義的演算法來作壓縮，可有效減少檔案系統 中空間的耗費。其他像是RAR、7-Zip 也與 ZIP 同為壓縮的檔案 格式。

2) 高級加密標準(Advanced Encryption Standard，AES)，是美

國聯邦政府採用的一種區塊加密標準，和DES 同為對稱型加密演

算法。由於DES 演算法的加密金鑰長度不足所引發安全性上的問

題，因而衍伸出這個演算法用來替代原先的DES。AES 在 2002 年5 月 26 日成為有效的標準。

3) Triple DES 是透過 DES 加解密演算法的反覆運作來增加複雜度， 分為四種方式：  DES-EEE3：以三把不同金鑰，依序加密、加密、加密的方式 處理。 圖 2、DES-EEE3 加密法  DES-EDE3：以三把不同金鑰，依序加密、解密、加密的方 處理。

6 圖 3、DES-EDE3 加密法  DES-EEE2：以兩把不同金鑰，依序加密、加密、加密的方式 處理。其中第三次加密所使用的金鑰與第一把金鑰相同。 圖 4、DES-EEE2 加密法  DES-EDE2：以兩把不同金鑰，依序加密、解密、加密的方 處理。其中第三次加密所使用的金鑰與第一把金鑰相同。 圖 5、DES-EDE2 加密法

1.5 章節說明

本論文共分為七個章節，以下簡單說明各章節內容： 第一章，首先介紹文件保護與文件多媒體講解錄製的重要性，進一步引導出 本研究的動機與目標，並且簡略地介紹研究方法與步驟。最後，著手了解本研究 的實驗對象：pdf 與 txt 檔案格式。

第二章，介紹現有的文件保護系統，例如：Microsoft Information Rights Management、Adobe LiveCycle Policy Server，逐步說明這兩套系統如何 對文件作權限設定與保護，並進一步引出使用上所發生的問題，以及解決方式。

第三章，根據上一章提出的解決方式，衍生出本研究在文件保護與解講錄製 系統上的運作機制，規劃出所需的功能模組，著手分析各模組的功能、以及模組 間該如何溝通。

7 第四章，介紹本研究的系統架構，以及說明在此架構之下，系統的運作流程 是如何進行。 第五章，詳細介紹各個模組的設計概念、與實作方式，並且說明如何與現有 的DRM server 溝通，達到對文件的控管；另外，詳述如何與智勝國際科技公 司的講解錄製工具作配合，完成對文件的多媒體講解錄製能力。 第六章，將實作出來的系統，透過畫面擷取、與文字解說，逐步說明系統如 何從一份未受保護的文件，轉換成一份受DRM 保護的文件、讀者如何通過伺服 器的認證並閱讀該文件、以及如何利用講解錄製工具，達到對文件的重點錄製。 第七章，本章為總結，說明本研究的研究結果，所達成的研究目的，以及未 來展望。

8

二、 相關研究與探討

隨著網際網路的便利，讀者可以輕易地取得未受保護的文件來閱讀，這對於 文件原始作者的智慧財產權無疑是一種傷害。因此有許多公司，例如：微軟、 Adobe，開始針對自己所發展出來的文件做權限控管與保護。在接下來的幾個 小節，會先對這兩套系統做流程說明，並歸納出使用上的問題，最後，再對本研 究所使用的相關工具作介紹。

2.1 文件控管流程

2.1.1 Microsoft 文件控管流程

Microsoft 辦公室軟體(Microsoft office)在 2003 與 2007 的版本，開始 支援文件權限控管與保護，稱作IRM(Information Rights Management) [4] [5]，支援的文件格式包括：doc、xls、ppt、eml。此系統需要一台 DRM server， 而這台伺服器由Microsoft 提供，文件原始作者毋頇自行架設。

由於此兩版本的文件控管流程一致，以下針對2007 的版本作說明。 1. 首先，文件原始作者自行下載並安裝 Windows Rights Management

Services (RMS) 1.0 用戶端軟體[6]。 2. 若文件原始作者沒有.net passport 帳戶，則必頇上網申請，申請完畢 後，會透過微軟的認證伺服器建立一張憑證給用戶，該憑證是作為日後 DRM server 確認身分的依據。 3. 啟動 word 文書軟體，按下開始鈕 ，選擇「準備→限制權限→限制 存取」。 4. 接下來文件原始作者開始針對不同用戶建立文件的存取等級，共分作三 類：「讀取」、「變更」、「完全控制」。 5. 設定完畢後，文件原始作者可以透過網路、或卸除式裝置來發送文件。 下頁圖6 說明 IRM 如何讓文件原始作者設定讀者權限。首先，文件原始作 者頇按下新增按鈕，接著一個個手動輸入擁有使用權限的讀者帳號，以及訂定相 關使用政策，最後按下確定按鈕即可完成設定。 從這裡我們可以發現，文件原始作者頇自行將每位讀者的帳戶一個個手動輸 入進去，這對於文件原始作者而言非常不方便且耗費時間，也降低文件原始作者 使用的意願，導致無法有效地解決問題。

9

圖 6、Microsoft 文件控管流程

2.1.2 Adobe 文件控管流程

Adobe 會將文件原始作者對權限設定的資訊以 Access Control List(ACL) 的方式儲存於檔案中，所以每次開啟文件，文件播放器會在剖析檔案格式的同 時，順便檢查這些片段(pattern)，來達成文件保護的功效，以下透過 Adobe Acrobat 8.0，逐步說明設定方式。

Step1、點選「保全→管理保全策略」，會開啟管理保全策略的視窗。(圖 7)

10 Step2、接著按下新增按鈕，會彈出新增保全策略的視窗來讓文件原始作者作設 定，一共分為四個步驟：選擇保全類型、一般設定、文件限制、摘要， 以下會說明各步驟。(圖 8) 圖 8、新增保全策略 Step3、首先是選擇保全類型，採取「使用密碼」的方式做保護，選擇完畢後按 下一步，進入一般設定。(圖 9) 圖 9、選擇使用密碼保護

11 Step4、一般設定的部份，主要是針對此次所新增的保全策略設定名稱，以及一 些相關說明，輸入完畢後按下一步，進入文件限制的設定。(圖 10) 圖 10、輸入策略名稱與說明 Step5、文件限制的設定頁面是用來設定開啟文件的密碼，文件原始作者輸入完 密碼後按下一步。(圖 11) 圖 11、設定保全密碼

12 Step6、Adobe Acrobat 文件播放器會再次詢問上一步所設定的密碼，以便確 認密碼是否正確，接著就是最後一個步驟。(圖 12) 圖 12、再次確認保全密碼 Step7、新增保全策略的最後一個頁面是用來顯示方才所設定的資訊摘要，為了 讓使用者作最後的確認，若正確無誤就按下完成鈕，即完成一個保全策 略的新增。(圖 13) 圖 13、確認設定資訊

13 Step8、接下來就是將上述 Step1~Step7 所產生的一個新的保全策略套用至 目前所開啟的文件中，也就是按下右下方的「套用至文件」按鈕。 (圖 14) 圖 14、套用保全策略 Step9、往後若想開啟這份文件，便會先彈出一個視窗，要求使用者輸入密碼， 輸入的密碼正確後，才能順利開啟該份文件來閱讀。(圖 15) 圖 15、輸入密碼

14 Step10、輸入的密碼正確後，即可順利閱讀該份文件。(圖 16) 圖 16、允許閱讀文件 PDF 文件格式是開放標準，任何人皆可以取得相關說明書(specification) 來了解其格式，因此使用ACL 的方式來保護文件，會面臨一個潛在性的問題： 若該讀者熟悉PDF 檔案格式，只要直接從格式的內容作修改即可破解，就算讀 者不了解PDF 檔案格式，現今在網路上可以找到許多破解工具來解除權限的限 制，所以這種保護方式是不夠安全。

因此Adobe 公司在 2006 年底推出 Adobe LifeCycle Policy Server，用 來持續追蹤文件的去向，以及管理文件的使用權限。以下簡單說明使用方式： Step1、首先，文件原始作者必頇擁有Adobe ID 帳戶，並且上網作登入，成

功後才能下載Adobe 公司提供的詴用版軟體。

Step2、下載 Adobe LifeCycle Policy Server，並自行架設此伺服器，檔案大 小約為2.9 GB。由於該系統是建立在 Java 2 Enterprise Edition 的 環境，所以需額外安裝Java Virtual Machine、另外還需安裝 JBOSS webserver 與 MySQL database，並完成相關的組態設定。

Step3、文件原始作者可以開始在 Adobe LifeCycle Policy Server 上設定使 用權限(或稱作安全性原則)。

Step4、文件原始作者透過 Adobe Acrobat 文件播放器來開啟一份未受保護的

文件，並利用先前提到的做法「保全→管理保全策略→新增」，並選擇

保全類型為「使用Adobe LifeCycle Policy Server」，接著輸入帳戶 資訊，認證通過後即可套用Step3 所定義好的安全性原則。

15

2.1.3 使用上的問題

從2.1.1 與 2.1.2 這兩小節的討論中，我們可以發現，Microsoft、Adobe 各自開發出來的文件控管系統，保護的對象僅針對自己所發展的文件類型，而且 彼此的DRM server 並無一個溝通的管道用來分享文件的使用政策，這對於文 件原始作者在使用這兩套獨立的系統時，會面臨到幾點不便： 1. 文件保護作法不一，文件原始作者若希望使用該服務，兩套系統就都必 頇學會如何設定，增加使用上的複雜度。 2. 文件原始作者在設置使用環境之前，都必頇上網各申請一組帳戶，才能 合法使用。另外，在設定文件的使用權限之前，文件原始作者都需要各 登入一次，給DRM server 做身份確認，確認通過後才能進行後續操 作，使用步驟繁瑣。 3. 對於 Microsoft 文件控管的設過程，文件原始作者需要一個個手動輸入 允許使用該文件的讀者帳戶；而Adobe LiveCycle Policy Server 複 雜的安裝與設定過程也只適合用在企業、組織，且需要專業的技術人員 協助建置，這些對於文件原始作者而言是一大負擔。 對於這些使用上的問題，本研究在第三章會提出一文件保護與講解錄製的機 制來解決上述的問題，並分析在此機制的運作下所需的功能模組。

2.2 相關工具介紹

本研究所需要的文件播放器是自行撰寫，並非使用現有的文件播放器，原因 在於需要同時滿足兩個需求：「開啟各種不同格式的文件」、「能夠在記憶體中讀 取文件」，然而，現有的文件播放器無法同時支援以上兩個需求，因此這部份需 實作出來。 本研究的實驗對象有二：txt 與 pdf，前者為文字檔，檔案格式由 ASCII 字 碼所組成，無額外的格式標籤，可以直接讀取到內容；後者的檔案格式相對複雜 許多，需要配合格式說明書[7]以及相關工具來處理。

2.2.1 XPDF 函式庫

由於pdf 為一跨平台與開放標準的檔案格式，因此有許多專為 pdf 所撰寫 的工具，以下列舉一些pdf 的相關軟體名稱：

16

表 2、PDF 軟體列表

Linux/UNIX Mac OS X Microsoft Windows Adobe Reader Adobe Reader Adobe Reader Foxit Reader Foxit Reader Foxit Reader Evince PDFView Sumatra PDF[16]

KPDF Preview CutePDF

Xpdf[15] Skim PDF-XChange Viewer

表2 所提及的 pdf 軟體皆可讓使用者免費下載使用。另外，本研究會配合 Xpdf 所提供的函式庫來處理 pdf 檔案格式。Xpdf 為一個 Linux/UNIX 下的 pdf 文件播放器，其中所使用的函式庫為跨平台、開放原始碼，並且以C++語言撰 寫出來，適合本研究所需的開發環境，因而採用。

2.2.2 智勝國際科技公司講解手

講解手錄製工具為智勝國際科技公司所研發的產品之一[12]，可以將一份 簡報檔(ppt)匯入，並利用虛擬畫筆與聲音的同步錄製，來對簡報檔的做重點式 的講解。本研究會將一份文件轉換成講解手所需要的素材與腳本檔案，接著利用 講解手的特性與能力，來對文件做重點解說。 在第三章的系統需求分析會進一步說明講解手所需要的素材和腳本檔案為 何。下頁圖17 為講解手錄製工具的介面，其中右方白色顯示區域，比例約為 4:3 的繪圖區，是講解手錄製時的工作區域。使用者可以在智勝國際科技公司的 官方網站取得詴用版來詴用[12]。

17

18

三、 系統需求分析

依據「2.1.3 使用上的問題」一節中所提出 Microsoft 與 Adobe 文件保護 與控管系統使用上所面臨的問題，在3.1 節會說明本研究所提出的方法，並根 據整個系統的運作機制，著手分析所需的功能模組，與各模組的運作流程。

3.1 文件保護與講解錄製的運作機制

本研究擬發展一文件保護與講解錄製之應用系統，當中為了解決2.1.3 節 所提及使用上的問題，該系統頇滿足以下幾點特性： 1. 文件保護與控管的機制要能因應各種類型的文件，讓文件原始作者毋頇 針對不同類型的文件，學習不同的設定方式。 2. 只需一套 DRM server 來對用戶身份、及文件的使用政策作追蹤與管 理。對於文件原始作者而言，只需要一組帳戶來讓DRM server 作身 份確認，使用時只需登入一次即可。 3. 提供現有文件播放器所缺少的多媒體講解錄製能力，利用畫筆與聲音來 講解內文重點，以便讓讀者在閱讀文件時可以更快速地掌握內文重點。 圖18 為本研究所提出的文件保護與講解錄製之系統，該機制的運作滿足上 述的所提及的特性，後續會對此圖作詳細解說： 圖 18、文件保護與講解錄製的運作機制

19

整個運作機制分為兩個部份：「End-user side」和「Server side」。在 「End-user side」這部分，有製作端與閱讀端。首先，製作端(即文件原始作 者)會將未受保護的文件，利用一個轉換工具(稱為文件編碼器)，將各種類型的 文件都編碼成統一的格式，並且在轉換過程中加入DRM 的相關資訊，以便日後 和DRM server 作溝通。 此轉換工具具備著能將各種類型的文件作限制與保護，讓文件原始作者只需 了解一種設定方式，即可對自己所分享的各種類型的文件作保護。 轉換完畢後，產生一份受保護的文件，並透過網際網路上傳至學習平台，供 讀者觀看，DRM server 也會持續追蹤這份受保護的文件。這其中的學習平台與 DRM server 構成「Server side」的部分。

在此要補充一點，學習平台只是一個存放的媒介，為了方便說明本研究所提 出的文件保護與講解錄製運作機制。文件原始作者亦可將受保護的文件存放在本 地端的電腦，然後透過網路或卸除式裝置自行發佈文件給讀者閱讀。 接下來是「End-user side」的閱讀端，也就是所謂的讀者。當讀者需要開 啟這份受保護的文件之前，先透過本地端的文件解碼器來和「Server side」的 DRM server 溝通，並且將讀者的驗證資訊送交給 DRM server 作確認，待檢 查通過後，文件解碼器即可從DRM server 取得解密金鑰，並且將該份文件作 解碼的動作，解碼完畢後即可閱讀以及講解錄製該份文件。 整個運作機制從製作端到「Server side」，再到閱讀端，一氣呵成。接下 來開始介紹構成整個系統所需的模組，分製作端與閱讀端： (a). 製作端：為文件原始作者所需要的轉換工具，文件編碼器。 (b). 閱讀端：為讀者所需要的文件播放器，該播放器包含文件解碼器模組、 文件解析模組、與文件講解錄製模組。 文件編碼器和文件解碼器構成文件保護機制中重要的一環，轉換過程會連線 和DRM server 溝通。當文件解碼器執行完畢，就透過文件解析模組來解讀文 件內容；接著，若讀者需要對該文件作重點錄製時，即可啟動文件講解錄製模組， 將文件內容轉換成講解錄製工具所需的素材與腳本檔案，轉換完畢，啟動講解錄 製工具來做重點解說，接下來會針對各模組作詳細說明。

20

3.2 文件編碼器

文件編碼器會將一份原始文件經由一連串的轉換動作，並且加入DRM 相關 資訊，以產生一份受保護的文件，其中DRM 資訊是用來日後開啟文件時與 DRM server 溝通之用。 為了讓文件編碼的複雜度提升，進而提高安全性，本研究是透過一層介面， 該介面的底層會和現有的演算法作繫結(binding)，而每一次編碼文件時，會透 過一個隨機演算法來決定該介面此次使用何種演算法來轉換文件，這使得文件的 轉換過程具備通透性(transparency)，也就是說，無論底層實際轉換方式為何， 文件編碼器的運作機制仍舊不變。 另外，文件編碼器在設計上，會將空間與安全性的因素納入考量。因此，針 對一份原始文件，會採取壓縮方式減少硬碟空間的耗費；以及使用加密方式保護 原始資料。而運作順序為先壓縮、後加密，原因是為了避免先加密造成資料散亂， 而降低了壓縮率。 根據圖18 文件保護與講解錄製的運作機制，不論文件原始作者所匯入的文 件類型為何，文件編碼器皆會將該文件作編碼後，統一輸出成某種固定格式。這 部份本研究採用智勝國際科技公司所制定的檔案格式「BST」作為文件編碼器編 碼後的輸出格式，使用原因有二： 1. BST 檔案格式已趨成熟，且規格書取得方便。 2. 毋頇自行設計，減少開發所需時間。 所以在3.2.1 節，會簡單介紹 BST 檔案格式，接著 3.2.2 節再進一步說明 文件編碼器的運作流程。

3.2.1 BST 檔案格式

BST 檔案格式全名為「Bestwise Story Teller」，由智勝國際科技公司所 制定。下頁圖19 為 BST 格式的示意圖，共分為兩個區段：Header atom 與 Data Atom，茲說明如下：

21

圖 19、BST 檔案格式架構

(a). Header atom

Header atom 是由 Data reference atom 所組成，而 Data reference atom 是用來記錄所參照的資料區塊(Reference data)的相關資訊，如表 3 即列舉出Data reference atom 所定義的欄位及大小：

表 3、Data reference atom 欄位說明

欄位名稱 欄位說明 欄位大小

Type Data reference atom 種類 4 bytes Size Data reference atom 大小 4 bytes Reference Name Size 所參照的資料區塊其名稱大小 4 bytes

Reference Name 所參照的資料區塊名稱 不限

Reference Size 所參照的資料區塊的原始大小 4 bytes

Offset 所參照的資料區塊在Data

atom 之位移量

4 bytes

Data Size 所參照的資料區塊大小 4 bytes

從上表3 我們可以發現，想要取得資料區塊，只需 Reference Size、Offset 與Data Size 三個欄位即可。本研究會將編碼後的文件擺放在 Data atom 區段成為一筆Reference data，並透過對應的 Data reference atom 來 參照它。

22 (b). Data atom：

Data atom 是由 Reference data 所組成，而 Reference data 即擺放編 碼後的資料，表4 列舉出 Reference data 所定義的欄位及大小：

表 4、Reference data 欄位說明

欄位名稱 欄位說明 欄位大小

Type 資料區塊的編碼類型 3 bytes Data Size 資料區塊的大小 4 bytes Original Size 資料區塊的原始大小 4 bytes Data Block 編碼過的資料區塊 不限 表4 的 Type 欄位會記錄文件編碼器透過隨機選取的方式，所選用的編碼演 算法之類型，再配合其他三個欄位，以及DRM server 的金鑰，即可順利 解碼文件。

3.2.2 文件編碼器運作流程

在說明完文件編碼器的功能需求分析，與BST 檔案格式的介紹，接下來會 說明當文件原始作者匯入一份未受保護的文件後，文件編碼器的運作流程： 1. 首先，文件原始作者匯入一份原始文件，並啟動編碼程序。 2. 文件編碼器去會先使用壓縮演算法減少檔案的空間，接著透過隨機演算 法的決策來決定該份文件所用的加密演算法，並和DRM server 取得 加密金鑰。 3. 當壓縮與加密演算法處理完畢後，即產生一份編碼後的文件，且編碼的 資料區塊會放在BST 檔案中的 Data atom 區段，如圖 20 所示。 圖 20、文件編碼器運作流程

23

3.3 文件解碼器

接下來3.3 節的文件解碼器、3.4 節的文件解析模組、3.5 節的文件講解錄 製模組皆為「End-user side」的閱讀端子系統模組，稱作文件播放器，往後會 陸續說明各小節。

3.3.1 文件解碼器需求分析

文件解碼器的主要工作是：當讀者開啟一份受保護的文件時，會經過DRM server 檢查讀者身份與使用的權限，完成伺服器的驗證後執行解碼的動作，以 下分析其功能： 1) 文件解碼器與 DRM server 溝通 解碼器需要建立http 連線與 DRM server 溝通，並透過此連線將讀者 的驗證資訊傳送給DRM server 作確認。當 DRM server 完成讀者身 份的驗證、以及相關權限的檢查，確定對該文件有使用的權限時，會傳 送解密金鑰給文件解碼器。 2) 文件解碼功能

取得解密金鑰後，解碼器會從BST 檔案中的 Data reference atom 取得資料區塊的相關資訊，並進一步找到該資料區塊來執行解碼的動 作。 在此需注意一點，本研究會將解碼後的文件內容置放於記憶體之中，而不會 存放在讀者的電腦，以避免文件原始內容被竊取。因此，一旦讀者關閉文件甚至 是關閉電腦，則解碼後的文件會隨即消失。

3.3.2 文件解碼器運作流程

當讀者需要開啟一份受保護的文件，首先，文件播放器會啟動解碼器來與 DRM server 溝通，整個運作流程如下： 1. 文件解碼器首先要求讀者輸入帳號、密碼，並傳送給 DRM server 做 身份確認。 2. 當 DRM server 完成讀者身份以及使用權限的檢查，確認讀者有使用 該文件的權限後，DRM server 會傳送解密金鑰給文件解碼器。 3. 文件解碼器依序執行「解密」→「解壓縮」的解碼動作，並將解碼後的 文件擺放到記憶體中。 4. 接著，文件播放器就會啟動文件解析模組來解讀文件內容，並顯示在螢 幕供讀者觀看。如下頁圖21 所示：

24 圖 21、文件解碼器運作流程

3.4 文件解析模組功能需求分析

文件播放器的文件解析模組是用來解讀文件格式，並且將結果顯示在螢幕供 讀者閱讀觀看。文件解析模組為文件播放器的核心，其中包含一些功能提供給讀 者閱讀文件時使用，茲列舉如下： (a). 上下頁切換功能 (b). 放大縮小功能 (c). 畫面全螢幕功能 (d). 搜尋功能 (e). 捲軸拖拉與頁數顯示功能

3.5 文件講解錄製模組需求分析

接下來介紹文件播放器的第三個模組：文件講解錄製模組。該模組是用來將 文件轉換成講解錄製工具所需的素材和腳本檔案，以便講解錄製之用。其中，素 材檔案為圖檔，如：JPG、EMF、PNG 等；而腳本檔案為 XML 描述檔，當中記 錄素材(或稱演員)的相關屬性，如尺寸大小、出現的時間等。

25 在轉換文件的過程中，需要注意的一點是，由於講解錄製工具的內容顯示區 域為4 : 3 的顯示比例，與文件的長條狀顯示比例不符合，因此轉換時需要做前 置處理的動作，來協調顯示的內容，稱作內容協調(content adaptation)[13]。

3.5.1 XML 描述檔

文件講解錄製模組會產生XML 描述檔給講解錄製工具使用，XML 描述檔共 分為三類： (a). 場景的 XML 描述檔： 紀錄每一頁(場景)中多媒體素材(圖片)的屬性，例如出現的位置及大小 就對應圖22 中虛線方框的 Left、Top、Width、Height 屬性。 圖 22、場景的 XML 描述檔 (b). 文件的 XML 描述檔： 紀錄整份文件有多少頁(場景)、每一頁(場景)的標題及 ID，例如圖 23 就代表需要錄製的文件有兩頁。 圖 23、文件的 XML 描述檔 (c). 專案的 XML 描述檔： 紀錄專案的metadata，例如音效卡型號就對應圖 24 中虛線方框的 AudioCapName 屬性。

26 圖 24、專案的 XML 描述檔

3.5.2 文件講解錄製模組運作流程

當讀者在閱讀文件時，需要對文件的內容做重點式講解，這時會從文件播放 器去啟動多媒體講解錄製功能，該功能模組的運作如下： 1. 將文件作內容協調，以符合講解錄製工具顯示區域的比例。 2. 產生講解錄製工具所需的素材檔案。 3. 產生講解錄製工具所需的 XML 描述檔案。 4. 專案產生完畢後，啟動講解錄製工具，利用畫筆與聲音來對文件內容作 重點講解。 5. 講解完畢後，產生一份文件的講解檔，其中包含文件內容，讀者講解的 聲音，與畫筆所畫記的內文重點。如圖25 所示： 圖 25、文件解析模組運作流程

27

本章在介紹完製作端的文件編碼器，閱讀端的文件解碼器、文件解析模組、 與文件講解錄製模組，以及如何和DRM server 配合，接下來第四章會介紹本 研究的系統架構與流程，先闡述整個系統架構，接著說明文件保護與文件講解錄 製的系統流程。

28

四、 系統架構與流程

第三章針對本研究所提出的各模組做功能上的需求分析，以及說明各模組如 何運作，接下來會以這些模組為基礎，詴圖建構出整個系統，並對其架構、模組 間的溝通、與系統流程來作說明。

4.1 系統架構

本研究的系統架構如圖26 所示，包含「End-user side」的製作端與閱讀 端，以及「Server side」的 DRM server 和學習平台：

圖 26、系統架構

 「End-user side」

 文件保護製作端

為本研究系統建置的第一個步驟，文件原始作者會將需要保護的文件， 利用文件編碼器來做編碼轉換。文件編碼器開始運作之前，會和DRM server 索取加密金鑰，取得後再開始作編碼。文件編碼器的轉換過程 會執行壓縮，使檔案空間變小，接著利用隨機演算法的方式選用一個加 密演算法，配合加密金鑰作轉換。當文件編碼器處理完畢，產生一份受 保護的文件，隨即上傳至學習平台供讀者閱讀觀看。

29

 被保護文件閱讀端

閱讀端為一文件播放器，當中包含三個模組：文件解碼器模組、文件解 析模組、與文件講解錄製模組。當讀者從學習平台上開啟一份受保護的 文件，解碼器模組會先和DRM server 做連線，而 DRM server 會要 求讀者的驗證資訊，一旦身份與使用權限確認通過，DRM server 就會 傳送解密金鑰給文件解碼器，此時便可開始執行解碼的動作，而解碼後 的文件會擺放於記憶體中，再交由文件解析模組去解析文件，並在顯示 裝置上呈現。讀者在閱讀文件的過程中，想要使用錄製模式來對文件內 容作重點式的講解，則啟動文件講解錄製模組，該模組會將文件轉換成 講解錄製工具所需要的素材與腳本檔案，轉換完畢後，會將產生的專案 檔匯入講解錄製工具，並啟動講解系統開始錄製。在講解的過程中，讀 者可以利用畫筆對文件的重點處畫記，並且透過聲音來同步解說文件內 容。錄製完畢後所產生的文件講解檔，就會記錄當初讀者在錄製過程中 所畫的重點，以及所講解的內容，這讓讀者可以更輕鬆掌握文件重點。

 「Server side」

 DRM server

這部分是配合智勝國際科技公司所建置的DRM server，此伺服器主要 會記錄文件ID、文件加解密的金鑰、使用者的身份、與使用政策(如閱 讀次數)等。在文件的編碼與解碼過程，會和 DRM server 連線溝通， 以便取得編碼與解碼所需要的金鑰。另外，受保護的文件無論在何處， 都會受到DRM server 保護，也就是說，DRM server 會持續追蹤這 份受保護的文件。

 學習平台

學習平台是用來存放受保護的文件，作為文件原始作者與讀者交流的媒 介。文件編碼器將文件原始作者匯入的文件編碼後，會自動上傳至學習 平台，供讀者閱讀。 本研究所規劃出的系統架構是依循「製作端←→Server side←→閱讀端」 的模式。製作端有文件編碼器的本地端製作工具；閱讀端有文件播放器的本地端 閱讀工具，兩者再透過Server side 來對這些受保護的文件作管理與追蹤，而 讓整個系統架構趨於完整，下頁圖27 顯示出三者的關係：

30 圖 27、製作端、閱讀端與 Server side 三者之間的關係 在介紹完系統架構之後，緊接著會在4.2 節說明文件保護流程；以及說明 4.3 節的文件講解錄製流程。

4.2 文件保護流程

文件保護流程會從製作端開始，文件原始作者會將編碼完成的文件，以學習 平台為存放的空間、並透過DRM server 來追蹤管理這些受保護的文件。以下 對文件保護流程分為四點來作說明：

31 圖 28、文件保護流程 1. 首先，文件原始作者(Content creator)啟動文件編碼器，匯入一份原始文 件，接著輸入DRM 驗證資訊以便和 DRM server 取得編碼所需的金鑰。 當金鑰取得後，就可以利用編碼器將原始文件轉換成一份受保護的文件。 2. 接下來文件原始作者即可將這份編碼後的文件分享到學習平台，供讀者觀 看，而DRM server 也會持續管理這份受保護的文件。 3. 當讀者(Content reader)在學習平台上想要閱讀這份受保護的文件，此時 DRM server 會要求讀者輸入 DRM 驗證所需資訊，即帳號密碼。 4. 當 DRM server 完成讀者身份與使用權限的驗證，會傳送解密金鑰給文件 解碼器，文件解碼器即可解開此文件。而解碼後的文件會擺放在記憶體中， 接著交由文件解析模組來解析文件，並顯示在螢幕上供讀者閱讀觀看。

32

4.3 文件講解錄製流程

文件的多媒體講解錄製功能會與講解錄製工具作配合，將文件轉換成講解錄 製工具所需的素材與腳本檔案，以下透過PDF 圖示來說明其運作流程： 圖 29、文件多媒體講解錄製流程 1. 當讀者在閱讀文件的過程中，需要對文件畫記重點、與錄製聲音講解，讓整 份文件的可讀性提高，此時啟動文件講解錄製模組將文件作轉換。 2. 文件講解錄製模組在轉換過程中，會將文件內容轉換成圖檔與 XML 描述檔 案，供講解錄製工具使用。 3. 轉換完畢後，將產生的專案檔匯入講解錄製工具，並開始講解錄製。錄製過 程中，可以利用畫筆將文件的重點處作畫記，也可配合聲音的同步解說，來 加深讀者的印象。 4. 當文件錄製完畢後，讀者可將錄製的結果發佈成一份文件講解檔，該講解檔 會記錄讀者當初在錄製時所畫的重點、以及所講解的內容，如此在閱讀時可 以更快地掌握文件重點。

33

五、 系統設計與實作

本章開始介紹本研究的實作部份，包含製作端的文件編碼器，這在5.1 節 會做說明；以及閱讀端的文件播放器，其中文件播放器是由文件解碼器、文件解 析模組、與文件講解錄製模組所組成，分別會在5.2、5.3、5.4 節作介紹。

5.1 文件編碼器的實作

在第三章的系統需求分析所提及的編碼器製作概念，是採取「一個介面，多 種轉換法」的方式，也就是說，上層提供一個轉換用的介面，下層會繫結許多的 演算法，當中透過一個隨機的方式，亂數取用，以完成文件的編碼。 系統需求分析中也有提到，為了兼顧編碼後的文件大小與安全性，本研究在 編碼實作上就會採取壓縮與加密策略。另外，為了讓資料壓縮率較高，編碼過程 會先使用壓縮方式，接著才是加密，如此可以避免先加密造成資料散亂，降低壓 縮率。 基於上述的文件編碼器設計上的彈性，本研究實作第一章研究範圍所提及的 AES 和 Triple DES 加密演算法和上層介面作繫結。當然，想使用不同的演算法 作轉換，甚至想增加演算法的數量，讓複雜度再提升，都是允許的。 至於和介面繫結的加密演算法、以及壓縮演算法，會使用編號的方式來記 錄，如此一來，不論有幾種轉換演算法都可正確無誤地作對應(mapping)，如 以下程式片段所述： #define ZIP_Compress 0x01 #define Triple_DES_Encryption 0x10 #define AES_Encryption 0x20 … 文件編碼器的演算法流程為：「原始文件→壓縮成ZIP 格式→隨機演算法運 作→產生受保護的文件」，如下頁圖30 所示：

34

圖 30、文件編碼器的演算法流程

文件編碼完成後，會在Data atom 區段產生編碼過的資料區塊(Reference Data)，並透過一個 Data reference atom 去參照它。以下為文件編碼器的虛

擬碼片段，主要說明如何隨機選取轉換用的演算法，以及如何產生編碼後的BST

檔案(即受保護的文件)： bool RandomSelector(void) {

srand((unsigned)time(NULL)); //以目前系統時間作為亂數種子 int temp = rand(void);

if (temp%2 == 0) { //亂數為偶數則使用 Triple DES 加密演算法 } else { //亂數為奇數則使用 AES 加密演算法 } }

bool Encoder(vector<wstring> FileList, wstring FileName, vector<wstring> &Info) {

//Step1: 設定使用 ZIP 壓縮

//Step2: 呼叫 RandomSelector()演算法隨機選用加密演算法 //Step3: 和 DRM server 取得金鑰

//Step4: 將文件原始作者匯入的原始文件執行編碼

//Step5: 將 BST 檔頭寫入檔案，檔頭中的主要資訊為 Data reference atom //Step6: 將 Step4 所編碼的資料區塊寫入檔案

35

從上述的文件編碼器實作方式，我們可以發現需要加密金鑰才能夠完成，因 此執行Encoder 的 Step4 前會先和 DRM server 索取金鑰，DRM server 也 會要求先經過身份驗證才能取得加密金鑰，以下是和DRM server 溝通的虛擬 碼： void DRMConnected(void) { //Step1: 透過 Http 協定和 DRM server 連線 //Step2: 將文件原始作者身份驗證資訊傳送到 DRM server 作檢查 if (身份驗證通過) //Step3: DRM server 產生文件代碼與相關資訊，並記錄於伺服器中 //Step4: DRM server 隨機產生一份加密金鑰，並傳送給編碼器使用 else //傳回錯誤訊息給文件原始作者 } 文件編碼完成，產生一份受保護的文件，文件原始作者可以選擇存放在本地 端，爾後自行發佈，或者直接讓編碼器自動上傳至學習平台。  選擇本地端要存放的目錄位置 if (m_PublishType == wstring(L"Local")) { //Step1: 彈出對話視窗讓文件原始作者選擇擺放路徑 //Step2: 記錄文件存放路徑 //Srep3: 將編碼後的文件存放於文件原始作者指定的位置 }  選擇上傳至學習平台 if (m_PublishType == wstring(L"Blog")) { … … //產生一個上傳用的 Upload 物件 CHttpUpload Upload; //設定學習平台的網址、與文件原始作者的帳號密碼 Upload.SetCheckInfo( WideStringTowstring(UploadURL), WideStringTowstring(BlogUserName),

36 WideStringTowstring(BlogUserPassword) ); //設定 Upload 物件的 metadata Upload.SetAPName(wstring(L"soEZLecturing Upload")); Upload.SetInfo(InfoList[L"CourseName"], InfoList[L"Comment"]); Upload.SetXMLFileName(XMLFileName); Upload.AddFile(…); //開始上傳文件 Upload.Upload(void); }

5.2 文件解碼器的實作

當讀者要閱讀一份受保護的文件，則文件播放器會先啟動文件解碼器來作處 理。文件解碼器一開始會和DRM server 溝通，並要求讀者輸入身份驗證的資 訊，當身份與使用權限驗證通過後，就從DRM server 取得解密金鑰，以下虛 擬碼說明了取得金鑰的過程： void DRMConnected(void) { //Step1: 透過 Http 協定和 DRM server 連線 //Step2: 將讀者身份驗證資訊傳送到 DRM server 作檢查 if (身份驗證通過) //Step3: DRM server 以文件的代碼為索引，到資料庫中查閱該讀者 是否有權限可以開啟文件閱讀 if (有權限可以閱讀) //Step4: DRM server 將解密金鑰傳送給解碼器使用 else //傳回錯誤訊息給讀者 else //傳回錯誤訊息給讀者 } 順利取得解密金鑰後，文件解碼器就開始解碼文件。整個解碼流程，會先解 密、接著解壓縮，完成後將解碼的資料區塊置放於記憶體中，底下會配合圖31 說明文件解碼過程：

37

圖 31、文件解碼過程

Step1： 首先，從 Data reference atom 紀錄的內容找到 Reference data(即 圖31 的 Encrypted document)。

Step2： 取得 Reference data 後，從第一個欄位可以得知該使用何種演算法解 密，而此處會先配合解密金鑰，使用解密演算法。 Step3： 解密後的資料區塊，同 Step2 再做一次處理，此處會使用解壓縮演算 法。 Step4： 解碼動作處理完，就會將文件內容置放到記憶體中，再交由文件解析模 組去解析文件。 圖31 右上方虛線區域的程式碼，是解碼器模組的部分區段，我們可以發現，

該使用AES_Decryption 或者 Triple_DES_Decryption，只要從 Reference data 的第一個欄位判讀即可。當編碼器的介面需要繫結更多的演算法，只要對 每個新增的演算法定義一個名稱(identifier)，另外，讓解碼器增加對應 switch case 即可完成，如此更加難以猜測編碼方式，進而讓複雜度大幅提升。

最後補充一點，Reference data 的第一欄位(如：aes、zip)，並非以文字 的方式寫入，而是先轉換成二進制(binary)，然後再寫入，圖 31 只是為了方便 示意。下頁表5 將對應的二進制碼列出，其中小寫字母 a 到 z 對應十進制為 97 到122：

38

表 5、使用 ASCII 字元碼轉換成二進制

ASCII 十進制 ASCII 二進制

aes (97,101,115) 01100001 01100101 01110011 des(此為 Triple DES) (100,101,115) 01100100 01100101 01110011 zip (122,105,112) 01111010 01101001 01110000

5.3 文件解析模組的實作

當解碼器將一份受保護的文件解碼後，會放置到記憶中，緊接著文件播放器 就會啟動文件解析模組，並從記憶體中讀取解碼後的資料區塊。

文件解析模組的設計方式是採用「Observer Design Pattern」，對此先做 簡單介紹，「Observer Design Pattern」的概念是：當某一個物件(object)發 生狀態上的改變時，則會通知其他具有相依性(dependency)的物件，讓這些物 件做相對應的處理與更新動作，而這些具有相依性的物件就稱作「Observer」。 [20][21]

舉例來說，當讀者在閱讀文件的過程中，對文件播放器下拉捲軸，想要觀看

其他的文件內容，則下拉時GUI 物件的狀態隨即改變，並通知文件解析模組的

Play System Observer 做相對應地處理，而 Play System Observer 就會通 知Parser Thread 到記憶體中去解析文件資料，當 Parser Thread 解析完後告 知Play System Observer，Play System Observer 隨即更新文件播放器的 內容，如圖32 所示：

圖 32、文件解析模組套用 Observer Design Pattern 的運作方式

因此，文件解析模組會一直觀察文件播放器是否有狀態上的改變，只要一有 變化，就會馬上執行相對應地處理動作。底下透過sequence diagram，再一 次詳細說明整個文件解析模組運作流程：

39

圖 33、文件解析模組之 sequence diagram

1. 當文件播放器上有事件觸發(GUI event driven)，並且有狀態上的改變， 則通知文件解析模組的Play System Observer。

2. Play System Observer 設定狀態為 ready，代表準備開始處理程序，並 通知Parser Thread Observer。

3. Parser Thread Observer 接收到 Play System Observer 的通知，便開 始從記憶體中解析文件內容。

4. 當 Parser Thread Observer 解析完畢後，會將狀態設定成 done，代表 已經解析完文件內容，並告知Play System Observer。

5. Play System Observer 更新文件播放器顯示的內容(update display)。 從圖33 可以發現，文件解析模組的運作包含三種角色：GUI object、Play System Observer 與 Parser Thread Observer。GUI object 係指文件播放 器上的GUI 元件，只要有事件觸發，就會通知 Play System Observer，以下 為虛擬碼：

40 void TPlayer1::WndProc(TMessage& Message) { //GUI 物件的訊息處理 switch (Message.Msg) { case WM_VSCROLL: { if (下拉捲軸) {

//Step1: 設定捲軸移動方向為向下(Direction == Down) //Step2: 設定所要解析的文件頁碼

//Step3: 通知 Play System Observer 作處理 }

else //上拉捲軸 {

//Step1: 設定捲軸移動方向為向上(Direction == Up) //Step2: 設定所要解析的文件頁碼

//Step3: 通知 Play System Observer 作處理 } } break; … //其他類型的訊息，如上下頁切換、放大縮小等等 } }

接下來 Play System Observer 就會將狀態設定為 ready，並利用一個計 時器(Timer)每隔 0.1 秒檢查 Parser Thread 是否完成工作，若完成工作，則 告知Play System Observer 更新文件的顯示內容，如以下虛擬碼：

//狀態是用來監督 Parser Thread 的處理情況，共分為四種：None(在背景等候) //Ready(準備解析文件內容)、Parsing(解析中)、Done(文件內容已解析完畢) enum ParserState { None, Ready, Parsing, Done };

void PlaySystem::Processing(void) {

//Step1: 將狀態設定成 Ready

//Step2: 啟動 Timer，每 0.1 秒檢查執行緒是否將文件內容解析完畢 }

41 ParserState Timer::CheckContent(void) { //取得目前狀態 if (狀態為 None 或者 Parsing) { //不作任何處理 } else if (狀態為 Ready) { //喚起執行緒至前景作業 } else if (狀態為 Done) {

//Play System Observer 更新文件播放器顯示的內容(update display) }

}

而Parser Thread 為一個執行緒，用來解析記憶體中的文件內容，當接獲 Play System Observer 的通知(狀態設定為 ready)，則開始處理工作，如以 下虛擬碼所示： void ParserThread::Execute(void) { while (!Terminated) { if (狀態為 Ready) { //Step1: 將狀態設定成 Parsing //Step2: 開始解析文件內容 //Step3: 解析完畢，將狀態設為 Done //Step4: 到背景等候命令(suspend) } } }

透過Observer Design Pattern 的設計模式，使得文件解析模組可以更高 度模組化，且彼此之間以物件的方式作溝通，讓程式的結構性提升，降低開發的 時間成本。

42 在介紹完閱讀端文件播放器的「解碼器」與「文件解析模組」實作後，最後 一個為文件多媒體講解錄製模組，這在接下來5.4 節中會做說明：

5.4 文件講解錄製模組之內容協調

當讀者在閱讀文件時，需要對文件內容做講解錄製，就啟動錄製模式，將文 件內容轉換成講解錄製工具所需的素材與腳本檔案，其中腳本描述檔在第三章的 系統需求中已做過分析，共有三種腳本描述檔，以下透過虛擬碼的方式作說明：  產生場景(每一頁文件)的 XML 描述檔 void ProduceSceneXML(void) { //Step1: 啟動 XML Parser

//Step2: 透過 XML Parser 紀錄場景的名稱、ID、編號、標題

//Step3: 透過 XML Parser 設定素材的擺放路徑、長寬、左上角座標 //Step4: 儲存該 XML 描述檔 }  產生整份文件的 XML 描述檔 void ProduceDocumentXML(void) { //Step1: 啟動 XML Parser

//Step2: 透過 XML Parser 記錄所有場景的名稱、ID、編號、標題 //Step3: 透過 XML Parser 設定整份文件總頁數 //Step4: 儲存該 XML 描述檔 }  產生專案的 XML 描述檔 void ProduceProjectXML(void) { //Step1: 啟動 XML Parser //Step2: 透過 XML Parser 紀錄文件的 XML 描述檔路徑 //Step3: 透過 XML Parser 設定音效卡型號 //Step4: 儲存該 XML 描述檔 }

43 接下來就是產生素材的部分，由於講解錄製工具得顯示區域為4:3 的比例， 與文件的顯示比例不符合，因此，在產生這些素材檔案之前，要先做內容協調 (content adaptation)的前置處理動作，讓讀者在錄製過程，可以享有更好的 觀看品質。 本研究在實作內容協調時，會採取兩個步驟：「裁切」與「延展」。「裁切」 是為了將文字放大；而「延展」是為了讓文件比例符合講解手顯示區域的比例。 底下就針對這兩個步驟做詳細說明。 Step1： 將文件轉換後的素材，周圍做裁切的動作 由於文件周圍會保留白色區域，因此便針對這些白色區域做裁切動作， 目的是讓文件內容區域的相對面積放大，進而讓文字有放大效果。本研 究針對周圍裁切的部分實驗了幾項數據：60 列、90 列、120 列、150 列。經過觀察比較，60 列和 90 列還有裁切的空間；150 列則過於貼 近頂部。因此，周圍各裁切120 列，在文字大小與觀看品質上可以達 到最好的效果。如下頁圖34 所示：

44

45

Step2： 將裁切後的內容延展成 4:3 的比例，以符合講解錄製工具的顯示區域

比例。當裁切完畢後，緊接著就是對內容作延展。如圖35 所示：

圖 35、文件解析模組之內容協調

假設文件裁切後的保留區域為Width x Height，接著產生一塊 Width’ x Height 的畫布，其中畫布的高度和保留區域一樣，寬度的計算方式 如下：

3

4

'

3

:

4

:

'







Height

Width

Height

Width

然後將保留區域的內容以置中的方式描繪在畫布上，並儲存起來。如此 一來，便完成文件的延展成4:3 的目的。 對於文件多媒體講解錄製模組產生的素材檔案，採用「裁切」與「延展」的 方式來完成內容協調的工作，而協調後的品質也因為掌握三個重點而提升： 1. 協調後的文件比例和講解錄製工具的顯示區域比例一致，讓講解錄製工 具的繪圖系統可以達到最佳的縮放品質。

46

圖 36、將協調好的素材在講解錄製工具的顯示區域中呈現

2. 對文件周圍做裁切的動作，使得文件延展後，保留區域的面積相對地變 大，而文字也有放大的效果。

47 3. 文件延展時維持保留區域的比例，讓文字不會因為被擠壓而失真，進而 保持文字清晰。 圖 38、不同延展方式的呈現效果 底下是文件講解錄製模組的虛擬碼，其中包含上述所提及的「裁切」與「延 展」，用來產生素材檔案；以及產生三種不同類型的XML 描述檔案。

void MultimediaLecturing(TObject *Sender) {

for (page = 1; page <= lastPage; ++page) {

//Step1: 將文件轉換成素材檔

//Step2: 將素材檔做內容協調，包含裁切與延展的處理 //Step3: 產生一塊 Width' x Height 大小的畫布

//Step4: 將協調完的素材檔以置中的方式描繪在畫布上 //Step5: 將畫布上的圖片儲存起來

//Step6: 產生場景(每一頁)的 XML 描述檔案 ProduceSceneXML(void);

48 //Step7: 產生文件的 XML 描述檔案 ProduceDocumentXML(void); } //Step8: 產生專案的 XML 描述檔案 ProduceProjectXML(void); //Step9: 啟動講解手錄製工具，並將專案檔匯入 OpenSoezLecturing(void); //Step10: 將動態產生的記憶體歸還給作業系統 } 下一章為應用範例，會將本研究的文件保護與文件多媒體講解錄製，以文字 配合截圖的方式來逐步說明。

49

六、 應用範例

在6.1 節會針對「文件保護」的操作方式作說明，其中包括「製作端」與 「閱讀端」。另外，無論是哪一種文件類型，文件保護的運作機制皆相同。因此， 本節就僅以PDF 文件格式來當範例說明。 文件從編碼保護，到交由DRM server 管理追蹤，不論文件放置在學習平 台、或者本地端的電腦上，整個文件保護的運作機制皆相同，故6.1 節僅以學 習平台為例作說明，本地端的部分則不加贅述。到了6.2 節會介紹讀者如何使 用錄製模式來講解文件。 這兩節都會採用圖文的方式來描述，讓整個說明更臻完善，底下就從文件保 護的操作方式開始。

6.1 文件保護的操作方式

圖39 為文件保護操作的步驟，其中發佈受保護的文件供讀者閱讀所需要的 學習平台，本研究是使用智勝國際科技公司所建置的web2.0 平台，稱為「樣 版國度」[22]，本人已在此申請一個帳戶。往後的說明便依循這個操作步驟圖 來實施。 圖 39、文件保護操作步驟

50

6.1.1 製作端

 首先啟動文件編碼器，並選擇發佈至樣版國度學習平台 圖 40、選擇文件發佈位置(以學習平台為例)  輸入帳號密碼以供和樣版國度學習平台做連線，建立此連線的目的是：當文 件編碼完成，會自動上傳至本人在樣版國度已註冊好的免費使用空間 圖 41、輸入學習平台的帳號密碼

51  文件編碼器的設定過程共分為三個步驟，以下會依序說明如何設定。首先是 「步驟一、選擇要加密轉換的文件」，在此需要文件原始作者匯入需要保護 的原始文件，從圖42 可以清楚得知，文件原始作者頇先按下匯入原始文件 的按鈕，接著會彈出一個視窗，讓文件原始作者選擇要匯入的文件，匯入完 畢後，就會在列表中看到作者選擇要匯入的原始文件，然後就可以到下一步 驟繼續後續的設定 圖 42、匯入要編碼轉換的原始文件

52  接著是「步驟二、設定文件資訊」，文件資訊包含：文件名稱、文件分類、 文件相關說明等，這些文件資訊會在文件編碼完成，發佈到學習平台後，顯 示在學習平台的頁面上，以供讀者了解此份受保護文件的相關資訊。設定完 後按下一步，進行最後一個步驟的設定 圖 43、設定文件資訊