OFDの定義と背景
OFD(Open Fixed-layout Document)は、中華人民共和国国家標準化管理委員会が発行した固定レイアウト文書フォーマット規格であり、規格番号はGB/T 33190-2016です。Adobeが作成し後にISO 32000国際規格となったPDFとは異なり、OFDは中国が独自に開発した国家規格であり、固定レイアウト文書分野における自主制御の課題に対処するために設計されました。
固定レイアウト文書の核心的な特徴は「レイアウトの固定」です — 文書のレイアウト、フォント、画像の配置は作成時に固定され、どのデバイスで開いても同一にレンダリングされます。これは、画面サイズやフォントの利用可能性などの要因に基づいてリフローするWordやHTMLなどの「リフロー型文書」と対照的です。固定レイアウト文書はレイアウトを固定し、WYSIWYG(見たままが得られる)ことを保証します。
OFDファイルはXMLを使用して文書構造を記述し、ZIPパッケージとして編成されています — 実体は複数のXMLファイルとメディアリソースを含む圧縮コンテナです。テキスト、画像、グラフィックス、署名、印章、アニメーションをサポートし、文書の視覚的なレイアウトを正確に保持します。この規格は固定レイアウト文書産業連盟(OFD連盟)によって産業化に向けて推進され、2016年に国家推奨規格として発行されました。
2020年以降、OFDは中国の党・政府機関の電子公文書システムで広く採用され、政府部門における固定レイアウト文書の事実上の標準となりつつあります。今日、OFDファイルは電子請求書、電子ライセンス、電子契約などのシナリオでますます一般的に使われています。OFDの技術体系を理解することは、政府文書の処理や政府・企業システムとのインターフェースにおいて前提知識となります。
OFD vs PDF:2つの固定レイアウトフォーマットの技術で比較
OFDとPDFはどちらも固定レイアウト文書フォーマットであり、類似した機能の位置づけを持っています — どちらも文書レイアウトを正確に保持し、デバイス間の一貫性を保証するために使用されます。しかし、両者は技術体系とエコシステムにおいて大きく異なります。これらの違いを理解することは、異なるシナリオに適したフォーマットを選択するのに役立ちます。
| 次元 | OFD | |
|---|---|---|
| フォーマット規格 | 中国国家規格 GB/T 33190-2016 | 国際規格 ISO 32000(Adobe発祥) |
| ファイル構造 | XML + ZIPコンテナ、オープン構造 | バイナリ/テキストハイブリッド、比較的クローズドな構造 |
| ユースケース | 政府文書、電子ライセンス、入札 | 一般文書、契約書、レポート、出版物 |
| サポートツール | 少なく、主にSuke、Foxitなどの国内ツール | 成熟したエコシステム、Adobe、Foxitおよび多くの無料ツール |
| 印章/署名サポート | ネイティブ電子印章、中国暗号規格(国密)に準拠 | デジタル署名サポート、中国暗号には追加対応が必要 |
| 国際的な認知 | 主に国内利用 | 世界中で受け入れられている |
以下のフローチャートは、規格の起源、ファイル構造、アプリケーションエコシステムの3つの次元でOFDとPDFの技術の経路をで比較しています:
1. フォーマット規格
OFDは公開された透明な技術仕様を持つ中国国家規格です。文書構造はXMLに基づいており、国内環境への適応と中国の暗号アルゴリズム(国密SM2・SM3・SM4)との統合が容易です。PDFは最も成熟したエコシステムと世界中の普及を持つ国際規格ですが、機密指定および政府のシナリオでは自主制御に関する懸念があります。両者は置換関係ではなく、異なるコンプライアンス要件と応用分野に対処する並行規格です。
2. ファイル構造
これはOFDとPDFの最も根本的な技術的違いです。OFDファイルは実体がZIPアーカイブであり、XMLが内部でページ、テキスト、画像などの要素を記述しています — 構造が明確で解析が容易です。PDFはバイナリ/テキストハイブリッドフォーマットを使用し、内部がオブジェクト、クロスリファレンステーブル、トレーラ構造で構成されています — 比較的複雑です。開発者にとって、OFDはより高い可読性と解析性を提供します。エンドユーザーにとっては、開いた時の見た目は両者とも類似しています。
3. サポートツール
PDFのツールエコシステムは非常に豊富で、無料のブラウザ内蔵ビューアからプロフェッショナルなAdobe Acrobatまで、あらゆる種類の編集、変換、圧縮ツールがあります。これに対して、OFDのツールチェーンはまだ開発の初期段階にあります。OFDを表示および編集できるソフトウェアの数は限られており、OFD圧縮に対応したツールはさらに少ないのが現状です。これがOFDの現時点のエコシステムにおける主な弱点です。
4. 印章および署名サポート
OFDはネイティブに電子印章と、中国の暗号規格に準拠した印章検証をサポートしています。印章データは文書構造内の独立したノードとして埋め込まれ、公文書ワークフローにおける真正性、完全性、否認防止の要件を満たしています。PDFはPKIシステムに基づくデジタル署名をサポートしていますが、中国の暗号アルゴリズム対応には追加の開発が必要です。政府文書シナリオでは、OFDの印章システムは国内の暗号インフラにより密接に適合しています。
OFDファイル構造:XML + ZIPコンテナ
OFDファイル構造を理解することは、その圧縮手法とツールエコシステムを理解する基礎です。PDFのバイナリフォーマットとは異なり、OFDは現代のオフィス文書(OOXML、ODFなど)に類似した「XML + ZIPコンテナ」アーキテクチャを採用しています。
コンテナの編成
OFDファイルは実体がZIPアーカイブです。ファイル拡張子を.zipに変更して展開すると、明確な多層ディレクトリ構造が現れます。最も外層にはOFD.xmlエントリファイルが含まれ、文書の基本情報と物理ファイルパスが宣言されています。内部では、コンテンツは「文書(Doc)— ページ — オブジェクト」の階層で編成されています。
XML記述層
OFDはXMLファイルを使用して文書の論理構造とページコンテンツを記述します。Document.xmlは文書のページツリー、アウトライン、メタデータなどを定義します。各ページはContent.xmlに対応し、そのページ上のテキスト、画像、グラフィックス、パスなどのレイアウトオブジェクトとその座標およびスタイルを記述します。このXMLベースの記述アプローチはいくつかの特徴をもたらします:
- 高い可読性:任意のテキストエディタでOFDのページ記述を表示でき、デバッグと監査が容易
- 解析が容易:標準のXMLパーサーで、専用のバイナリパーサーなしに文書構造を読み取れる
- 高い拡張性:新しい機能の追加はXMLスキーマの拡張だけで済み、既存の構造に影響しない
PDFのバイナリフォーマットとの比較
PDFはバイナリ/テキストハイブリッドフォーマットを使用し,内部が番号付きオブジェクトで構成され,クロスリファレンステーブル(Cross-Reference Table)を通じてリンクされ,ファイル末尾のトレーラがルートオブジェクトを指しています.この設計はファイルのコンパクトさに利点がありますが,構造が不透明であり — 一般ユーザーは内部コンテンツを直接確認できません.
両者の違いは圧縮レベルでも明らかです:OFDはすでにZIPコンテナであり、内部リソースは既に圧縮層を経ているため、ファイル全体を再圧縮しても得られる効果は限定的です — 最適化の焦点は内部リソース(画像、フォント)にあります。一方、PDFの圧縮は個々のストリームオブジェクトに分散しており、各ストリームオブジェクトが独立して圧縮アルゴリズムを選択できます。
政府文書におけるOFDの応用
OFDの政府部門での推進には実用上の背景があります。従来の政府文書は主に紙ベースであり、電子化にはレイアウトを正確に保持し、電子印章をサポートし、国家暗号管理要件に準拠する固定レイアウトフォーマットが必要です。PDFは強力ですが、外国規格として機密情報システムにおいて自主制御の懸念を引き起こします。OFDは国家規格としてこのギャップを埋めます。
電子公文書
中国の多くの地域で、党・政府機関の電子公文書システムがOFDを標準フォーマットとして採用しています。起案、審査、署名、配布、アーカイブのすべてのワークフローでOFDファイルが媒体として使用され、中国暗号電子印章と組み合わせて改ざん防止とトレーサビリティを実現しています。OFDの固定レイアウト特性により、異なるオフィスシステム間で文書が一貫したレイアウトを維持し、フォントの欠落やソフトウェアの違いによるフォーマット崩れが発生しません。
電子ライセンス
電子営業ライセンス、不動産登記証明書、電子身分証明書などの電子ライセンスが順次OFDフォーマットに移行しています。OFDファイルにはライセンス情報、保有者写真、発行機関の電子印章を埋め込むことができ、偽造防止検証をサポートします。紙のライセンスと比較して、OFD電子ライセンスはオンライン検証や部門間共有がより便利です。
電子請求書
一部の地域の電子請求書がOFDフォーマットを採用しています。OFD請求書には請求書コード、金額、税額などの構造化データが含まれ、視覚的なレイアウトも保持されています — 人間の読み取りと機械解析の両方に便利です。OFD請求書の印章メカニズムは真正性と否認防止を保証します。
アプリケーション規模が拡大するにつれて、OFDのファイルサイズの問題が顕在化しています — 大量のスキャン文書と文書に埋め込まれた高解像度の印章画像により、公文書が数十MBに達し、ストレージと送信に圧力がかかり、OFD圧縮へのニーズが生じています。
OFD圧縮メソッド
OFD圧縮の原理はPDF圧縮と非常に類似しています — 中核はファイル内で最も多くのスペースを占める部分を最適化することです。OFDはすでにZIPコンテナであり、ファイル構造はDEFLATE圧縮層を経ているため、OFD圧縮の鍵はさらなる圧縮層を追加することではなく、内部リソース(画像、フォント)を最適化することです。
画像リサンプリング
OFDファイル内のスキャン文書と印章画像は、通常ファイルサイズの最大の要因です。スキャンされた公文書は複数の300dpiの高解像度スキャンページを埋め込んでいる可能性があり、各ページは数MBになります。高解像度画像を適切な解像度(例:300dpiから150dpi)に下げることで、サイズを大幅に削減でき、画面での読み取りや印刷への影響は許容範囲内です。
リサンプリングは解像度と鮮明さのバランスを取る必要があります:政府文書のテキストコンテンツは150dpiでも明確に読めますが、精密な印章の細かいディテールはより高い解像度が必要な場合があります。賢明なアプローチは、画像の用途に応じて異なる目標解像度を設定することです。
フォントサブセット化
OFDファイルはデバイス間で一貫した表示を保証するために完全フォントを埋め込みますが、文書は通常フォントファイル内の文字のごく一部しか使用しません。フォントサブセット化は、文書で実際に使用されている文字グリフのみを保持し、未使用のフォントデータを破棄します。
この技術は中国語文書に特に効果的です。完全な中国語フォントファイルは通常数万の漢字グリフを含み、サイズが10MBを超える可能性があります。しかし、政府文書は1〜2千の漢字しか使用しない場合があり、サブセット化によりフォントデータを80%以上削減できます。
冗長オブジェクトのクリーンアップ
OFDパッケージには未参照のリソースや重複オブジェクトが含まれる可能性があります:編集中に削除された画像がリソースディレクトリに残存したり、複数回の保存で重複メタデータが生成されたりします。冗長オブジェクトのクリーンアップは、文書構造を走査してページから参照されていないすべてのリソースを削除し、文書構造ツリーを合理化します。
画像フォーマット最適化
OFDは複数の画像フォーマットの埋め込みをサポートしており、非圧縮ビットマップ(BMP)と圧縮フォーマット(JPEG、PNG)が含まれます。非圧縮ビットマップをJPEGなどの圧縮フォーマットに変換することで、画像リソースの使用量を直接削減できます。広範囲の単色を持つ印章グラフィックスの場合、PNGがJPEGより小さい場合があります。色彩豊かなスキャン写真の場合、JPEGはより高い圧縮率を提供します。
以下のコードは、OFDファイルを展開して内部リソース使用量を分析するメソッドを示しています — 圧縮最適化の第1歩です:
import zipfile
import os
from collections import defaultdict
def analyze_ofd(ofd_path):
"""OFDファイルを展開し、内部リソース使用量を分析する"""
with zipfile.ZipFile(ofd_path, 'r') as zf:
# 各ファイルタイプのサイズを集計
type_sizes = defaultdict(int)
type_counts = defaultdict(int)
total_size = 0
for info in zf.infolist():
ext = os.path.splitext(info.filename)[1].lower()
type_sizes[ext] += info.compress_size
type_counts[ext] += 1
total_size += info.compress_size
print(f"Total OFD size: {total_size / 1024 / 1024:.2f} MB\n")
print(f"{'Type':<12} {'Count':<8} {'Size(MB)':<12} {'Share'}")
print("-" * 45)
for ext, size in sorted(type_sizes.items(), key=lambda x: -x[1]):
pct = size / total_size * 100
print(f"{ext or '(none)':<12} {type_counts[ext]:<8} "
f"{size / 1024 / 1024:<12.2f} {pct:.1f}%")
# 使用例
# analyze_ofd("sample.ofd")
この種の分析スクリプトを実行すると、OFDファイルのサイズの80%以上が画像リソース(.jpg、.png、.bmp)から来ており、フォントファイル(.ttf、.otf)が次にくることが通常わかります。これはOFD圧縮の中核戦略を裏付けています:画像最適化を優先し、次にフォント最適化を行う。
50MBのOFDスキャン公文書は、適切な画像リサンプリングとフォントサブセット化の後、通常8〜12MBに圧縮でき、テキストと印章は依然として明確に読めます — 政府ワークフローとアーカイブの要件を完全に満たします。
OFDツールエコシステムの現状
OFDの国家規格としての位置づけは明確ですが、そのツールエコシステムはPDFと比べてはるかに成熟していません。現時点で、OFDを表示できるソフトウェアは主にSukeリーダーやFoxit OFDなどの国内ツールです。ブラウザはOFDプレビューをネイティブにサポートしておらず、OFDを圧縮できるツールはさらに少ないのが現状です。
ツールエコシステムの弱さは2つの実用上の問題をもたらします。第1に、OFDファイルを受け取った一般ユーザーは、それを開くための適切なツールを見つけられず、専用リーダーをダウンロードする必要があります。第2に、OFDファイルが大きすぎる場合、既製の圧縮ツールがないため、多くのユーザーはそのまま保存または送信するしかなく、ストレージと帯域幅のコストを負担します。
技術の観点から見ると、OFDのオープンなXML + ZIP構造は、解析と処理の障壁がPDFのバイナリフォーマットより理論的に低いことを意味します。ツールエコシステムの遅れは、技術的な障壁というより市場推進と応用規模の問題です。OFDアプリケーションが政府と金融分野で拡大し続けるにつれて、ツールチェーンは徐々に成熟すると期待されます。
比較表:OFD vs PDF圧縮手法
| 圧縮メソッド | OFD適用性 | PDF適用性 | 備考 |
|---|---|---|---|
| 画像リサンプリング | 高い | 高い | 両方とも画像がサイズを支配する;解像度の削減が最も効果的 |
| フォントサブセット化 | 高い | 高い | 中国語文書に特に効果的;フォントデータを80%以上削減できる |
| 冗長オブジェクトのクリーンアップ | 中 | 中 | 未参照リソースと重複を削除し、構造を合理化 |
| 画像フォーマット最適化 | 高い | 高い | ビットマップをJPEGに変換;画像タイプに応じて最適フォーマットを選択 |
| ファイル全体のZIP圧縮 | 低い(すでにZIP) | 中 | OFDはすでにZIPコンテナ;再圧縮の効果は僅か |
| ストリームオブジェクト圧縮 | N/A | 高い | PDF固有;各Streamが独立して圧縮を選択できる |
FAQ
Q1:OFDファイルはPDFに変換できますか?
はい。一部のOFDリーダーや変換ツールはOFDからPDFへのエクスポートをサポートしています。ただし、電子印章などOFD固有の情報は変換中に完全に保持されない場合があることに注意してください。OFDの中国暗号印章システムとPDFのPKI署名システムは完全には対応していないからです。長期アーカイブや法的効力が必要なシナリオでの変換は慎重に行うことをお勧めします — 変換前にバックアップを作成し、変換後の文書の印章状態を検証してください。
Q2:OFD圧縮は電子印章の有効性に影響しますか?
適切なOFD圧縮は画像やフォントなどのリソースのみを最適化し、印章データや文書のハッシュ検証情報を変更しないため、電子印章の有効性には影響しません。ただし、印章の完全性検証は通常文書の特定の一部をカバーすることに注意してください — 圧縮プロセスが印章で保護されたコンテンツを変更した場合、印章検証が失敗します。専門ツールを使用し、圧縮後に印章状態を再度検証して、文書の法的有効性が損なわれていないことを確認することをお勧めします。
Q3:通常のオフィスシナリオでOFDを使用する必要がありますか?
一般的なビジネス文書にはPDFで十分です。OFDは主に政府文書、電子ライセンス、その他の公式シナリオに使用されます。政府とのインターフェースに関わらない場合、意図的にOFDを使用する必要はありません。ただし、政府機関と電子公文書を交換したり、OFD形式の入札文書を提出したりする必要がある場合は、OFDを使用する必要があります。両者は置換関係ではなく、コンプライアンス要件と応用シナリオに応じて選択します。
Q4:OFDとPDFはどちらがサイズが小さいですか?
絶対的な答えはありません。ファイルサイズは主にコンテナフォーマット自体ではなく、内部リソース(画像、フォント)に依存します。同一のコンテンツの場合、OFDのXML記述はPDFのバイナリ記述よりわずかに大きい場合がありますが、両方とも圧縮を使用しており、差は通常無視できます。サイズを決定する主な要因は画像解像度とフォント埋め込み戦略であり、フォーマットの選択ではありません。多くの高解像度スキャンページを埋め込んだOFD公文書は、プレーンテキストのPDFよりはるかに大きくなりますし、逆もまた然りです。
まとめ
OFDとPDFはどちらも固定レイアウト文書フォーマットですが、異なる技術的経路とアプリケーションエコシステムを代表しています:
- OFDは、中国国家規格(GB/T 33190-2016)として、オープンなXML + ZIPコンテナ構造を採用し、中国暗号電子印章をネイティブにサポートし、政府文書、電子ライセンス、電子請求書などの国内公式シナリオで安定した地位を占めています。そのツールエコシステムはまだ初期段階ですが、オープン構造が国内環境への適応とカスタム開発のしやすさを提供しています。
- PDFは、国際規格(ISO 32000)として、バイナリ/テキストハイブリッドフォーマットを採用し、世界で最も成熟したツールエコシステムを持ち、一般オフィスシナリオで不可欠な存在です。
両者は圧縮手法において非常に類似しています — 中核は埋め込まれた画像およびフォントリソースの最適化です。OFD圧縮の4つの主要技術(画像リサンプリング、フォントサブセット化、冗長オブジェクトのクリーンアップ、画像フォーマット最適化)は、固定レイアウト文書のサイズ構成原理が普遍的であるため、PDF圧縮と同じ系統を共有しています。
OFDを理解する鍵は、その「XML + ZIPコンテナ」の実体を把握することです:オープンで解析しやすく、適応させやすい固定レイアウトアーキテクチャであり、その圧縮の焦点は — PDF同様に — コンテナ自体ではなく内部リソースにあります。
関連記事:
ファイル圧縮をお探しですか?SmartSlim をお試しください
独自開発のRust圧縮エンジンに基づき、PDF・画像・動画・Office・OFDなど10分野40以上の形式をサポート。ローカル圧縮でデータは外部に持ち出されません。