この規格ページの目次
19
X 5810-1 : 2008
c) 符号化入力の最後の分量が,ちょうど16 bitになっている。この場合,符号化出力の最後の単位(か
たまり)は,三つの文字に,一つの“=”パディング文字が後続したものとなる。
“=”文字はデータの最後のパディングのためだけに用いられるので,途中で切り取られなかった場合には,
“=”文字の出現はデータの最後に到達した証拠とみなしてもよい。しかし,転送されたオクテットの数が3
の倍数であって“=”文字が存在しないときは,このような保証は可能ではない。
base64アルファベット以外の文字は,base64符号化データの中では,無視するのが望ましい。
正準形式に変換されていないテキストデータに対してbase64符号化を直接に適用する場合には,行区切
りのために適切なオクテットを使うように注意しなければならない。特に,テキストの行区切りは,base64
符号化の前に,CRLF列に変換されなければならない。実装の中には,この変換を,先行する正準化段階
ではなく,符号化器によって直接に行うものもあるという点に注意することが重要である。
注記2 マルチパート実体の内部のbase64符号化本体内で,存在する可能性のある境界区切り子を引
用する( quote )ことについては,心配する必要はない。これは,base64符号化では“-”(ハイ
フン)文字は使用されないことによる。
7 Content-ID(内容識別子)ヘッダフィールド
高機能のUAを作成するとき,ある本体が他の本体への参照を行うのを可能にすることが望まれる場合
がある。それに従って,本体は,構文的にはMessage-IDヘッダフィールドと同一の,Content-IDヘッダフ
ィールドを使ってラベル付けしてよい。
id := "Content-ID" ":" msg-id
Message-ID値と同様に,Content-ID値は,世界で一意となるように生成されなければならない。
注記 世界で一意とする方法については,この規格では規定しない。
Content-ID値は,幾つかの文脈においてMIME実体を一意に識別するために,特に,message/external-body
機構によって参照されるデータをキャッシュするために使ってよい。Content-IDは一般にオプションだが,
オプションのMIMEメディア型である“message/external-body”のデータを生成する実装では,その使用は必
す(須)とする。すなわち,それぞれのmessage/external-body実体は,これらデータのキャッシュ化を許
すためにContent-IDフィールドをもたなければならない。
Content-ID値は,multipart/alternativeメディア型の場合には特別なセマンティクスをもつことに注意する
ことも重要である。このことは,JIS X 5810-2において,multipart/alternativeについて扱う箇条で示される。
8 Content-Description(内容記述)ヘッダフィールド
説明的な情報を与えられた本体と関連付ける能力が,望まれることが多い。例えば,“image”本体に“ス
ペースシャトルエンデバーの写真”といった印を付けることは役に立つかもしれない。それらテキストは,
Content-Descriptionヘッダフィールドの中に置いてよい。このヘッダフィールドは,常にオプションとする。
description := "Content-Description" ":" *text
この記述( description )は,US-ASCII文字集合で与えられることを想定する。ただし,JIS X 5810-3で規
定される機構を使って,非US-ASCII文字をContent-Descriptionフィールドの値としてもよい。
9 追加のMIMEヘッダフィールド
将来の規定では,種々の目的のために追加のMIMEヘッダフィールドを定義することを決定してもよい。
メッセージの内容を更に記述する新しいヘッダフィールドは,メッセージヘッダに現れるそれらフィール
――――― [JIS X 5810-1 pdf 21] ―――――
20
X 5810-1 : 2008
ドを通常のRFC 822ヘッダフィールドと区別するために,文字列“Content-”で始めることが望ましい。
MIME-extension-field := <文字列“Content-”で始まる任意のRFC 822ヘッダフィールド>
10 要約
MIME-Versionヘッダフィールド,Content-Typeヘッダフィールド及びContent-Transfer-Encodingヘッダ
フィールドを使って,標準化された方法で,RFC 822に適合するメールメッセージに任意の型のデータを
含ませることが可能になる。RFC 821又はRFC 822のどちらかによって課される制約に違反しない。幾つ
かのインターネットメール転送機構の特徴によって追加的に課される制約が引き起こす問題を避けるため
の注意が行われた。これについては,JIS X 5810-5に記す。
JIS X 5810-2では,これらのヘッダを使ってラベル付け及び転送ができるメディア型の初期集合を規定
する。
11 セキュリティへの考慮
セキュリティに関しては,JIS X 5810-2で論じられる。
――――― [JIS X 5810-1 pdf 22] ―――――
21
X 5810-1 : 2008
附属書A
(参考)
文法一覧
この附属書は,本体に関連する事柄を補足するものであって,規定の一部ではない。
この附属書は,この規格で規定されるすべての構文の,完全な拡張BNF文法を示す。
しかし,この文法は,それ自体だけでは不完全である。この文法は,RFC 822で定義される幾つかの構
文規則を名前によって参照する。これらの定義をここで再び示し,二つの間で意図しない差異を生じる危
険を冒すのではなく,残りの定義については,読者にRFC 822を参照してもらうことにした。用語(term。
構文の中の終端子又は非終端子。)が定義されていない場合には,それは,RFC 822の定義を参照している。
attribute := token
; 属性の合致は,
; 常に大文字・小文字を区別しない。
composite-type := "message" / "multipart" / extension-token
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; メディア型及びメディア下位型の合致は,
; 常に大文字・小文字を区別しない。
description := "Content-Description" ":" *text
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
encoding := "Content-Transfer-Encoding" ":" mechanism
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
extension-token := ietf-token / x-token
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; 127より大きな文字,=,又は行末のSPACE若しくはTABには
――――― [JIS X 5810-1 pdf 23] ―――――
22
X 5810-1 : 2008
; オクテットが使われなければならず,
; JIS X 5810-5で“mail-safe”の一覧にない文字のためには
; オクテットが推奨される。
iana-token := <公式に定義された拡張トークン。
この形式のトークンは,RFC 2048で規定されるとおりに
IANAに登録されなければならない。>
ietf-token := <標準化手続のRFCによって定義され,IANAで登録された拡張トークン>
id := "Content-ID" ":" msg-id
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
MIME-extension-field := <文字列“Content-”で始まる
任意のRFC 822ヘッダフィールド。>
MIME-message-headers := entity-headers
fields
version CRLF
; この拡張BNF定義が含むヘッダフィールドの順序付けは,
; 無視するほうがよい。
MIME-part-headers := entity-headers
[ fields ]
;“content-”で始まらないすべてのフィールドは,
; 定義された意味をもつことはできず,無視してよい。
; この拡張BNF定義が含むヘッダフィールドの順序付けは,
; 無視するほうがよい。
parameter := attribute "=" value
ptext := hex-octet / safe-char
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
――――― [JIS X 5810-1 pdf 24] ―――――
23
X 5810-1 : 2008
; 最大長は76文字。
qp-section := [*(ptext / SPACE / TAB) text]
qp-segment := qp-section *(SPACE / TAB) "="
; 最大長は76文字。
quoted-printable := qp-line *(CRLF qp-line)
safe-char := <10進の値が3360及び62126をもつ任意のオクテット>
; 更に,JIS X 5810-5の“mail-safe”の一覧にない
; 文字も推奨しない。
subtype := extension-token / iana-token
token := 1*<SPACE,CTL,tspecialsを除く,任意の(US-ASCII) HAR>
transport-padding := *LWSP-char
; 送信者は,長さが0ではないトランスポート
; パディングを生成してはならないが,
; 受信者は,メッセージトランスポート
; によって追加されたパディングを
; 処理できなければならない。
"(" / ")" / "<" / ">" / "@" /
tspecials :=
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "・" / "="
; パラメタ値内で使うため,
; quoted-stringでなければならない。
type := discrete-type / composite-type
value := token / quoted-string
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
x-token := <“X-”又は“x-”の2文字で始まり,空白を含まない,任意のトークン。>
――――― [JIS X 5810-1 pdf 25] ―――――
次のページ PDF 26
JIS X 5810-1:2008の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.240 : 情報技術(IT)の応用 > 35.240.30 : 情報,ドキュメンテーション及び出版業務におけるITの応用
- 35 : 情報技術.事務機械 > 35.110 : 情報通信ネットワーキング
JIS X 5810-1:2008の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX0202:1998
- 情報技術―文字符号の構造及び拡張法
- JISX5810-2:2008
- 多目的インターネットメール拡張(MIME)―第2部:メディア型
- JISX5810-3:2008
- 多目的インターネットメール拡張(MIME)―第3部:非ASCIIテキストへのメッセージヘッダ拡張
- JISX5810-5:2008
- 多目的インターネットメール拡張(MIME)―第5部:適合基準