[12] 本項の Internet Draft は古いものです。最新の情報は
text/plain の項を参照してください。
URI Fragment Identifiers for the text/plain Media Type <draft-wilde-text-fragment-02>
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2003.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This memo defines URI fragment identifiers for text/plain resources. These fragment identifiers make it possible to refer to parts of a text resource, identified by character count or range, line count or range, or a regular expression. These identification methods can be combined to identify more than one sub-resource of a text/plain resource.
このメモは text/plain 資源用 URI 素片識別子を定義します。
この素片識別子は、文資源の一部分を、
文字数や範囲、行数や範囲、あるいは正規表現で識別することを可能にします。
この識別方法は、組合せて text/plain 資源の複数の部文資源を識別できます。
1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 What is text/plain? . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Line Endings in text/plain Resources . . . . . . . . . . . . 4
2.2 What is a URI Fragment Identifier? . . . . . . . . . . . . . 4
2.3 Why text/plain Fragment Identifiers? . . . . . . . . . . . . 5
2.4 Incremental Deployment . . . . . . . . . . . . . . . . . . . 5
3. Fragment Identification Methods . . . . . . . . . . . . . . 6
3.1 Fragment Identification Schemes . . . . . . . . . . . . . . 6
3.1.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Combining the Principles . . . . . . . . . . . . . . . . . . 8
3.1.3 Regular Expressions . . . . . . . . . . . . . . . . . . . . 9
3.1.4 Combining Fragment Identification Scheme Parts . . . . . . . 9
4. Fragment Identification Syntax . . . . . . . . . . . . . . . 9
4.1 Handling of position Values . . . . . . . . . . . . . . . . 10
4.2 Non-ASCII Characters in Regular Expressions . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 12
7.2 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . 13
Non-Normative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
A. POSIX BRE Syntax . . . . . . . . . . . . . . . . . . . . . . 14
B. Where to send Comments . . . . . . . . . . . . . . . . . . . 14
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 15This section will not be part of the final RFC text, it serves as a place to collect open issues regarding this memo.
この章は最終的な RFC の文章の一部とはしません。 このメモに関する公開問題を集めておきます。
- o Provide more complex example(s).
- o Provide short BRE syntax and description in Appendix A (by inclusion or by reference).
- o Should regex ranges be allowed (ie, a fragment ranging from one regex match to another regex match)?
- o Should a more sophisticated regex mechanism than BREs be used?
- o Regexes by themselves may identify disjoint sub-resources. Should there be a mechanism to say something like "the 5th appearance of the following regex"? Or are users responsible for composing regexes which do not need this kind of additional mechanism?
次の正規表現の5番目の出現のように言う仕組みを用意するべきか。 それとも利用者がこのような追加の仕組みが要らないように正規表現を構成する責任を持つべきか。
- o Is the concatenation of scheme parts (Section 3.1.4) and its semantics of joining the individual fragments a good thing? Or a bad thing?
- o Should there be more schemes? Or less?
- o Is it necessary to mention that applications must be able to transcode characters, because the text file and the fragment identifier may use different character encodings? What about character normalization? Should that be addressed or at least mentioned as being out of scope?
Compliant software MUST follow this specification. The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
適合ソフトウェアは、この仕様書に従わなければなりません。
この文書の大文字鍵語 しなければなりません
, してはなりません
,
する必要があります
, するべきです
,
するべきではありません
, 推奨します
,
して構いません
, 任意選択で
は
RFC 2119 で記述されているように解釈します。
訳注: このメモでは、実体
という言葉が使われていますが、
MIME などで使われる意味とは異なるようで、非専門用語として使っているようです。
このメモの範囲では、 text/plain 資源を構成する最小単位である
文字
を指しているようです。
Internet Media Types as defined in RFC 2045 [2] and RFC 2046 [3] are used to identify different types and sub-types of media. RFC 2046 [3] and RFC 2646 [4] specify the text/plain media type, which is used for simple, unformatted text. Quoting from RFC 2046 [3]: "Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks."
RFC 2045 と RFC 2046 で定義されたインターネット媒体型は、
色々な型と亜型を識別するために使われます。 RFC 2046 と RFC 2646
は、単純で書式付けされていない文章に使用する text/plain
媒体型を規定しています。 RFC 2046 から引用すると、
平文は書式付け命令、フォント属性指定、処理指令、解釈指令や内容マークを提供しませんし、認めもしません。平文は単純に、場合によっては改行や改頁で中断され得る、文字の線形の列です
。
The text/plain media type does not restrict the character encoding, any character encoding may be used. In the absence of an explicit character encoding declaration, US-ASCII is assumed as the default character encoding. This variability of the character encoding makes it impossible to count characters in a text/plain resource without taking the character encoding into account, because there are many character encodings using more than one octet per character.
text/plain 媒体型は文字符号化を制限しておらず、
どんな文字符号化でも使うことができます。陽文字符号化宣言が明示されていなければ、
既定文字符号化として US-ASCII が仮定されます。
文字符号化が一定しないので、
多くの文字符号化が1文字に複数のオクテットを使っていますから、
文字符号化を考慮せずに text/plain 資源の文字を数えるのは不可能です。
The biggest advantage of text/plain resources is their portability among different platforms. As long as they use popular character encodings (such as US-ASCII), they can be displayed and processed on virtually every computer system.
text/plain 資源の最大の長所は、
異なる環境への可搬性です。よく使われる文字符号化 (例えば US-ASCII)
を使う限り、 text/plain
は実質的にどの計算機システムでも表示・処理できます。
RFC 2046 [3] and RFC 2646 [4] specify that line endings in text/plain resources are represented by CR+LF character sequences. In implementation practice, however, text/plain resources use different conventions, for example depending on the operating system they have been created with (in most cases, Unix uses LF, MacOS uses CR, and Windows uses CR+LF). Because of this diversity of conventions, implementations interpreting text/plain fragment identifiers MUST take different line ending conventions into account.
RFC 2046 と RFC 2646 は、 text/plain 資源の行末は
CR+LF 文字列で表現すると規定しています。
しかし、実際の実装では、 text/plain 資源は異なる方法を使っていて、
作成されたオペレーティング・システムなどに依存しています
(ほとんどの場合、 Unix は LF を使用し、 Mac OS
は CR を使用し、 Windows は CR+LF
を使用します)。このように行末表現が色々なので、
text/plain 素片識別子を解釈する実装は、
異なる行末表現を考慮しなければなりません。
Line endings in text/plain resources MAY be represented by other character (sequences) than CR+LF, specifically CR, LF, NEL, and CR+NEL. All these character (sequences) MUST be interpreted as line endings. This interpretation MUST affect the evaluation of text/plain fragment identifiers. All representations of line endings (CR+LF, CR, LF, NEL, and CR+NEL) MUST be treated as a single character in character counts. For the purpose of regular expression matching, all representations of line endings must be treated as single LF characters. The reason for this is that fragment identifiers should not be broken by converting a file from one line ending convention to another.
text/plain 資源の行末は CR+LF
以外文字(列)、特に CR, LF,
NEL, CR+NEL
で表現しても構いません。
これらの文字(列)すべてを行末と解釈しなければなりません。
この解釈は text/plain 素片識別子の評価に影響しなければなりません。
すべての行末の表現 (CR+LF, CR,
LF, NEL, CR+NEL)
は文字計数時に1つの文字として扱わなければなりません。
正規表現一致においては、すべての行末の表現は1つの LF
文字として扱わなければなりません。この理由は、
素片識別子はファイルの行末表現を他のものに変換した時に壊れるべきではないからです。
In general, the line ending conventions used in text/plain resources depends on the character encoding of the resource. Implementations SHOULD attempt to be as accurate as possible in recognizing line ending specific to particular character encodings, and MUST treat all these line endings as one character in character counts, and single LF characters for regular expression matching.
一般に、 text/plain 資源で使われる行末表現は資源の文字符号化に依存します。
実装者は、特定文字符号化に特有の行末を可能な限り正確に認識しようと試みるべきであり、
すべての行末を文字数計数時に1つの文字として扱い、
正規表現一致では1つの LF 文字として扱わなければなりません。
URIs are the identification mechanism for resources on the Web. The URI syntax specified in RFC 2396 [5] includes as part of a URI reference a fragment identifier, which (quoting from RFC 2396 [5]) "consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result."
URI はウェブの資源を識別する仕組みです。 RFC 2396 で規定されている
URI 構文は、 URI 参照の一部として素片識別子を含んでいます。素片識別子は、
(RFC 2396 から引用すると、) ]取出し動作が成功裏に完了した後に利用者エージェントが解釈する追加の参照情報から成ります。ですから、これは URI の一部ではありませんが、しばしば URI と組合せて使います。素片識別子の意味は取出し動作の結果のデータの特性であり、参照で使われる URI の型には関わりません。従って、素片識別子の書式と解釈は取出し結果の媒体型に依存します。
The most popular fragment identifier is defined for text/html (defined in RFC 2854 [8]), and makes it possible to refer to a specific element (identified by a 'name' or 'id' attribute) of an HTML document.
もっとも良く使われる素片識別子は text/html 用に
(RFC 2854 で) 定義されたもので、 HTML 文書の (name
属性や id 属性で識別される) 特定の要素を参照できます。
Referring to specific parts of a resource can be very useful, because it enables users to create more specific references. Rather than pointing to a whole resource, users can create references to the part they really are interested in or want to talk about. Even though it is suggested that fragment identification methods are specified in a media type's MIME registration, many media types do not have fragment identification methods associated with them.
資源の特定の部分を参照することは、 利用者がより特定的な参照を作成できますから、とても有用であります。 利用者は、資源全体ではなく、実際に関心があったり話題に上げたりしたい部分を参照することができます。 素片識別子方式を MIME 媒体型登録で規定することが提案されているものの、 多くの媒体型は関連付けられた素片識別子方式を持っていません。
Fragment identifiers are only useful if supported by the client, because they are only interpreted by the client. Therefore, a new fragment identification method will require some time to be adopted by clients, and older clients will not support it. However, because the URI reference still works even if the fragment identifier is not supported (the resource is retrieved, but the fragment identifier is not interpreted), rapid adoption is not highly critical to ensure the success of a new fragment identification method.
素片識別子は、クライアントだけが解釈するものですから、 クライアントが対応しているときだけ有用です。従って、 新しい素片識別子識別方式はいつかの時点でクライアントが採用することが必要で、 古いクライアントはこれに対応していません。 しかし、 URI 参照はたとえ素片識別子に対応していなくても機能します (資源は取出されますが、素片識別子は解釈されません) から、 即座に採用することは新しい素片識別子方式の成功を約束するために然程重要ではありません。
Fragment identifiers for text/plain make it possible to refer to specific parts of a text resource, using concepts of positions and ranges, which may be applied to characters and lines. The also support locating a fragment by using a regular expression for searching for a specific character sequence. Thus, text/plain fragment identifiers enable users to exchange information more specifically, thereby reducing time and effort that is necessary to manually search for the relevant part of a text/plain resource.
text/plain の素片識別子は、
文資源の特定の部分を、文字や行に適用できる位置や範囲の概念を使って参照することを可能とします。
この素片識別子は特定の文字列を検索する正規表現を使った素片の位置付けにも対応しています。
ですから、 text/plain 素片識別子は利用者がより特定的な情報を交換することを可能とし、
text/plain 資源の適当な部分を手動で探すのに必要な時間と労力を削減します。
As long as support for text/plain fragment identifiers is not implemented by all programs, it is important to consider the implications of incremental deployment. Clients (for example, Web browsers) not supporting the text/plain fragment identifier described in this memo will work with URI references to text/plain resources, but they will fail to locate the sub-resource identified by the fragment identifier. This is a reasonable fallback behavior, and in general users should take into account the possibility that a program interpreting a given URI reference will fail to interpret the fragment identifier part. Since fragment identifier evaluation is local to the client (and happens after retrieving the resource), there is no way for a server to determine whether a requesting client is using a URI reference containing a fragment identifier.
text/plain 素片識別子がすべてのプログラムで実装されていない限り、
徐々に配備されていくことの絡み合いを考慮することが重要です。
このメモで説明する text/plain 素片識別子に対応していないクライアント
(例えばウェブ・ブラウザ) は、 text/plain 資源への URI
参照は機能するでしょうが、素片識別子で識別される部分資源の位置づけには失敗するでしょう。
これは適度な fallback 動作であり、通常利用者は URI
参照を解釈するプログラムが素片識別子部分の解釈に失敗する可能性を考慮するべきです。
素片識別子はクライアント局所で評価されます (し資源の取出しの後起こります)
から、要求しているクライアントが素片識別子を含んだ URI
参照を使っているかどうかを鯖が決定する方法はありません。
The identification of resource fragments of text/plain resources can be based on different foundations. Since it is not possible to insert explicit, invisible identifiers into a text/plain resource (as for example used in HTML documents, implemented through special attributes), fragment identification has to rely on certain inherent criteria of the resource. This memo specifies fragment identification using five different methods, character positions and ranges, line positions and ranges, and regular expression matching.
text/plain 資源の資源素片の識別は、
色々な土台の上で行うことができます。明示的で不可視な識別子を
text/plain 資源に挿入すること
(例えば HTML bunsho で使われているように、特別な属性を通して実装すること)
は不可能ですから、素片識別は資源の内在的基準に依存せざるを得ません。
このメモは、5つの異なる方式 — 文字位置、文字範囲、
行位置、行範囲、正規表現一致を使った素片識別を規定します。
When interpreting character or line numbers, implementations MUST take the character encoding of the resource into account, because character count and octet count may differ for the character encoding being used. For example, a resource using UTF-16 encoding (as specified in RFC 2718 [9]) uses two octets per character, and it may have a leading BOM (Byte-Order Mark), which does not count as a character and thus also affects the mapping from a simple octet count to a character count.
資源の文字符号化によっては文字数とオクテット数が異なるかもしれませんから、
文字数や行数を解釈する時、実装は、資源の文字符号化を考慮しなければなりません。
例えば、 UTF-16 符号化 (RFC 2718 で規定されています。) を使った資源は、
1文字あたり2オクテットを使いますし、先頭に
BOM (バイト順マーク) を持つかもしれません。
BOM は文字として数えませんから、
単純なオクテット数から文字数への写像にも影響します。
Fragment identification can be done using regular expressions or combining two orthogonal principles, which are positions and ranges, and characters and lines. The following section describe the principles themselves, while Section 3.1.2 describes the combination of the principles.
素片識別は正規表現や2つの直行する方法、位置と範囲ならびに文字と行を使って行うことができます。 次の節では方法を説明し、3.1.2節では方法の組合せを説明します。
A position does not identify an actual fragment of the resource, but a position inside the resource, which could be regarded as a fragment of zero length. The usa case for positions is to provide pointers for applications which may use them to implement functionalities such as "insert some text here", which needs a position rather than a fragment. Positions are counted from zero (position zero being before the first character or line of a text/plain resource), so that a text/plain resource having one character has two positions, one before the first character (position 0), and one after the first character (position 1).
位置は実際の資源の素片ではなく、資源の中の位置を識別します。
これは長さ零の素片とみなすことができます。
位置を使う場合の例としては、
文章をここに挿入
のような機能を実装するために使う指示子の提供で、
この場合素片ではなく位置が必要です。位置は零から数えます
(位置零は text/plain 資源の最初の文字・行の前です)
から、1つの文字を持つ text/plain 資源は2つの位置を持ちます
(1つは最初の文字の前 (位置 0) で、もう1つは最初の文字の後
(位置 1) です)。
Since positions are fragments of length zero, applications SHOULD use other methods than highlighting to indicate positions, the most reasonable way being the positions of a cursor (if the application supports the concept of a cursor).
位置は長さ零の素片ですから、応用は位置を示すために強調以外の方法を使うべきです。 最も合理的な方法は cursor 位置とすることでしょう (応用が cursor の概念を持っていればの話です)。
Ranges, on the other hand, identify fragments of a resource that have a length that may be greater than zero. As a general principle for ranges, they specify both a lower and a upper bound. The start or the end of a range specification may be omitted, defaulting to the first repectively last position of the resource. The ending position of a range must have a value greater than or equal to the lower position (consequently, a range with identical lower and upper positions is legal, and identifies a range of length 0, which is equivalent to a position). Counting for ranges uses positions, so that a fragment containing one entity is specified by using a range with two adjacent positions.
他方、範囲は、零以上の長さを持つ資源の素片を識別します。 範囲の一般原則として、下限と上限の両方を指定します。 範囲の開始や終了の指定は省略でき、それぞれ資源の最初と最後を既定値とします。 範囲の終了位置は開始位置以上の値でなければなりません (ですから、最小位置と最大位置が同じである範囲も合法であり、 長さ零の範囲を識別しまして、これは位置と等価です)。 範囲の計数には位置を用いますから、一つの実体を含む素片は2つの隣接位置の範囲を使って指定します。
Since ranges are fragments with a length greater than zero, applications SHOULD use methods like highlighting to indicate ranges (if the application supports the concept of highlighting).
範囲は長さ零以上の素片ですから、応用は範囲を示すための強調のような方式を使うべきです (応用が強調の概念を持っていればの話です)。
For positions and ranges it is implicitly assumed that if a number is greater than the actual number of entities in the resource, then it is referring to the last entity of the resource.
位置と範囲では、数が資源中の実体の実際の数より大きければ、 資源の最後の実体を参照することを暗に仮定しています。
The concept of positions and ranges may be applied to characters and lines. In both cases, positions indicate points between entities, while ranges identify zero or more entities by indicating positions.
位置と範囲の概念は文字と行に適用できます。 どちらの場合でも、位置は実体間の場所を示し、 範囲は位置を示すことによって零個以上の実体を識別します。
Character positions are numbered starting with zero (ignoring initial BOM marks or similar concepts that are not part of the actual textual content of a text/plain resource), and counting each character separately, with the exception of line endings, which are always counted as one character (Section 2.1.1 describes how line endings MUST be identified).
文字位置は零から数え始め (最初の BOM
や同様の概念は実際の text/plain 資源の一部ではありません)、
各文字を別個に数えます。ただし行末は、常に1文字として数えます
(2.1.1 節で行末をどう識別しなければならないかを説明しています)。
Line positions are numbered starting with zero (with line position zero always being identical with character position zero), with Section 2.1.1 describing how line endings must be identified. Fragments identified by lines include the line endings, so applications identifying line-based fragments MUST include the line endings in the fragment identification they are using (eg, the highlighted selection). If a resource does not contain any line endings, then it consists of a single (the first) line.
行位置は零から数え始めます (行位置零は常に文字位置零と同一です)。 行末をどう識別しなければならないかは2.1.1 節で説明しています。 行によりしい別される素片は行末を含みますから、 行を基にした素片を識別する応用は、使用する素片識別方法 (例えば強調選択) で行末を含めなければなりません。 資源が行末を含まない時は、その資源は1つの (最初の) 行だけから成ります。
In the following sections, the principles described in the preceding section are combined, resulting in four use cases.
以降の節では、以前の節で説明した原則を組合せて、4つの場合について説明します。
Using the char scheme followed by a single number, it is possible to point to a character position (ie, a fragment of length zero between two characters). Rather than identifying a fragment consisting of a number of characters, this method identifies a position between two characters (or before the first or after the last character). Character position counting starts with 0, so the character position before the first character of a text/plain resource has the character position 0, and a resource containing n distinct characters has n+1 distinct character positions.
char scheme と1つの数字を使って、
文字位置 (長さ零の、2つの文字の間の素片) を指すことができます。
この方式は、幾つかの文字を含む素片を識別するのではなく、
2つの文字の間の位置 (または最初の文字の前か最後の文字の後)
を識別します。文字位置計数は零からはじめますから、
text/plain 資源の最初の文字の前の文字位置は文字位置
0 となり、 n 個の文字を含む資源は
n + 1 個の文字位置を持ちます。
If it is necessary to identify a fragment of zero or more characters using character counting, this can be done by using a character range, using the char scheme followed by a range specification. A character range is a consecutive region of the resource that extends from the starting character position of the range to the ending character position of the range.
文字計数を使って零個以上の素片を識別することが必要であれば、
char scheme と範囲指定により、
文字範囲を使って行うことができます。文字範囲は資源の連続的領域であり、
範囲の開始文字位置から範囲の終了文字位置までです。
Using the line scheme followed by a single number, it is possible to point to a character position (ie, a fragment of length zero between two lines). Rather than identifying a fragment consisting of a number of lines, this method identifies a position between two lines (or before the first or after the last line). Line position counting starts with 0, so the line position before the first line of a text/plain resource has the line position 0, and a resource containing n distinct lines has n+1 distinct line positions.
line scheme と1つの数字を使って、
文字位置 (2つの行の間の長さ零の素片) を指すことができます。
この方式は、幾つかの行を含む素片を識別するのではなく、
2つの行の間の位置 (または最初の行の前か、
最後の行の後) を識別します。行位置計数は 0
から始めますから、 text/plain 資源の最初の行の前の行位置は行位置
0 を持ち、 n 個の行を持つ資源は
n + 1 個の行位置を持ちます。
If it is necessary to identify a fragment of zero or more lines using line counting, this can be done by using a line range, using the line scheme followed by a range specification. A line range is a consecutive region of the resource that extends from the starting line position of the range to the ending line position of the range.
行計数を使って零個以上の行の素片を識別する必要があれば、
line scheme と範囲指定により、
行範囲を使って行うことができます。行範囲は資源の連続敵領域であり、
範囲の開始行位置から範囲の終了行位置までです。
A common problem with fragment identifiers is their robustness (to changes in the resource), and character and line counts can be broken very easily. A more robust way of identifying a fragment is by searching for a specific pattern. Thus, it is possible to use a Basic Regular Expression (BRE) as defined by ISO 9945-2 [6] (the POSIX standard) as a fragment identifier (Appendix A contains a short summary of the POSIX BRE syntax).
素片識別の共通の問題は (資源の変更に対する) 頑強性であり、 文字数や行数は非常に壊れやすいです。素片を識別するより頑強な方法は、 特定のパターンによる検索によることです。従って、素片識別子として ISO 9945‐2 (POSIX 規格) で定義された基本正規表現 (BRE) を使うことが可能です (附属書 A に POSIX BRE 構文の短い要約があります)。
While in most cases only one fragment identification scheme part will be used, it is possible to combine them. By simply concatenating different fragment identification scheme parts, separated by a semicolon, the whole fragment identifier refers to the union of all fragments of the text resource identified by the individual fragment identification scheme parts. This way, it is possible to identify disjoint ranges, such as multiple line ranges.
ほとんどの場合、1つの素片識別 scheme 部分が使われるでしょうが、 scheme 部分を組合せることが可能です。単純に異なる素片識別 scheme 部分をセミコロンで分離して連結すれば、全体の素片識別子は個々の素片識別 scheme 部分が識別する文資源の素片すべての和集合を参照します。 この方法で、つながっていない範囲、例えば複数の行範囲を識別することが可能です。
It should be noticed that regular expressions by themselves may identify disjoint fragments, which is true in any case where the regular expression matches more than one occurrence in the resource.
正規表現自体がつながっていない素片を識別するかもしれないことに注意してください。 これは、資源が複数箇所で正規表現に一致する場合に真となります。
Since disjoint fragments can be identified, implementations SHOULD make sure that these fragments are appropriately marked, for example by highlighting the fragment (rather than only scrolling to some line, which only identifies a single location in the resource). If an implementation can not mark disjoint fragments, it MAY resort to marking only the first of the disjoint fragments. However, the exact method of how implementations deal with disjoint fragments depends on the application and interface, and is beyond the scope of this memo.
つながっていない素片を識別できるのですから、実装は、 そのような素片を適切に印付け、たとえば強調できるようにするべきです (どこかの行に scroll するだけでは、資源の1つの場所しか識別できません)。 実装がつながっていない素片に印付けできないのであれば、 つながっていない素片の最初だけを印付けすることとしても構いません。 しかし、実装がつながっていない素片をどう処理するかの正確な方法は応用と界面に依存し、 このメモの適用適用範囲外であるとします。
The syntax for the fragment identifiers is straightforward. The syntax defines three schemes, 'char', 'line', and 'match'. The 'char' and 'line' can be used in two different variants, either the position variant (with a single number), or the range variant (with two comma-separated positions). The 'match' scheme has a regular expression as parameter, which must be specified as a string with escaped semicolons (because the semicolon is used to concatenate multiple fragment identification schem parts).
素片識別子の構文は簡単です。構文は char, line,
match の3つの scheme を定義します。 char scheme
と line scheme は、位置 (1つの数) と範囲
(読点で分離した2つの位置) の2種類の書式を使うことができます。
match scheme は引数として正規表現を持ちますが、
セミコロンを逃避した文字列として指定しなければなりません
(セミコロンは複数の素片識別 scheme 部分の連結に使います)。
The following syntax definition uses ABNF as defined in RFC 2234 [7].
次の構文定義は RFC 2234 の ABNF を使います。
text-fragment = text-scheme 0*( ";" text-scheme)
text-scheme = ( char-scheme / line-scheme / match-scheme )
char-scheme = "char=" ( position / range )
line-scheme = "line=" ( position / range )
match-scheme = "match=" regex
position = number
range = (position "," [ position ]) / ("," position )
number = 1*DIGIT
regex = StringWithEscapedSemicolonThe StringWithEscapedSemicolon is a string where all characters may appear literally (except the characters which are required by the URI syntax to be escaped), with the exception of a semicolon. A semicolon that should be part of the regular expression must be escaped with a leading backslash, and implementations MUST make sure to properly interpret regular expressions, properly dereferencing all escape mechanisms that apply (ie, URI encoding, semicolon escaping, and BRE escaping, as well as any additional escaping that may be present due to the context of the URI reference).
StringWithEscapedSemicolon は、
セミコロン以外のすべての文字
(URI 構文で逃避する必要のある文字を除きます。)
が生で出現できる文字列です。正規表現の一部となるべきセミコロンは、
直前に逆斜線を加えて逃避しなければなりません。また、
実装は、正規表現を適切に解釈できるように、
適用されているすべての逃避機構 (URI 符号化、セミコロン逃避、
BRE 逃避、 URI 参照の文脈によって存在し得るすべての追加の逃避機構)
を適切に解決しなければなりません。
訳注: URI 参照の文脈〜
というのは、例えば URI 参照を HTML
で使用するときに & を &
にしなければならないことがあるようなものを指しているのだと思われます。
ところで、セミコロン逃避に逆斜線を使っていますが、 その逆斜線も URI 参照では直接使えない文字なので URI 逃避符号化しなければなりません。 (セミコロンを直接 URI 符号化すれば良いのだろうに。)
If any position value (as a position or inside a range) is greater than the value for the actual resource, then it identifies the last character or line position of the resource. If the first position value in a range is not present, then the range extends from the start of the resource. If the second position value in a range is not present, then the range extends to the end of the resource. If a range scheme's positions are not properly ordered (ie, the first number is less than the second), then this scheme part MUST be ignored.
位置値 (位置として、または範囲の中で。) が実際の資源の値よりも大きいのなら、 資源の最後の文字または行位置を識別します。 範囲の最初の位置値が存在しなければ、範囲は資源の開始から始まります。 範囲の2番目の位置値が存在しなければ、範囲は資源の最後で終わります。 範囲 scheme の位置が適切に指示されていなければ (最初の数が2番目の数以下でなければ)、 その scheme 部分は無視しなければなりません。
RFC 2396 [5] does not define how to use non-ASCII characters in URIs. Consequently, it is not possible to use non-ASCII characters in URIs in a standardized and reliable way. However, work on Internationalized Resource Identifiers (IRI) [10] is in progress, and as soon as this work results in a published RFC, it will be possible to use non-ASCII characters in regular expressions, using the encoding defined by IRI.
RFC 2396 は URI で非 ASCII 文字をどう使うかを定義していません。 ですから、 URI で非 ASCII 文字を標準化された信頼できる方法で使うことは不可能です。 しかし、国際化資源識別子 (IRI) が作業中で、 この作業が RFC として出版されることになれば、 IRI で定義される符号化を使って、正規表現で非 ASCII 文字を使うことができるようになるでしょう。
The following examples show some usages for the fragment identifiers defined in this memo.
以降の例はこのメモで定義した素片識別子の用法を示します。
http://example.com/text.txt#char=100
This URI reference identifies the position after the 100th character of the text.txt resource. It should be noted that it is not clear which octet(s) of the resource this will be without retrieving the resource and thus knowing which character encoding is it using (in case of HTTP, this information will be given in the response's Content-type header). If the resource has fewer than 100 characters, the URI reference identifies the position after the resource's last character.
この URI 参照は text.txt 資源の100番目の文字の後の位置を識別します。
それが資源のどのオクテットになるのかは、
資源を取出して使用している文字符号化 (HTTP の場合、個の情報は応答の
Content-Type 頭で与えられます。)
を知らないとはっきりしないことに注意してください。
資源が100文字未満しかなければ、この URI
参照は資源の最後の文字の後の位置を識別します。
http://example.com/text.txt#line=10,20
This URI reference identifies lines 11 to 20 of the text.txt resource. If the resource has fewer than 11 lines, it identifies the position after last line. If the resource has less than 20 but at least 11 lines, it identifies the lines 11 to the last line of the resource.
この URI 参照は text.txt 資源の11行から20行を識別します。
資源が11行未満しかなければ、最後の行の後の位置を識別します。
資源が11行以上20行未満であれば、11行から資源の最後の行までを識別します。
http://example.com/text.txt#match=searchterm
This URI reference identifies all occurrences of the regular expression 'searchterm' in the resource, ie all occurrences of the string 'searchterm'. If there is more than one occurrence, then this URI reference identifies a disjoint fragment, consisting of all of these occurrences. If there is no occurrence of the search term, the URI reference does not identify a fragment.
この URI 参照は資源内の正規表現 searchterm のすべての出現、すなわち文字列 searchterm のすべての出現を識別します。複数の出現があれば、 この URI 参照は、その出現すべてから成る、つながっていない素片を識別します。 検索語の出現がなければ、この URI 参照は素片を識別しません。
http://example.com/text.txt#line=,1;match=searchterm
This URI reference identifies the first line and all occurrences of the regular expression 'searchterm' in the resource. If there is an occurrence of 'searchterm' outside of the first line, then this URI reference identifies a disjoint fragment.
この URI 参照は最初の行と資源中の正規表現 searchterm のすべての出現を識別します。最初の行以外に searchterm が出現すれば、この URI 参照はつながっていない素片を識別します。
http://example.com/text.txt#match=hello\;
This URI reference identifies all occurrences of the regular expression 'hello;' in the resource. The semicolon with the leading backslash has to be interpreted as a literal semicolon insode of the BRE, treating the '\;' as an escaped ';', so that the actual regular expression is 'hello;'. If there is more than one occurrence of this regular expression, then this URI reference identifies a disjoint fragment, consisting of all of these occurrences.
この URI 参照は資源中の正規表現 hello; のすべての出現を識別します。 逆斜線が前に付いたセミコロンは、 \; を逃避した ; として BRE の生のセミコロンとして解釈しなければなりませんから、 実際の正規表現は hello; となります。 この正規表現の出現が複数あれば、この URI 参照はその出現すべてから成る、つながっていない素片を識別します。
...
(more complex example...)
Regular expression matching code is notoriously vulnerable to buffer overflow security holes, so any implementation supporting text/plain fragment identifiers MUST make sure that the code being used has been tested against buffer overflow attacks.
正規表現一致符号はバッファ溢れ保安孔に脆弱であり、 text/plain
素片識別子に対応する実装は使用する符号がバッファ溢れ攻撃について試験したものであることを確かめなければなりません。
o Fundamental change in semantics: counts turn into positions
(between characters or lines), so in order to identify a character
or line, ranges must be used (which now use positions to specify
the upper and lower bounds of the range). o Made the first value of a range optional as well, so that line=,5
also is legal, identifying everything from the start of the
resource to the 5th line. o Changed the syntax from paranthesis-style to a more traditional
style using equals-signs. o Made the second count value of ranges optional, so that something
like line(10,) is legal and properly defined. o Added non-normative reference to Internet draft about non-ASCII
characters in search strings.o Added Section 2.4 about incremental deployement.
o Added more elaborate examples.
o Added text about regex buffer overflow problems in Section 6.
o Added Section 2.1.1 about line endings in text/plain resources.
o Added Section 1 to collect open issues regarding this memo (will
be deleted in final RFC text). [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996. [4] Gellens, R., "The Text/Plain Format Parameter", RFC 2646, August
1999. [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] International Organization for Standardization, "Information
technology - Portable Operating System Interface (POSIX) - Part
2: Shell and Utilities", ISO 9945-2, 1993. [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. [8] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC
2854, June 2000. [9] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000. [10] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRI)", draft-duerst-iri-03 (work in progress),
March 2003. [11] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.Erik Wilde Swiss Federal Institute of Technology ETH-Zentrum 8092 Zurich Switzerland
Phone: +41-1-6325132 EMail: net.dret@dret.net URI: http://dret.net/netdret/
This section contains a short (and non-normative) summary of the POSIX BRE syntax defined in ISO 9945-2 [6]. The definition of BRE syntax in ISO 9945-2 [6] is the normative reference, and the following summary is for informative purposes only.
(tbd - is there some rfc that could be referenced instead?)
Please send all comments and questions concerning this document to Erik Wilde.
This document has been prepared using the IETF document DTD described in RFC 2629 [11].
Thanks for comments and suggestions provided by Dan Kohn, John Cowan, Benja Fallenstein, and Henrik Levkowetz.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.
[1] この I-D は既に期限が切れています。
原文は http://dret.net/netdret/docs/draft-wilde-text-fragment-02.txt などから入手できます。