Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://dpublishing.github.io/audiobooks-specs-tc/lpf.html below:

輕量封裝格式（Lightweight Packaging Format, LPF）

本節不具規範性。

本規格定義了一個檔案格式，以及將構成一份數位出版品之組成資源與相關詮釋資料集封裝成單一檔案容器的處理模型。

本節解釋了本文件在其發布時的狀態。其他文件可能取代本文件。W3C的當前出版品清單以及本技術報告的最新版本可於位在https://www.w3.org/TR/之W3C技術報告索引中獲得。

本文件由出版工作小組以工作小組備忘形式發布。

推薦使用GitHub Issues對本規格進行討論。此外，你也可以將意見寄送到我們的郵寄列表。請寄送到public-publ-wg@w3.org（郵件封存紀錄）。

作為工作小組備忘的出版品並不意味著受到W3C會員所背書。這是一份草稿文件並且可能隨時受其他文件更新、取代或者淘汰。將本文件作為進行中工作以外的文件來引用是不合適的。

本文件是由在W3C專利政策下運作的小組所製作。

此小組不預期本文件會成為W3C推薦規格。

本文件受2019年3月1日W3C流程文件所規範。

1. 1. 導論
2. 2. 術語
3. 3. 一致性
4. 4. 封裝格式
5. 5. 資源壓縮
6. 6. 檔案與目錄結構
7. 7. 取得出版品宣告
8. A. application/lpf+zip媒體類別
9. B. 致謝
10. C. 參考資料
    1. C.1 規範性文件
    2. C.2 參考性文件

本節不具規範性。

一份數位出版品封裝檔是用於：

• 在不同個人及（或）不同組織間交換製作中的封裝出版品。

• 出版社或者轉換業者提供已完成的封裝出版品給不同的分發商或者銷售管道。

• 提供封裝出版品給使用者（user）或者使用者代理程式（user agent）。

本規格是基於已受驗證的技術且允許數位出版品能被以簡單的方式進行封裝，因此其名稱使用了「輕量」的術語。

本節不具規範性。

本文件使用了定義於W3C備忘「Web上的出版與連結」 [publishing-linking] 中的術語，特別是包含了使用者（user）與使用者代理（user agent）。

此外，以下術語定義供本規格所使用：

編碼內容類型（Codec content types）

本質為二進位格式性質的內容類型，例如為了壓縮最佳化所設計或者提供最佳化串流能力的影片及聲音等媒體類型。

非編碼內容類型（Non-Codec content types）

因其內在資料結構特性而利於壓縮的內容類型，例如基於字元與字串之檔案格式（如HTML、CSS…等）。

封裝檔（Package）

由構成數位出版品的一組組成資源與相關詮釋資料集所形成的單一檔案容器。

主要進入頁面（Primary Entry Page）

數位出版品的首選起始資源，在某些案例中可用於發現其出版品宣告。

數位出版品（Digital Publication）

由一組組成資源與相關詮釋資料所組織在一起而型成的一個具獨特性的可識別群組。

出版品宣告（Publication Manifest）

採用 [pub-manifest] 中對數位出版品的定義並以 [JSON-LD] 形式呈現描述的數位出版品資源清單宣告。

根目錄（Root Directory）

封裝檔案系統的基底目錄。

每個術語僅在第一次於章節出現中時才會連結到其定義。

本節不具規範性。

除了標註為不具規範性的章節外，本規格中所有製作指引、圖表、範例與注意事項亦不具規範性。其餘本規格中的內容則均為具規範性。

本文件中出現之關鍵字可以（MAY）、必需（MUST）、應該（SHOULD）之解釋以BCP 14 [RFC2119] [RFC8174] 所描述為準，同時也僅在出現時以全大寫（中文為粗體）顯示。

本節不具規範性。

為了將構成數位出版品的組成資源與相關詮釋資料集封裝起來，本規格採用定義在ISO/IEC 21320-1:2015 ( [ISO21320] 與 [zip] )中之ZIP格式。

本節不具規範性。

當資源儲存於封裝檔中時，非編碼內容類型的資源應該被壓縮且必需使用Deflate壓縮演算法。這項實踐確保檔案實體能在封裝檔中以較小的尺寸存放。

編碼內容類型資源應該以無壓縮的方式儲存。因為在這情況下，壓縮會在產製過程中產生不必要的處理成本（尤其是大型資源檔案）並且可能會影響使用聲音/影片時的播放效能。

注意事項

在一些情況下，壓縮與某些加密方案結合使用時可能會阻礙使用者代理的「處理部分內容請求」能力（例如，HTTP位元範圍），這是因為在技術上難以在媒體播放前就確認整個資源的長度（例如，HTTP Content-Length標頭）。

本節不具規範性。

封裝檔必需在其根目錄中包含至少一個以下檔案：

• 名為publication.json的檔案，其內容必需為出版品宣告所定義的格式。
• 名為index.html的檔案，其必需符合數位出版品對主要進入頁面的需求。

根目錄本質上為虛擬的：使用者代理進行封裝檔的解封裝時，產生或不產生存放內容的實體根目錄均可。

這兩個檔案的內容必需不被加密。

封裝檔也必需包含所有在該數位出版品範圍中的資源，也就是從預設閱讀順序和出版品宣告所列的資源清單組合中獲得的所有資源集合。

這些資源檔案可以置放在根目錄下的任何子資料夾，或者放在根目錄中。

封裝檔中的內容必需透過相對URL字串 [url] 以參照到這些內容。

注意事項

[zip] 規格對檔案與資料夾名稱允許使用的字元有些限制。當使用這類名稱時，作者必須小心使用這些字元，以使得在跨作業系統時能得到廣泛的互通性。

本節不具規範性。

若封裝檔在其根目錄中包含publication.json檔案時，出版品宣告可於開啟及分析該檔案時取得。

除此之外，如果封裝檔在其根目錄中包含index.html檔案時，出版品宣告可透過以下步驟取得：

1. 假定由封裝檔中解出index.html檔案的內容為document。
2. 如果其不包含text/html或application/xhtml+xml媒體類型（media type），結束此演算法。
3. 將document之樹狀結構中，第一個rel屬性值為publication的link元素設為manifest link。
4. 如果manifest link為null，結束此演算法。
5. 如果manifest link的href屬性值為空字串，結束此演算法。

6. 如果manifest link的href屬性值存在片段識別符號（fragment）且可識別出document中的某個識別碼id時：

   1. 將樹狀構結中第一個id屬性與id相同且type屬性為application/ld+json的script元素設為embedded manifest script。
   2. 如果embedded manifest script為null，結束此演算法。
   3. 將embedded manifest script的子節點文字內容存為manifest text。
   解釋

   此分支流程用於當宣告內嵌於主要進入頁面時的情況。本演算法用來確認script元素的位置並且取出宣告。

7. 否則：
   1. 將manifest URL設為href屬性的值。
   2. 如果manifest URL不是一個相對的URL字串，中止這些步驟。
   3. 利用manifest URL從封裝檔中將宣告取出。
   4. 開啟並且讀取宣告檔案，其檔案內容即為manifest text。
   解釋

   此分支流程用於當宣告位在獨立檔案時的情況。其展示了從封裝檔中取得宣告的標準程序。

如果封裝檔中同時存在index.html與publication.json，則主要進入頁面應該包含對publication.json檔案之參照，其規則請參照本章節之定義。

這是一份在根目錄下，簡單地在主要進入頁面中透過 [HTML] link元素參照的出版品宣告。

<link href="publication.json" rel="publication"/>

在主要進入頁面中嵌入出版品宣告的範例可參見 [有聲書] 規格。

本節不具規範性。

本附錄註冊了application/lpf+zip媒體類型供輕量封裝格式使用。

輕量封裝格式（Lightweight Packaging Format, LPF）為一個基於 [zip] 封存格式之容器技術，用於將構成數位出版品的組成資源與相關詮釋資料集封裝成一個單一檔案容器。LPF和其相關標準由W3C所維護及定義。

MIME媒體類別名稱：

application

MIME子類別名稱：

lpf+zip

必要參數：

無

選擇性參數：

無

編碼考量：

LPF檔案為ZIP格式的二進位檔案。

安全性考量：

適用於application/zip的安全性考量也適用於LPF檔案。例如，一個封存檔可能包含了一個解壓縮時會在硬碟上擴張填滿所有可用磁碟空間的壓縮內容。因此，讀取LPF檔案的使用者代理應該嚴格地檢查所取得資料之檔案大小與正確性。

此外，由於各種內容類型都可能嵌入於LPF檔案中，application/lpf+zip可能會被視為有安全疑慮的內容，例如在封裝檔中被故意包含了惡意的可執行內容。然而這些潛在的安全問題只會發生於當使用者代理可識別並處理該額外內容，或者該內容被進一步交付給其他使用者代理處理時的情境。在這樣的案例中，安全性考量將不屬於本註冊文件之範圍。

互通性考量：

任何基於LPF的格式，當使用內容加密時，必需選擇不同於本規格定義之MIME媒體類型與副檔名。

已發表規格：

本媒體類型註冊供輕量封裝格式（Lightweight Packaging Format, LPF）使用，描述於位在https://www.w3.org/TR/lpf的輕量封裝格式規格。

使用本媒體類型的應用程式：

本媒體類型之目的係用於在多種互通性應用程式間進行電子書、有聲書、數位視覺敘與其他類型之數位出版品之分發與消費使用。

額外資訊：

魔術數字：

0: PK 0x03 0x04

副檔名：

LPF檔案多半可透過副檔名.lpf識別。

麥金塔檔案類型代碼：

ZIP

片段識別碼：

無

進一步資訊的聯絡人與郵件位址：

Ivan Herman (ivan@w3.org)

預期用途：

一般（COMMON）

作者/變更管控：

此發布規格是World Wide Web Consortium(W3C)出版工作小組的成果產出。W3C對本規格有變更的管控權。

本節不具規範性。

編輯者感謝所有出版工作小組的成員對本規格的貢獻：

• Greg Albers (J. Paul Getty Trust)
• Franco Alvarado (Macmillan Learning)
• Boris Anthony (The Rebus Foundation)
• Luc Audrain (Hachette Livre)
• Baldur Bjarnason (The Rebus Foundation)
• Laura Brady (W3C Invited Expert)
• Steve Breault (Scenarex Inc.)
• Don Brutzman (Web3D Consortium)
• Kaylin Bugbee (Earth Science Data Systems Program)
• Yu-Wei Chang (Taiwan Digital Publishing Forum)
• Fred Chasen (W3C Invited Expert)
• Timothy Cole (University of Illinois at Urbana-Champaign)
• Simon Collinson (Rakuten, Inc.)
• Rachel Comerford (Macmillan Learning)
• Garth Conboy (Google, Inc., chair)
• Juan Corona (Evident Point Software)
• Christopher Cosner (Stanford University)
• Dave Cramer (Hachette Livre)
• Greg Davis (Pearson plc)
• Romain Deltour (DAISY Consortium)
• Marisa DeMeglio (DAISY Consortium)
• Vagner Diniz (NIC.br - Brazilian Network Information Center)
• Kenneth Dougherty (Pearson plc)
• Brady Duga (Google, Inc.)
• Ben Dugas (Rakuten, Inc.)
• Roger Espinosa (University of Michigan)
• Reinaldo Ferraz (NIC.br - Brazilian Network Information Center)
• Teenya Franklin (Pearson plc)
• Jun Gamo (Voyager Japan, Inc.)
• Matt Garrish (DAISY Consortium)
• Michael Goodman (Wiley)
• Markku Hakkinen (Educational Testing Service)
• Katie Haritos-Shea (Knowbility)
• Ivan Herman (W3C Staff)
• Geoff Jukes (Blackstone Audio, Inc.)
• Deborah Kaplan (W3C Invited Expert)
• Bill Kasdorf (Book Industry Study Group)
• George Kerscher (DAISY Consortium)
• Yuri Khramov (Evident Point Software)
• Masakazu Kitahara (Voyager Japan, Inc.)
• Toshiaki Koike (Voyager Japan, Inc.)
• Charles LaPierre (Benetech)
• Mustapha Lazrek (Microsoft Corporation)
• Vladimir Levantovsky (Monotype)
• Mia Lipner (Pearson plc)
• Phil Madans (Hachette Livre)
• Christopher Maden (University of Illinois at Urbana-Champaign)
• Dmitry Markushevich (Evident Point Software)
• keith mcfarland (Blackstone Audio, Inc.)
• Jonathan McGlone (University of Michigan)
• Hugh McGuire (The Rebus Foundation)
• Nellie McKesson (W3C Invited Expert)
• Selma Morais (NIC.br - Brazilian Network Information Center)
• Jasmine Mulliken (Stanford University)
• Cristina Mussinelli (Fondazione LIA)
• Christos Nikolakakos (Wiley)
• Gregorio Pellegrino (Fondazione LIA)
• Fernando Pinto da Silva (EDRLab)
• Nicholas Polys (Web3D Consortium)
• Chris Powell (University of Michigan)
• Jeff Printy (Macmillan Learning)
• Ryan Pugatch (Hachette Livre)
• Joshua Pyle (Wiley)
• Wendy Reid (Rakuten, Inc., chair)
• Florian Rivoal (W3C Invited Expert)
• Leonard Rosenthol (Adobe)
• Robert Sanderson (J. Paul Getty Trust)
• Jodi Schneider (University of Illinois at Urbana-Champaign)
• Ben Schroeter (Pearson plc)
• Tzviya Siegman (Wiley, chair)
• Avneesh Singh (DAISY Consortium)
• Adam Sisco (Earth Science Data Systems Program)
• David Stroup (Pearson plc)
• Mateus Teixeira (W. W. Norton & Company)
• Jonathan Thurston (Pearson plc)
• Yukio Tomikura (Kodansha, Publishers, Ltd.)
• Ben Walters (Microsoft Corporation)
• Daniel Weck (EDRLab, DAISY Consortium)
• John Weise (University of Michigan)
• Jason White (Educational Testing Service)
• Richard Wright (EDRLab)
• Jeff Xu (Rakuten, Inc.)
• Evan Yamanishi (W. W. Norton & Company)
• Maurice York (University of Michigan)
• Junichi Yoshii (Kodansha, Publishers, Ltd.)
• Benjamin Young (Wiley)
• Mohamed ZERGAOUI (INNOVIMAX)

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174

[audiobooks]

Audiobooks. Wendy Reid; Matt Garrish. W3C. 28 January 2020. W3C Candidate Recommendation. URL: https://www.w3.org/TR/audiobooks/

[dom]

DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/

[HTML]

HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/

[ISO21320]

Document Container File - ISO/IEC 21320. ISO. 2015. International Standard. URL: https://www.iso.org/standard/60101.html

[JSON-LD]

JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/

[pub-manifest]

Publication Manifest. Matt Garrish; Ivan Herman. W3C. 28 January 2020. W3C Candidate Recommendation. URL: https://www.w3.org/TR/pub-manifest/

[publishing-linking]

Publishing and Linking on the Web. Ashok Malhotra; Larry Masinter; Jeni Tennison; Daniel Appelquist. W3C. 30 April 2013. W3C Note. URL: https://www.w3.org/TR/publishing-linking/

[url]

URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/

[zip]

.ZIP File Format Specification. 1 September 2012. Final. URL: https://www.pkware.com/documents/casestudies/APPNOTE.TXT

↑

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3