この規格ページの目次
14
X 5810-1 : 2008
たCRLFへ変換されなければならない。同様に,base64復号後に得られるデータの正準形式でのCRLF列
は,テキストデータを変換するときにだけ,quoted-printableでの原文内( hard )行区切りに変換されなけれ
ばならない。
6.6 正準符号化モデル
この規格の原規定であるRFCの以前の版では,電子メールデータが正準形式に変換され符号化されると
きのモデルについて,特に,システムごとに改行の表現が非常に異なっているときに,この(変換)処理
が,CRLFの振る舞いにどう影響するか,及び内容転送符号化と文字集合との間の関係にどう影響するか
について,多少の混乱があった。この理由から,符号化のための正準モデルが,JIS X 5810-5で提示され
る。
6.7 quoted-printable(印字可能引用)Content-Transfer-Encoding
quoted-printable符号化は,大部分がUS-ASCII文字集合の中の印字可能文字に対応するオクテットから
構成されるデータを表現することを意図している。この符号化は,結果として生じるオクテットがメール
トランスポートによって変更されることはまずないといった方法で,データを符号化する。符号化される
データがほとんどUS-ASCIIテキストの場合,データの符号化された形式は,人によって大部分認識可能
なままになっている。全体がUS-ASCIIである本体も,文字変換及び/又は行折返しを行うゲートウェイ
をメッセージが通過する場合に,データの完全性を保証するために,quoted-printableによって符号化して
もよい。
この符号化では,オクテットは,次の規則によって決定されるとおりに表現されるのが望ましい。
a) 一般8 bit表現 符号化されるデータの正準形式(標準形式)のCRLF行区切りの一部であるCR又は
LFを除くあらゆるオクテットは,一つの“=”にそのオクテットの値の16進表現の二つの数字(2けた
の16進数)を続けたもので表してよい。この目的のために使う16進の数字は,“0123456789ABCDEF”
とする。大文字を使わなければならず,小文字は使ってはならない。例えば,10進の値が12( US-ASCII
form feed )は“=0C”で表現でき,10進の値が61( US-ASCII EQUAL SIGN )は“=3D”で表現できる。後続
の規則が代替の符号化を許す場合を除き,この規則には従わなければならない。
b) 文字表現 10進の値が33以上60以下及び62以上126以下のオクテットは,それらのオクテットに
対応するUS-ASCII文字,それぞれ,EXCLAMATION POINTからLESS THANまで及びGREATER
THANからTILDEまで,として表現してよい。
c) 空白 10進の値が9及び32のオクテットは,US-ASCIIのTAB( HT )文字及びSPACE文字として表現
してよいが,符号化された行の末尾で表現してはならない。符号化された行のTAB( HT )文字及び
SPACE文字には,印字可能文字がその行で後続しなければならない。符号化された行の末尾の“=”は,
無指定( soft )行区切り[規則e)を参照]を示しているが,一つ以上のTAB( HT )文字又はSPACE文字
に続いてもよい。これは,符号化された行の末尾で10進の値が9又は32のオクテットは,1番目の
規則によって表現されなければならないことに従っている。MTA[Message Transport Agent(メッセー
ジ転送エージェント),すなわち,一人の利用者から他の利用者へのメッセージを転送する,又はそれ
ら転送の一部を実行するプログラム]の中には,テキストの行をSPACEでパディングするものがあ
ることが知られていて,更に行末から“空白”文字を取り除くものも知られているので,この規則が必
要になる。そのために,中間の転送エージェントによって空白が加えられることが避けがたいので,
quoted-printable本体を復号するとき,行の末尾に付いているすべての空白を削除しなければならない。
d) 改行 テキストの正準形式ではCRLF列として表現される,テキスト本体中の行区切りは,
quoted-printable符号化では,やはりCRLF列であるRFC 822の行区切りによって表現されなければな
――――― [JIS X 5810-1 pdf 16] ―――――
15
X 5810-1 : 2008
らない。テキスト以外のメディア型の正準表現は一般にはCRLF列としての行区切りの表現を含まな
いので,原文内( hard )行区切り(すなわち,意味があり,利用者に表示されることを意図している行
区切り)は,これらの型のquoted-printableには出現できない。もちろん,quoted-printableで表現され
たテキストでないデータには,“=0D”,“=0A”,“=0A=0D”及び“=0D=0A”といった列は,機械的に現れ
ることがある。
多くの実装は,まず正準形式に変換し,符号化し,それから局所的な表現に戻すのではなく,直接
に様々な内容型の局所的な表現を符号化することを選んでもよいことに注意する。特に,このことを,
CRLF終端子列ではない改行規約を使うシステムで,プレーンテキストのデータに適用してもよい。
このような実装の最適化は許されるが,(それと)組み合わされた正準化符号化の段階が,三つの段階
を別々に実施するのと等価な場合だけに限る。
e) 符号化時(soft)行区切り quoted-printable符号化では,符号化された行が76文字を超えてはならない。
quoted-printable符号化でそれより長い行が符号化される場合,“符号化時( soft )”行区切りが使われな
ければならない。符号化された行の最後の文字としての等号は,符号化されたテキストの中で意味が
ない“符号化時( soft )”行区切りを示す。
そこで,行の“元の( raw )”形式が,次の符号化されていない単一の行の場合を考える。
Now's the time for all folk to come to the aid of their country.
quoted-printable符号化では,これを次のとおりに表せる。
Now's the time =
for all folk to come=
to the aid of their country.
これは,UAによって元に戻されるといった方法で,長い行を符号化する機構を提供する。76文字制限
は,末尾のCRLFを数えないが,等号を含めた他のすべての文字を数える。
ハイフン文字(“-”)は,それ自体,quoted-printable符号化で表現してよいので,一つ以上のマルチパート
実体の内部にquoted-printableで符号化された本体をカプセル化するときには,その境界区切り子1)が,符
号化された本体のどこにも現れないことを保証するために,注意をしなければならない。よい戦略として
は,quoted-printable(で符号化された)本体には現れることのない“=” といった文字列を境界に選ぶこと
がある。JIS X 5810-2のマルチパートメッセージの定義を参照1)。
注記1 quoted-printable符号化は,可読性と転送における信頼性との折衷的なものを表現している。
quoted-printable符号化で符号化された本体は,ほとんどのメールゲートウェイにおいて高い
信頼性で動作するが,少数のゲートウェイ,特に,EBCDICへの変換を伴うものでは完全に
は動かないかもしれない。より高いレベルの信頼性は,base64 Content-Transfer-Encodingによ
って提供される。EBCDICゲートウェイを通る妥当な信頼性のある転送を得る方法は,次の
US-ASCII文字も,前の1番目の規則で示した16進表現にすることである。
!"#$@[\]^[{|}]~
quoted-printableデータは一般に行に基づくことを仮定しているので,改行規約の異なるシス
テム間で渡されるとき,インターネットメールにおいてプレーンテキストメールが常に変更
されてきたのと同じように,quoted-printableデータの行の間の区切りの表現は,転送中に変
更されるかもしれないと予想される。これら変更が,データの変造を引き起こす可能性があ
る場合,quoted-printable符号化ではなく,base64符号化を使うことがおそらくより賢明とい
える。
――――― [JIS X 5810-1 pdf 17] ―――――
16
X 5810-1 : 2008
注記2 quoted-printable内容転送符号化のための符号化規則に従って,ある種の部分文字列を生成す
ることはできない。したがって,quoted-printable符号化器の出力にそれらが出現する場合は,
形式的には不正とする。この注記は,これらの場合を列挙し,復号されるquoted-printableデ
ータの中で次のどれかに出会う場合,それら不正な部分文字列を取り扱う方法を示す。
a) 一つ又は両方が“abcdef”のうちのいずれかの小文字となっている二つの16進数字に後続
される“=”は,形式的には不正とする。頑健な実装は,それらを対応する大文字として認
識するとよいかもしれない。
b) “abcdef”の場合を含む16進の数字でなく,CRLF対のCR文字でもない文字に後続され
る“=”は,不正とする。この場合は,それ自体がquoted-printable符号化に従っていない,
メッセージのquoted-printable部分に含まれている,US-ASCIIテキストの結果の可能性
がある。頑健な実装による理にかなった方針は,復号されたデータに,“=”文字及びそれ
に後続する(一つの)文字を変換せずに含ませ,可能な場合には,利用者に,データの
この箇所で適切な復号ができなかったことを示すことかもしれない。
c) “=”は,符号化されたオブジェクトの中で最後又は最後から2番目の文字となることはで
きない。これは,前項の場合として取り扱ってよい。
d) AB,又はCRLF対の一部としてのCR及びLF,以外の制御文字は現れてはならない。
10進の値が126より大きい値のオクテットに対しても同じとする。それらの文字が,復
号器によって,到着したquoted-printableデータの中に発見された場合,頑健な実装は,
復号されたデータからそれら文字を除外し,利用者に不正文字が発見されたことを警告
するとよいかもしれない。
e) 符号化した行は,末尾のCRLFを数えずに,76文字より長くてはならない。より長い行
が到着した符号化されたデータの中に発見された場合,頑健な実装は,エラーではある
がその行を復号し,利用者にエラーのある符号化であることを報告するとよいかもしれ
ない。
注記3 binaryデータがquoted-printableで符号化される場合,CR文字及びLF文字をそれぞれ“=0D”
及び“=0A”として符号化することに注意しなければならない。特に,binaryデータでのCRLF
列は,“=0D=0A”と符号化するのがよい。そうでない場合であって,CRLFが指定( hard )行区
切りとして表現される場合,異なった行区切り規約をもつプラットホームでは,正しく復号
されないかもしれない。
注1) IS X 5810-2において,境界区切り子は,ハイフン文字を使って定義されている。
quoted-printableデータの構文は,次の形式文法で記述される。
quoted-printable := qp-line *(CRLF qp-line)
qp-line := *(qp-segment transport-padding CRLF)
qp-part transport-padding
qp-part := qp-section
; 最大長76文字。
qp-segment := qp-section *(SPACE / TAB) "="
――――― [JIS X 5810-1 pdf 18] ―――――
17
X 5810-1 : 2008
; 最大長76文字。
qp-section := [*(ptext / SPACE / TAB) text]
ptext := hex-octet / safe-char
safe-char := <10進の値が3360及び62126をもつ任意のオクテット>
; 更に,JIS X 5810-5の“mail-safe”の一覧にない
; 文字も推奨しない。
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; 127より大きな文字,=,又は行末のSPACE若しくはTABには
; hex-octetが使われなければならず,
; JIS X 5810-5で“mail-safe”の一覧にない文字のためには
; hex-octetが推奨される。
transport-padding := *LWSP-char
; 送信者は,長さが0ではないトランスポート
; パディングを生成してはならないが,
; 受信者は,メッセージトランスポート
; によって追加されたパディングを
; 処理できなければならない。
この拡張BNFでは構造化ヘッダフィールドを規定していないので,この拡張BNFに示される要素間で
のLWSP(空白の並び)の追加は許されない。このことは,重要である。
6.8 Base64 Content-Transfer-Encoding
Base64 Content-Transfer-Encodingは,任意のオクテット列を,人が読めなくともよい形式で,表現するた
めに設計された。符号化及び復号のアルゴリズムは単純だが,符号化されたデータは,符号化されていな
いデータに比べ,一貫しておよそ33パーセントほど大きい。この符号化は,実質的に,RFC 1421で定義
されている,Privacy Enhanced Mail ( PEM ) アプリケーションと同等になっている。
US-ASCIIの65文字の部分集合を使用し,印字可能な一つの文字ごとに6 bitを表現可能とする。65番
目の文字“=”は,特別な処理機能を意味するために使用する。
注記1 この部分集合は,US-ASCIIを含むISO/IEC 646のすべての版で同一に表現されるという,重
要な特性をもち,このすべての文字は,EBCDICのすべての版でも,同一に表現される。
uuencodeユティリティ,Macintoshのbinhex 4.0 [RFC 1741]及びレベル 2 PostScriptの一部と
して規定されるbase85符号化といった,他のよく利用される符号化は,この特性を共有せず,
そのために,メール用のbinary内容転送符号化が満たさなければならない可搬性要件を満足
しない。
符号化処理は,四つの符号化文字の出力列として,入力ビットの24 bit(単位の)群( 24-bit group )を表
現する。左から右へと進めて,一つの24 bitの入力群が,三つの8 bit入力群を連結することによって,形
――――― [JIS X 5810-1 pdf 19] ―――――
18
X 5810-1 : 2008
成される。次に,これらの24 bitを,四つの連結された6 bit群として取り扱い,それぞれをbase64アルフ
ァベット(base64の構成単位)における単一の数字へと変換する。base64符号化を通じてビットストリー
ムを符号化する場合,ビットストリームは,最上位ビットが先になる順番と仮定されていなければならな
い。すなわち,ビットストリームの最初のビットは,最初の8 bit(単位の)バイトの中の上位ビットとな
り,8番目のビットは,最初の8 bit(単位の)バイトの中の下位ビットとなる,など,以下同様とする。
それぞれの6 bit群は,64個の印字可能文字の配列へのインデクスとして使われる。インデクスによっ
て参照される文字が,出力列の中に置かれる。次の表1で識別されるこれらの文字は,広い範囲で表現可
能なように選ばれ,例えば,“.”,CR,LFなどの,SMTPに対して特定の意味をもつ文字,及び例えば“-”
などのJIS X 5810-2で定義されるマルチパート境界区切り子に対して特定の意味をもつ文字を除外してあ
る。
表1−Base64アルファベット
値 符号 値 符号 値 符号 値 符号
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
符号化された出力ストリームは,それぞれ76文字を超えない行で表現されなければならない。すべての
行区切り又は表1にない他の文字は,復号ソフトウェアによって,無視されなければならない。base64デ
ータの中の,表1以外の文字,行区切り及びその他の空白は,おそらく,ある状況では警告メッセージ又
はメッセージ拒否が適切かもしれない,転送誤りを示す。
符号化されるデータの末尾において,24 bitに満たない場合には,特別な処理が実行される。本体の末
尾では常に欠けることのない符号化の分量で完結する。入力群の中で,24よりも少ない入力ビットが存在
する場合,値0のビットが右に追加され,6 bit群を単位とする整数倍の数へと整形される。データの末尾
へのパディングは“=”文字を使って実行される。すべてのbase64入力はオクテットの整数倍の数なので,
次の場合だけが発生する。
a) 符号化入力の最後の分量が,24 bitの整数倍になっている。この場合,符号化出力の最後の単位(か
たまり)は,“=”パディングなしで4文字の整数倍となる。
b) 符号化入力の最後の分量が,ちょうど8 bitになっている。この場合,符号化出力の最後の単位(かた
まり)は,二つの文字に,二つの“=”パディング文字が後続したものとなる。
――――― [JIS X 5810-1 pdf 20] ―――――
次のページ PDF 21
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部:適合基準