[要約] RFC 2482は、Unicodeプレーンテキストでの言語タグ付けに関する規格であり、テキスト内の言語を識別するための方法を提供します。その目的は、異なる言語のテキストを正確に識別し、適切な処理や表示を可能にすることです。
Network Working Group K. Whistler
Request for Comments: 2482 Sybase
Category: Informational G. Adams
Spyglass
January 1999
Language Tagging in Unicode Plain Text
Unicodeプレーンテキストの言語タグ付け
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
IESG Note:
IESG注：
This document has been accepted by ISO/IEC JTC1/SC2/WG2 in meeting #34 to be submitted as a recommendation from WG2 for inclusion in Plane 14 in part 2 of ISO/IEC 10646.
このドキュメントは、ミーティング＃34でISO / IEC JTC1 / SC2 / WG2によって承認され、WG2からの勧告として提出され、ISO / IEC 10646のパート2のプレーン14に含めることができます。
This document proposed a mechanism for language tagging in [UNICODE] plain text. A set of special-use tag characters on Plane 14 of [ISO10646] (accessible through UTF-8, UTF-16, and UCS-4 encoding forms) are proposed for encoding to enable the spelling out of ASCII-based string tags using characters which can be strictly separated from ordinary text content characters in ISO10646 (or UNICODE).
このドキュメントは、[UNICODE]プレーンテキストでの言語タグ付けのメカニズムを提案しました。 [ISO10646]の平面14にある一連の特殊用途タグ文字（UTF-8、UTF-16、およびUCS-4エンコードフォームを介してアクセス可能）は、文字を使用してASCIIベースの文字列タグのスペルアウトを可能にするエンコード用に提案されていますこれは、ISO10646（またはUNICODE）の通常のテキストコンテンツ文字から厳密に分離できます。
One tag identification character and one cancel tag character are also proposed. In particular, a language tag identification character is proposed to identify a language tag string specifically; the language tag itself makes use of [RFC1766] language tag strings spelled out using the Plane 14 tag characters. Provision of a specific, low-overhead mechanism for embedding language tags in plain text is aimed at meeting the need of Internet Protocols such as ACAP, which require a standard mechanism for marking language in UTF-8 strings.
1つのタグ識別文字と1つのキャンセルタグ文字も提案されています。特に、言語タグ識別文字は、言語タグ文字列を具体的に識別するために提案されています。言語タグ自体は、Plane 14タグ文字を使用して綴られた[RFC1766]言語タグ文字列を使用します。プレーンテキストに言語タグを埋め込むための特定の低オーバーヘッドメカニズムの提供は、UTF-8文字列で言語をマークするための標準メカニズムを必要とするACAPなどのインターネットプロトコルのニーズを満たすことを目的としています。
The tagging mechanism as well the characters proposed in this document have been approved by the Unicode Consortium for inclusion in The Unicode Standard. However, implementation of this decision awaits formal acceptance by ISO JTC1/SC2/WG2, the working group responsible for ISO10646. Potential implementers should be aware that until this formal acceptance occurs, any usage of the characters proposed herein is strictly experimental and not sanctioned for standardized character data interchange.
このドキュメントで提案されているタグ付けメカニズムと文字は、Unicodeコンソーシアムによって、Unicode標準に含まれることが承認されています。ただし、この決定の実施は、ISO10646を担当するワーキンググループであるISO JTC1 / SC2 / WG2による正式な承認を待っています。潜在的な実装者は、この正式な承認が行われるまで、ここで提案されている文字の使用は厳密に実験的なものであり、標準化された文字データの交換には認可されていないことに注意してください。
No attempt is made to define all terms used in this document. In particular, the terminology pertaining to the subject of coded character systems is not explicitly specified. See [UNICODE], [ISO10646], and [RFC2130] for additional definitions in this area.
このドキュメントで使用されているすべての用語を定義することはありません。特に、コード化文字システムの主題に関する用語は明示的に指定されていません。この領域の追加の定義については、[UNICODE]、[ISO10646]、および[RFC2130]を参照してください。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119].
このドキュメントでは、大文字で表示される用語を使用することがあります。 「MUST」、「SHOULD」、「MUST NOT」、「SHOULD NOT」、および「MAY」という用語は、大文字で表記されている場合、この仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は[RFC2119]にあります。
The terms defined below are used in special senses and thus warrant some clarification.
以下に定義されている用語は特別な意味で使用されているため、いくつかの説明が必要です。
The association of attributes of text with a point or range of the primary text. (The value of a particular tag is not generally considered to be a part of the "content" of the text. Typical examples of tagging is to mark language or font of a portion of text.)
テキストの属性と一次テキストのポイントまたは範囲との関連付け。 （特定のタグの値は、通常、テキストの「コンテンツ」の一部とは見なされません。タグ付けの典型的な例は、テキストの一部の言語またはフォントをマークすることです。）
The association of secondary textual content with a point or range of the primary text. (The value of a particular annotation *is* considered to be a part of the "content" of the text. Typical examples include glossing, citations, exemplication, Japanese yomi, etc.)
二次テキストコンテンツと一次テキストのポイントまたは範囲との関連付け。 （特定の注釈の値は、テキストの「内容」の一部であると見なされます。典型的な例には、つや出し、引用、省略、日本語の読みなどがあります。）
An out-of-band channel conveys a tag in such a way that the textual content, as encoded, is completely untouched and unmodified. This is typically done by metadata or hyperstructure of some sort.
アウトオブバンドチャネルは、エンコードされたテキストコンテンツがまったく変更されずにそのままの方法でタグを伝達します。これは通常、メタデータまたは何らかの超構造によって行われます。
An in-band channel conveys a tag along with the textual content, using the same basic encoding mechanism as the text itself. This is done by various means, but an obvious example is SGML markup, where the tags are encoded in the same character set as the text and are interspersed with and carried along with the text data.
インバンドチャネルは、テキスト自体と同じ基本的なエンコーディングメカニズムを使用して、テキストコンテンツとともにタグを伝達します。これはさまざまな方法で行われますが、明らかな例はSGMLマークアップです。この場合、タグはテキストと同じ文字セットでエンコードされ、テキストデータと共に散在して運ばれます。
There has been much discussion over the last 8 years of language tagging and of other kinds of tagging of Unicode plain text. It is fair to say that there is more-or-less universal agreement that language tagging of Unicode plain text is required for certain textual processes. For example, language "hinting" of multilingual text is necessary for multilingual spell-checking based on multiple dictionaries to work well. Language tagging provides a minimum level of required information for text-to-speech processes to work correctly. Language tagging is regularly done on web pages, to enable selection of alternate content, for example.
言語のタグ付けやUnicodeプレーンテキストの他の種類のタグ付けについては、過去8年間にわたって多くの議論がありました。 Unicodeプレーンテキストの言語タグ付けが特定のテキストプロセスに必要であるという多かれ少なかれ普遍的な合意があると言っても過言ではありません。たとえば、複数の辞書に基づく多言語のスペルチェックが適切に機能するには、多言語テキストの「ヒント」という言語が必要です。言語タグ付けは、音声合成プロセスが正しく機能するために必要な最低限の情報を提供します。言語タグはWebページで定期的に行われ、たとえば、代替コンテンツを選択できるようにします。
However, there has been a great deal of controversy regarding the appropriate placement of language tags. Some have held that the only appropriate placement of language tags (or other kinds of tags) is out-of-band, making use of attributed text structures or metadata. Others have argued that there are requirements for lower-complexity in-band mechanisms for language tags (or other tags) in plain text.
ただし、言語タグの適切な配置に関しては多くの論争がありました。言語タグ（または他の種類のタグ）の適切な配置は帯域外であり、属性付きテキスト構造またはメタデータを利用しているとの見方もあります。他の人は、プレーンテキストの言語タグ（または他のタグ）の複雑さの低いインバンドメカニズムの要件があると主張しました。
The controversy has been muddied by the existence and widespread use of a number of in-band text markup mechanisms (HTML, text/enriched, etc.) which enable language tagging, but which imply the use of general parsing mechanisms which are deemed too "heavyweight" for protocol developers and a number of other applications. The difficulty of using general in-band text markup for simple protocols derives from the fact that some characters are used both for textual content and for the text markup; this makes it more difficult to write simple, fast algorithms to find only the textual content and ignore the tags, or vice versa. (Think of this as the algorithmic equivalent of the difficulty the human reader has attempting to read just the content of raw HTML source text without a browser interpreting all the markup tags.)
論争は、言語のタグ付けを可能にするが、あまりにも多すぎると見なされる一般的な解析メカニズムの使用を暗示する多数のインバンドテキストマークアップメカニズム（HTML、テキスト/エンリッチなど）の存在と広範な使用によって混乱しています。プロトコル開発者および他の多くのアプリケーションにとって「ヘビー級」。単純なプロトコルで一般的なインバンドテキストマークアップを使用することの難しさは、一部の文字がテキストコンテンツとテキストマークアップの両方に使用されるという事実に由来します。これにより、テキストコンテンツのみを検索してタグを無視する、またはその逆の単純で高速なアルゴリズムを作成することが難しくなります。 （これは、人間の読者がブラウザがすべてのマークアップタグを解釈せずに、未加工のHTMLソーステキストのコンテンツのみを読み取ろうとしたときの難しさと同等のアルゴリズムと考えてください。）
The Plane 14 proposal addresses the recurrent and persistent call for a lighter-weight mechanism for text tagging than typical text markup mechanisms in Unicode. It proposes a special set of characters used *only* for tagging. These tag characters can be embedded into plain text and can be identified and/or ignored with trivial algorithms, since there is no overloading of usage for these tag characters--they can only express tag values and never textual content itself.
Plane 14の提案は、Unicodeの一般的なテキストマークアップメカニズムよりも軽量なテキストタグ付けメカニズムの継続的かつ永続的な要求に対応しています。タグ付けに「のみ」使用される特別な文字セットを提案します。これらのタグ文字は、プレーンテキストに埋め込むことができ、簡単なアルゴリズムで識別および/または無視できます。これは、これらのタグ文字の使用の過負荷がないため、タグ値のみを表現でき、テキストコンテンツ自体は決して表現できないためです。
The Plane 14 proposal is not intended for general annotation of text, such as textual citations, phonetic readings (e.g. Japanese Yomi), etc. In its present form, its use is intended to be restriced solely to specifying in-line language tags. Future extensions may widen this scope of intended usage.
Plane 14の提案は、テキストの引用、音声の読み（たとえば、日本語の読み）など、テキストの一般的な注釈を目的としたものではありません。現在の形式では、その使用は、インライン言語タグの指定のみに制限されています。将来の拡張により、この使用目的の範囲が広がる可能性があります。
This proposal suggests the use of 97 dedicated tag characters encoded at the start of Plane 14 of ISO/IEC 10646 consisting of a clone of the 94 printable 7-bit ASCII graphic characters and ASCII SPACE, as well as a tag identification character and a tag cancel character.
この提案では、ISO / IEC 10646のPlane 14の最初にエンコードされた97個の専用タグ文字の使用を提案しています。これは、94個の印刷可能な7ビットASCIIグラフィック文字とASCIIスペースのクローン、およびタグ識別文字とタグで構成されています。文字をキャンセルします。
These tag characters are to be used to spell out any ASCII-based tagging scheme which needs to be embedded in Unicode plain text. In particular, they can be used to spell out language tags in order to meet the expressed requirements of the ACAP protocol and the likely requirements of other new protocols following the guidelines of the IAB character workshop (RFC 2130).
これらのタグ文字は、Unicodeプレーンテキストに埋め込む必要のあるASCIIベースのタグ付けスキームを説明するために使用されます。特に、それらは、IAB文字ワークショップ（RFC 2130）のガイドラインに従って、ACAPプロトコルの表現された要件と他の新しいプロトコルの可能性のある要件を満たすために、言語タグを詳しく説明するために使用できます。
The suggested range in Plane 14 for the block reserved for tag characters is as follows, expressed in each of the three most generally used encoding schemes for ISO/IEC 10646:
タグ文字用に予約されたブロックのPlane 14での推奨範囲は次のとおりであり、ISO / IEC 10646で最も一般的に使用される3つのエンコーディングスキームのそれぞれで表されます。
UCS-4
UCS-4
U-000E0000 .. U-000E007F
U-000E0000 .. U-000E007F
UTF-16
UTF-16
U+DB40 U+DC00 .. U+DB40 U+DC7F
UTF-8
UTF-8
0xF3 0xA0 0x80 0x80 .. 0xF3 0xA0 0x81 0xBF
0xF3 0xA0 0x80 0x80 .. 0xF3 0xA0 0x81 0xBF
Of this range, U-000E0020 .. U-000E007E is the suggested range for the ASCII clone tag characters themselves.
この範囲のうち、U-000E0020 .. U-000E007Eは、ASCIIクローンタグ文字自体の推奨範囲です。
The names for the ASCII clone tag characters should be exactly the ISO 10646 names for 7-bit ASCII, prefixed with the word "TAG".
ASCIIクローンタグ文字の名前は、7ビットASCIIのISO 10646名であり、先頭に「TAG」という単語が付いている必要があります。
In addition, there is one tag identification character and a CANCEL TAG character. The use and syntax of these characters is described in detail below.
さらに、1つのタグ識別文字とCANCEL TAG文字があります。これらの文字の使用と構文については、以下で詳しく説明します。
The entire encoding for the proposed Plane 14 tag characters and names of those characters can be derived from the following list. (The encoded values here and throughout this proposal are listed in UCS-4 form, which is easiest to interpret. It is assumed that most Unicode applications will, however, be making use either of UTF-16 or UTF-8 encoding forms for actual implementation.)
提案されているPlane 14タグの文字のエンコーディング全体とそれらの文字の名前は、次のリストから導出できます。 （ここおよびこの提案全体でエンコードされた値は、解釈が最も簡単なUCS-4形式でリストされています。ただし、ほとんどのUnicodeアプリケーションは、実際にはUTF-16またはUTF-8エンコード形式のいずれかを使用していると想定されています実装。）
U-000E0000 <reserved> U-000E0001 LANGUAGE TAG U-000E0002 <reserved> U-000E001F <reserved> U-000E0020 TAG SPACE U-000E0021 TAG EXCLAMATION MARK U-000E0041 TAG LATIN CAPITAL LETTER A U-000E007A TAG LATIN SMALL LETTER Z U-000E007E TAG TILDE U-000E007F CANCEL TAG
U-000E0000 <予約済み> U-000E0001言語タグU-000E0002 <予約済み> U-000E001F <予約済み> U-000E0020タグスペースU-000E0021タグの除外マークU-000E0041タグラテン大文字A U-000E007Aタグラテン小文字Z U-000E007EタグチルトU-000E007Fタグをキャンセル
The range checks required for code testing for tag characters would be as follows. The same range check is expressed here in C for each of the three significant encoding forms for 10646.
タグ文字のコードテストに必要な範囲チェックは次のようになります。ここでは、10646の3つの重要なエンコード形式のそれぞれについて、同じ範囲チェックがCで表現されています。
Range check expressed in UCS-4:
UCS-4で表現された範囲チェック：
if ( ( *s >= 0xE0000 ) || ( *s <= 0xE007F ) )
Range check expressed in UTF-16 (Unicode):
UTF-16（Unicode）で表現された範囲チェック：
if ( ( *s == 0xDB40 ) && ( *(s+1) >= 0xDC00 ) && ( *(s+1) <= 0xDC7F ) )
Expressed in UTF-8:
UTF-8で表現：
if ( ( *s == 0xF3 ) && ( *(s+1) == 0xA0 ) && ( *(s+2) & 0xE0 == 0x80 )
Because of the choice of the range for the tag characters, it would also be possible to express the range check for UCS-4 or UTF-16 in terms of bitmask operations, as well.
タグ文字の範囲の選択により、ビットマスク操作の観点からも、UCS-4またはUTF-16の範囲チェックを表すこともできます。
The use of the Plane 14 tag characters is very simple. In order to embed any ASCII-derived tag in Unicode plain text, the tag is simply spelled out with the tag characters instead, prefixed with the relevant tag identification character. The resultant string is embedded directly in the text.
Plane 14タグ文字の使用は非常に簡単です。 UnicodeプレーンテキストにASCII派生タグを埋め込むために、タグは、代わりにタグ文字でスペルアウトされ、関連するタグ識別文字が前に付けられます。結果の文字列は、テキストに直接埋め込まれます。
The tag identification character is used as a mechanism for identifying tags of different types. This enables multiple types of tags to coexist amicably embedded in plain text and solves the problem of delimitation if a tag is concatenated directly onto another tag. Although only one type of tag is currently specified, namely the language tag, the encoding of other tag identification characters in the future would allow for distinct tag types to be used.
タグ識別文字は、異なるタイプのタグを識別するためのメカニズムとして使用されます。これにより、複数のタイプのタグが共存してプレーンテキストに埋め込まれ、タグが別のタグに直接連結されている場合の区切りの問題が解決されます。現在、1種類のタグ、つまり言語タグのみが指定されていますが、将来的に他のタグ識別文字をエンコードすることにより、異なるタグタイプを使用できるようになります。
No termination character is required for a tag. A tag terminates either when the first non Plane 14 Tag Character (i.e. any other normal Unicode value) is encountered, or when the next tag identification character is encountered.
タグに終了文字は必要ありません。タグは、最初のPlane 14タグ以外の文字（つまり、他の通常のUnicode値）が検出されたとき、または次のタグ識別文字が検出されたときに終了します。
All tag arguments must be encoded only with the tag characters U-000E0020 .. U-000E007E. No other characters are valid for expressing the tag argument.
すべてのタグ引数は、タグ文字U-000E0020 .. U-000E007Eでのみエンコードする必要があります。タグ引数を表現するために他の文字は無効です。
A detailed BNF syntax for tags is listed below.
タグの詳細なBNF構文を以下に示します。
The value of an established tag continues from the point the tag is embedded in text until either:
確立されたタグの値は、タグがテキストに埋め込まれた時点から次のいずれかまで続きます。
A. The text itself goes out of scope, as defined by the application. (E.g. for line-oriented protocols, when reaching the end-of-line or end-of-string; for text streams, when reaching the end-of-stream; etc.)
A.アプリケーションで定義されているように、テキスト自体は範囲外になります。 （たとえば、行指向のプロトコルの場合、行の終わりまたは文字列の終わりに達した場合、テキストストリームの場合、ストリームの終わりに達した場合など）
or
または
B. The tag is explicitly cancelled by the CANCEL TAG character.
B.タグはCANCEL TAG文字によって明示的にキャンセルされます。
Tags of the same type cannot be nested in any way. The appearance of a new embedded language tag, for example, after text which was already language tagged, simply changes the tagged value for subsequent text to that specified in the new tag.
同じタイプのタグはいかなる方法でもネストできません。たとえば、すでに言語タグが付けられているテキストの後の新しい埋め込み言語タグの外観は、後続のテキストのタグ付けされた値を新しいタグで指定された値に変更するだけです。
Tags of different type can have interdigitating scope, but not hierarchical scope. In effect, tags of different type completely ignore each other, so that the use of language tags can be completely asynchronous with the use of character set source tags (or any other tag type) in the same text in the future.
異なるタイプのタグは相互にスコープを組み合わせることができますが、階層的なスコープはできません。実際、異なるタイプのタグは互いに完全に無視するため、言語タグの使用は、将来同じテキストで文字セットソースタグ（または他のタグタイプ）を使用することと完全に非同期になる可能性があります。
U-000E007F CANCEL TAG is provided to allow the specific cancelling of a tag value. The use of CANCEL TAG has the following syntax. To cancel a tag value of a particular type, prefix the CANCEL TAG character with the tag identification character of the appropriate type. For example, the complete string to cancel a language tag is:
U-000E007F CANCEL TAGは、タグ値の特定のキャンセルを可能にするために提供されています。 CANCEL TAGの使用には、次の構文があります。特定のタイプのタグ値をキャンセルするには、CANCEL TAG文字の前に適切なタイプのタグ識別文字を付けます。たとえば、言語タグをキャンセルするための完全な文字列は次のとおりです。
U-000E0001 U-000E007F
U-000E0001 U-000E007F
The value of the relevant tag type returns to the default state for that tag type, namely: no tag value specified, the same as untagged text.
関連するタグタイプの値は、そのタグタイプのデフォルトの状態に戻ります。つまり、タグ値が指定されていない、タグなしテキストと同じです。
The use of CANCEL TAG without a prefixed tag identification character cancels *any* Plane 14 tag values which may be defined. Since only language tags are currently provided with an explicit tag identification character, only language tags are currently affected.
接頭辞付きタグ識別文字なしでCANCEL TAGを使用すると、定義されている*すべての* Plane 14タグ値がキャンセルされます。現在、明示的なタグ識別文字が提供されているのは言語タグだけなので、現在影響を受けるのは言語タグだけです。
The main function of CANCEL TAG is to make possible such operations as blind concatenation of strings in a tagged context without the propagation of inappropriate tag values across the string boundaries. For example, a string tagged with a Japanese language tag can have its tag value "sealed off" with a terminating CANCEL TAG before another string of unknown language value is concatenated to it. This would prevent the string of unknown language from being erroneously marked as being Japanese simply because of a concatenation to a Japanese string.
CANCEL TAGの主な機能は、不適切なタグ値が文字列の境界を越えて伝播することなく、タグ付きコンテキスト内の文字列のブラインド連結などの操作を可能にすることです。たとえば、日本語のタグでタグ付けされた文字列は、未知の言語値の別の文字列が連結される前に、終端のCANCEL TAGでタグ値を「封印」することができます。これにより、単に日本語の文字列に連結されているために、不明な言語の文字列が誤って日本語であるとマークされるのを防ぐことができます。
An extended BNF (Backus-Naur Form) description of the tags specified in this proposal is found below. Note the following BNF extensions used in this formalism:
この提案で指定されたタグの拡張BNF（バッカスナウアフォーム）の説明を以下に示します。この形式で使用される次のBNF拡張に注意してください。
1. Semantic constraints are specified by rules in the form of an assertion specified between double braces; the variable $$ denotes the string consisting of all terminal symbols matched by the this non-terminal.
1. 意味的制約は、二重ブレースの間に指定されたアサーションの形式でルールによって指定されます。変数$$は、この非終端記号と一致するすべての終端記号で構成される文字列を示します。
Example: {{ Assert ( $$[0] == '?' ); }}
Meaning: The first character of the string matched by this
non-terminal must be '?'
2. A number of predicate functions are employed in semantic constraint rules which are not otherwise defined; their name is sufficient for determining their predication.
2. 多くの述語関数は、他に定義されていない意味的制約規則で使用されます。彼らの名前は彼らの予測を決定するのに十分です。
Example: IsRFC1766LanguageIdentifier ( tag-argument )
例：IsRFC1766LanguageIdentifier（tag-argument）
Meaning: tag-argument is a valid RFC1766 language identifier
意味：タグ引数は、有効なRFC1766言語識別子です
3. A lexical expander function, TAG, is employed to denote the tag form of an ASCII character; the argument to this function is either a character or a character set specified by a range or enumeration expression.
3. 字句拡張関数TAGは、ASCII文字のタグ形式を示すために使用されます。この関数の引数は、範囲または列挙式で指定された文字または文字セットです。
Example: TAG('-')
例：TAG（ '-'）
Meaning: TAG HYPHEN-MINUS
意味：TAG HYPHEN-MINUS
Example: TAG([A-Z])
例：TAG（[A-Z]）
Meaning: TAG LATIN CAPITAL LETTER A ... TAG LATIN CAPITAL LETTER Z
意味：タグラテン大文字A ...タグラテン大文字Z
4. A macro is employed to denote terminal symbols that are character literals which can't be directly represented in ASCII. The argument to the macro is the UNICODE (ISO/IEC 10646) character name.
4. マクロは、ASCIIで直接表現できない文字リテラルである終端記号を示すために使用されます。マクロの引数は、UNICODE（ISO / IEC 10646）文字名です。
Example: '${TAG CANCEL}'
Meaning: character literal whose code value is U-000E007F
意味：コード値がU-000E007Fである文字リテラル
5. Occurrence indicators used are '+' (one or more) and '*' (zero or more); optional occurrence is indicated by enclosure in '[' and ']'.
5. 使用されるオカレンスインジケーターは '+'（1つ以上）および '*'（0以上）です。オプションの出現は、「[」と「]」の囲みで示されます。
tag : language-tag | cancel-all-tag ;
タグ：言語タグ|すべてタグをキャンセル;
language-tag : language-tag-introducer language-tag-argument ;
言語タグ：言語タグ紹介者言語タグ引数;
language-tag-argument : tag-argument
{{ Assert ( IsRFC1766LanguageIdentifier ( $$ ); }}
| tag-cancel
;
cancel-all-tag : tag-cancel ;
cancel-all-tag：tag-cancel;
tag-argument : tag-character+ ;
タグ引数：タグ文字;
tag-character : { c : c in
TAG( { a : a in printable ASCII characters or SPACE } ) }
;
language-tag-introducer : '${TAG LANGUAGE}'
;
tag-cancel : '${TAG CANCEL}'
;
Language tags are of general interest and should have a high degree of interoperability for protocol usage. To this end, a specific LANGUAGE TAG tag identification character is provided. A Plane 14 tag string prefixed by U-000E0001 LANGUAGE TAG is specified to constitute a language tag. Furthermore, the tag values for the language tag are to be spelled out as specified in RFC 1766, making use only of registered tag values or of user-defined language tags starting with the characters "x-".
言語タグは一般的に重要であり、プロトコルの使用には高度な相互運用性が必要です。この目的のために、特定のLANGUAGE TAGタグ識別文字が提供されています。 U-000E0001 LANGUAGE TAGで始まるPlane 14タグ文字列が言語タグを構成するように指定されています。さらに、言語タグのタグ値はRFC 1766で指定されているとおりにスペルアウトされ、登録されたタグ値または文字「x-」で始まるユーザー定義の言語タグのみを使用します。
For example, to embed a language tag for Japanese, the Plane 14 characters would be used as follows. The Japanese tag from RFC 1766 is "ja" (composed of ISO 639 language id) or, alternatively, "ja-JP" (composed of ISO 639 language id plus ISO 3166 country id). Since RFC 1766 specifies that language tags are not case significant, it is recommended that for language tags, the entire tag be lowercased before conversion to Plane 14 tag characters. (This would not be required for Unicode conformance, but should be followed as general practice by protocols making use of RFC 1766 language tags, to simplify and speed up the processing for operations which need to identify or ignore language tags embedded in text.) Lowercasing, rather than uppercasing, is recommended because it follows the majority practice of expressing language tag values in lowercase letters.
たとえば、日本語の言語タグを埋め込むには、次のようにPlane 14文字を使用します。 RFC 1766の日本語タグは「ja」（ISO 639言語IDで構成）、または「ja-JP」（ISO 639言語IDとISO 3166国IDで構成）です。 RFC 1766では、言語タグは大文字と小文字を区別しないと規定されているため、言語タグの場合は、Plane 14タグ文字に変換する前にタグ全体を小文字にすることをお勧めします。 （これは、Unicode準拠には必要ありませんが、RFC 1766言語タグを使用するプロトコルの一般的な慣習に従って、テキストに埋め込まれた言語タグを識別または無視する必要がある操作の処理を簡略化および高速化する必要があります。）言語タグの値を小文字で表現する慣例に従っているため、大文字ではなくをお勧めします。
Thus the entire language tag (in its longer form) would be converted to Plane 14 tag characters as follows:
したがって、言語タグ全体（長い形式）は、次のようにPlane 14タグ文字に変換されます。
U-000E0001 U-000E006A U-000E0061 U-000E002D U-000E006A U-000E0070
U-000E0001 U-000E006A U-000E0061 U-000E002D U-000E006A U-000E0070
The language tag (in its shorter, "ja" form) could be expressed as follows:
言語タグ（短い "ja"形式）は次のように表現できます。
U-000E0001 U-000E006A U-000E0061
U-000E0001 U-000E006A U-000E0061
The value of this string is then expressed in whichever encoding form (UCS-4, UTF-16, UTF-8) is required and embedded in text at the relevant point.
この文字列の値は、必要なエンコード形式（UCS-4、UTF-16、UTF-8）で表現され、関連するポイントでテキストに埋め込まれます。
Additional tag identification characters might be defined in the future. An example would be a CHARACTER SET SOURCE TAG, or a GENERIC TAG for private definition of tags.
将来、追加のタグ識別文字が定義される可能性があります。例としては、CHARACTER SET SOURCE TAG、またはタグのプライベート定義のためのGENERIC TAGがあります。
In each case, when a specific tag identification character is encoded, a corresponding reference standard for the values of the tags associated with the identifier should be designated, so that interoperating parties which make use of the tags will know how to interpret the values the tags may take.
いずれの場合も、特定のタグ識別文字がエンコードされている場合、識別子に関連付けられたタグの値に対応する参照標準を指定する必要があります。これにより、タグを利用する相互運用者は、タグの値を解釈する方法を知ることができます。取るかもしれません。
All characters in the tag character block are considered to have no visible rendering in normal text. A process which interprets tags may choose to modify the rendering of text based on the tag values (as for example, changing font to preferred style for rendering Chinese versus Japanese). The tag characters themselves have no display; they may be considered similar to a U+200B ZERO WIDTH SPACE in that regard. The tag characters also do not affect breaking, joining, or any other format or layout properties, except insofar as the process interpreting the tag chooses to impose such behavior based on the tag value.
タグ文字ブロック内のすべての文字は、通常のテキストでは表示されないものと見なされます。タグを解釈するプロセスは、タグ値に基づいてテキストのレンダリングを変更することを選択できます（たとえば、フォントを中国語と日本語のレンダリングに適したスタイルに変更するなど）。タグ文字自体は表示されません。それらは、その点でU + 200B ZERO WIDTH SPACEに似ていると考えられます。タグを解釈するプロセスがタグ値に基づいてそのような動作を強制することを選択する場合を除いて、タグ文字は分割、結合、または他のフォーマットやレイアウトのプロパティにも影響を与えません。
For debugging or other operations which must render the tags themselves visible, it is advisable that the tag characters be rendered using the corresponding ASCII character glyphs (perhaps modified systematically to differentiate them from normal ASCII characters). But, as noted below, the tag character values are chosen so that even without display support, the tag characters will be interpretable in most debuggers.
タグ自体を表示する必要があるデバッグやその他の操作の場合、対応するASCII文字グリフを使用してタグ文字をレンダリングすることをお勧めします（通常、通常のASCII文字と区別するために体系的に変更されています）。ただし、以下に示すように、タグ文字の値は、表示がサポートされていなくても、ほとんどのデバッガーでタグ文字を解釈できるように選択されています。
The basic rules for Unicode conformance for the tag characters are exactly the same as for any other Unicode characters. A conformant process is not required to interpret the tag characters. If it does not interpret tag characters, it should leave their values undisturbed and do whatever it does with any other uninterpreted characters. If it does interpret them, it should interpret them according to the standard, i.e. as spelled-out tags.
タグ文字のUnicode準拠の基本的なルールは、他のUnicode文字の場合とまったく同じです。タグ文字を解釈するために適合プロセスは必要ありません。タグ文字を解釈しない場合は、それらの値をそのままにし、他の解釈されていない文字を使用して何をする必要があります。それらを解釈する場合、標準に従って、つまりスペルアウトされたタグとして解釈する必要があります。
So for a non-TagAware Unicode application, any language tag characters (or any other kind of tag expressed with Plane 14 tag characters) encountered would be handled exactly as for uninterpreted Tibetan from the BMP, uninterpreted Linear B from Plane 1, or uninterpreted Egyptian hieroglyphics from private use space in Plane 15.
したがって、TagAware以外のUnicodeアプリケーションの場合、発生した言語タグ文字（または平面14のタグ文字で表されるその他の種類のタグ）は、BMPからの未解釈のチベット語、平面1からの未解釈の線形B、または解釈されないエジプト語とまったく同じように処理されます。平面15の私用空間からの象形文字。
A TagAware but TagPhobic Unicode application can recognize the tag character range in Plane 14 and choose to deliberately strip them out completely to produce plain text with no tags.
TagAware but TagPhobic Unicodeアプリケーションは、プレーン14のタグ文字範囲を認識し、意図的に完全に削除して、タグのないプレーンテキストを生成することを選択できます。
The presence of a correctly formed tag cannot be taken as a guarantee that the data so tagged is correctly tagged. For example, nothing prevents an application from erroneously labelling French data as Spanish, or from labelling JIS-derived data as Japanese, even if it contains Greek or Cyrillic characters.
正しく形成されたタグの存在は、そのようにタグ付けされたデータが正しくタグ付けされていることの保証と見なすことはできません。たとえば、ギリシャ語やキリル文字が含まれている場合でも、アプリケーションがフランス語のデータを誤ってスペイン語としてラベル付けしたり、JIS派生データを日本語としてラベル付けしたりすることを防ぐものはありません。
The fact that this proposal for encoding tag characters in Unicode includes a mechanism for specifying language tag values does not mean that Unicode is departing from one of its basic encoding principles:
Unicodeでタグ文字をエンコードするためのこの提案が言語タグ値を指定するメカニズムを含むという事実は、Unicodeがその基本的なエンコード原理の1つから逸脱していることを意味しません。
Unicode encodes scripts, not languages.
Unicodeは言語ではなくスクリプトをエンコードします。
This is still true of the Unicode encoding (and ISO/IEC 10646), even in the presence of a mechanism for specifying language tags in plain text. There is nothing obligatory about the use of Plane 14 tags, whether for language tags or any other kind of tags.
これは、プレーンテキストで言語タグを指定するメカニズムが存在する場合でも、Unicodeエンコーディング（およびISO / IEC 10646）に当てはまります。言語タグであれ、その他の種類のタグであれ、Plane 14タグの使用に関して義務的なことは何もありません。
Language tagging in no way impacts current encoded characters or the encoding of future scripts.
言語のタグ付けは、現在のエンコードされた文字や将来のスクリプトのエンコードにはまったく影響しません。
It is fully anticipated that implementations of Unicode which already make use of out-of-band mechanisms for language tagging or "heavy-weight" in-band mechanisms such as HTML will continue to do exactly what they are doing and will ignore Plane 14 tag characters completely.
言語のタグ付けにアウトオブバンドメカニズムまたはHTMLなどの「ヘビーウェイト」インバンドメカニズムをすでに使用しているUnicodeの実装は、彼らがしていることを正確に実行し続け、Plane 14タグを無視することが完全に予想されます。文字を完全に。
There are no known security issues raised by this document.
このドキュメントによって引き起こされる既知のセキュリティ問題はありません。
References
参考文献
[ISO10646] ISO/IEC 10646-1:1993 International Organization for Standardization. "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", Geneva, 1993.
[ISO10646] ISO / IEC 10646-1：1993国際標準化機構。 「情報技術-ユニバーサル複数オクテットコード化文字セット（UCS）-パート1：アーキテクチャと基本的な多言語面」、ジュネーブ、1993年。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC2070] Yergeau, F., Nicol, G. Adams, G. and M. Duerst, "Internationalization of the Hypertext Markup Language", RFC 2070, January 1997.
[RFC2070] Yergeau、F.、Nicol、G。Adams、G。およびM. Duerst、「ハイパーテキストマークアップ言語の国際化」、RFC 2070、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2130] Weider, C. Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M. and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[RFC2130]ワイダー、C。プレストン、C。、サイモンセン、K。、アルベストランド、H。、アトキンソン、R。、クリスピン、M.、P。スヴァンバーグ、「IABキャラクターセットワークショップのレポートは2月29日から1日に開催されました。 1996年3月」、RFC 2130、1997年4月。
[UNICODE] The Unicode Standard, Version 2.0, The Unicode Consortium, Addison-Wesley, July 1996.
[UNICODE] Unicode標準、バージョン2.0、Unicodeコンソーシアム、Addison-Wesley、1996年7月。
Acknowledgements
謝辞
The following people also contributed to this document, directly or indirectly: Chris Newman, Mark Crispin, Rick McGowan, Joe Becker, John Jenkins, and Asmus Freytag. This document also was reviewed by the Unicode Technical Committee, and the authors wish to thank all of the UTC representatives for their input. The authors are, of course, responsible for any errors or omissions which may remain in the text.
次の人々も、このドキュメントに直接的または間接的に寄稿しました。ChrisNewman、Mark Crispin、Rick McGowan、Joe Becker、John Jenkins、およびAsmus Freytag。このドキュメントは、Unicode Technical Committeeによってもレビューされました。執筆者は、UTCの代表者全員からの情報提供に感謝します。もちろん、著者は、テキストに残る可能性のある誤りや脱落について責任があります。
Authors' Addresses
著者のアドレス
Ken Whistler Sybase, Inc. 6475 Christie Ave. Emeryville, CA 94608-1050
Ken Whistler Sybase、Inc. 6475 Christie Ave. Emeryville、CA 94608-1050
Phone: +1 510 922 3611
EMail: kenw@sybase.com
Glenn Adams Spyglass, Inc. One Cambridge Center Cambridge, MA 02142
Glenn Adams Spyglass、Inc. One Cambridge Center Cambridge、MA 02142
Phone: +1 617 679 4652
EMail: glenn@spyglass.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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 assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。