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] 行末: 行末は、それが CRLF、LF などどう表現されていようとも、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 では length と md5 が定義されています。 将来の拡張のため、それ以外の名前は無視しなければならないとされています。 また、複数の情報が与えられている場合、そのいずれを用いて検査してもよいとされています。 RFC 5147 3.1. なお、 scheme の名前では大文字・小文字を区別します RFC 5147 3.。 同じ種類の情報が複数与えられた場合について明記はされていませんが、 同様にどれを用いてもよいということでしょうか。

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

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

[26]

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

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

[27]

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

最初の行を表します。

[28]

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

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

メモ

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