2. Lexical Analysis of Messages (メッセージの字句解析)
2.1. General Description (一般的な説明)
最も基本的なレベルでは、メッセージは一連の文字です。本仕様に準拠するメッセージは、1から127の範囲の値を持つ文字で構成され、US-ASCII 文字として解釈されます。便宜上、本文書ではこの文字範囲を単に「US-ASCII 文字」と呼ぶことがあります。
注意: 本仕様は、メッセージが US-ASCII の 1 から 127 の範囲の文字で構成されることを規定しています。他の文書、特に MIME 文書シリーズ (RFC 2045、RFC 2046、RFC 2047、RFC 2049、RFC 4288、RFC 4289) は、この範囲外の値を許可するように本仕様を拡張しています。これらのメカニズムの議論は、本仕様の範囲外です。
メッセージは複数の文字行に分割されます。行は、キャリッジリターンとラインフィードの2文字で区切られた一連の文字です。つまり、キャリッジリターン (CR, Carriage Return) (ASCII 値 13) の直後にラインフィード (LF, Line Feed) (ASCII 値 10) が続きます。(キャリッジリターン/ラインフィードのペアは、本文書では通常「CRLF」と記述されます。)
メッセージは、ヘッダーフィールド (Header Fields) (総称して「メッセージのヘッダーセクション」と呼ばれる) で構成され、オプションで本文 (Body) が続きます。ヘッダーセクションは、本仕様で定義されている特別な構文を持つ文字行のシーケンスです。本文は、ヘッダーセクションに続く単なる文字のシーケンスであり、空行 (つまり、CRLF の前に何もない行) によってヘッダーセクションから分離されます。
注意: 一般的な言い方や本仕様の以前のバージョンでは、「header」という用語を使用して、ヘッダーセクション全体または個々のヘッダーフィールドを指していました。曖昧さを避けるため、本文書では「header」または「headers」という用語を単独で使用せず、個々のフィールドを指す場合は常に「header field」(ヘッダーフィールド)、コレクション全体を指す場合は「header section」(ヘッダーセクション) を使用します。
メッセージ構造図
メッセージ (Message)
├── ヘッダーセクション (Header Section)
│ ├── From: [email protected] CRLF
│ ├── To: [email protected] CRLF
│ ├── Subject: Hello CRLF
│ └── Date: ... CRLF
├── 空行 (Empty Line)
│ └── CRLF
└── 本文 (Body)
├── This is the message body. CRLF
└── Second line. CRLF
2.1.1. Line Length Limits (行長制限)
本仕様は、行内の文字数に2つの制限を設けています。各文字行は、CRLF を除いて 998 文字以下でなければならず (MUST)、78 文字以下であるべきです (SHOULD)。
998 文字制限は、IMF メッセージを送信、受信、または保存する多くの実装において、単に 998 文字を超える行を処理できないという制限があるために存在します。受信実装は、堅牢性のために、行内の任意に大きな数の文字を処理できることが望ましいです。ただし、(RFC 5321 の転送要件に準拠して) CR と LF を含めて 1 行あたり 1000 文字を超えるメッセージを受け入れない実装が非常に多いため、実装がそのようなメッセージを作成しないことが重要です。
より保守的な 78 文字の推奨は、これらのメッセージを表示する多くのユーザーインターフェース実装を収容するためのものです。これらの実装は、1 行あたり 78 文字を超える内容を切り捨てたり、悲惨な折り返し表示をしたりする可能性があります。そのような実装は本仕様の意図に準拠していませんが (実際に情報が失われる場合は RFC 5321 の意図にも準拠していません)。繰り返しますが、このような制限がメッセージに課されていても、メッセージを表示する実装は、堅牢性のために、行内の任意に大きな数の文字 (少なくとも 998 文字制限まで) を処理する責任があります。
行長制限まとめ:
| 制限タイプ | 長さ (CRLF を除く) | 要件 | 理由 |
|---|---|---|---|
| ハード制限 | 998 文字 | しなければならない (MUST) | 多くの実装がより長い行を処理できない |
| 推奨制限 | 78 文字 | すべきである (SHOULD) | UI での表示切り捨てに対応 |
行長の例:
✅ 推奨に準拠 (78 文字以内):
Subject: This is a short subject line
✅ 準拠しているが推奨を超える (78-998 文字):
Subject: This is a very long subject line that exceeds the recommended 78 character limit but is still within the required 998 character maximum limit
❌ 非準拠 (998 文字を超える):
Subject: [998 文字を超えるコンテンツ...]
2.2. Header Fields (ヘッダーフィールド)
ヘッダーフィールドは、フィールド名 (Field Name) で始まり、コロン (":")、フィールド本体 (Field Body)、CRLF で終了する行です。フィールド名は、コロンを除いて、印字可能な US-ASCII 文字 (つまり、33 から 126 までの値を持つ文字、境界を含む) で構成されなければなりません (MUST)。フィールド本体は、印字可能な US-ASCII 文字、およびスペース (SP、ASCII 値 32) と水平タブ (HTAB、ASCII 値 9) 文字 (合わせて空白文字、WSP として知られる) で構成できます。フィールド本体は、セクション 2.2.3 で説明されている「折り返し」(Folding) および「展開」(Unfolding) で使用される場合を除き、CR と LF を含んではなりません (MUST NOT)。すべてのフィールド本体は、本仕様のセクション 3 および 4 で説明されている構文に準拠しなければなりません (MUST)。
ヘッダーフィールド形式:
Field-Name: Field-BodyCRLF
↑ ↑ ↑ ↑
| | | +--- 行終端子
| | +---------- フィールド内容
| +----------------- コロン区切り文字
+------------------------- フィールド名
例:
From: [email protected]
Subject: Meeting Tomorrow
Date: Mon, 20 Dec 2025 10:00:00 +0800
2.2.1. Unstructured Header Field Bodies (非構造化ヘッダーフィールド本体)
本仕様の一部のフィールド本体は、単に「非構造化」(Unstructured) として定義されています (セクション 3.2.5 で、任意の印字可能な US-ASCII 文字と空白文字として規定されています)。これ以上の制限はありません。これらは非構造化フィールド本体と呼ばれます。意味的には、非構造化フィールド本体は、(セクション 2.2.3 で説明されている「折り返し」と「展開」を除いて) さらなる処理なしに、単に文字の単一行として扱われます。
非構造化フィールドの例:
Subject: This is any text I want to write
Comments: Here's a free-form comment
特徴:
- 自由形式の内容、任意の印字可能 ASCII 文字
- 特定の構文構造は不要
- 折り返し/展開のみを処理する必要がある
2.2.2. Structured Header Field Bodies (構造化ヘッダーフィールド本体)
本仕様の一部のフィールド本体は、上記の非構造化フィールド本体よりも制限的な構文を持っています。これらは「構造化」(Structured) フィールド本体と呼ばれます。構造化フィールド本体は、本仕様のセクション 3 および 4 で説明されている特定の字句トークン (Lexical Tokens) のシーケンスです。これらのトークンの多くは (その構文に従って)、セクション 3.2.2 で説明されているコメントや空白文字で開始または終了することが許可されており、これらの空白文字はセクション 2.2.3 で説明されている「折り返し」と「展開」の対象となります。構造化フィールド本体のセマンティクス分析は、その構文とともに示されます。
構造化フィールドの例:
From: Alice Smith <[email protected]>
To: [email protected], [email protected]
Date: Mon, 20 Dec 2025 10:00:00 +0800
特徴:
- 厳密な構文規則に従わなければならない
- 特定の字句トークンを含む (例: メールアドレス、日時)
- コメントと空白を含めることができる
- 構文に従って解析する必要がある
比較:
| タイプ | 構文の厳格さ | 処理方法 | 典型的な例 |
|---|---|---|---|
| 非構造化 | 緩い、自由テキスト | 文字列全体として | Subject、Comments |
| 構造化 | 厳密、特定の構文 | 字句トークンで解析 | From、To、Date |
2.2.3. Long Header Fields (長いヘッダーフィールド)
各ヘッダーフィールドは、論理的には、フィールド名、コロン、フィールド本体で構成される単一の文字行です。ただし、便宜上、また 1 行あたり 998/78 文字の制限に対処するために、ヘッダーフィールドのフィールド本体部分を複数行表現に分割できます。これは「折り返し」(Folding) と呼ばれます。一般的な規則は、本仕様が折り返し空白 (単なる WSP 文字ではない) を許可している場所では、任意の WSP の前に CRLF を挿入できるというものです。
折り返しの例:
元のヘッダーフィールド:
Subject: This is a test
次のように表現できます (折り返し後):
Subject: This
is a test
注意: 構造化フィールド本体の定義では、折り返し空白が許可されている場所 (字句トークン内でも) であればどこでも折り返しが許可されますが、折り返しは、CRLF をより高レベルの構文ブレークに配置することに制限すべきです (SHOULD)。たとえば、フィールド本体がコンマ区切りの値として定義されている場合、他の場所でも許可されていても、構造化された項目を区切るコンマの後で折り返すことが推奨されます。
折り返しルール:
- 挿入位置: 任意の WSP (スペースまたはタブ) の前に CRLF を挿入
- 継続行: 次の行は WSP で始まらなければならない
- 推奨位置: 高レベルの構文ブレーク (例: コンマの後)
複数アドレス折り返しの例:
推奨される折り返し (コンマの後):
To: [email protected],
[email protected],
[email protected]
推奨されないが合法:
To: [email protected], bob@
example.com, [email protected]
展開 (Unfolding) は、この折り返された複数行表現を単一行表現に戻す逆のプロセスです。展開は、WSP の直後にある CRLF を単純に削除することによって行われます。各ヘッダーフィールドは、さらなる構文およびセマンティクス評価のために、その展開された形式で処理されるべきです。展開されたヘッダーフィールドには長さ制限がないため、不定の長さになる可能性があります。
展開プロセス:
折り返し前 (論理):
Subject: This is a very long subject line
折り返し後 (転送):
Subject: This is a
very long subject line
展開後 (解析):
Subject: This is a very long subject line
展開アルゴリズム:
1. 識別: CRLF + WSP パターンを見つける
2. 削除: CRLF を削除し、WSP を保持
3. 結果: 連続した単一行文字列
2.3. Body (本文)
メッセージの本文は、単に US-ASCII 文字の行です。本文に対する唯一の2つの制限は次のとおりです:
- CR と LF は CRLF として一緒にのみ発生しなければなりません (MUST)。本文内で独立して出現してはなりません (MUST NOT)。
- 本文内の文字行は、CRLF を除いて、998 文字に制限されなければならず (MUST)、78 文字に制限されるべきです (SHOULD)。
注意: 前述のように、他の文書、特に MIME 文書 (RFC 2045、RFC 2046、RFC 2049、RFC 4288、RFC 4289) は、異なる種類のメッセージ本文を許可するようにこの仕様を拡張 (および制限) しています。繰り返しますが、これらのメカニズムは本文書の範囲外です。
本文制限まとめ:
| 制限タイプ | 要件 | 説明 |
|---|---|---|
| 行終端子 | CRLF を使用しなければならない (MUST) | CR と LF は独立して出現できない |
| 行長 (ハード) | ≤ 998 文字でなければならない (MUST) | CRLF を除く |
| 行長 (推奨) | ≤ 78 文字であるべき (SHOULD) | CRLF を除く |
合法的な本文の例:
Hello Bob,CRLF
CRLF
Let's meet tomorrow at 10am.CRLF
CRLF
Best regards,CRLF
Alice CRLF
非合法的な本文の例:
❌ 独立した CR または LF を含む:
Hello BobCR (LF が欠けている)
LineLF (CR が欠けている)
❌ 行が長すぎる (998 文字を超える):
[998 文字を超える連続テキスト...]
第 2 章のまとめ
主要概念
- 文字セット: US-ASCII (1-127)
- 行終端子: CRLF (CR+LF)
- メッセージ構造: ヘッダーセクション + 空行 + 本文
- 行長: 998 文字 (MUST)、78 文字 (SHOULD)
ヘッダーフィールドタイプの比較
非構造化フィールド 構造化フィールド
↓ ↓
Subject: Any text From: user@domain
Comments: ... To: user1, user2
Date: Day, DD Mon YYYY
↓ ↓
全体として 構文で解析
処理
折り返しメカニズム
長いフィールド 折り返し
↓ ↓
To: [email protected], To: [email protected],
[email protected] --> [email protected]
↑ ↑
単一行 (論理) 複数行 (転送)
←--- 展開 ---
次のステップ
第 2 章では、メッセージの字句概要を提供しました。セクション 3 では、準拠メッセージを作成するための正確な ABNF 構文規則を定義します。
次へ: 3. Syntax (構文)