PDFディクショナリキーは、PDFディクショナリ内のエントリの識別子として機能する名前オブジェクトです。PDFディクショナリは、PDF文書全体でオブジェクトを定義する基本的なデータ構造です。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で規定されているように、これらのキーは名前オブジェクトの構文（スラッシュで始まる）に従い、PDFオブジェクトのプロパティと動作を記述する値にマッピングされます。/Type、/Subtype、/Length、/Resourcesなどのディクショナリキーは、アプリケーションが文書構造、コンテンツ、メタデータを解釈するために不可欠なPDF構文のコンポーネントです。

PDFディクショナリキーは、PDFディクショナリ内のキーと値のペアにおける識別子部分として機能する名前オブジェクトです。ディクショナリキーは常にスラッシュ（/）で始まり、その後に文字列が続きます（例：/Type、/Width、/FontDescriptor）。ディクショナリの値は任意のPDFオブジェクトタイプ（数値、文字列、配列、または他のディクショナリ）を取ることができますが、キーは具体的に名前オブジェクトでなければなりません。

ディクショナリキーはコンテキスト依存です。その意味と期待される値のタイプは、それらが現れるディクショナリタイプによって異なります。例えば、/Typeキーはディクショナリが表すオブジェクトのカテゴリを識別しますが、ストリームディクショナリの/Lengthはストリーム内のバイト数を指定するのに対し、署名ディクショナリの/Lengthは全く異なる目的を持ちます。PDF仕様では数百の標準化されたキーが定義されており、それぞれがどのディクショナリタイプに出現できるか、どの値タイプとペアにする必要があるかについて具体的な要件があります。

キーは、スタンドアロンの値としてではなく、ディクショナリの識別子として機能するという点で、PDF内の他の名前オブジェクトとは異なります。/DeviceRGBのような名前オブジェクトがカラースペースを指定する値として使用される場合もありますが、ディクショナリ内でその前に/ColorSpaceが現れる場合、/ColorSpaceはキーとして機能しています。

PDFディクショナリキーを理解することは、PDF生成、解析、または操作に携わる開発者にとって重要です。これらのキーは、PDFオブジェクトのプロパティにアクセスし、変更するための主要なインターフェースを形成するためです。正しいキーとそれらが期待する値のタイプに関する知識がなければ、開発者は有効なPDF構造をプログラムで作成したり、既存の文書から意味のある情報を抽出したりすることができません。

PDFオブジェクト種別（PDF object types）は、PDF辞書内の/Typeキーによって指定される標準化された値で、PDF文書内のオブジェクトの目的と構造を明示的に識別します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で定義されているように、これらの種別識別子は、PDFプロセッサが文書カタログから個々のページ、フォント、注釈まで、さまざまな種類のオブジェクトを正しく解釈し処理するのに役立ちます。常に必須というわけではありませんが、/Typeエントリは複雑なPDF構造を解析する際に重要なコンテキストを提供します。特に、インタラクティブフォームやTagged PDFのコンテンツ構造などの高度な機能を持つ文書では重要です ( Citation: PDF Association, 2023 PDF Association(2023). Retrieved from https://pdfa.org/resource/tagged-pdf-best-practice-guide-syntax/ ) 。

PDFオブジェクト種別は、PDF辞書オブジェクト内の/Typeキーの値として現れる名前値（スラッシュで始まる）です。このキーと値のペアは型宣言として機能し、その辞書が表すPDFオブジェクトの種類を明示的に示します。例えば、/Type /Pageを持つ辞書はページオブジェクトであることを識別し、/Type /Fontはフォントリソースオブジェクトを示します。

Stream filterとは、PDFのstreamディクショナリの/Filterエントリに指定される名前付きアルゴリズムで、streamの生データをどのようにデコードまたはエンコードすべきかを定義します ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。Filterはstreamデータを圧縮、暗号化、またはその他の方法で変換し、ファイルサイズを削減したりコンテンツを保護したりします。一般的なfilterには、汎用圧縮用の/FlateDecodeやJPEG画像データ用の/DCTDecodeがあります。

Stream filterは、streamデータに適用される特定のデコードまたはエンコードアルゴリズムを識別するPDF name objectです。PDFの構文では、filterはstreamディクショナリ内の/Filterキーの値として表され、単一の名前（例：/FlateDecode）、または複数のfilterが順次適用される場合は名前の配列として記述されます ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。Filterは、streamとendstreamキーワードの間の生バイトデータを、元のデータを復元するためにどのように処理すべきかを決定します。

PDFにおけるWhitespaceとは、PDFファイル構造内でトークンを区切るために使用される文字を指し、スペース文字（SP、0x20）、水平タブ（HT、0x09）、ラインフィード（LF、0x0A）、キャリッジリターン（CR、0x0D）、ヌル（0x00）、フォームフィード（FF、0x0C）が含まれます。これらの文字はPDFの字句文法における重要な構成要素であり、パーサーがファイル内の個別の構文要素を正しく識別し処理できるようにします ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。Whitespaceの規則を理解することは、有効なPDFファイルを生成する場合と既存のPDFファイルを正しく解析する場合の両方において基本となります。

PDFにおけるWhitespaceは、PDF構文内で区切り文字として機能する6つの特定のASCII文字で構成されます：スペース（SP）、水平タブ（HT）、ラインフィード（LF）、キャリッジリターン（CR）、ヌル、フォームフィード（FF）です。多くのプログラミング言語ではWhitespaceは純粋に人間の可読性のためのものですが、PDFのWhitespaceは名前、数値、キーワードなどの字句トークンを区切る構造的な役割を果たします。PDF仕様では、これらの文字をほとんどのコンテキストで交換可能な区切り文字として扱いますが、改行規則（LF、CR、またはCR+LFの組み合わせ）はストリームコンテンツなどの特定のコンテキストにおいて特別な意味を持ちます。

Whitespaceは区切り文字（括弧、山括弧、角括弧、スラッシュ）とは異なります。区切り文字は別個の構文要素であり、トークンを区切る役割も果たしますが、追加の構造的意味を持ちます。連続する複数のWhitespace文字は単一の区切り文字として扱われ、区切り文字がすでにトークンの分離を提供している場合、Whitespaceは省略可能なことが多いです。

PDF生成または解析を扱う開発者にとって、適切なWhitespace処理はいくつかの理由から重要です。第一に、誤ったWhitespaceの使用は無効なPDFファイルを生成し、ファイルが開かなかったり正しくレンダリングされなかったりする可能性があります。これは、PDFパーサーが数値、キーワード、名前などのトークンを区別するためにWhitespaceに依存しているためです。第二に、Whitespace規則を理解することで、戦略的なWhitespace配置を通じてファイルサイズを最小化できます—複数のWhitespaceが冗長である場合は単一のスペースを使用します。第三に、PDFパーサーや分析ツールを構築する際、Whitespace認識を正しく実装することでPDFコンテンツの正確なトークン化が保証されます。

ブール値オブジェクトは、論理値を表現するPDF構文の基本的なアトミックオブジェクト型の1つです。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) PDF仕様で定義されているように、ブール値オブジェクトはtrueまたはfalseの2つの値のみを取ることができます。これらのオブジェクトは、PDF文書全体で機能の制御、フラグの設定、およびPDF操作における二値的な判断に使用されます。

PDFにおけるブール値オブジェクトは、キーワードtrueとfalseを使用して二値状態を表現するプリミティブデータ型です。整数（0と1）やその他のシンボル表現でブール値を表す一部のプログラミング言語とは異なり、PDFでは小文字で記述された2つのリテラルキーワードとしてブール値オブジェクトを厳密に定義しています。ブール値オブジェクトはアトミックであり、より小さなコンポーネントに分解できず、PDF構文内で完全な自己完結型の値として存在します。これらはPDFコンテンツストリーム、辞書、配列内に、特別な区切り文字や囲み構文なしで直接記述されます。キーワード自体が完全なオブジェクトを構成します。

PDFの生成、操作、解析を行う開発者にとって、ブール値オブジェクトの理解は、文書プロパティの正確な設定とPDFの動作制御に不可欠です。ブール値は、フォームフィールドが読み取り専用かどうか、注釈が印刷時に表示されるかどうか、文書が変更を許可するかどうか、その他無数の二値設定など、重要な文書特性を決定します。プログラムでPDFを作成または変更する際、開発者は ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で規定された正確な小文字のキーワードtrueとfalseを使用する必要があります。True、TRUE、1、0などの代替表現を使用すると、無効なPDF構文になります。ブール値オブジェクトを適切に処理することで、異なるプラットフォームやアプリケーション間でPDFプロセッサとリーダーが文書設定を正しく解釈できるようになります。

ネームツリーは、PDF文書内でテキスト文字列（名前）からPDFオブジェクトへの効率的なマッピングを提供する特殊なデータ構造です。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で定義されているように、ネームツリーはPDF全体で、埋め込みファイル、ナビゲーション用の移動先、JavaScriptアクションなどの名前付きリソースを整理するために使用されます。すべてのエントリをメモリにロードする必要がある辞書とは異なり、ネームツリーは平衡木構造を使用することで、数千のエントリがある場合でも高速な検索を可能にします。

ネームツリーは、PDF内でUnicode文字列を任意のPDFオブジェクトに関連付ける階層的な木構造です。この構造は、子ノードへの参照を含む中間ノードと、ソート順に格納された実際の名前とオブジェクトのマッピングを含むリーフノードで構成されます。ネームツリーは、ナンバーツリー（整数をオブジェクトにマッピング）や単純なPDF辞書とは異なり、すべてのエントリを同時にロードすることなく大規模なデータセットを効率的に処理できます。木構造により、検索、挿入、削除の操作を、総エントリ数に対して対数的な計算量で実行できます。

ネームツリーは ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で明示的に定義されており、名前はUnicodeコードポイントを使用して辞書順にソートする必要があるという厳密な順序規則に従います。木内の各ノードには、子ノードを指す/Kids配列、または実際のキーと値のペアを交互の要素として含む/Names配列のいずれかが含まれます。

ネームツリー（EmbeddedFiles）は、PDF文書内の特殊なネームツリー構造であり、人間が読めるファイル名と対応する埋め込みファイル仕様との間のマッピングを確立します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で定義されているように、このツリーは文書のネーム辞書に格納され、PDF内に埋め込まれたファイルを整理して検索およびアクセスするための方法を提供します。EmbeddedFilesネームツリーは、PDF文書内のすべての添付ファイルの主要なインデックスとして機能し、PDFプロセッサとユーザーの両方が埋め込みコンテンツを列挙および取得できるようにします。

EmbeddedFilesネームツリーは、キーがファイル名を表すテキスト文字列で、値が埋め込みファイルを記述するファイル仕様辞書であるキー・バリュー型のデータ構造です。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) によると、このツリーは文書カタログのNames辞書内に存在し、PDFで定義されている一般的なネームツリー構造に従います。さまざまなオブジェクトタイプにマッピングされる可能性のある他のネームツリーとは異なり、EmbeddedFilesネームツリーは特に埋め込みファイルストリームを含むファイル仕様辞書にマッピングされます。このツリー構造により、PDFに数百または数千の添付ファイルが含まれている場合でも、効率的な検索と埋め込みファイルの列挙が可能になります。これは、文書レベルでカタログ化されるのではなく、特定のページに関連付けられるページレベルのファイル添付注釈とは異なります。

トークンは、PDFパーサーがPDFファイルを読み取る際に認識して処理できる、構文上の最小単位です ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。トークンはPDF構文の基本的な構成要素であり、名前、数値、キーワード、文字列、配列、辞書、演算子などが含まれます。PDFファイル構造を扱う全ての開発者にとって、トークンの理解は不可欠です。なぜなら、トークンはドキュメント内のデータと命令がどのように表現されるかを定義するものだからです。

PDF構文において、トークンは解析プロセスにおいてこれ以上意味のある単位に分割できないアトミックな単位を表します。PDF仕様では、いくつかのトークンカテゴリを定義しています：真偽値（true/false）、数値オブジェクト（整数および実数）、文字列オブジェクト（リテラルおよび16進数）、名前オブジェクト（スラッシュで始まる識別子）、配列オブジェクト（角括弧で囲まれたもの）、辞書オブジェクト（山括弧で囲まれたもの）、nullオブジェクト、およびストリームキーワードです ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。

ナンバーツリーは、PDF仕様で定義された特殊なツリー構造であり、整数からPDFオブジェクトへの効率的なマッピングを提供します ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。文字列を値にマッピングするネームツリーとは異なり、ナンバーツリーは整数キーを使用してデータをソート順に整理・取得します。この構造は、ページラベリングや構造要素の整理など、連続的な数値インデックスを必要とするPDFドキュメントの機能で一般的に使用されます。

ナンバーツリーは、PDF形式で規定された平衡木データ構造であり、整数キーを任意のPDFオブジェクトにマッピングします。この構造は、リーフレベルでは「Nums」配列を、親レベルでは「Kids」配列を持つ中間ノードを使用して、エントリを階層的に整理します。Nums配列の各エントリは、整数キーとそれに関連付けられた値オブジェクトで構成されます。キーは昇順の数値順序で格納される必要があり、これにより効率的な二分探索操作が可能になります。ナンバーツリーは、文字列ではなく整数キーを使用する点でネームツリーと異なり、未使用のインデックスに領域を割り当てることなく疎な整数範囲をより効率的に処理できる点で単純な配列とは異なります。

ナンバーツリーは、大規模な範囲にわたって数値インデックスを必要とするオブジェクトの効率的な保存と取得を可能にするため、PDFドキュメントを扱う開発者にとって不可欠です。PDFジェネレーターやプロセッサーを構築する際、ナンバーツリーを理解することは、カスタムナンバリングスキームを持つページラベルの実装、Tagged PDFにおける構造要素の管理、構造コンテンツアイテムを親要素にマッピングする親ツリーの処理において重要です ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。大きなドキュメントでは、特に可能なインデックスのサブセットのみが実際に使用される疎な数値範囲を扱う場合、ナンバーツリーはフラット配列に比べて大きなパフォーマンス上の利点を提供します。アクセシビリティ機能に取り組む開発者は、PDF/UA準拠に不可欠な構造階層のParentTreeでナンバーツリーに頻繁に遭遇します。

リテラル文字列は、PDF構文における2つの基本的な文字列オブジェクトタイプの1つであり、括弧(...)で囲まれたテキストで構成され、PDFファイル内で文字データを直接表現します ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。16進数文字列とは異なり、リテラル文字列は人間が読める形式を使用し、直接入力できない文字を表現するための特殊なエスケープシーケンスを備えています。この文字列タイプは、PDFドキュメント全体でテキストコンテンツ、メタデータ、およびさまざまな文字列ベースのプロパティに一般的に使用されます。

PDFにおけるリテラル文字列は、左括弧と右括弧の間に記述される文字のシーケンスであり、文字が直接それ自身を表現します。PDF仕様では、リテラル文字列は括弧(と)で囲まれると定義されており、文字列内にこれらの区切り文字が出現する場合は、バックスラッシュ文字を使用したエスケープシーケンスが必要です ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。