RFC 5147

RFC 5147

[1] 媒体型 text/plain素片識別子RFC 5147 で規定されています。

[2] RFC 5147提案標準 RFC となるまでには長い年月を要しました。 古い案は RFC となるものとは異なった、 XPointer 風の構文を提案していたこともありました。

[3] また、 RFC 化される前に独自の構文で実装していたものもありました。

[34] 現在まで RFC 5147 はほとんど実装されておらず、 URL で使われることも滅多にないようです。

RFC 5147 に基づく定義

[31] RFC 5147 は、 RFC 2046更新 >>5 で、 素片識別子を規定するものです。

以下で紹介する ABNF 構文は RFC 5147 3. からの引用です。

[6] 素片識別子構文概要: text/plain素片識別子は、 name=value;name=value のようないわゆる param 形式の構文を採用しています。ただし、 charset の指定はそれに沿っていないなど、 変則的なところもあります。

name の部分は「scheme」と呼ばれています。1つ目の name は必ず charline です (text-scheme)。これらが実際に MIME実体中の部分を現します。 2つ目以降の namemd5length で、 識別する MIME実体に関する整合性の判断のための情報を含めるために使います。

Scheme の名前は大文字小文字を区別します RFC 5147 3.

   text-fragment   =  text-scheme 0*( ";" integrity-check )
   text-scheme     =  ( char-scheme / line-scheme )

[22] 素片識別子が構文的に正しくない場合、その素片識別子は無視しなければなりません。 誤り訂正を試みてはなりません。正しくない旨を利用者に通知しても構いませんRFC 5147 4.4.

char, line

[7] char scheme: char scheme は、文字数を使って素片 (位置または範囲) を識別します RFC 5147 2.2.1., 2.2.2.

   char-scheme     =  "char=" ( position / range )

[8] line scheme: line scheme は、行数を使って素片 (位置または範囲) を識別します RFC 5147 2.2.3., 2.2.4.line scheme によって識別される「」には、 行末 (line ending) も含まれており、応用は識別の際に行末も含めなければなりません RFC 5147 2.1.2.

   line-scheme     =  "line=" ( position / range )

[9] 位置と範囲: 文字を数える場合もを数える場合も、位置範囲を指定することができます。 位置は長さ 0、範囲は長さ 0 以上 (狭義には 0 より大きい) です。 範囲は始まりと終わりの位置によって指定します。 RFC 5147 2.1.1.

   position        =  number
   range           =  ( position "," [ position ] ) / ( "," position )
   number          =  1*( DIGIT )

[10] 一番初めの場所が位置 0 になり、その1つ先 (1文字後、または1後) が 1 になります。 RFC 5147 2.1.1., 2.2.1., 2.2.3., 2.2.4.

[11] 範囲の始めや終わりが省略された場合には、当該 MIME実体全体の最初や最後が指定されたものと扱わなければなりませんRFC 5147 2.1.1., 4.2.

[14] 範囲の終わりは始め以上の値でなければなりません。 (始めと終わりが同じ範囲位置と同じになります。) RFC 5147 2.1.1. 逆転している場合、素片識別子を無視しなければなりません RFC 5147 4.2..

[12] 位置が当該 MIME実体の末尾を超えた部分を指す場合、一番最後の位置を指すものと扱わなければなりませんRFC 5147 2.1.1., 4.2.

[13] 文字符号化との関係: 実装は文字数行数の算出時に当該 MIME実体文字符号化を考慮しなければなりません RFC 5147 2.。つまり、「文字」や「」という概念は文字の列に対して定義されるもので、 バイト列に対してではありません。 BOM も数に入りません RFC 5147 2.1.2.

[19] 行末: 行末は、それが CRLFLF などどう表現されていようとも、1文字として処理しなければなりません。 実装はその場面で適当な行末の表現に対応しなければならずCRLF に対応するべきであり、 その場面で関係しない行末の表現に対応しても構いませんRFC 5147 4.1.

整合性

[14] 整合性検査: 文字数行数は編集によって変化することがありますから、 元々の実体かどうかを判断するための整合性の情報を付与する仕組みが用意されています。 ただし実装は無視しても構いません RFC 5147 4.3.

[21] 検査の結果一致しないことがわかった場合、素片識別子は無視するべきで、 その旨を利用者に通知しても構いません RFC 5147 4.3.

[20] 整合性情報は、内容符号化内容転送符号化を元に戻した後に適用されます RFC 5147 2.3., 3.1.

[18] 整合性の情報の記述の方法として、 RFC 5147 では lengthmd5 が定義されています。 将来の拡張のため、それ以外の名前は無視しなければならないとされています。 また、複数の情報が与えられている場合、そのいずれを用いて検査してもよいとされています。 RFC 5147 3.1. なお、 scheme の名前では大文字小文字を区別します RFC 5147 3.。 同じ種類の情報が複数与えられた場合について明記はされていませんが、 同様にどれを用いてもよいということでしょうか。

   integrity-check =  ( length-scheme / md5-scheme )
                        [ "," mime-charset ]

[15] 整合性情報には当該 MIME実体charset も指定することができます RFC 5147 3.1.整合性情報に charset が指定されている場合、クライアントはその charsetMIME実体のものと一致するか検査しなければなりません。 一致しなかった場合には整合性情報を使ってはなりませんが、 文字符号化の変換を行った後に使うのは構いません。ただし、 完全に元のバイト列に復元できるとは限らないので、 あまり信頼できるものではありません。 RFC 5147 2.3.

[16] length scheme: length scheme は、適用対象の MIME実体文字 (符号位置) のを指定します RFC 5147 3.1.

   length-scheme   =  "length=" number

[17] md5 scheme: md5 scheme は、適用対象の MIME実体MD5 指紋を指定します。 charset が指定されている場合、それが MD5 算法を実行した際に用いた charset になります。 値は Base16 ですが、大文字でも小文字でも構いません。 RFC 5147 3.1.

   md5-scheme      =  "md5=" md5-value
   md5-value       =  32HEXDIG

レンダリング

[23] 位置のレンダリング: アプリケーション位置を示す際に強調 (highlighting) 以外の方法を使うべきです RFC 5147 2.1.1.。 (長さ 0 の文字列を強調しても見えないため。) 実装例としては「カーソルの位置設定を行うこと」 が挙げられています。

[24] 範囲のレンダリング: 強調 (highlighting) のような概念を持つ応用は、 長さが零以上の素片を示すためにそのような概念を使うべきですRFC 5147 2.1.1.

実装

[33] あまり実装されているという話は聞きません。

[32] Annoplus が実装しているといいます。

[25]

   http://example.com/text.txt#char=100

100番目の文字の直後の位置を表します。実体が100文字に満たない場合、 最後の文字の直後の位置を表します。

出典: RFC 5147 5.

[26]

   http://example.com/text.txt#line=10,20

11行目から20行目までを表します。実体が11行に満たない場合、 最後のの直後の位置を表します。実体が11行以上で20行に満たない場合、 11行目から最後までを表します。

出典: RFC 5147 5.

[27]

   https://example.com/text.txt#line=,1

最初の行を表します。

出典: RFC 5147 5.

[28]

   ftp://example.com/text.txt#line=10,20;length=9876,UTF-8

実体UTF-8符号化されている状態で9876文字の場合 (や実装が整合性を検査しない場合) に、11行目から20行目までを表します。

出典: RFC 5147 5.

メモ

[29] テキスト・ファイル素片の識別には一般に「○行○列 (文字)」といった表記方法がよく用いられていますが、 RFC 5147 の方法はこれとは異なっています。文字の間である位置をベースにしているので、 「2行目」が「#line=1,2」になるなど、自然な表記とずれが生じています。 なんでこんなのにしちゃったんでしょうか。

w3m の実装

[4] w3m は素片識別子を行数 (最初が 1 行目) とみなすようです。

[30] ( ( 版)) <http://dret.net/netdret/docs/wilde-ht2005-textfrag.pdf>