Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6365 VPN Consortium
BCP: 166 J. Klensin
Obsoletes: 3536 September 2011
Category: Best Current Practice
ISSN: 2070-1721
Terminology Used in Internationalization in the IETF
Abstract
抽象
This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
この文書では、国際化を議論する際にIETFで使用される用語のリストを提供します。目的は、IETFの様々な分野における国際化のフレーム議論を助け、IETFの参加者に主要な概念を紹介する手助けをすることです。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモはインターネット最も良い現在の練習を説明します。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6365.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6365で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose of this Document . . . . . . . . . . . . . . . . . 3
1.2. Format of the Definitions in This Document . . . . . . . . 4
1.3. Normative Terminology . . . . . . . . . . . . . . . . . . 4
2. Fundamental Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Standards Bodies and Standards . . . . . . . . . . . . . . . . 10
3.1. Standards Bodies . . . . . . . . . . . . . . . . . . . . . 11
3.2. Encodings and Transformation Formats of ISO/IEC 10646 . . 13
3.3. Native CCSs and Charsets . . . . . . . . . . . . . . . . . 15
4. Character Issues . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Types of Characters . . . . . . . . . . . . . . . . . . . 20
4.2. Differentiation of Subsets . . . . . . . . . . . . . . . . 23
5. User Interface for Text . . . . . . . . . . . . . . . . . . . 24
6. Text in Current IETF Protocols . . . . . . . . . . . . . . . . 27
7. Terms Associated with Internationalized Domain Names . . . . . 31
7.1. IDNA Terminology . . . . . . . . . . . . . . . . . . . . . 31
7.2. Character Relationships and Variants . . . . . . . . . . . 32
8. Other Common Terms in Internationalization . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Additional Interesting Reading . . . . . . . . . . . 41
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Appendix C. Significant Changes from RFC 3536 . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
As the IETF Character Set Policy specification [RFC2277] summarizes: "Internationalization is for humans. This means that protocols are not subject to internationalization; text strings are." Many protocols throughout the IETF use text strings that are entered by, or are visible to, humans. Subject only to the limitations of their own knowledge and facilities, it should be possible for anyone to enter or read these text strings, which means that Internet users must be able to enter text using typical input methods and have it be displayed in any human language. Further, text containing any character should be able to be passed between Internet applications easily. This is the challenge of internationalization.
IETF文字セットPolicy仕様[RFC2277]がまとめたように、「国際化が人間のためにあるこれは、プロトコルが国際化の対象とならないことを意味し、テキスト文字列です。」入力された、または、人間に表示されているIETF使用テキスト文字列全体に多くのプロトコル。誰が入るか、インターネットユーザーは、典型的な入力方法を使用してテキストを入力することができなければならないことを意味し、これらのテキスト文字列を読んで、それがどんな人間の言語で表示されていることのためにのみ、自分の知識や設備の制限を受けるが、それは可能なはず。さらに、任意の文字を含むテキストを簡単にインターネットアプリケーション間で渡されることができるはずです。これは、国際化の課題です。
This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
この文書では、国際化を議論する際にIETFで使用している用語を解説します。目的は、IETFの様々な分野における国際化のフレーム議論を助け、IETFの参加者に主要な概念を紹介する手助けをすることです。
Internationalization is discussed in many working groups of the IETF. However, few working groups have internationalization experts. When designing or updating protocols, the question often comes up "Should we internationalize this?" (or, more likely, "Do we have to internationalize this?").
国際化は、IETFの多くのワーキンググループで議論されています。しかし、いくつかのワーキンググループは、国際化の専門家を持っています。プロトコルを設計または更新する場合、「我々はこれを国際化すべきか？」、質問が頻繁に来ます（または、より多くの可能性が高い、「我々はこれを国際化する必要がありますか？」）。
This document gives an overview of internationalization terminology as it applies to IETF standards work by lightly covering the many aspects of internationalization and the vocabulary associated with those topics. Some of the overview is somewhat tutorial in nature. It is not meant to be a complete description of internationalization. The definitions here SHOULD be used by IETF standards. IETF standards that explicitly want to create different definitions for the terms defined here can do so, but unless an alternate definition is provided the definitions of the terms in this document apply. IETF standards that have a requirement for different definitions are encouraged, for clarity's sake, to find terms different than the ones defined here. Some of the definitions in this document come from earlier IETF documents and books.
それは軽く国際これらのトピックに関連した語彙の多くの側面を覆うことにより、IETF標準化作業に適用されるこの文書は、国際化の用語の概要を説明します。概要の一部は、自然の中で多少のチュートリアルです。国際化の完全な記述であることを意味するものではありません。ここでの定義は、IETF標準で使用されるべきです。明示的にそうすることができ、ここで定義された用語に異なる定義を作成したいのですが、別の定義は、この文書で用語の定義を提供されない限り適用するIETF標準規格。異なる定義の要件を持っているIETF標準規格は、ここで定義されたものとは異なる用語を見つけるために、明瞭のために、奨励されています。この文書の定義の一部は、以前のIETF文書や書籍から来ます。
As in many fields, there is disagreement in the internationalization community on definitions for many words. The topic of language brings up particularly passionate opinions for experts and non-experts alike. This document attempts to define terms in a way that will be most useful to the IETF audience.
多くの分野と同様に、多くの単語の定義上の国際コミュニティの意見の相違があります。言語の話題を問わず、専門家と非専門家のために特に情熱的な意見が表示されます。この文書は、IETF視聴者に最も有用であろうように、用語を定義しようとします。
This document uses definitions from many documents that have been developed inside and outside the IETF. The primary documents used are:
この文書は、IETFの内側と外側で開発されてきた多くの文書から定義を使用しています。使用される主な書類は以下のとおりです。
o ISO/IEC 10646 [ISOIEC10646]
お いそ／いえＣ １０６４６ 「いそいえＣ１０６４６」
o The Unicode Standard [UNICODE]
O Unicode標準[UNICODE]
o W3C Character Model [CHARMOD]
O W3Cキャラクターモデル[CHARMOD]
o IETF RFCs, including the Character Set Policy specification [RFC2277] and the domain name internationalization standard [RFC5890]
文字セットPolicy仕様[RFC2277]とドメイン名の国際標準[RFC5890]を含むIETFのRFC、O
In the body of this document, the source for the definition is shown in angle brackets, such as "<ISOIEC10646>". Many definitions are shown as "<RFC6365>", which means that the definitions were crafted originally for this document. The angle bracket notation for the source of definitions is different than the square bracket notation used for references to documents, such as in the paragraph above; these references are given in the reference sections of this document.
本文書の本文に、定義のソースは、「<ISOIEC10646>」のように、角括弧で示されています。多くの定義は、定義がこの文書のために元々作られたことを意味し、「<RFC6365>」として示されています。定義のソースのアングルブラケット表記は、上の段落のようにドキュメントへの参照に使用される角括弧表記法とは異なります。これらの文献は、このドキュメントの参照セクションに記載されています。
For some terms, there are commentary and examples after the definitions. In those cases, the part before the angle brackets is the definition that comes from the original source, and the part after the angle brackets is commentary that is not a definition (such as an example or further exposition).
いくつかの用語について、定義後の解説と例があります。これらの場合、角括弧の前の部分は、元のソースから来ている定義であり、角括弧の後の部分ではない（例えば、またはさらに博覧会など）の定義解説です。
Examples in this document use the notation for code points and names from the Unicode Standard [UNICODE] and ISO/IEC 10646 [ISOIEC10646]. For example, the letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER A". See RFC 5137 [RFC5137] for a description of this notation.
この文書に記載されている例は、Unicode標準[UNICODE]およびISO / IEC 10646 [ISOIEC10646]のコードポイントと名の表記を使用します。例えば、文字「は」「U + 0061」又は「ラテン小文字A」のいずれかとして表すことができます。この表記法の説明については、RFC 5137 [RFC5137]を参照。
The 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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This section covers basic topics that are needed for almost anyone who is involved with making IETF protocols more friendly to non-ASCII text (see Section 4.2) and with other aspects of internationalization.
このセクションでは、非ASCIIテキストへのIETFプロトコルは、より親しみやすい作りに関与しているほとんど誰のために必要とされる基本的なトピックをカバーし、国際化の他の側面で（4.2節を参照してください）。
language
言語
A language is a way that humans communicate. The use of language occurs in many forms, the most common of which are speech, writing, and signing. <RFC6365>
言語は人間がコミュニケーションの方法です。言語の使用は、音声、書き込み、および署名されている最も一般的なものは、多くの形で発生します。 <RFC6365>
Some languages have a close relationship between the written and spoken forms, while others have a looser relationship. The so-called LTRU (Language Tag Registry Update) standards [RFC5646] [RFC4647] discuss languages in more detail and provide identifiers for languages for use in Internet protocols. Note that computer languages are explicitly excluded from this definition.
他の人が緩い関係を持っていながら、いくつかの言語は、書かれたと話さフォームの間の密接な関係を持っています。いわゆるLTRU（言語タグレジストリ更新）規格[RFC5646] [RFC4647]より詳細に言語を議論し、インターネットプロトコルで使用するための言語の識別子を提供しています。コンピュータ言語が明示的にこの定義から除外されることに注意してください。
script
脚本
A set of graphic characters used for the written form of one or more languages. <ISOIEC10646>
一の以上の言語の表記に使用するグラフィック文字のセット。 <ISOIEC10646>
Examples of scripts are Latin, Cyrillic, Greek, Arabic, and Han (the characters, often called ideographs after a subset of them, used in writing Chinese, Japanese, and Korean). RFC 2277 discusses scripts in detail.
スクリプトの例は、ラテン語、キリル文字、ギリシャ語、アラビア語、およびハン（多くの場合、中国語、日本語、韓国語の記述で使われるそれらのサブセット後表意文字と呼ばれる文字）です。 RFC 2277を詳細にスクリプトを説明します。
It is common for internationalization novices to mix up the terms "language" and "script". This can be a problem in protocols that differentiate the two. Almost all protocols that are designed (or were re-designed) to handle non-ASCII text deal with scripts (the written systems) or characters, while fewer actually deal with languages.
国際初心者は用語「言語」と「スクリプト」をアップミックスするのが一般的です。これは、二つを区別するプロトコルで問題になることができます。少数の実際の言語を扱う一方で、スクリプト（書かれたシステム）または文字で非ASCIIテキストの契約を扱うように設計されている（または再設計されました）ほとんどすべてのプロトコル。
A single name can mean either a language or a script; for example, "Arabic" is both the name of a language and the name of a script. In fact, many scripts borrow their names from the names of languages. Further, many scripts are used to write more than one language; for example, the Russian and Bulgarian languages are written in the Cyrillic script. Some languages can be expressed using different scripts or were used with different scripts at different times; the Mongolian language can be written in either the Mongolian or Cyrillic scripts; Malay is primarily written in Latin script today, but the earlier, Arabic-script-based, Jawa form is still in use; and a number of languages were converted from other scripts to Cyrillic in the first half of the last century, some of which have switched again more recently. Further, some languages are normally expressed with more than one script at the same time; for example, the Japanese language is normally expressed in the Kanji (Han), Katakana, and Hiragana scripts in a single string of text.
単一の名前は、言語やスクリプトのいずれかを意味することができます。例えば、「アラビア語は、」言語の名前とスクリプトの名前でもあります。実際には、多くのスクリプトは、言語の名前から自分の名前を借りて。さらに、多くのスクリプトは、複数の言語を記述するために使用されています。例えば、ロシア語、ブルガリア語はキリル文字で書かれています。一部の言語では異なるスクリプトを使用して表現することができるか、異なる時間に異なるスクリプトで使用されました。モンゴル語はモンゴルやキリル文字のスクリプトのいずれかに書き込むことができます。マレーは、主に今日のラテン文字で書かれていますが、以前、アラビア語スクリプトベースされ、ジャワの形はまだ使われています。そして、言語の数は、最近になって再び切り替えているそのうちのいくつかは、前世紀の前半にキリル文字に他のスクリプトから変換されました。さらに、いくつかの言語は、通常、同時に複数のスクリプトを使用して表現されます。例えば、日本語の言語は、通常のテキストの単一の列に漢字（漢）、カタカナ、ひらがな、およびスクリプトで表現されます。
writing system
ライティングシステム
A set of rules for using one or more scripts to write a particular language. Examples include the American English writing system, the British English writing system, the French writing system, and the Japanese writing system. <UNICODE>
特定の言語を記述するために、1つのまたは複数のスクリプトを使用するためのルールのセット。例としては、アメリカ英語のライティングシステム、イギリス英語のライティングシステム、フランスの書き込みシステム、および日本語の表記体系が含まれます。 <UNICODE>
character
キャラクター
A member of a set of elements used for the organization, control, or representation of data. <ISOIEC10646>
組織のために使用される要素の集合のメンバー、制御、又はデータの表現。 <ISOIEC10646>
There are at least three common definitions of the word "character":
単語「文字」の少なくとも3つの共通の定義があります。
* a general description of a text entity
*テキストエンティティの一般的な説明
* a unit of a writing system, often synonymous with "letter" or similar terms, but generalized to include digits and symbols of various sorts
多くの場合、「文字」または類似の用語と同義語ではなく、様々な種類の数字と記号を含むように一般筆記システムの*ユニット、
* the encoded entity itself
*エンコードされた実体そのもの
When people talk about characters, they usually intend one of the first two definitions. The term "character" is often abbreviated as "char".
人々は文字について話すとき、彼らは通常、最初の二つの定義のいずれかを意図します。用語「文字」は、多くの場合、「CHAR」と略記されます。
A particular character is identified by its name, not by its shape. A name may suggest a meaning, but the character may be used for representing other meanings as well. A name may suggest a shape, but that does not imply that only that shape is commonly used in print, nor that the particular shape is associated only with that name.
特定の文字はないその形状によって、その名前で識別されます。名前は意味を示唆するかもしれないが、文字は、他の意味を表すために使用することができます。名前は、形を提案してもよいが、それは特定の形状のみがその名前に関連付けられていることだけで形状は一般的に、印刷に使用されていることを意味するもので、もしません。
coded character
符号化文字
A character together with its coded representation. <ISOIEC10646>
一緒にその符号化表現を持つ文字。 <ISO IEC 10646>
coded character set
コード化文字セット
A coded character set (CCS) is a set of unambiguous rules that establishes a character set and the relationship between the characters of the set and their coded representation. <ISOIEC10646>
コード化文字セット（CCS）は、文字セットとセットの文字とその符号化表現との間の関係を確立する明確な規則のセットです。 <ISOIEC10646>
character encoding form
文字エンコーディング形式
A character encoding form is a mapping from a coded character set (CCS) to the actual code units used to represent the data. <UNICODE>
文字エンコード形式は、データを表すために使用される実際のコード単位に符号化された文字セット（CCS）からのマッピングです。 <UNICODE>
repertoire
レパートリー
The collection of characters included in a character set. Also called a character repertoire. <UNICODE>
文字のコレクションは、文字セットに含まれています。また、文字レパートリと呼ばれます。 <UNICODE>
glyph
グリフ
A glyph is an image of a character that can be displayed after being imaged onto a display surface. <RFC6365>
グリフは、表示面上に結像された後に表示することができる文字の画像です。 <RFC6365>
The Unicode Standard has a different definition that refers to an abstract form that may represent different images when the same character is rendered under different circumstances.
Unicode標準は、同じ文字が異なる状況下でレンダリングされるときに異なる画像を表すことができる抽象的な形態を指す異なる定義を有します。
glyph code
グリフコード
A glyph code is a numeric code that refers to a glyph. Usually, the glyphs contained in a font are referenced by their glyph code. Glyph codes are local to a particular font; that is, a different font containing the same glyphs may use different codes. <UNICODE>
グリフコードがグリフを意味する数値コードです。通常、フォントに含まれるグリフは、そのグリフコードによって参照されています。グリフコードは、特定のフォントにローカルです。つまり、同一のグリフを含む異なるフォントが異なるコードを使用することができます。 <UNICODE>
transcoding
トランスコーディング
Transcoding is the process of converting text data from one character encoding form to another. Transcoders work only at the level of character encoding and do not parse the text. Note: Transcoding may involve one-to-one, many-to-one, one-to-many, or many-to-many mappings. Because some legacy mappings are glyphic, they may not only be many-to-many, but also unordered: thus XYZ may map to yxz. <CHARMOD>
トランスコーディングは、別の文字エンコード形式からテキストデータを変換する処理です。トランスコーダは、文字エンコーディングのレベルでのみ動作し、テキストを解析しません。注：トランスコーディングは1対多、または多対多マッピング、多対1、1対1を含むことができます。一部のレガシーマッピングがglyphicなので、多対多、だけでなく、順不同かもしれないだけ：これXYZはYXZしてマッピングすることができます。 <CHARMOD>
In this definition, "many-to-one" means a sequence of characters mapped to a single character. The "many" does not mean alternative characters that map to the single character.
この定義では、「多対一」は、単一の文字にマッピングされた文字の配列を意味します。 「多くの」は、単一の文字にマップする代替文字を意味するものではありません。
character encoding scheme
文字符号化方式
A character encoding scheme (CES) is a character encoding form plus byte serialization. There are many character encoding schemes in Unicode, such as UTF-8 and UTF-16BE. <UNICODE>
文字符号化スキーム（CES）は、文字エンコーディング形式に加えてバイトのシリアル化です。このようUTF-8とUTF-16BEなどのUnicodeには多くの文字符号化スキームは、あります。 <UNICODE>
Some CESs are associated with a single CCS; for example, UTF-8 [RFC3629] applies only to the identical CCSs of ISO/IEC 10646 and Unicode. Other CESs, such as ISO 2022, are associated with many CCSs.
いくつかのCESSは、単一のCCSに関連しています。例えば、UTF-8 [RFC3629]は、ISO / IEC 10646とUnicodeの同一CCSSにのみ適用されます。他のCESSは、例えばISO 2022など、多くのCCSSに関連しています。
charset
文字セット
A charset is a method of mapping a sequence of octets to a sequence of abstract characters. A charset is, in effect, a combination of one or more CCSs with a CES. Charset names are registered by the IANA according to procedures documented in [RFC2978]. <RFC6365>
文字セットは、抽象文字の列にオクテットのシーケンスをマッピングする方法です。文字セットは、実際に、CESを有する1つ以上のCCSSの組み合わせです。文字セット名は、[RFC2978]に記載の手順に従って、IANAによって登録されています。 <RFC6365>
Many protocol definitions use the term "character set" in their descriptions. The terms "charset", or "character encoding scheme" and "coded character set", are strongly preferred over the term "character set" because "character set" has other definitions in other contexts, particularly outside the IETF. When reading IETF standards that use "character set" without defining the term, they usually mean "a specific combination of one CCS with a CES", particularly when they are talking about the "US-ASCII character set".
多くのプロトコル定義は、その説明において、「文字セット」を使用します。 「文字セット」は、特にIETF外の他の状況において他の定義を持っているので用語「文字セット」、または「文字符号化方式」と「符号化された文字セットは、」強く用語「文字セット」よりも好まれます。用語を定義せずに、「文字セット」を使用IETF標準を読むとき、彼らは通常、彼らが「US-ASCII文字セット」について話している場合は特に、「CESで1件のCCSの特定の組み合わせ」を意味します。
internationalization
国際化
In the IETF, "internationalization" means to add or improve the handling of non-ASCII text in a protocol. <RFC6365> A different perspective, more appropriate to protocols that are designed for global use from the beginning, is the definition used by W3C:
IETFでは、「国際化」プロトコルに非ASCIIテキストの取り扱いを追加したり、改善することを意味します。 <RFC6365>は異なる視点が、最初からグローバルな使用のために設計されたプロトコルへのより適切な、W3Cによって使用される定義です。
"Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language." [W3C-i18n-Def]
「国際化は文化、地域、または言語が異なるターゲットオーディエンスのための容易なローカライズを可能にし、製品、アプリケーションやドキュメントのコンテンツの設計と開発です。」 [W3C-I18N-デフ]
Many protocols that handle text only handle one charset (US-ASCII), or leave the question of what CCS and encoding are used up to local guesswork (which leads, of course, to interoperability problems). If multiple charsets are permitted, they must be explicitly identified [RFC2277]. Adding non-ASCII text to a protocol allows the protocol to handle more scripts, hopefully all of the ones useful in the world. In today's world, that is normally best accomplished by allowing Unicode encoded in UTF-8 only, thereby shifting conversion issues away from individual choices.
テキストは唯一の文字セット（US-ASCII）を処理、または何CCSとエンコーディングの問題を残して扱う多くのプロトコルは、（相互運用性の問題のために、当然のことながら、リード）ローカル当て推量まで使用されています。複数の文字セットが許可されている場合は、明示的に[RFC2277]を特定しなければなりません。プロトコルに非ASCIIテキストを追加すると、うまくいけば、全世界で有用なものの、プロトコルは複数のスクリプトを処理することができます。今日の世界では、それは通常最高これにより、個々の選択肢の中から離れ変換の問題をシフト、UnicodeはUTF-8のみでエンコードできるようにすることによって達成されます。
localization
ローカリゼーション
The process of adapting an internationalized application platform or application to a specific cultural environment. In localization, the same semantics are preserved while the syntax may be changed. [FRAMEWORK]
特定の文化的環境に国際化されたアプリケーションのプラットフォームやアプリケーションを適応させるプロセス。構文を変更することができる一方でローカライズでは、同じ意味が保存されています。 [フレームワーク]
Localization is the act of tailoring an application for a different language or script or culture. Some internationalized applications can handle a wide variety of languages. Typical users only understand a small number of languages, so the program must be tailored to interact with users in just the languages they know.
ローカライズは、異なる言語やスクリプトや文化のためのアプリケーションを調整する行為です。いくつかの国際化アプリケーションは、さまざまな言語を扱うことができます。プログラムは、彼らが知っているだけの言語でユーザーと対話するように調整されなければならないので、一般的なユーザーは、言語の小さな数を理解しています。
The major work of localization is translating the user interface and documentation. Localization involves not only changing the language interaction, but also other relevant changes such as display of numbers, dates, currency, and so on. The better internationalized an application is, the easier it is to localize it for a particular language and character encoding scheme.
ローカライズの主な仕事は、ユーザーインターフェイスとドキュメントを翻訳しています。ローカライズは言語の相互作用を変更するだけでなく、必要とする、だけでなく、その上の数字の表示、日付、通貨、およびその他の関連の変更。より良い国際化されたアプリケーションは、より簡単に、それは特定の言語と文字符号化スキームのためにそれをローカライズすることにあります。
Localization is rarely an IETF matter, and protocols that are merely localized, even if they are serially localized for several locations, are generally considered unsatisfactory for the global Internet.
ローカライズはめったにIETFの問題ではない、と彼らはシリアルにいくつかの場所にローカライズされていても、単に、ローカライズされているプロトコルは、一般的にグローバルなインターネットには不十分と考えられています。
Do not confuse "localization" with "locale", which is described in Section 8 of this document.
このドキュメントのセクション8に記載されている「ロケール」、と「ローカリゼーション」を混同しないでください。
i18n, l10n
国際化、ローカライゼーション
These are abbreviations for "internationalization" and "localization". <RFC6365>
これらは、「国際化」と「ローカリゼーション」の略称です。 <RFC6365>
"18" is the number of characters between the "i" and the "n" in "internationalization", and "10" is the number of characters between the "l" and the "n" in "localization".
「18」は、「国際」の「I」と「N」の間の文字の数であり、「10」は「局在」において「L」と「N」の間の文字の数です。
multilingual
多言語
The term "multilingual" has many widely varying definitions and thus is not recommended for use in standards. Some of the definitions relate to the ability to handle international characters; other definitions relate to the ability to handle multiple charsets; and still others relate to the ability to handle multiple languages. <RFC6365>
用語「多言語」は、多くの広く様々な定義を持っているので、標準での使用は推奨されません。定義の一部は、国際文字を処理する能力に関係します。他の定義は、複数の文字セットを処理する能力に関係します。そして、まだ他の人が複数の言語を処理する能力に関係します。 <RFC6365>
displaying and rendering text
テキストを表示し、レンダリング
To display text, a system puts characters on a visual display device such as a screen or a printer. To render text, a system analyzes the character input to determine how to display the text. The terms "display" and "render" are sometimes used interchangeably. Note, however, that text might be rendered as audio and/or tactile output, such as in systems that have been designed for people with visual disabilities. <RFC6365>
テキストを表示するために、システムは、スクリーンやプリンタなどの視覚表示装置に文字を置きます。テキストを描画するために、システムは、テキストを表示する方法を決定するために文字入力を分析します。用語「ディスプレイ」と時々交換可能に使用される「レンダリング」。注意は、しかし、そのテキストは、視覚障害を持つ人々のために設計されたシステムのようなオーディオおよび/または触覚出力、としてレンダリングされる可能性があります。 <RFC6365>
Combining characters modify the display of the character (or, in some cases, characters) that precede them. When rendering such text, the display engine must either find the glyph in the font that represents the base character and all of the combining characters, or it must render the combination itself. Such rendering can be straightforward, but it is sometimes complicated when the combining marks interact with each other, such as when there are two combining marks that would appear above the same character. Formatting characters can also change the way that a renderer would display text. Rendering can also be difficult for some scripts that have complex display rules for base characters, such as Arabic and Indic scripts.
文字を組み合わせることで、それらの前の文字（または、いくつかのケースでは、文字）の表示を変更します。そのようなテキストをレンダリングすると、ディスプレイエンジンは、基本文字と結合文字のすべてを表しているフォントにグリフを見つけなければならないか、それは組み合わせ自体をレンダリングする必要があります。このようなレンダリングは簡単なことができますが、組み合わせたマークは、そのような同じ文字の上に表示されます2組み合わせた跡がある場合など、互いに相互作用するとき、それは時々複雑です。フォーマット文字もレンダラーがテキストを表示するような方法を変更することができます。レンダリングはまた、アラビア語やインド語スクリプトなどの基本文字、のための複雑な表示ルールを持っているいくつかのスクリプトのために困難な場合があります。
This section describes some of the standards bodies and standards that appear in discussions of internationalization in the IETF. This is an incomplete and possibly over-full list; listing too few bodies or standards can be just as politically dangerous as listing too many. Note that there are many other bodies that deal with internationalization; however, few if any of them appear commonly in IETF standards work.
このセクションでは、IETFでの国際化の議論に表示される標準化団体及び規格のいくつかを説明します。これはおそらく不完全で、過完全なリストです。少なすぎる体や基準をリストアップすることはあまりにも多くをリストと同じように政治的に危険なことができます。国際化に対処する他の多くの団体があることに注意してください。しかし、それらのいずれかのいくつかは、IETF標準化作業に一般的に表示されます。
ISO and ISO/IEC JTC 1
ISO及びISO / IEC JTC 1
The International Organization for Standardization has been involved with standards for characters since before the IETF was started. ISO is a non-governmental group made up of national bodies. Most of ISO's work in information technology is performed jointly with a similar body, the International Electrotechnical Commission (IEC) through a joint committee known as "JTC 1". ISO and ISO/IEC JTC 1 have many diverse standards in the international characters area; the one that is most used in the IETF is commonly referred to as "ISO/IEC 10646", sometimes with a specific date. ISO/IEC 10646 describes a CCS that covers almost all known written characters in use today.
国際標準化機構は、IETFが開始された前以降の文字を基準に携わってきました。 ISOは、国家機関で構成された非政府グループです。情報技術のISOの仕事のほとんどは、「JTC 1」として知られている合同委員会を通じて類似したボディ、国際電気標準会議（IEC）と共同で行っています。 ISO及びISO / IEC JTC 1には、国際的な文字領域に多くの多様な基準を持っています。ほとんどのIETFで使用されている1は、一般的に、時には特定の日付で、「ISO / IEC 10646」と呼ばれています。 ISO / IEC 10646は、今日使用されているほとんどすべての既知の書かれた文字をカバーしていCCSについて説明します。
ISO/IEC 10646 is controlled by the group known as "ISO/IEC JTC 1/ SC 2 WG2", often called "SC2/WG2" or "WG2" for short. ISO standards go through many steps before being finished, and years often go by between changes to the base ISO/IEC 10646 standard although amendments are now issued to track Unicode changes. Information on WG2, and its work products, can be found at <http://www.dkuug.dk/JTC1/SC2/WG2/>. Information on SC2, and its work products, can be found at <http://www.iso.org/iso/ standards_development/technical_committees/ list_of_iso_technical_committees/ iso_technical_committee.htm?commid=45050>
ISO / IEC 10646は、しばしば "SC2 / WG2" または略して "WG2" と呼ばれる "ISO / IEC JTC 1 / SC 2 WG2" として知られているグループによって制御されます。 ISO規格は、完成される前に多くのステップを経ると、年は、多くの場合、修正案は、現在のUnicodeが変更を追跡するために発行されているが、ベースISO / IEC 10646標準への変更の間で行きます。 WG2、およびその作業成果物に関する情報は、<http://www.dkuug.dk/JTC1/SC2/WG2/>で見つけることができます。 SC2の情報、およびその作業成果物は、<http://www.iso.org/iso/ standards_development / technical_committees / list_of_iso_technical_committees / iso_technical_committee.htm？commid = 45050>で見つけることができます
The standard comes as a base part and a series of attachments or amendments. It is available in PDF form for downloading or in a CD-ROM version. One example of how to cite the standard is given in [RFC3629]. Any standard that cites ISO/IEC 10646 needs to evaluate how to handle the versioning problem that is relevant to the protocol's needs.
標準では、ベース部と添付ファイルや修正のシリーズとして付属しています。それは、ダウンロードまたはCD-ROM版ではPDF形式で提供されています。標準を引用する方法の一例は、[RFC3629]で与えられています。 ISO / IEC 10646を引用している任意の標準的なプロトコルのニーズに関連するバージョン管理の問題をどのように処理するかを評価する必要があります。
ISO is responsible for other standards that might be of interest to protocol developers concerned about internationalization. ISO 639 [ISO639] specifies the names of languages and forms part of the basis for the IETF's Language Tag work [RFC5646]. ISO 3166 [ISO3166] specifies the names and code abbreviations for countries and territories and is used in several protocols and databases including names for country-code top level domain names. The responsibilities of ISO TC 46 on Information and Documentation <http://www.iso.org/iso/standards_development/ technical_committees/list_of_iso_technical_committees/ iso_technical_committee.htm?commid=48750> include a series of standards for transliteration of various languages into Latin characters.
ISOは、国際化を懸念プロトコル開発者を対象とあるかもしれない他の規格を担当しています。 ISO 639 [ISO639]は言語の名前を指定してIETFの言語タグの仕事[RFC5646]のための基礎の一部を形成します。 ISO 3166 [ISO3166]は国と地域の名前とコードの省略形を指定し、国コードトップレベルドメイン名の名前を含むいくつかのプロトコルとデータベースで使用されています。情報とドキュメント<http://www.iso.org/iso/standards_development/ technical_committees / list_of_iso_technical_committees / iso_technical_committee.htm？commid = 48750>のISO TC 46の責任はラテン文字へのさまざまな言語の音訳のための一連の標準が含まれます。
Another relevant ISO group was JTC 1/SC22/WG20, which was responsible for internationalization in JTC 1, such as for international string ordering. Information on WG20, and its work products, can be found at <http://www.dkuug.dk/jtc1/sc22/wg20/>. The specific tasks of SC22/WG20 were moved from SC22 into SC2, and there has been little significant activity since that occurred.
他の関連するISOグループは、このような国際的な文字列の順序付けのためのようJTC 1、で国際化を担当したJTC 1 / SC22 / WG20、でした。 WG20、およびその作業成果物に関する情報は、<http://www.dkuug.dk/jtc1/sc22/wg20/>で見つけることができます。 SC22 / WG20の特定のタスクは、SC2にSC22から移動し、それが発生したので、少し顕著な活性がありました。
Unicode Consortium
ユニコードコンソーシアム
The second important group for international character standards is the Unicode Consortium. The Unicode Consortium is a trade association of companies, governments, and other groups interested in promoting the Unicode Standard [UNICODE]. The Unicode Standard is a CCS whose repertoire and code points are identical to ISO/IEC 10646. The Unicode Consortium has added features to the base CCS that make it more useful in protocols, such as defining attributes for each character. Examples of these attributes include case conversion and numeric properties.
国際文字規格の第二の重要なグループは、Unicodeコンソーシアムです。ユニコードコンソーシアムは、企業、政府、およびUnicode標準[UNICODE]を促進する上で興味を持って他のグループの業界団体です。 Unicode標準は、そのレパートリーとコードポイントのISO / IEC 10646と同じユニコードコンソーシアムは、各文字の属性を定義するように、プロトコルにそれをより有用にするベースCCSへ機能を追加しましたれる。CCSありますこれらの属性の例としては、ケースの変換や数字のプロパティが含まれます。
The actual technical and definitional work of the Unicode Consortium is done in the Unicode Technical Committee (UTC). The terms "UTC" and "Unicode Consortium" are often treated, imprecisely, as synonymous in the IETF.
ユニコードコンソーシアムの実際の技術と、定義作業は、Unicode技術委員会（UTC）で行われます。用語は、「UTC」と「ユニコードコンソーシアムは、」多くの場合、IETFでの代名詞として、不正確、扱われます。
The Unicode Consortium publishes addenda to the Unicode Standard as Unicode Technical Reports. There are many types of technical reports at various stages of maturity. The Unicode Standard and affiliated technical reports can be found at <http://www.unicode.org/>.
ユニコードコンソーシアムは、UnicodeテクニカルレポートとしてUnicode標準に添加物を発行しています。成熟の様々な段階での技術報告書の多くの種類があります。 Unicode標準と提携して技術的なレポートは、<http://www.unicode.org/>で見つけることができます。
A reciprocal agreement between the Unicode Consortium and ISO/IEC JTC 1/SC 2 provides for ISO/IEC 10646 and The Unicode Standard to track each other for definitions of characters and assignments of code points. Updates, often in the form of amendments, to the former sometimes lag updates to the latter for a short period, but the gap has rarely been significant in recent years.
ユニコードコンソーシアムおよびISO / IEC JTC 1 / SC 2との間の相互合意が文字とコードポイントの割り当ての定義については、互いを追跡するためにISO / IEC 10646およびUnicode標準を提供します。更新は、しばしば改正の形で、元に時々短い期間のために、後者への更新を遅れるが、ギャップはめったに近年の重要なされていません。
At the time that the IETF character set policy [RFC2277] was established and the first version of this terminology specification was published, there was a strong preference in the IETF community for references to ISO/IEC 10646 (rather than Unicode) when possible. That preference largely reflected a more general IETF preference for referencing established open international standards over specifications from consortia. However, the Unicode definitions of character properties and classes are not part of ISO/IEC 10646. Because IETF specifications are increasingly dependent on those definitions (for example, see the explanation in Section 4.2) and the Unicode specifications are freely available online in convenient machine-readable form, the IETF's preference has shifted to referencing the Unicode Standard. The latter is especially important when version consistency between code points (either standard) and Unicode properties (Unicode only) is required.
IETF文字集合方針[RFC2277]が設立され、この用語仕様の最初のバージョンが発表された時点で、可能な場合（Unicodeではなく）ISO / IEC 10646への参照のためのIETFコミュニティの強い好みがありました。その好みは主にコンソーシアムからの仕様上で確立オープン国際標準を参照するための、より一般的なIETFの好みを反映しています。 IETF仕様はそれらの定義にますます依存している（例えば、4.2節での説明を参照）、Unicodeの仕様は便利な機械にオンラインで自由に利用可能であるためしかし、文字属性とクラスのUnicodeの定義は、ISO / IEC 10646の一部ではありません読取可能形式は、IETFの好みは、Unicode標準を参照するに移行しました。コードポイント（いずれかの標準）とUnicode特性（のみUnicode）の間のバージョンの整合性が必要とされる場合、後者は特に重要です。
World Wide Web Consortium (W3C)
World Wide Webコンソーシアム（W3C）
This group created and maintains the standard for XML, the markup language for text that has become very popular. XML has always been fully internationalized so that there is no need for a new version to handle international text. However, in some circumstances, XML files may be sensitive to differences among Unicode versions.
このグループが作成され、XMLの標準的な、非常に人気となっているテキストのマークアップ言語を維持します。国際的なテキストを処理するために、新しいバージョンの必要がないように、XMLは、常に完全に国際化されています。しかし、いくつかの状況では、XMLファイルは、Unicodeのバージョン間の違いに敏感です。
local and regional standards organizations
地元や地域の標準化団体
Just as there are many native CCSs and charsets, there are many local and regional standards organizations to create and support them. Common examples of these are ANSI (United States), CEN/ISSS (Europe), JIS (Japan), and SAC (China).
多くのネイティブCCSSと文字セットがあるのと同様に、多くの地方や地域の標準化団体は、それらを作成し、サポートすることがあります。これらの一般的な例としては、ANSI（米国）、CEN / ISSS（ヨーロッパ）、JIS（日本）、およびSAC（中国）です。
Characters in the ISO/IEC 10646 CCS can be expressed in many ways. Historically, "encoding forms" are both direct addressing methods, while "transformation formats" are methods for expressing encoding forms as bits on the wire. That distinction has mostly disappeared in recent years.
ISO / IEC 10646 CCSの文字は、多くの方法で表現することができます。 「変換フォーマットは」ワイヤ上のビットとして符号化形態を発現させる方法であるが、歴史的に、「符号化形態」は、両方の直接アドレッシング方法です。その区別は、主に近年では消えています。
Documents that discuss characters in the ISO/IEC 10646 CCS often need to list specific characters. RFC 5137 describes the common methods for doing so in IETF documents, and these practices have been adopted by many other communities as well.
10646件のCCSは、多くの場合、特定の文字を一覧表示する必要があるISO / IECの文字を議論する書類。 RFC 5137は、IETF文書でそのようにするための一般的な方法を説明し、これらのプラクティスは、同様に他の多くのコミュニティで採用されています。
Basic Multilingual Plane (BMP)
基本多言語面（BMP）
The BMP is composed of the first 2^16 code points in ISO/IEC 10646 and contains almost all characters in contemporary use. The BMP is also called "Plane 0".
BMPは、ISO / IEC 10646の最初の2 ^ 16のコードポイントで構成され、現代的な使用中のほぼすべての文字が含まれています。 BMPはまた、「プレーン0」と呼ばれています。
UCS-2 and UCS-4
UCS-2及びUCS-4
UCS-2 and UCS-4 are the two encoding forms historically defined for ISO/IEC 10646. UCS-2 addresses only the BMP. Because many useful characters (such as many Han characters) have been defined outside of the BMP, many people consider UCS-2 to be obsolete.
UCS-2及びUCS-4は、歴史的にISO / IEC 10646 UCS-2アドレスのみBMPために定義された2つの符号化形態です。 （例えば、多くの漢字など）多くの有用な文字がBMPの外部で定義されているので、多くの人は、UCS-2は時代遅れであると考えています。
UCS-4 addresses the entire range of code points from ISO/IEC 10646 (by agreement between ISO/IEC JTC 1 SC2 and the Unicode Consortium, a range from 0..0x10FFFF) as 32-bit values with zero padding to the left. UCS-4 is identical to UTF-32BE (without use of a BOM (see below)); UTF-32BE is now the preferred term.
UCS-4は、左にゼロパディング付き32ビット値として（ISO / IEC JTC 1 SC2およびUnicodeコンソーシアム、0..0x10FFFFの範囲との間の合意により）ISO / IEC 10646のコードポイントの全範囲に対処します。 UCS-4は、UTF-32BE（BOMを使用せずに（下記参照））と同一です。 UTF-32BEは現在、優先用語です。
UTF-8
UTF-8
UTF-8 [RFC3629] is the preferred encoding for IETF protocols. Characters in the BMP are encoded as one, two, or three octets. Characters outside the BMP are encoded as four octets. Characters from the US-ASCII repertoire have the same on-the-wire representation in UTF-8 as they do in US-ASCII. The IETF-specific definition of UTF-8 in RFC 3629 is identical to that in recent versions of the Unicode Standard (e.g., in Section 3.9 of Version 6.0 [UNICODE]).
UTF-8 [RFC3629]はIETFプロトコルの好ましい符号化です。 BMPの文字は、1つ、2つ、または3つのオクテットとしてエンコードされています。 BMP外の文字は、4つのオクテットとしてエンコードされています。彼らはUS-ASCIIでそうであるようにUS-ASCIIレパートリーからの文字はUTF-8で同じオン・ワイヤー表現を持ちます。 RFC 3629でUTF-8のIETF固有の定義は、ユニコード規格（例えば、バージョン6.0 [UNICODE]のセクション3.9で）の最近のバージョンのものと同一です。
UTF-16, UTF-16BE, and UTF-16LE
UTF-16、UTF-16BE、およびUTF-16LE
UTF-16, UTF-16BE, and UTF-16LE, three transformation formats described in [RFC2781] and defined in The Unicode Standard (Sections 3.9 and 16.8 of Version 6.0), are not required by any IETF standards, and are thus used much less often in protocols than UTF-8. Characters in the BMP are always encoded as two octets, and characters outside the BMP are encoded as four octets using a "surrogate pair" arrangement. The latter is not part of UCS-2, marking the difference between UTF-16 and UCS-2. The three UTF-16 formats differ based on the order of the octets and the presence or absence of a special lead-in ordering identifier called the "byte order mark" or "BOM".
UTF-16、UTF-16BE、およびUTF-16LE三の変換形式[RFC2781]に記載されており、Unicode標準（セクション3.9およびバージョン6.0の16.8）で定義され、任意のIETF規格で必要とされないので、あまり使用されていますあまり頻繁プロトコルでUTF-8より。 BMPの文字は、常に2つのオクテットとして符号化され、BMP外の文字は「サロゲートペア」構成を使用して4つのオクテットとして符号化されます。後者は、UTF-16、UCS-2との間の差をマーキング、UCS-2の一部ではありません。 3 UTF-16フォーマットはオクテットの順序と「バイト順マーク」や「BOM」と呼ばれる特殊なリードイン順序識別子の有無に基づいて異なります。
UTF-32
UTF-32
The Unicode Consortium and ISO/IEC JTC 1 have defined UTF-32 as a transformation format that incorporates the integer code point value right-justified in a 32-bit field. As with UTF-16, the byte order mark (BOM) can be used and UTF-32BE and UTF-32LE are defined. UTF-32 and UCS-4 are essentially equivalent and the terms are often used interchangeably.
ユニコードコンソーシアムおよびISO / IEC JTC 1は、32ビットフィールドで右寄せ整数コードポイント値を組み込んだ変換形式としてUTF-32を定義しています。 UTF-16と同様に、バイト順マーク（BOM）を用いることができ、UTF-32BEおよびUTF-32LEが定義されています。 UTF-32とUCS-4は、本質的に同等であり、用語は、しばしば互換的に使用されます。
SCSU and BOCU-1
SCSUとBOTTLE-1
The Unicode Consortium has defined an encoding, SCSU [UTR6], which is designed to offer good compression for typical text. A different encoding that is meant to be MIME-friendly, BOCU-1, is described in [UTN6]. Although compression is attractive, as opposed to UTF-8, neither of these (at the time of this writing) has attracted much interest.
ユニコードコンソーシアムは、典型的なテキストのための良好な圧縮を提供するように設計されている符号化、SCSU [UTR6]を、定義しています。 MIME向けであることを意味する、異なる符号化、BOCU-1は、[UTN6]に記載されています。圧縮はUTF-8とは反対に、魅力的ではあるが、これらのどちらも（この記事の執筆時点では）多くの関心を集めています。
The compression provided as a side effect of the Punycode algorithm [RFC3492] is heavily used in some contexts, especially IDNA [RFC5890], but imposes some restrictions. (See also Section 7.)
ピュニコードアルゴリズム[RFC3492]の副作用として提供圧縮が重く特にIDNA [RFC5890]、いくつかの文脈で使用されるが、いくつかの制限を課しています。 （また、セクション7を参照してください）
Before ISO/IEC 10646 was developed, many countries developed their own CCSs and charsets. Some of these were adopted into international standards for the relevant scripts or writing systems. Many dozen of these are in common use on the Internet today. Examples include ISO 8859-5 for Cyrillic and Shift-JIS for Japanese scripts.
ISO / IEC 10646が開発される前は、多くの国が独自のCCSSと文字セットを開発しました。これらのいくつかは、関連するスクリプトや書き込みシステムの国際標準規格に採用されました。これらの多くのダースは、インターネット上で一般的に使用され、今日です。例としては、キリル文字のISO 8859-5が含まれており、シフトJISの日本語のスクリプト用。
The official list of the registered charset names for use with IETF protocols is maintained by IANA and can be found at <http://www.iana.org/assignments/character-sets>. The list contains preferred names and aliases. Note that this list has historically contained many errors, such as names that are in fact not charsets or references that do not give enough detail to reliably map names to charsets.
IETFプロトコルで使用するために登録した文字セット名の正式なリストはIANAによって維持され、<http://www.iana.org/assignments/character-sets>で見つけることができます。リストは優先名とエイリアスが含まれています。このリストは、歴史的な事実で確実に文字セットに名前をマップするために十分な詳細を与えていないではない文字セットまたは参照されている名前など、多くのエラーを、含まれていることに注意してください。
Probably the most well-known native CCS is ASCII [US-ASCII]. This CCS is used as the basis for keywords and parameter names in many IETF protocols, and as the sole CCS in numerous IETF protocols that have not yet been internationalized. ASCII became the basis for ISO/IEC 646 which, in turn, formed the basis for many national and international standards, such as the ISO 8859 series, that mix Basic Latin characters with characters from another script.
おそらく最もよく知られているネイティブCCS [US-ASCII] ASCIIです。このCCSは、多くのIETFプロトコルでは、まだ国際化されていない数多くのIETFプロトコルにおける唯一のCCSなどのキーワードとパラメータ名の基礎として使用されています。 ASCIIは、順番に、それは別のスクリプトから文字を基本ラテン文字を混在させるようにISO 8859シリーズなど多くの国内および国際的な基準のための基礎を形成し、ISO / IEC 646の基礎となりました。
It is important to note that, strictly speaking, "ASCII" is a CCS and repertoire, not an encoding. The encoding used for ASCII in IETF protocols involves the 7-bit integer ASCII code point right-justified in an 8-bit field and is sometimes described as the "Network Virtual Terminal" or "NVT" encoding [RFC5198]. Less formally, "ASCII" and "NVT" are often used interchangeably. However, "non-ASCII" refers only to characters outside the ASCII repertoire and is not linked to a specific encoding. See Section 4.2.
厳密に言えば、「ASCII」はCCSとレパートリーではなく、エンコードされ、それを注意することが重要です。 IETFプロトコルにASCIIのために使用される符号化は右揃え8ビットのフィールドで7ビット整数ASCIIコードポイントを含み、しばしば「ネットワーク仮想端末」又は「NVT」エンコーディング[RFC5198]として記載されています。あまり正式には、「ASCII」と「NVT」は、しばしば互換的に使用されています。しかし、「非ASCIIは」唯一のASCIIレパートリー外の文字を指し、特定のエンコーディングにリンクされていません。 4.2節を参照してください。
A Unicode publication describes issues involved in mapping character data between charsets, and an XML format for mapping table data [UTR22].
Unicodeの刊行物は、文字セットとの間のマッピング文字データに関連する問題、およびマッピングテーブルデータ[UTR22]のXMLフォーマットを記述する。
This section contains terms and topics that are commonly used in character handling and therefore are of concern to people adding non-ASCII text handling to protocols. These topics are standardized outside the IETF.
このセクションでは、一般的に文字処理に使用されるため、プロトコルに非ASCIIテキスト処理を追加する人々に懸念されている用語やトピックが含まれています。これらのトピックは、IETFの外に標準化されています。
code point
コードポイント
A value in the codespace of a repertoire. For all common repertoires developed in recent years, code point values are integers (code points for ASCII and its immediate descendants were defined in terms of column and row positions of a table).
レパートリーのコードスペースの値。近年開発されたすべての一般的なレパートリーのために、コードポイント値は整数（ASCIIとその直接の子孫のためのコードポイントがテーブルの列と行位置の観点から定義された）です。
combining character
結合文字
A member of an identified subset of the coded character set of ISO/IEC 10646 intended for combination with the preceding non-combining graphic character, or with a sequence of combining characters preceded by a non-combining character. Combining characters are inherently non-spacing. <ISOIEC10646>
前述の非結合図形文字との組み合わせのために意図さISO / IEC 10646のコード化文字セットの識別されたサブセットのメンバー、または非結合文字が先行文字を組み合わせた配列を有します。文字を組み合わせることで、本質的に非スペーシングです。 <ISOIEC10646>
composite sequence or combining character sequence
複合シーケンスまたは組み合わせた文字列
A sequence of graphic characters consisting of a non-combining character followed by one or more combining characters. A graphic symbol for a composite sequence generally consists of the combination of the graphic symbols of each character in the sequence. The Unicode Standard often uses the term "combining character sequence" to refer to composite sequences. A composite sequence is not a character and therefore is not a member of the repertoire of ISO/IEC 10646. <ISOIEC10646> However, Unicode now assigns names to some such sequences especially when the names are required to match terminology in other standards [UAX34].
非結合文字からなるグラフィック文字のシーケンスは、一つ以上の結合文字が続きます。複合シーケンスのためのグラフィックシンボルは、一般的にシーケンス内の各文字の図形の組み合わせで構成されています。 Unicode標準は、多くの場合、用語「結合文字列は」複合配列を参照するために使用しています。複合配列は、文字ではなく、したがってただし、Unicodeは今の名前は、他の規格[UAX34]で用語を一致させるために必要とされる場合は特に、いくつかのこのような配列に名前を割り当て、ISO / IEC 10646 <ISOIEC10646>のレパートリーのメンバーではありません。 。
In some CCSs, some characters consist of combinations of other characters. For example, the letter "a with acute" might be a combination of the two characters "a" and "combining acute", or it might be a combination of the three characters "a", a non-destructive backspace, and an acute. In the same or other CCSs, it might be available as a single code point. The rules for combining two or more characters are called "composition rules", and the rules for taking apart a character into other characters are called "decomposition rules". The result of decomposition is called a "decomposed character"; the result of composition is usually a "precomposed character".
いくつかのCCSSでは、いくつかの文字が他の文字の組み合わせで構成されます。例えば、文字は「急性と」「」と「急性の組み合わせ」の2つの文字の組み合わせである場合もあれば、3つの文字「A」の組み合わせ、非破壊バックスペース、および急性かもしれません。同じ又は他のCCSSでは、単一のコードポイントとして利用できるかもしれません。 2文字以上を組み合わせるためのルールは、「構成ルール」と呼ばれ、他の文字に文字を離れて取るためのルールは、「分解ルール」と呼ばれています。分解の結果は、「分解文字」と呼ばれています。構図の結果は、通常、「合成済み文字」です。
normalization
正常化
Normalization is the transformation of data to a normal form, for example, to unify spelling. <UNICODE>
正規化は、例えば、スペルを統一するために、正規形へのデータの変換です。 <UNICODE>
Note that the phrase "unify spelling" in the definition above does not mean unifying different strings with the same meaning as words (such as "color" and "colour"). Instead, it means unifying different character sequences that are intended to form the same composite characters, such as "<n><combining tilde>" and "<n with tilde>" (where "<n>" is U+006E, "<combining tilde>" is U+0303, and "<n with tilde>" is U+00F1).
フレーズが上記の定義では、「スペルを統一」ことに注意してください（例えば「色」と「色」など）の言葉と同じ意味を持つ統一異なる文字列を意味するものではありません。その代わりに、そのような「<N> <合成チルダ>」と同様の複合文字を形成するよう意図された統一異なる文字配列を意味し、「<Nチルダと>」（ここで、「<n>は」 "、U + 006Eであります<チルダを組み合わせる>」U + 0303であり、 "<Nチルダと>"）U + 00F1です。
The purpose of normalization is to allow two strings to be compared for equivalence. The strings "<a><n><combining tilde><o>" and "<a><n with tilde><o>" would be shown identically on a text display device. If a protocol designer wants those two strings to be considered equivalent during comparison, the protocol must define where normalization occurs.
正規化の目的は、2つの文字列が等価性を比較するようにすることです。文字列 "aは<N> <合成チルダ> <O>" および "<A> <nのチルダ> <O>" テキスト表示装置に同一示されるであろう。プロトコルの設計者は、これらの2つの文字列が比較時に同等とみなされたい場合は、正規化が発生する場所、プロトコルが定義する必要があります。
The terms "normalization" and "canonicalization" are often used interchangeably. Generally, they both mean to convert a string of one or more characters into another string based on standardized rules. However, in Unicode, "canonicalization" or similar terms are used to refer to a particular type of normalization equivalence ("canonical equivalence" in contrast to "compatibility equivalence"), so the term should be used with some care. Some CCSs allow multiple equivalent representations for a written string; normalization selects one among multiple equivalent representations as a base for reference purposes in comparing strings. In strings of text, these rules are usually based on decomposing combined characters or composing characters with combining characters. Unicode Standard Annex #15 [UTR15] describes the process and many forms of normalization in detail. Normalization is important when comparing strings to see if they are the same.
用語「正規化」と「正規化」は、しばしば互換的に使用されています。一般的には、どちらも標準化されたルールに基づいて、別の文字列に1文字以上の文字列を変換することを意味します。しかし、Unicodeで、「正規化」または類似の用語は正規等価の特定のタイプ（「互換性等価」とは対照的に、「標準的な同値」）を指すために使用されているので、この用語は、いくつか注意して使用すべきです。いくつかのCCSSが書かれた文字列に対して複数の同等の表現が可能。正規化は、文字列を比較するに、参照目的のためのベースとして、複数の同等の表現のうちの一つを選択します。テキストの文字列では、これらのルールは通常、組み合わせ文字を分解したり、文字を組み合わせて文字を構成するに基づいています。 Unicode規格付属書＃15 [UTR15]細部の処理および正規化の多くの形態を記載しています。それらが同じであるかどうかを確認するために、文字列を比較するときに正規化は重要です。
The Unicode NFC and NFD normalizations support canonical equivalence; NFKC and NFKD support canonical and compatibility equivalence.
UnicodeのNFCとNFD正規化は、標準的な同値をサポートしています。 NFKCとNFKDは、標準的な互換性と同値をサポートしています。
case
場合
Case is the feature of certain alphabets where the letters have two (or occasionally more) distinct forms. These forms, which may differ markedly in shape and size, are called the uppercase letter (also known as capital or majuscule) and the lowercase letter (also known as small or minuscule). Case mapping is the association of the uppercase and lowercase forms of a letter. <UNICODE>
ケースは、文字が2つ（または時にはそれ以上）の異なる形態を有する特定のアルファベットの特徴です。形状及び大きさが著しく異なることがあり、これらの形態は、大文字（また、資本又はmajusculeとしても知られる）と小文字（も小さいか微小としても知られる）と呼ばれます。ケースマッピングは、文字の大文字と小文字のフォームの団体です。 <UNICODE>
There is usually (but not always) a one-to-one mapping between the same letter in the two cases. However, there are many examples of characters that exist in one case but for which there is no corresponding character in the other case or for which there is a special mapping rule, such as the Turkish dotless "i", some Greek characters with modifiers, and characters like the German Sharp S (Eszett) and Greek Final Sigma that traditionally do not have uppercase forms. Case mapping can even be dependent on locale or language. Converting text to have only a single case, primarily for comparison purposes, is called "case folding". Because of the various unusual cases, case mapping can be quite controversial and some case folding algorithms even more so. For example, some programming languages such as Java have case-folding algorithms that are locale-sensitive; this makes those algorithms incredibly resource-intensive and makes them act differently depending on the location of the system at the time the algorithm is used.
2例では、同じ文字の間に1対1のマッピングは、（常にではない）通常あります。しかし、修飾子と「I」、一部のギリシャ語の文字が一つのケース内に存在する文字の多くの例があるが、そのために、他の場合には対応する文字が存在しないか、そのためにこのようなトルコのドットなしとして、特別なマッピングルールがあり、そして伝統的に大文字のフォームを持っていないドイツのシャープS（エスツェット）とギリシャ語の最終シグマのような文字。ケースマッピングは、さらにロケールまたは言語に依存することができます。テキストは主に比較のために、ただ一つのケースを持つように変換する、「ケースの折りたたみ」と呼ばれています。そのため、様々な珍しいケースで、ケースマッピングは、それ以上に、非常に物議とアルゴリズムを折りたたみ、いくつかのケースであることができます。例えば、Javaなどのいくつかのプログラミング言語は、ロケールに依存している場合、折り畳みアルゴリズムを有します。これは、これらのアルゴリズムは非常にリソースを集中的になり、それらはアルゴリズムが使用されている時にシステムの場所に応じて異なる動作になります。
sorting and collation
並べ替えと照合
Collating is the process of ordering units of textual information. Collation is usually specific to a particular language or even to a particular application or locale. It is sometimes known as alphabetizing, although alphabetization is just a special case of sorting and collation. <UNICODE>
照合は、テキスト情報の単位を注文するプロセスです。照合は、特定の言語に、あるいは特定のアプリケーションまたはロケールに通常は固有のものです。それは時々alphabetizationは、ソートと照合するだけの特殊なケースではあるが、アルファベット順に並べとして知られています。 <UNICODE>
Collation is concerned with the determination of the relative order of any particular pair of strings, and algorithms concerned with collation focus on the problem of providing appropriate weighted keys for string values, to enable binary comparison of the key values to determine the relative ordering of the strings.
照合は、文字列の任意の特定のペアの相対的な順序の決意に関係し、文字列値に適切な重み付きキーを提供するという課題に照合フォーカスに関するアルゴリズムは、の相対的な順序を決定するために、キー値のバイナリ比較を可能にするために文字列。
The relative orders of letters in collation sequences can differ widely based on the needs of the system or protocol defining the collation order. For example, even within ASCII characters, there are two common and very different collation orders: "A, a, B, b,..." and "A, B, C, ..., Z, a, b,...", with additional variations for lowercase first and digits before and after letters.
照合配列中の文字の相対次数は、照合順序を定義するシステムまたはプロトコルのニーズに基づいて大きく異なることができます。例えば、偶数ASCII文字内に、2つの一般的な非常に異なる照合順序があります。 "A、B、B、..." 及び「A、B、C、...、Z、A、B ,. .. "、小文字の最初の文字と前後の数字のための追加のバリエーションを持ちます。
In practice, it is rarely necessary to define a collation sequence for characters drawn from different scripts, but arranging such sequences so as to not surprise users is usually particularly problematic.
実際には、異なるスクリプトから引き出された文字のための照合順序を定義する必要はほとんどありませんが、ユーザーを驚かないように、このような配列を配置することは、通常は特に問題です。
Sorting is the process of actually putting data records into specified orders, according to criteria for comparison between the records. Sorting can apply to any kind of data (including textual data) for which an ordering criterion can be defined. Algorithms concerned with sorting focus on the problem of performance (in terms of time, memory, or other resources) in actually putting the data records into the desired order.
ソートは、レコード間の比較のための基準に従って、実際に指定された次数にデータレコードを置くのプロセスです。ソート順序の基準を定義できる（テキストデータを含む）あらゆる種類のデータにも適用することができます。実際には、所望の順序にデータレコードを入れに（時間、メモリ、または他のリソースの点で）パフォーマンスの問題に焦点をソーティングに関するアルゴリズム。
A sorting algorithm for string data can be internationalized by providing it with the appropriate collation-weighted keys corresponding to the strings to be ordered.
文字列データのソートアルゴリズムを注文するための文字列に対応する適切な照合加重キーでそれを提供することで、国際化することができます。
Many processes have a need to order strings in a consistent (sorted) sequence. For only a few CCS/CES combinations, there is an obvious sort order that can be applied without reference to the linguistic meaning of the characters: the code point order is sufficient for sorting. That is, the code point order is also the order that a person would use in sorting the characters. For many CCS/CES combinations, the code point order would make no sense to a person and therefore is not useful for sorting if the results will be displayed to a person.
多くのプロセスは、一貫性のある（ソート）の順序で文字列を注文する必要があります。ほんの数CCS / CESの組み合わせの場合は、文字の言語的な意味を参照することなく適用することができ明白なソート順序があります：コード・ポイントの順序は、ソートのために十分です。これは、コード・ポイントの順序は、人が文字を並べ替えに使用することもオーダーである、です。多くのCCS / CESの組み合わせの場合は、コード・ポイントの順序は、人に意味をなさないので、結果は人に表示される場合は、ソートのために有用ではありませんでしょう。
Code point order is usually not how any human educated by a local school system expects to see strings ordered; if one orders to the expectations of a human, one has a "language-specific" or "human language" sort. Sorting to code point order will seem inconsistent if the strings are not normalized before sorting because different representations of the same character will sort differently. This problem may be smaller with a language-specific sort.
コード・ポイントの順序は、地元の学校制度で教育を受けたすべての人が注文した文字列を見ることを期待どのように通常ではありません。人間の期待に1つのオーダー場合、一つは「言語固有」または「人間の言語」の並べ替えを持っています。文字列が同じ文字の異なる表現がソート異なりますので、並べ替えの前に正規化されていない場合は、コード・ポイント順にソートすることは矛盾するように見えるだろう。この問題は、言語固有のソートと小さくてもよいです。
code table
コード表
A code table is a table showing the characters allocated to the octets in a code. <ISOIEC10646>
符号テーブルは、コードのオクテットに割り当てられた文字を示す表です。 <ISOIEC10646>
Code tables are also commonly called "code charts".
コードテーブルは一般に「コードチャート」と呼ばれています。
The following definitions of types of characters do not clearly delineate each character into one type, nor do they allow someone to accurately predict what types would apply to a particular character. The definitions are intended for application designers to help them think about the many (sometimes confusing) properties of text.
文字の種類の以下の定義が明確にいずれかのタイプに各文字を描くていない、また彼らは誰かが正確に特定の文字に適用される種類を予測することができます。定義は、それらがテキストの多くの（時には混乱）の性質について考えるのを助けるためにアプリケーション設計者のために意図されています。
alphabetic
アルファベット順の
An informative Unicode property. Characters that are the primary units of alphabets and/or syllabaries, whether combining or non-combining. This includes composite characters that are canonical equivalents to a combining character sequence of an alphabetic base character plus one or more combining characters: letter digraphs; contextual variants of alphabetic characters; ligatures of alphabetic characters; contextual variants of ligatures; modifier letters; letterlike symbols that are compatibility equivalents of single alphabetic letters; and miscellaneous letter elements. <UNICODE>
有益なUnicodeのプロパティ。結合または非結合かどうかをアルファベットおよび/または音節の主要部である文字。これはアルファベット基本文字を加えた一つ以上の結合文字の組み合わせの文字列に対して正規等価物である複合文字含む：文字ダイグラフと、アルファベット文字の文脈の変種。アルファベット文字の合字。合字の文脈の変種。修飾子手紙;単一アルファベットの互換性の等価物であるシンボルletterlike。およびその他の文字要素。 <UNICODE>
ideographic
表意
Any symbol that primarily denotes an idea (or meaning) in contrast to a sound (or pronunciation), for example, a symbol showing a telephone or the Han characters used in Chinese, Japanese, and Korean. <UNICODE>
主に音（または発音）とは対照的にアイデア（または意味）を示す任意のシンボル、例えば、中国語、日本語、韓国語で使用される電話や漢字を示すシンボル。 <UNICODE>
While Unicode and many other systems use this term to refer to all Han characters, strictly speaking not all of those characters are actually ideographic. Some are pictographic (such as the telephone example above), some are used phonetically, and so on. However, the convention is to describe the script as ideographic as contrasted to alphabetic.
Unicodeと他の多くのシステムは、厳密にこれらの文字をすべてではないに言えば、すべての漢字を参照するためにこの用語を使用していますが、実際に表意文字です。いくつかは、（例えば、上記の電話の例として）絵文字一部を音声的に使用される、などです。しかし、規則はアルファベットとは対照的に表意文字としてスクリプトを記述することです。
digit or number
数字または数
All modern writing systems use decimal digits in some form; some older ones use non-positional or other systems. Different scripts may have their own digits. Unicode distinguishes between numbers and other kinds of characters by assigning a special General Category value to them and subdividing that value to distinguish between decimal digits, letter digits, and other digits. <UNICODE>
すべての近代的な書き込みシステムが何らかの形で小数点以下の桁を使用します。一部の古いものは非位置または他のシステムを使用します。異なるスクリプトは、独自の桁を有することができます。 Unicodeは、彼らに特別な汎用カテゴリ値を代入し、小数点以下の桁数、文字の数字、およびその他の数字を区別するために、その値を細分化することにより、数字や文字の他の種類を区別します。 <UNICODE>
punctuation
句読
Characters that separate units of text, such as sentences and phrases, thus clarifying the meaning of the text. The use of punctuation marks is not limited to prose; they are also used in mathematical and scientific formulae, for example. <UNICODE>
したがって、テキストの意味を明確にする、などの文章やフレーズなどのテキストの単位を、区切り文字。句読点の使用は、散文に限定されるものではありません。彼らはまた、例えば、数学や科学の式で使用されています。 <UNICODE>
symbol
シンボル
One of a set of characters other than those used for letters, digits, or punctuation, and representing various concepts generally not connected to written language use per se. <RFC6365>
文字、数字、または句読点のために使用されるもの以外に、様々な概念を表す文字のセットの1つは、一般的にそれ自体が書かれた言語使用に接続されていません。 <RFC6365>
Examples of symbols include characters for mathematical operators, symbols for optical character recognition (OCR), symbols for box-drawing or graphics, as well as symbols for dingbats, arrows, faces, and geometric shapes. Unicode has a property that identifies symbol characters.
シンボルの例としては、算術演算子、光学式文字認識（OCR）の記号、ボックス描画やグラフィックのシンボル、並びに飾りの記号、矢印、顔、及び幾何学的形状のための文字を含みます。 Unicodeは、記号文字を識別する性質を持っています。
nonspacing character
ノンスペーシング文字
A combining character whose positioning in presentation is dependent on its base character. It generally does not consume space along the visual baseline in and of itself. <UNICODE>
そのポジショニングプレゼンテーションの結合文字は、その基本文字に依存しています。これは、一般的に、それ自体の視覚的なベースラインに沿ってスペースを消費しません。 <UNICODE>
A combining acute accent (U+0301) is an example of a nonspacing character.
合成急性アクセント（U + 0301）ノンスペーシング文字の一例です。
diacritic
分音
A mark applied or attached to a symbol to create a new symbol that represents a modified or new value. They can also be marks applied to a symbol irrespective of whether they change the value of that symbol. In the latter case, the diacritic usually represents an independent value (for example, an accent, tone, or some other linguistic information). Also called diacritical mark or diacritical. <UNICODE>
マークは、適用または修飾された、または新しい値を表す新しいシンボルを作成するシンボルに取り付けられています。彼らはまたかかわらず、彼らは、そのシンボルの値を変更するかどうかのシンボルに適用されたマークであってもよいです。後者の場合、発音区別符号は、通常、（例えば、アクセント、トーン、またはいくつかの他の言語情報）の独立した値を表します。また、ダイアクリティカルマークや発音区別と呼ばれます。 <UNICODE>
control character
制御文字
The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F. The basic space character, U+0020, is often considered as a control character as well, making the total number 66. They are also known as control codes. In terminology adopted by Unicode from ASCII and the ISO 8859 standards, these codes are treated as belonging to three ranges: "C0" (for U+0000..U+001F), "C1" (for U+0080...U+009F), and the single control character "DEL" (U+007F). <UNICODE>
範囲U + 0000..U + 001FおよびU + 007F..U + 009Fで65の文字。基本的な空白文字、U + 0020は、多くの場合、彼らはまた、制御コードとして知られている総数は66を作り、同様に制御文字として考えられています。 ASCIIおよびISO 8859の標準からUnicodeで採用された用語では、これらのコードは、3つの範囲に属するものとして扱われる：（U + 0000..U + 001Fのための） "C0"、U + 0080のための "C1"（... U + 009F）、および単一の制御文字 "DEL"（U + 007F）。 <UNICODE>
Occasionally, in other vocabularies, the term "control character" is used to describe any character that does not normally have an associated glyph; it is also sometimes used for device control sequences [ISO6429]. Neither of those usages is appropriate to internationalization terminology in the IETF.
時折、他のボキャブラリでは、用語「制御文字」は、通常関連するグリフを持たない任意の文字を記述するために使用されます。また、時には、デバイス制御配列[ISO6429]のために使用されます。これらの用途のいずれも、IETFでの用語を国際化することが適当です。
formatting character
文字の書式設定
Characters that are inherently invisible but that have an effect on the surrounding characters. <UNICODE>
本質的に目に見えないですが、文字は、周囲の文字に影響を与えます。 <UNICODE>
Examples of formatting characters include characters for specifying the direction of text and characters that specify how to join multiple characters.
書式文字の例としては、複数の文字を結合する方法を指定したテキストと文字の方向を指定するための文字が含まれています。
compatibility character or compatibility variant
互換性の文字や互換性の変異体
A graphic character included as a coded character of ISO/IEC 10646 primarily for compatibility with existing coded character sets. <ISOIEC10646)>
図形文字は、主に既存の符号化文字集合との互換性のためのISO / IEC 10646の符号化文字として含まれています。 <ISOIEC10646）>
The Unicode definition of compatibility charter also includes characters that have been incorporated for other reasons. Their list includes several separate groups of characters included for compatibility purposes: halfwidth and fullwidth characters used with East Asian scripts, Arabic contextual forms (e.g., initial or final forms), some ligatures, deprecated formatting characters, variant forms of characters (or even copies of them) for particular uses (e.g., phonetic or mathematical applications), font variations, CJK compatibility ideographs, and so on. For additional information and the separate term "compatibility decomposable character", see the Unicode standard.
互換性のチャーターのUnicodeの定義はまた、他の理由のために組み込まれている文字を含んでいます。書式設定文字、文字（あるいはコピーの変異型を、東アジアのスクリプトで使用さ半角と全角文字、アラビア語文脈形態（例えば、初期または最終の形）、いくつかの合字は非推奨：自分のリストには、文字のいくつかの別々のグループには互換性の目的のために含ま含まその上、特定の用途（例えば、発音や数学の応用）、フォントの変化、CJK互換表意文字、およびそれらのための）。追加情報や別の用語「互換性の分解文字」の場合は、Unicode標準を参照してください。
For example, U+FF01 (FULLWIDTH EXCLAMATION MARK) was included for compatibility with Asian charsets that include full-width and half-width ASCII characters.
例えば、U + FF01（FULLWIDTH感嘆符）は全角と半角ASCII文字を含むアジアの文字セットとの互換性のために含まれていました。
Some efforts in the IETF have concluded that it would be useful to support mapping of some groups of compatibility equivalents and not others (e.g., supporting or mapping width variations while preserving or rejecting mathematical variations). See the IDNA Mapping document [RFC5895] for one example.
IETFのいくつかの努力が、いくつかの互換性の同等物のグループとしない他のマッピングをサポートするために有用であると結論付けている（例えば、保存又は数学的な変動を排除しながら支持またはマッピング幅の変動）。 1例えばIDNAマッピングドキュメント[RFC5895]を参照してください。
Especially as existing IETF standards are internationalized, it is necessary to describe collections of characters including especially various subsets of Unicode. Because Unicode includes ways to code substantially all characters in contemporary use, subsets of the Unicode repertoire can be a useful tool for defining these collections as repertoires independent of specific Unicode coding.
既存のIETF標準が国際化され、特にとして、Unicodeの特に種々のサブセットを含む文字の集合を記述する必要があります。 Unicodeは、実質的に現代的な使用中のすべての文字をコーディングする方法を含んでいるので、ユニコードレパートリーのサブセットが特定のUnicodeコードの独立レパートリーとして、これらのコレクションを定義するための有用なツールであることができます。
However specific collections are defined, it is important to remember that, while older CCSs such as ASCII and the ISO 8859 family are close-ended and fixed, Unicode is open-ended, with new character definitions, and often new scripts, being added every year or so. So, while, e.g., an ASCII subset, such as "uppercase letters", can be specified as a range of code points (4/1 to 5/10 for that example), similar definitions for Unicode either have to be specified in terms of Unicode properties or are very dependent on Unicode versions (and the relevant version must be identified in any specification). See the IDNA code point specification [RFC5892] for an example of specification by combinations of properties.
しかし、特定のコレクションが定義されている、そのようなASCIIやISO 8859ファミリなどの古いCCSSがクローズエンドと固定されている一方で、Unicodeは新しい文字定義で、オープンエンド型であり、多くの場合、新しいスクリプトは、すべてのを追加され、それを覚えておくことが重要です1年かそこら。例えば、ASCIIのサブセット、例えば、「大文字」としては、Unicodeのコードポイント（4/1すなわち例えば5/10まで）、同様の定義の範囲として指定することができつつ、いずれかの用語で指定しなければなりませんUnicodeプロパティのまたはUnicodeバージョン（及び任意明細書で識別される必要があり、関連するバージョン）に非常に依存しています。特性の組み合わせにより仕様の例えばIDNAコードポイント仕様[RFC5892]を参照。
Some terms are commonly used in the IETF to define character ranges and subsets. Some of these are imprecise and can cause confusion if not used carefully.
いくつかの用語は、一般的に文字範囲とサブセットを定義するためにIETFで使用されています。これらのいくつかは不明確であり、慎重に使用されていない場合は、混乱を引き起こす可能性があります。
non-ASCII
非ASCII
The term "non-ASCII" strictly refers to characters other than those that appear in the ASCII repertoire, independent of the CCS or encoding used for them. In practice, if a repertoire such as that of Unicode is established as context, "non-ASCII" refers to characters in that repertoire that do not appear in the ASCII repertoire. "Outside the ASCII repertoire" and "outside the ASCII range" are practical, and more precise, synonyms for "non-ASCII".
用語「非ASCIIは、」厳密に彼らのために使用さCCSやエンコーディングとは無関係に、ASCIIレパートリーに表示されているもの以外の文字を指します。このようユニコードのものとレパートリーはコンテキストとして確立されている場合、実際には、「非ASCIIは、」ASCIIレパートリーには表示されません。そのレパートリーの中の文字を指します。 「ASCIIレパートリー外側」および「ASCII範囲外」は、「非ASCII」の同義語実用的であり、そしてより正確。
letters
手紙
The term "letters" does not have an exact equivalent in the Unicode standard. Letters are generally characters that are used to write words, but that means very different things in different languages and cultures.
用語「手紙は、」Unicode標準で、完全に同等ではありません。文字は、一般的に単語を書くために使用されている文字であるが、それは異なる言語や文化に非常に異なるものを意味します。
Although the IETF does not standardize user interfaces, many protocols make assumptions about how a user will enter or see text that is used in the protocol. Internationalization challenges assumptions about the type and limitations of the input and output devices that may be used with applications that use various protocols. It is therefore useful to consider how users typically interact with text that might contain one or more non-ASCII characters.
IETFは、ユーザーインターフェイスを標準化していませんが、多くのプロトコルは、ユーザーが入力したかのプロトコルで使用されるテキストが表示されます方法についての仮定を行います。国際化は、様々なプロトコルを使用するアプリケーションで使用することができる入出力装置の種類および制限についての仮定に挑戦します。これにより、ユーザーは通常、1つまたは複数の非ASCII文字が含まれている可能性があるテキストとの対話方法を検討するために有用です。
input methods
入力方法
An input method is a mechanism for a person to enter text into an application. <RFC6365>
入力方法は、アプリケーションにテキストを入力する人のためのメカニズムです。 <RFC6365>
Text can be entered into a computer in many ways. Keyboards are by far the most common device used, but many characters cannot be entered on typical computer keyboards in a single stroke. Many operating systems come with system software that lets users input characters outside the range of what is allowed by keyboards.
テキストは、多くの方法でコンピュータに入力することができます。キーボードは、これまでで使用される最も一般的なデバイスですが、多くの文字は、単一のストロークで、一般的なコンピュータのキーボードで入力することはできません。多くのオペレーティングシステムは、キーボードによって許可されているものの範囲外のユーザー入力文字をすることができ、システムソフトウェアが付属しています。
For example, there are dozens of different input methods for Han characters in Chinese, Japanese, and Korean. Some start with phonetic input through the keyboard, while others use the number of strokes in the character. Input methods are also needed for scripts that have many diacritics, such as European or Vietnamese characters that have two or three diacritics on a single alphabetic character.
例えば、中国語、日本語、韓国語での漢字のためのさまざまな入力方法の数十があります。他の人が文字にストローク数を使用しながら、いくつかは、キーボードからの入力表音で始まります。インプットメソッドはまた、単一のアルファベット文字の上に二、三分音符号を持っているヨーロッパやベトナム語の文字など、多くの発音区別符号を、持っているスクリプトのために必要とされます。
The term "input method editor" (IME) is often used generically to describe the tools and software used to deal with input of characters on a particular system.
用語「入力メソッドエディタ」（IME）は、多くの場合、特定のシステム上の文字の入力に対処するために使用するツールやソフトウェアを記述するために一般的に使用されます。
rendering rules
ルールをレンダリング
A rendering rule is an algorithm that a system uses to decide how to display a string of text. <RFC6365>
レンダリング・ルールは、システムがテキストの文字列を表示する方法を決定するために使用するアルゴリズムです。 <RFC6365>
Some scripts can be directly displayed with fonts, where each character from an input stream can simply be copied from a glyph system and put on the screen or printed page. Other scripts need rules that are based on the context of the characters in order to render text for display.
いくつかのスクリプトは、直接入力ストリームからの各文字は、単にグリフシステムからコピーされ、画面や印刷されたページに置くことができ、フォント、で表示することができます。他のスクリプトは、表示用テキストをレンダリングするために、文字のコンテキストに基づいているルールを必要としています。
Some examples of these rendering rules include:
これらのレンダリングルールのいくつかの例は次のとおりです。
* Scripts such as Arabic (and many others), where the form of the letter changes depending on the adjacent letters, whether the letter is standing alone, at the beginning of a word, in the middle of a word, or at the end of a word. The rendering rules must choose between two or more glyphs.
*このよう書簡の形式が文字が単語の途中で、単語の冒頭で、一人で立っているかどうか、またはの終わりに、隣接する文字に応じて変化アラビア語（および多くの他）、などのスクリプト単語。レンダリング規則は、二つ以上のグリフの間で選択する必要があります。
* Scripts such as the Indic scripts, where consonants may change their form if they are adjacent to certain other consonants or may be displayed in an order different from the way they are stored and pronounced. The rendering rules must choose between two or more glyphs.
*それらが特定の他の子音に隣接している、またはそれらが記憶され、発音される方法とは異なる順序で表示されてもよい場合に子音がその形状を変更することができるインド語スクリプトなどのスクリプト。レンダリング規則は、二つ以上のグリフの間で選択する必要があります。
* Arabic and Hebrew scripts, where the order of the characters displayed are changed by the bidirectional properties of the alphabetic and other characters and with right-to-left and left-to-right ordering marks. The rendering rules must choose the order that characters are displayed.
*表示される文字の順番はアルファベットやその他の文字の双方向の性質により、右から左、左から右への注文マークで変更されているアラビア語とヘブライ語のスクリプト、。レンダリング規則は文字が表示される順序を選択する必要があります。
* Some writing systems cannot have their rendering rules suitably defined using mechanisms that are now defined in the Unicode Standard. None of those languages are in active non-scholarly use today.
*一部の書き込みシステムは、そのレンダリングルールが適切に今Unicode標準で定義されているメカニズムを使用して定義することはできません。これらの言語のいずれもアクティブ非学術今日使用されません。
* Many systems use a special rendering rule when they lack a font or other mechanism for rendering a particular character correctly. That rule typically involves substitution of a small open box or a question mark for the missing character. See "undisplayable character" below.
彼らは正確に特定の文字を描画するためのフォントや他のメカニズムが欠けているとき*多くのシステムでは、特殊なレンダリングルールを使用しています。そのルールは、一般的に小さなオープンボックスまたは不足している文字の疑問符の置換を含みます。下の「表示不可能な文字」を参照してください。
graphic symbol
グラフィックシンボル
A graphic symbol is the visual representation of a graphic character or of a composite sequence. <ISOIEC10646>
グラフィックシンボルは、図形文字のか、複合シーケンスを視覚的に表現したものです。 <ISOIEC10646>
font
作ります
A font is a collection of glyphs used for the visual depiction of character data. A font is often associated with a set of parameters (for example, size, posture, weight, and serifness), which, when set to particular values, generates a collection of imagable glyphs. <UNICODE>
フォントは、文字データを視覚的に描写するために使用されたグリフのコレクションです。フォントは、多くの場合、特定の値に設定され、パラメータ（例えば、大きさ、姿勢、重量、及びserifness）のセットに関連付けられている、画像形成可能なグリフの集合を生成します。 <UNICODE>
The term "font" is often used interchangeably with "typeface". As historically used in typography, a typeface is a family of one or more fonts that share a common general design. For example, "Times Roman" is actually a typeface, with a collection of fonts such as "Times Roman Bold", "Times Roman Medium", "Times Roman Italic", and so on. Some sources even consider different type sizes within a typeface to be different fonts. While those distinctions are rarely important for internationalization purposes, there are exceptions. Those writing specifications should be very careful about definitions in cases in which the exceptions might lead to ambiguity.
用語「フォント」は、多くの場合、「書体」と交換可能に使用されます。歴史的タイポグラフィで使用されるように、書体は、共通の一般的な設計を共有する1つのまたは複数のフォントファミリです。たとえば、「タイムズローマン」は、「タイムズローマン太字」、「タイムズローマン中」、「タイムズローマンイタリック」などとして、実際のフォントのコレクションを持つ書体、です。いくつかのソースは、異なるフォントであることを書体内の異なるタイプのサイズを考えます。これらの区別は、国際化の目的のために稀に重要ですが、例外があります。これらの書き込み仕様は例外が曖昧につながる可能性のある場合の定義については非常に慎重でなければなりません。
bidirectional display
双方向ディスプレイ
The process or result of mixing left-to-right oriented text and right-to-left oriented text in a single line is called bidirectional display, often abbreviated as "bidi". <UNICODE>
左から右方向のテキストと一列に右から左方向のテキストを混合するプロセスまたは結果は、しばしば「双方向」と略記する、双方向ディスプレイと呼ばれています。 <UNICODE>
Most of the world's written languages are displayed left-to-right. However, many widely-used written languages such as ones based on the Hebrew or Arabic scripts are displayed primarily right-to-left (numerals are a common exception in the modern scripts). Right-to-left text often confuses protocol writers because they have to keep thinking in terms of the order of characters in a string in memory, an order that might be different from what they see on the screen. (Note that some languages are written both horizontally and vertically and that some historical ones use other display orderings.)
世界の書かれた言語のほとんどは、左から右に表示されます。しかし、ヘブライ語やアラビア語のスクリプトに基づいて、そのようなものとして、多くの広く使用されている書かれた言語は主に右から左に表示されます（数字は、現代のスクリプトで一般的な例外です）。彼らは、メモリ内の文字列内の文字の順序の観点で考えて、彼らが画面に表示されるものと異なる場合があります順序を維持する必要がありますので、右から左のテキストは、多くの場合、プロトコルの作家を混乱させる。 （水平方向と垂直方向の両方といくつかの歴史的なものは、他の表示順序を使用することをいくつかの言語が書かれていることに注意してください。）
Further, bidirectional text can cause confusion because there are formatting characters in ISO/IEC 10646 that cause the order of display of text to change. These explicit formatting characters change the display regardless of the implicit left-to-right or right-to-left properties of characters. Text that might contain those characters typically requires careful processing before being sorted or compared for equality.
テキストの表示の順序を変更することが原因とISO / IEC 10646での書式設定の文字があるので、さらに、双方向テキストは、混乱を引き起こす可能性があります。これらの明示的な書式文字は関係なく、文字の左から右への暗黙的または右から左のプロパティの表示を変更します。一般的にこれらの文字が含まれている可能性があるテキストは平等のためのソートや比較される前に慎重な処理が必要となります。
It is common to see strings with text in both directions, such as strings that include both text and numbers, or strings that contain a mixture of scripts.
テキストや数字、またはスクリプトの混合物を含む文字列の両方が含まれる文字列として両方向のテキストを含む文字列を、参照するのが一般的です。
Unicode has a long and incredibly detailed algorithm for displaying bidirectional text [UAX9].
Unicodeは、双方向テキスト[UAX9]を表示するために長いと信じられないほど詳細なアルゴリズムを持っています。
undisplayable character
表示不可能な文字
A character that has no displayable form. <RFC6365>
何も表示可能な形式を持っていない文字。 <RFC6365>
For instance, the zero-width space (U+200B) cannot be displayed because it takes up no horizontal space. Formatting characters such as those for setting the direction of text are also undisplayable. Note, however, that every character in [UNICODE]
それは水平方向のスペースを占有しないので、例えば、ゼロ幅スペース（U + 200B）を表示することができません。そのようなテキストの方向を設定するためのものとの書式文字も表示不可能です。 [UNICODE]のすべての文字があることに注意してください
has a glyph associated with it, and that the glyphs for undisplayable characters are enclosed in a dashed square as an indication that the actual character is undisplayable.
それに関連するグリフを持っており、表示不可能の文字のグリフが実際の文字が表示不能であることを示すものとして、破線の四角で囲まれています。
The property of a character that causes it to be undisplayable is intrinsic to its definition. Undisplayable characters can never be displayed in normal text (the dashed square notation is used only in special circumstances). Printable characters whose Unicode definitions are associated with glyphs that cannot be rendered on a particular system are not, in this sense, undisplayable.
それは表示不可能であることを原因と文字のプロパティは、その定義に固有のものです。表示不可能の文字は、通常のテキスト（点線の四角の表記は、特殊な状況でのみ使用されている）で表示することはできません。そのユニコード定義は、特定のシステム上でレンダリングすることができないグリフに関連付けられる印刷可能な文字は、この意味ではない表示不可能。
writing style
文体
Conventions of writing the same script in different styles. <RFC6365>
異なるスタイルで同じスクリプトを書くの表記。 <RFC6365>
Different communities using the script may find text in different writing styles difficult to read and possibly unintelligible. For example, the Perso-Arabic Nastalique writing style and the Arabic Naskh writing style both use the Arabic script but have very different renderings and are not mutually comprehensible. Writing styles may have significant impact on internationalization; for example, the Nastalique writing style requires significantly more line height than Naskh writing style.
スクリプトを使用して、異なるコミュニティは異なる書体のテキストは読みにくく、おそらく理解できないかもしれません。例えば、Perso - アラビア語Nastaliqueの文体とアラビア語ナスフ体の文体は、アラビア語のスクリプトを使用しますが、非常に異なるレンダリングを持ち、相互に理解されないの両方。スタイルを書くのは国際化に大きな影響を与える可能性があります。例えば、Nastaliqueの文体はナスフ体の文体よりも有意に多くの行の高さが必要です。
Many IETF protocols started off being fully internationalized, while others have been internationalized as they were revised. In this process, IETF members have seen patterns in the way that many protocols use text. This section describes some specific protocol interactions with text.
それらが修正されたとして、他の人が国際化されているが、多くのIETFプロトコルは、完全に国際化されてスタートを切りました。このプロセスでは、IETFのメンバーは、多くのプロトコルは、テキストを使用するような方法でパターンを見てきました。このセクションでは、テキストといくつかの特定のプロトコルの相互作用を記述する。
protocol elements
プロトコル要素
Protocol elements are uniquely named parts of a protocol. <RFC6365>
プロトコル要素は、一意のプロトコルの部分を命名しています。 <RFC6365>
Almost every protocol has named elements, such as "source port" in TCP. In some protocols, the names of the elements (or text tokens for the names) are transmitted within the protocol. For example, in SMTP and numerous other IETF protocols, the names of the verbs are part of the command stream. The names are thus part of the protocol standard. The names of protocol elements are not normally seen by end users, and it is rarely appropriate to internationalize protocol element names (even while the elements themselves can be internationalized).
ほぼすべてのプロトコルはTCPで、このような「ソースポート」などの要素を、名付けました。いくつかのプロトコルでは、要素（または名前のテキストトークン）の名前は、プロトコル内で送信されます。たとえば、SMTPおよび多数の他のIETFプロトコルでは、動詞の名前は、コマンドストリームの一部です。名前は、このようにプロトコル標準の一部です。プロトコル要素の名前は、通常、エンドユーザによって見られない、（さえ要素ながら自体が国際化することができる）プロトコル要素名を国際化するまれ適切です。
name spaces
名前空間
A name space is the set of valid names for a particular item, or the syntactic rules for generating these valid names. <RFC6365>
名前空間には、特定の項目のための有効な名前、またはこれらの有効な名前を生成するための構文規則のセットです。 <RFC6365>
Many items in Internet protocols use names to identify specific instances or values. The names may be generated (by some prescribed rules), registered centrally (e.g., such as with IANA), or have a distributed registration and control mechanism, such as the names in the DNS.
インターネット・プロトコルの多くの項目は、特定のインスタンスまたは値を識別するための名前を使用しています。名前は、DNS内の名前として、（いくつかの所定のルールにより）生成（例えば、IANAと同様に）中央登録、または分散登録および制御機構を有していてもよいです。
on-the-wire encoding
オン・ザ・ワイヤエンコーディング
The encoding and decoding used before and after transmission over the network is often called the "on-the-wire" (or sometimes just "wire") format. <RFC6365>
前とネットワークを介して送信した後に使用される符号化および復号化は、多くの場合、「オン・ザ・ワイヤ」（または時には単に「ワイヤ」）フォーマットと呼ばれます。 <RFC6365>
Characters are identified by code points. Before being transmitted in a protocol, they must first be encoded as bits and octets. Similarly, when characters are received in a transmission, they have been encoded, and a protocol that needs to process the individual characters needs to decode them before processing.
文字は、コード・ポイントによって識別されます。プロトコルで送信される前に、彼らは、最初のビットとのオクテットとして符号化されなければなりません。文字を送信で受信された場合も同様に、それらは、符号化されており、個々の文字を処理する必要があるプロトコルは、処理前にそれらをデコードする必要があります。
parsed text
解析されたテキスト
Text strings that have been analyzed for subparts. <RFC6365>
サブパーツのために分析されているテキスト文字列。 <RFC6365>
In some protocols, free text in text fields might be parsed. For example, many mail user agents (MUAs) will parse the words in the text of the Subject: field to attempt to thread based on what appears after the "Re:" prefix.
いくつかのプロトコルでは、テキストフィールドにフリーテキストを解析することがあります。接頭辞：「再」の後に表示される内容に基づいてスレッドしようとするフィールド：たとえば、多くのメールユーザエージェント（MUAには）件名のテキスト中の単語を解析します。
Such conventions are very sensitive to localization. If, for example, a form like "Re:" is altered by an MUA to reflect the language of the sender or recipient, a system that subsequently does threading may not recognize the replacement term as a delimiter string.
このような規則は、ローカリゼーションに非常に敏感です。例えば、「再：」のような形態が、場合送信者または受信者の言語を反映するようにMUAによって変更され、続いてスレッドないシステムは、区切り文字列として交換用語を認識しなくてもよいです。
charset identification
文字セット識別
Specification of the charset used for a string of text. <RFC6365>
テキストの文字列に使用する文字セットの仕様。 <RFC6365>
Protocols that allow more than one charset to be used in the same place should require that the text be identified with the appropriate charset. Without this identification, a program looking at the text cannot definitively discern the charset of the text. Charset identification is also called "charset tagging".
複数の文字セットが同じ場所で使用できるようにするプロトコルは、テキストが適切な文字セットを識別することを要求しなければなりません。この識別せずに、テキストを見ているプログラムは、決定的にテキストの文字セットを識別することはできません。文字セットの識別はまた、「文字セットタギング」と呼ばれています。
language identification
言語識別
Specification of the human language used for a string of text. <RFC6365>
テキストの文字列に使用する人間の言語の仕様。 <RFC6365>
Some protocols (such as MIME and HTTP) allow text that is meant for machine processing to be identified with the language used in the text. Such identification is important for machine processing of the text, such as by systems that render the text by speaking it. Language identification is also called "language tagging". The IETF "LTRU" standards [RFC5646] and [RFC4647] provide a comprehensive model for language identification.
（例えば、MIMEとHTTPなどの）いくつかのプロトコルは、機械加工のために意図されたテキストがテキストで使用される言語で識別されることを可能にします。そのような識別は、それを話すことによってテキストをレンダリングシステムなどによって、テキストの機械加工のために重要です。言語の識別はまた、「言語タグ」と呼ばれています。 IETF「LTRU」規格[RFC5646]と[RFC4647]は言語識別のための包括的なモデルを提供します。
MIME
MIME
MIME (Multipurpose Internet Mail Extensions) is a message format that allows for textual message bodies and headers in character sets other than US-ASCII in formats that require ASCII (most notably RFC 5322, the standard for Internet mail headers [RFC5322]). MIME is described in RFCs 2045 through 2049, as well as more recent RFCs. <RFC6365>
MIME（多目的インターネットメール拡張）はASCII（特にRFC 5322、インターネットメールのヘッダー[RFC5322]のための標準）が必要な形式でUS-ASCII以外の文字集合でのテキストメッセージの本文とヘッダを可能メッセージ形式です。 MIMEは2049年と同様に、より最近のRFC経由のRFC 2045に記述されています。 <RFC6365>
transfer encoding syntax
転送エンコード構文
A transfer encoding syntax (TES) (sometimes called a transfer encoding scheme) is a reversible transform of already encoded data that is represented in one or more character encoding schemes. <RFC6365>
転送符号化構文（TES）は、（時々転送符号化方式と呼ばれる）は、1つまたは複数の文字符号化スキームに示されている既に符号化データの変換を可逆的です。 <RFC6365>
TESs are useful for encoding types of character data into another format, usually for allowing new types of data to be transmitted over legacy protocols. The main examples of TESs used in the IETF include Base64 and quoted-printable. MIME identifies the transfer encoding syntax for body parts as a Content-transfer-encoding, occasionally abbreviated C-T-E.
TESSは通常、レガシープロトコルを介して送信されるデータの新しいタイプを可能にするために、別のフォーマットに文字データの種類をエンコードするために有用です。 IETFにおいて使用TESSの主な例は、Base64を含み、引用印刷可能。 MIMEは時折C-T-Eと略記、コンテンツ転送エンコーディングとして身体部分のための転送符号化構文を識別する。
Base64
Base64で
Base64 is a transfer encoding syntax that allows binary data to be represented by the ASCII characters A through Z, a through z, 0 through 9, +, /, and =. It is defined in [RFC2045]. <RFC6365>
BASE64は、Zを介して、0〜9、+、/、および=、バイナリデータは、Zを介してASCII文字のAで表されることを可能にする転送符号化シンタックスです。それは、[RFC2045]で定義されています。 <RFC6365>
quoted printable
引用された印刷可能
Quoted printable is a transfer encoding syntax that allows strings that have non-ASCII characters mixed in with mostly ASCII printable characters to be somewhat human readable. It is described in [RFC2047]. <RFC6365>
引用符で囲まれた印刷可能なは、ほとんどがASCII印刷可能な文字で混合非ASCII文字を持っている文字列が読める多少人間にすることができます転送エンコード構文です。これは、[RFC2047]に記載されています。 <RFC6365>
The quoted printable syntax is generally considered to be a failure at being readable. It is jokingly referred to as "quoted unreadable".
引用された印刷可能な構文は、一般的に読みやすいもので故障であると考えられています。それは冗談めかして「読めない引用さ」と呼ばれています。
XML
XML
XML (which is an approximate abbreviation for Extensible Markup Language) is a popular method for structuring text. XML text that is not encoded as UTF-8 is explicitly tagged with charsets, and all text in XML consists only of Unicode characters. The specification for XML can be found at <http://www.w3.org/XML/>. <RFC6365>
（拡張マークアップ言語のためのおおよその略語である）XMLは、構造化テキストのための一般的な方法です。 UTF-8としてエンコードされていないXMLテキストは明示的に文字セットでタグ付けされており、XML内のすべてのテキストはUnicode文字で構成されています。 XMLの仕様は、<http://www.w3.org/XML/>で見つけることができます。 <RFC6365>
ASN.1 text formats
ASN.1テキスト形式
The ASN.1 data description language has many formats for text data. The formats allow for different repertoires and different encodings. Some of the formats that appear in IETF standards based on ASN.1 include IA5String (all ASCII characters), PrintableString (most ASCII characters, but missing many punctuation characters), BMPString (characters from ISO/IEC 10646 plane 0 in UTF-16BE format), UTF8String (just as the name implies), and TeletexString (also called T61String).
ASN.1データ記述言語は、テキストデータのための多くのフォーマットを持っています。フォーマットが異なるレパートリーと異なるエンコーディングを可能とします。 ASN.1に基づくIETF標準に現れる形式のいくつかはIA5String（すべてのASCII文字）、PrintableStringの（ほとんどのASCII文字が、多くの句読点文字の欠落）、BMPString（UTF-16BE形式のISO / IEC 10646プレーン0から文字を含みます）、UTF8Stringを（名前が示すと同じように）、およびTeletexString（もT61String呼ばれます）。
ASCII-compatible encoding (ACE)
ASCIIコンパチブルエンコーディング（ACE）
Starting in 1996, many ASCII-compatible encoding schemes (which are actually transfer encoding syntaxes) have been proposed as possible solutions for internationalizing host names and some other purposes. Their goal is to be able to encode any string of ISO/IEC 10646 characters using the preferred syntax for domain names (as described in STD 13). At the time of this writing, only the ACE produced by Punycode [RFC3492] has become an IETF standard.
1996年に開始し、（実際に転送エンコード構文です）多くのASCII互換エンコード方式は、ホスト名といくつかの他の目的を国際化のための可能な解決策として提案されています。彼らの目標は、ドメイン名（STD 13で説明したように）のための好適な構文を使用して、ISO / IEC 10646個の任意の文字列をエンコードすることができることです。この記事の執筆時点では、ピュニコード[RFC3492]によって生成のみACEは、IETF標準となっています。
The choice of ACE forms to internationalize legacy protocols must be made with care as it can cause some difficult side effects [RFC6055].
それはいくつかの困難な副作用[RFC6055]を引き起こす可能性として、レガシープロトコルを国際化するACE形式の選択は注意して行わなければなりません。
LDH label
LDHラベル
The classical label form used in the DNS and most applications that call on it, albeit with some additional restrictions, reflects the early syntax of "hostnames" [RFC0952] and limits those names to ASCII letters, digits, and embedded hyphens. The hostname syntax is identical to that described as the "preferred name syntax" in Section 3.5 of RFC 1034 [RFC1034] as modified by
DNSといくつかの追加の制限はあるものの、それを呼び出すほとんどのアプリケーションで使用される、古典的なラベル形式は、「ホスト名」[RFC0952]の初期の構文を反映し、ASCII文字、数字、および埋め込まれたハイフンにそれらの名前を制限します。によって修正されたホスト名の構文は、RFC 1034 [RFC1034]のセクション3.5に「好ましい名前構文」として記載したものと同一であります
RFC 1123 [RFC1123]. LDH labels are defined in a more restrictive and precise way for internationalization contexts as part of the IDNA2008 specification [RFC5890].
RFC 1123 [RFC1123]。 LDHラベルはIDNA2008仕様[RFC5890]の一部として国際コンテキストのためのより限定的かつ正確な方法で定義されています。
The current specification for Internationalized Domain Names (IDNs), known formally as Internationalized Domain Names for Applications or IDNA, is referred to in the IETF and parts of the broader community as "IDNA2008" and consists of several documents. Section 2.3 of the first of those documents, commonly known as "IDNA2008 Definitions" [RFC5890] provides definitions and introduces some specialized terms for differentiating among types of DNS labels in an IDN context. Those terms are listed in the table below; see RFC 5890 for the specific definitions if needed.
アプリケーションまたはIDNAのための国際化ドメイン名として正式に知られている国際化ドメイン名（IDNの）、の現在の仕様は、IETFおよび「IDNA2008」としてより広範なコミュニティの一部に言及し、いくつかのドキュメントで構成されています。一般に「IDNA2008の定義」[RFC5890]として知られ、それらの文書の最初のセクション2.3には、定義を提供し、IDNの文脈におけるDNSラベルの種類の中から区別するためのいくつかの専門用語を紹介します。これらの用語は、以下の表に記載されています。必要に応じて、特定の定義については、RFC 5890を参照してください。
ACE Prefix A-label Domain Name Slot IDNA-valid string Internationalized Domain Name (IDN) Internationalized Label LDH Label Non-Reserved LDH label (NR-LDH label) U-label
ACEプレフィックスA-ラベルドメイン名スロットIDNA-有効な文字列国際化ドメイン名（IDN）国際化ラベルLDHラベル非予約LDHラベル（NR-LDHラベル）U-ラベル
Two additional terms entered the IETF's vocabulary as part of the earlier IDN effort [RFC3490] (IDNA2003):
二つの追加の用語は、[RFC3490]（IDNA2003）以前のIDNの取り組みの一環として、IETFの語彙に入りました。
Stringprep
文字列前
Stringprep [RFC3454] provides a model and character tables for preparing and handling internationalized strings. It was used in the original IDN specification (IDNA2003) via a profile called "Nameprep" [RFC3491]. It is no longer in use in IDNA, but continues to be used in profiles by a number of other protocols. <RFC6365>
。文字列[RFC3454]は準備と国際化された文字列を処理するためのモデルと文字のテーブルが用意されています。これは、「NAMEPREP」[RFC3491]というプロファイルを介して元のIDN仕様（IDNA2003）で使用しました。これはIDNAで使用されていませんが、他のプロトコルの数でプロファイルで使用され続けています。 <RFC6365>
Punycode
ピュニコード
This is the name of the algorithm [RFC3492] used to convert otherwise-valid IDN labels from native-character strings expressed in Unicode to an ASCII-compatible encoding (ACE). Strictly speaking, the term applies to the algorithm only. In practice, it is widely, if erroneously, used to refer to strings that the algorithm encodes.
これは、ASCIIコンパチブルエンコーディング（ACE）にUnicodeで表さネイティブ文字列から、そうでなければ、有効なIDNラベルを変換するために使用されるアルゴリズム[RFC3492]の名前です。厳密に言えば、この用語は、アルゴリズムにのみ適用されます。誤っている場合、実際に、広く、アルゴリズムは、コード文字列を指すために使用されます。
The term "variant" was introduced into the IETF i18n vocabulary with the JET recommendations [RFC3743]. As used there, it referred strictly to the relationship between Traditional Chinese characters and their Simplified equivalents. The JET recommendations provided a model for identifying these pairs of characters and labels that used them. Specific recommendations for variant handling for the Chinese language were provided in a follow-up document [RFC4713].
用語「変異体」は、JET勧告[RFC3743]とIETF I18N語彙に導入しました。そこに使用されるように、それは、繁体字中国語文字とその簡体同等物との間の関係を厳密に言及しました。 JETの推奨事項は、それらを使用して文字とラベルのこれらのペアを識別するためのモデルを提供します。中国語のために取り扱うバリアントのための具体的な提言をフォローアップ文書[RFC4713]に提供されました。
In more recent years, the term has also been used to describe other collections of characters or strings that might be perceived as equivalent. Those collections have involved one or more of several categories of characters and labels containing them including:
より最近では、この用語はまた、同等のものとして認識される可能性がある文字または文字列の他のコレクションを記述するために使用されてきました。 ：これらのコレクションは、文字を含むそれらを含むラベルのいくつかのカテゴリーの一つ以上を含んでいました
o "visually similar" or "visually confusable" characters. These may be limited to characters in different scripts, characters in a single script, or both, and may be those that can appear to be alike even when high-distinguishability reference fonts are used or under various circumstances that may involve malicious choices of typefaces or other ways to trick user perception. Trivial examples include ASCII "l" and "1" and Latin and Cyrillic "a".
O「視覚的に類似」または「視覚的に混同しやすい」の文字。これらは、異なるスクリプト、単一のスクリプトの文字、またはその両方の文字に制限され、高識別性の参照フォントが使用されている場合でも、同様のように見えるか、書体の悪質な選択を伴うかあり、様々な状況下でできているものであり得ますユーザーの認識をだますために他の方法。些細な例は、ASCII「L」と「1」とラテン語とキリル文字「A」を含みます。
o Characters assigned more than one Unicode code point because of some special property. These characters may be considered "the same" for some purposes and different for others (or by other users). One of the most commonly cited examples is the Arabic YEH, which is encoded more than once because some of its shapes are different across different languages. Another example are the Greek lowercase sigma and final sigma: if the latter were viewed purely as a positional presentation variation on the former, it should not have been assigned a separate code point.
Oの文字があるため、いくつかの特別なプロパティで複数のUnicodeコードポイントを割り当てました。これらの文字は、いくつかの目的のために、「同じ」と他人のために（または他のユーザによって）異なると考えることができます。最も一般的に引用された例の一つは、その形状の一部が異なる言語間で異なるため、複数回符号化されているアラビア語YEH、です。別の例では、ギリシャ語の小文字シグマ、最終シグマである。後者は前者の位置プレゼンテーション変化として純粋に見た場合には、別々のコード・ポイントが割り当てられていてはなりません。
o Numerals and labels including them. Unlike letters, the "meaning" of decimal digits is clear and unambiguous regardless of the script with which they are associated. Some scripts are routinely used almost interchangeably with European digits and digits native to that script. The Arabic script has two sets of digits (U+0660..U+0669 and U+06F0..U=06F9), written identically for zero through three and seven through nine but differently for four through six; European digits predominate in other areas. Substitution of digits with the same numeric value in labels may give rise to another type of variant.
それらを含めた数字とラベルO。文字とは異なり、小数点以下の桁の「意味は、」かかわらず、関連付けられているスクリプトの明確かつ曖昧でありません。いくつかのスクリプトは日常そのスクリプトにネイティブヨーロッパの数字と数字とほぼ同義的に使用されます。アラビア文字は、三七〜9が、異なる4~6貫通するための貫通ゼロのために同じ書かれた数字の二組（U + 0660..U + 0669とU + 06F0..U = 06F9）を有します。欧州の数字は他の地域で優勢。ラベルで同じ数値を持つ数字の置換は、別のタイプの変異体を生じさせる可能性があります。
o Orthographic differences within a language. Many languages have alternate choices of spellings or spellings that differ by locale. Users of those languages generally recognize the spellings as equivalent, at least as much so as the variations described above.
言語内のO正射違い。多くの言語は、ロケールによって異なるスペリングや綴りの代替選択肢があります。これらの言語のユーザは、一般的に少なくとも同じくらいのように、上述の変形例のように、等価であると綴りを認識する。
Examples include "color" and "colour" in English, German words spelled with o-umlaut or "oe", and so on. Some of these relationships may also create other types of language-specific perceived differences that do not exist for other languages using the same script. For example, in Arabic language usage at the end of words, ARABIC LETTER TEH MARBUTA (U+0629) and ARABIC LETTER HEH (U+0647) are differently shaped (one has 2 dots in top of it), but they are used interchangeably in writing: they "sound" similar when pronounced at the end of phrase, and hence the LETTER TEH MARBUTA sometimes is written as LETTER HEH and the two are considered "confusable" in that context.
例としては、その上の「色」と英語で「色」、O-ウムラウトまたは「OE」と綴られ、ドイツ語、が含まれます。これらの関係のいくつかは、同じスクリプトを使用して他の言語のために存在していない言語固有の知覚の違いの他のタイプを作成することがあります。例えば、単語の終わりにアラビア語の使用において、ARABIC LETTER TEH MARBUTA（U + 0629）とARABIC LETTER HEH（U + 0647）が異なる形状である（一方は上部の2点を有している）、それらは交換可能に使用されます書面で：フレーズの終わりに顕著なときには、同様の「音」、ひいてはLETTER TEH MARBUTAは時々LETTER HEHとして書き込まれ、二人はその文脈で「混同しやすい」と考えられています。
The term "variant" as used in this section should also not be confused with other uses of the term in this document or in Unicode terminology (e.g., those in Section 4.1 above). If the term is to be used at all, context should clearly distinguish among these different uses and, in particular, between variant characters and variant labels. Local text should identify which meaning, or combination of meanings, are intended.
このセクションで使用される用語「変異体」はまた、この文書に記載されているまたはUnicode用語（例えば、セクション4.1上記のもの）における用語の他の使用と混同すべきではありません。用語が全く使用される場合、文脈が明確にバリアント文字とバリアントのラベルの間、特に、これらの異なる使用を区別し、必要があります。ローカルテキストが意味を特定すべきである、あるいは意味の組合せは、意図されています。
This is a hodge-podge of other terms that have appeared in internationalization discussions in the IETF.
これは、IETFでの国際化の議論に登場している他の用語のホッジ-podgeです。
locale
ローカル
Locale is the user-specific location and cultural information managed by a computer. <RFC6365>
ロケールは、コンピュータによって管理されているユーザ固有の場所と文化の情報です。 <RFC6365>
Because languages and orthographic conventions differ from country to country (and even region to region within a country), the locale of the user can often be an important factor. Typically, the locale information for a user includes the language(s) used.
言語や正投影規則は（国内の領域にも地域）国によって異なるため、ユーザーのロケールは、多くの場合、重要な要因となることができます。典型的には、ユーザのロケール情報が使用される言語（複数可）を含みます。
Locale issues go beyond character use, and can include things such as the display format for currency, dates, and times. Some locales (especially the popular "C" and "POSIX" locales) do not include language information.
ロケールの問題は、文字の使用を越え、そして、通貨、日付、および時刻の表示形式として、物事を含めることができます。一部のロケール（特に人気の「C」と「POSIX」ロケール）は、言語情報が含まれていません。
It should be noted that there are many thorny, unsolved issues with locale. For example, should text be viewed using the locale information of the person who wrote the text, information that would apply to the location of the system storing or providing the text, or the person viewing it? What if the person viewing it is traveling to different locations? Should only some of the locale information affect creation and editing of text?
ロケールで、多くの厄介な、未解決の問題があることに留意すべきです。例えば、テキストは、テキストを格納または提供するシステム、またはそれを見る人の位置に適用されるテキスト、情報を書いた人のロケール情報を使用して表示すべきですか？どのような場合には、それを見た人は、別の場所に移動していますか？唯一のロケール情報の一部は、テキストの作成および編集に影響を与えるべきか？
Latin characters
ラテン文字
"Latin characters" is a not-precise term for characters historically related to ancient Greek script as modified in the Roman Republic and Empire and currently used throughout the world. <RFC6365>
「ラテン文字」ローマ共和国と帝国に変更され、現在世界中で使用されるように、歴史的に古代ギリシャのスクリプトに関連する文字のため、正確ではない用語です。 <RFC6365>
The base Latin characters are a subset of the ASCII repertoire and have been augmented by many single and multiple diacritics and quite a few other characters. ISO/IEC 10646 encodes the Latin characters in including ranges U+0020..U+024F and U+1E00..U+1EFF.
基本ラテン文字はASCIIレパートリーのサブセットであり、多くの単一および複数の発音区別符号とかなりの数の他の文字によって拡張されています。 ISO / IEC 10646は、以下を含むラテン文字をエンコードU + 0020..U + 024FおよびU + 1E00..U + 1EFFの範囲です。
Because "Latin characters" is used in different contexts to refer to the letters from the ASCII repertoire, the subset of those characters used late in the Roman Republic period, or the different subset used to write Latin in medieval times, the entire ASCII repertoire, all of the code points in the extended Latin script as defined by Unicode, and other collections, the term should be avoided in IETF specifications when possible. Similarly, "Basic Latin" should not be used as a synonym for "ASCII".
「ラテン文字」のでASCIIレパートリーからの手紙を参照するためにさまざまなコンテキストで使用され、共和政ローマ期の後半で使用されるものの文字のサブセット、または中世の時代にラテン語を書くために使用される様々なサブセットで、全体のASCIIレパートリー、ユニコード、および他のコレクションによって定義されるように、可能な場合、拡張ラテン文字のコード・ポイントのすべては、この用語は、IETF仕様では避けるべきです。同様に、「基本ラテンは、」「ASCII」の同義語として使用すべきではありません。
romanization
ローマ字
The transliteration of a non-Latin script into Latin characters. <RFC6365>
ラテン文字への非ラテン文字の音訳。 <RFC6365>
Because of their widespread use, Latin characters (or graphemes constructed from them) are often used to try to write text in languages that didn't previously have writing systems or whose writing systems were originally based on different scripts. For example, there are two popular romanizations of Chinese: Wade-Giles and Pinyin, the latter of which is by far more common today. Many romanization systems are inexact and do not give perfect round-trip mappings between the native script and the Latin characters.
そのため（それらから構築または書記素）が広く普及し、ラテン文字の多くの場合、以前に書き込みシステム、もともと別のスクリプトに基づいたシステムまたはを書いていなかった言語でテキストを書いてみるために使用されています。ウェード式やピンイン、はるかに一般的で、今日となっている後者：たとえば、中国の2つの人気ローマ字があります。多くのローマ字化システムは不正確であり、ネイティブのスクリプトとラテン文字の間の完璧なラウンドトリップマッピングを与えることはありません。
CJK characters and Han characters
CJK文字と漢字
The ideographic characters used in Chinese, Japanese, Korean, and traditional Vietnamese writing systems are often called "CJK characters" after the initial letters of the language names in English. They are also called "Han characters", after the term in Chinese that is often used for these characters. <RFC6365>
中国語、日本語、韓国語、伝統的なベトナム書き込みシステムで使用される表意文字は、多くの場合、英語での言語名の最初の文字の後に「CJK文字」と呼ばれています。彼らはまた、多くの場合、これらの文字のために使用されている中国での用語の後に、「漢字」と呼ばれています。 <RFC6365>
Note that Han characters do not include the phonetic characters used in the Japanese and Korean languages. Users of the term "CJK characters" may or may not assume those additional characters are included.
漢字は日本語と韓国語の言語で使用される表音文字が含まれていないことに注意してください。用語「CJK文字」のユーザーは、またはそれら追加の文字が含まれていると仮定しない場合があります。
In ISO/IEC 10646, the Han characters were "unified", meaning that each set of Han characters from Japanese, Chinese, and/or Korean that had the same origin was assigned a single code point. The positive result of this was that many fewer code points were needed to represent Han; the negative result of this was that characters that people who write the three languages think are different have the same code point. There is a great deal of disagreement on the nature, the origin, and the severity of the problems caused by Han unification.
ISO / IEC 10646では、漢字は同じ起源を持っていた日本、中国、および/または韓国語から漢字の各セットは、単一のコードポイントが割り当てられたことを意味し、「統一」でした。この肯定的な結果は、多くの、より少ないコードポイントがハンを表現するために必要であったということでした。この負の結果は、3つの言語を書く人々は異なっていると思うの文字が同じコードポイントを持っているということでした。自然、起源、そして漢の統一によって引き起こされる問題の深刻さの不一致の大きな取引があります。
translation
翻訳
The process of conveying the meaning of some passage of text in one language, so that it can be expressed equivalently in another language. <RFC6365>
それが別の言語で等価的に表すことができるように、一つの言語のテキストの一部通路の意味を伝えるプロセス。 <RFC6365>
Many language translation systems are inexact and cannot be applied repeatedly to go from one language to another to another.
多くの言語翻訳システムは不正確であり、他の言語から別の言語から行くために繰り返し適用することはできません。
transliteration
音訳
The process of representing the characters of an alphabetical or syllabic system of writing by the characters of a conversion alphabet. <RFC6365>
変換アルファベットの文字で書き込みのアルファベットまたは音節システムの文字を表現する方法。 <RFC6365>
Many script transliterations are exact, and many have perfect round-trip mappings. The notable exception to this is romanization, described above. Transliteration involves converting text expressed in one script into another script, generally on a letter-by-letter basis. There are many official and unofficial transliteration standards, most notably those from ISO TC 46 and the U.S. Library of Congress.
多くのスクリプト音訳は正確であり、多くは完璧なラウンドトリップのマッピングを持っています。これに注目すべき例外は、前述した、ローマ字表記です。音訳は、一般的に文字ごとの文字に基づいて、別のスクリプト内のスクリプトで表現さテキストを変換することを含みます。多くの公式と非公式の音訳規格はISO TC 46と議会の米国図書館から最も注目すべきものがあります。
transcription
トランスクリプション
The process of systematically writing the sounds of some passage of spoken language, generally with the use of a technical phonetic alphabet (usually Latin-based) or other systematic transcriptional orthography. Transcription also sometimes refers to the conversion of written text into a transcribed form, based on the sound of the text as if it had been spoken. <RFC6365>
体系的に一般的に技術的な音標文字（通常はラテン語ベース）、または他の系統的転写正書法を使用して、話し言葉のいくつかの通路の音を書き込む処理。転写はまた、時にはそれが話されていたかのようにテキストの音に基づいて転写し、フォームに書かれたテキストの変換を指します。 <RFC6365>
Unlike transliterations, which are generally designed to be round-trip convertible, transcriptions of written material are almost never round-trip convertible to their original form, at least without some supplemental information.
一般的に往復変換できるように設計されている音訳とは異なり、書かれた材料の編曲は、少なくともいくつかの補足情報がなく、ほとんどない元の形式への往復転換されません。
regular expressions
正規表現
Regular expressions provide a mechanism to select specific strings from a set of character strings. Regular expressions are a language used to search for text within strings, and possibly modify the text found with other text. <RFC6365>
正規表現は、文字列の集合から特定の文字列を選択するためのメカニズムを提供します。正規表現は、文字列内のテキストを検索し、おそらく他のテキストで見つかったテキストを変更するために使用される言語です。 <RFC6365>
Pattern matching for text involves being able to represent one or more code points in an abstract notation, such as searching for all capital Latin letters or all punctuation. The most common mechanism in IETF protocols for naming such patterns is the use of regular expressions. There is no single regular expression language, but there are numerous very similar dialects that are not quite consistent with each other.
テキストのパターンマッチングは、全ての資本ラテン文字又は全ての句読点を検索するように、抽象的表記で1つ以上のコードポイントを表現することができるということを含みます。このようなパターンに名前を付けるためのIETFプロトコルで最も一般的なメカニズムは、正規表現を使用することです。単一の正規表現言語はありませんが、お互いにかなり一致していない数多くの非常によく似た方言があります。
The Unicode Consortium has a good discussion about how to adapt regular expression engines to use Unicode. [UTR18]
ユニコードコンソーシアムは、Unicodeを使用するために、正規表現エンジンを適応する方法について良い議論を持っています。 [UTR18]
private use character
私的使用の文字
ISO/IEC 10646 code points from U+E000 to U+F8FF, U+F0000 to U+FFFFD, and U+100000 to U+10FFFD are available for private use. This refers to code points of the standard whose interpretation is not specified by the standard and whose use may be determined by private agreement among cooperating users. <UNICODE>
ISO / IECはU + 10FFFDにU + U + F8FFにE000、U + FFFFDにU + F0000、およびU + 100000から10646個のコードポイントは、私的使用のために利用可能です。これは解釈その使用が協働するユーザ間のプライベート契約によって決定することができる標準によって指定されていない標準のコードポイントを指します。 <UNICODE>
The use of these "private use" characters is defined by the parties who transmit and receive them, and is thus not appropriate for standardization. (The IETF has a long history of private use names for things such as "x-" names in MIME types, charsets, and languages. Most of the experience with these has been quite negative, with many implementors assuming that private use names are in fact public and long-lived.)
これらの「私的使用」の文字の使用は、それらを送信および受信当事者によって定義され、したがって、標準化のために適切ではないです。 （IETFは、MIMEタイプ、文字セット、および言語の「X-」の名前のように、物事のための私的使用の名前の長い歴史を持っている。これらの経験のほとんどは、多くの実装者は、私的使用の名前がであると仮定して、かなりのマイナスとなっています公共および長寿命という。）
Security is not discussed directly in this document. While the definitions here have no direct effect on security, they are used in many security contexts. For example, authentication usually involves comparing two tokens, and one or both of those tokens might be text; thus, some methods of comparison might involve using some of the internationalization concepts for which terms are defined in this document.
セキュリティは、この文書で直接議論されていません。ここでの定義は、セキュリティに直接影響を及ぼさないが、それらは多くのセキュリティコンテキストで使用されています。例えば、認証は、通常、2つのトークン、及びテキストであるかもしれないそれらのトークンの一方または両方を比較することを含みます。このように、比較のいくつかの方法が用語がこの文書で定義されている国際化概念のいくつかを使用することを含むかもしれません。
Having said that, other RFCs dealing with internationalization have security consideration descriptions that may be useful to the reader of this document. In particular, the security considerations in RFC 3454, RFC 3629, RFC 4013 [RFC4013], and RFC 5890 go into a fair amount of detail.
国際化に対処する他のRFCは、この文書の読者に有用である可能性があるセキュリティ上の配慮の記述を持っている、と述べました。具体的には、RFC 3454、RFC 3629、RFC 4013 [RFC4013]、およびRFC 5890のセキュリティの考慮事項は、詳細のかなりの量に入ります。
[ISOIEC10646] ISO/IEC, "ISO/IEC 10646:2011. International Standard -- Information technology - Universal Multiple-Octet Coded Character Set (UCS)", 2011.
[ISOIEC10646] ISO / IEC、 "ISO / IEC 10646：2011国際規格 - 情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS）"、2011年。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.0", (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6). <http://www.unicode.org/versions/Unicode6.0.0/>.
[UNICODE]のUnicodeコンソーシアム、 "Unicode標準、バージョン6.0"、（カリフォルニア州マウンテンビュー：ユニコードコンソーシアム、2011年ISBN 978-1-936213-01-6）。 <http://www.unicode.org/versions/Unicode6.0.0/>。
[CHARMOD] W3C, "Character Model for the World Wide Web 1.0", 2005, <http://www.w3.org/TR/charmod/>.
[CHARMOD] W3C、 "ワールド・ワイド・ウェブ1.0の文字モデル"、2005年、<http://www.w3.org/TR/charmod/>。
[FRAMEWORK] ISO/IEC, "ISO/IEC TR 11017:1997(E). Information technology - Framework for internationalization, prepared by ISO/IEC JTC 1/SC 22/WG 20", 1997.
【FRAMEWORK] ISO / IEC、 "ISO / IEC TR 11017：1997（E）情報技術 - 国際化のためのフレームワーク、ISO / IEC JTC 1 / SC 22 / WG 20によって調製"、1997。
[ISO3166] ISO, "ISO 3166-1:2006 - Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 2006.
[ISO3166] ISO、 "ISO 3166-1：2006 - 国及びその下位区分の名前の表現のためのコード - 第1部：国コード"、2006年。
[ISO639] ISO, "ISO 639-1:2002 - Code for the representation of names of languages - Part 1: Alpha-2 code", 2002.
[ISO639] ISO、 "ISO 639-1：2002 - 言語の名前の表現のためのコード - パート1：アルファ2コード"、2002年。
[ISO6429] ISO/IEC, "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control functions for coded character sets"", ISO/IEC 6429:1992, 1992.
[ISO6429] ISO / IEC、 "ISO / IEC、" ISO / IEC 6429：1992。情報技術 - 符号化文字集合のための制御機能 ""、ISO / IEC 6429：1992、1992。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952] Harrenstien、K.、スタール、M.、およびE. Feinler、 "DoDのインターネットホストテーブル仕様"、RFC 952、1985年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、2000年2月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC3743]小西、K.、黄、K.、銭、H.、およびY.コ、 "国際化ドメイン名のための共同エンジニアリングチーム（JET）ガイドライン中国語、日本語、韓国語用（IDN）登録と管理"、 RFC 3743、2004年4月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]フィリップス、A.とM.デイヴィス、 "言語タグのマッチング"、BCP 47、RFC 4647、2006年9月。
[RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, "Registration and Administration Recommendations for Chinese Domain Names", RFC 4713, October 2006.
[RFC4713]リー、X.、真央、W.、チェン、E.、スー、N.、およびJ. Klensin、RFC 4713、2006年10月 "中国のドメイン名の登録と管理勧告"。
[RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", BCP 137, RFC 5137, February 2008.
[RFC5137] Klensin、J.、 "ASCII Unicode文字のエスケープ"、BCP 137、RFC 5137、2008年2月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J.とM. Padlipsky、 "ネットワークインターチェンジのUnicodeフォーマット"、RFC 5198、2008年3月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A.とM.デイヴィス、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J.、 "アプリケーション（IDNA）のための国際化ドメイン名：定義とドキュメントフレームワーク"、RFC 5890、2010年8月。
[RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892] Faltstrom、P.、 "Unicodeのコードポイントとアプリケーションのための国際化ドメイン名（IDNA）"、RFC 5892、2010年8月。
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
[RFC5895]レズニック、P.およびP.ホフマン、 "アプリケーションにおける国際化ドメイン名のマッピング文字（IDNA）2008"、RFC 5895、2010年9月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055]ターラー、D.、Klensin、J.、およびS.チェシャー、 "国際化ドメイン名のエンコーディングのIAB思考"、RFC 6055、2011年2月。
[UAX34] The Unicode Consortium, "Unicode Standard Annex #34: Unicode Named Character Sequences", 2010, <http://www.unicode.org/reports/tr34>.
【UAX34]ユニコードコンソーシアム、 "Unicode規格付属書＃34：Unicodeは、文字シーケンス名前"、2010年<http://www.unicode.org/reports/tr34>。
[UAX9] The Unicode Consortium, "Unicode Standard Annex #9: Unicode Bidirectional Algorithm", 2010, <http://www.unicode.org/reports/tr9>.
【UAX9]ユニコードコンソーシアム、 "Unicode規格附属書＃9：ユニコード双方向アルゴリズム"、2010年<http://www.unicode.org/reports/tr9>。
[US-ASCII] ANSI, "Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986", 1986.
[US-ASCII] ANSIは、 "コード化文字セット - 情報交換、ANSI X3.4-1986ための7ビットの米国標準コード"、1986年。
[UTN6] The Unicode Consortium, "Unicode Technical Note #5: BOCU-1: MIME-Compatible Unicode Compression", 2006, <http://www.unicode.org/notes/tn6/>.
[UTN6]はUnicodeコンソーシアム、 "Unicodeのテクニカルノート＃5：BOCU-1：MIME互換のUnicode圧縮"、2006年、<http://www.unicode.org/notes/tn6/>。
[UTR15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2010, <http://www.unicode.org/reports/tr15>.
【UTR15]ユニコードコンソーシアム、 "Unicode規格付属書＃15：Unicode正規化フォーム" 2010年、<http://www.unicode.org/reports/tr15>。
[UTR18] The Unicode Consortium, "Unicode Standard Annex #18: Unicode Regular Expressions", 2008, <http://www.unicode.org/reports/tr18>.
[UTR18]はUnicodeコンソーシアム、 "Unicode規格附属書＃18：Unicodeの正規表現"、2008年、<http://www.unicode.org/reports/tr18>。
[UTR22] The Unicode Consortium, "Unicode Technical Standard #22: Unicode Character Mapping Markup Language", 2009, <http://www.unicode.org/reports/tr22>.
[UTR22]はUnicodeコンソーシアム、 "Unicodeの技術標準＃22：Unicode文字のマッピングマークアップ言語"、2009年、<http://www.unicode.org/reports/tr22>。
[UTR6] The Unicode Consortium, "Unicode Technical Standard #6: A Standard Compression Scheme for Unicode", 2005, <http://www.unicode.org/reports/tr6>.
[UTR6]はUnicodeコンソーシアム、 "Unicodeの技術標準＃6：Unicodeの標準圧縮スキーム"、2005年、<http://www.unicode.org/reports/tr6>。
[W3C-i18n-Def] W3C, "Localization vs. Internationalization", September 2010, <http://www.w3.org/International/ questions/qa-i18n.en>.
[W3C-I18N-デフ] W3C、 "国際対ローカライズ"、2010年9月には、<http://www.w3.org/International/が質問/ QA-i18n.en>。
Appendix A. Additional Interesting Reading
付録A.追加の興味深い読み物
Barry, Randall, ed. ALA-LC Romanization Tables. Washington: U.S. Library of Congress, 1997. ISBN 0844409405
バリー、ランドール、エド。 ALA-LCのローマ字表。ワシントン：議会の米国図書館、1997年ISBN 0844409405
Coulmas, Florian. Blackwell Encyclopedia of Writing Systems. Oxford: Blackwell Publishers, 1999. ISBN 063121481X
Coulmas、フロリアン。ライティングシステムのブラックウェル百科事典。オックスフォード：ブラックウェル出版、1999年ISBN 063121481X
Dalby, Andrew. Dictionary of Languages: The Definitive Reference to More than 400 Languages. New York: Columbia University Press, 2004. ISBN 978-0231115698
ダルビー、アンドリュー。言語の辞書：400以上の言語に決定的なリファレンス。ニューヨーク：コロンビア大学プレス、2004年ISBN 978から0231115698
Daniels, Peter, and William Bright. The World's Writing Systems. New York: Oxford University Press, 1996. ISBN 0195079930
ダニエルズ、ピーター、とウィリアム明るいです。世界のライティングシステム。ニューヨーク：オックスフォード大学出版局、1996年ISBN 0195079930
DeFrancis, John. The Chinese Language: Fact and Fantasy. Honolulu: University of Hawaii Press, 1984. ISBN 0-8284-085505 and 0-8248-1058-6
DeFrancis、ジョン。中国の言語：事実とファンタジー。ホノルル：ハワイ大学出版、1984年ISBN 0-8284-085505と0-8248-1058-6
Drucker, Joanna. The Alphabetic Labyrinth: The Letters in History and Imagination. London: Thames & Hudson, 1995. ISBN 0-500-28068-1
ドラッカー、ジョアンナ。アルファベット迷宮：歴史と想像力で文字。ロンドン：テムズ＆ハドソン、1995年ISBN 0-500-28068-1
Fazzioli, Edoardo. Chinese Calligraphy. New York: Abbeville Press, 1986, 1987 (English translation). ISBN 0-89659-774-1
Fazzioli、エドアルド。中国の書道。ニューヨーク：アブビルプレス、1986年、1987年（英語訳）。 ISBN 0-89659-774-1
Hooker, J.T., et al. Reading the Past: Ancient Writing from Cuneiform to the Alphabet. London: British Museum Press, 1990. ISBN 0-7141-8077-7
フッカー、J。T.、ら。アルファベットの楔形文字から古代執筆：過去を読みます。ロンドン：大英博物館を押して、1990年ISBN 0-7141-8077-7
Lunde, Ken. CJKV Information Processing. Sebastopol, CA: O'Reilly & Assoc., 1999. ISBN 1-56592-224-7
ルンデ、ケン。 CJKV情報処理。セバストポル、CA：オライリー＆准、1999年ISBN 1-56592-224-7。
Nakanishi, Akira. Writing Systems of the World. Rutland, VT: Charles E. Tuttle Company, 1980. ISBN 0804816549
中西、アキラ。世界のシステムを書きます。ラトランド、バーモント：チャールズ・E・タトル社、1980年ISBN 0804816549
Robinson, Andrew. The Story of Writing: Alphabets, Hieroglyphs, & Pictograms. London: Thames & Hudson, 1995, 2000. ISBN 0-500-28156-4
ロビンソン、アンドリュー。アルファベット、象形文字、および絵文字：ライティングの物語。ロンドン：テムズ＆ハドソン、1995年、2000年ISBN 0-500-28156-4
Sacks, David. Language Visible. New York: Broadway Books (a division of Random House, Inc.), 2003. ISBN 0-7679-1172-5
サックス、デビッド。言語見えます。ニューヨーク：ブロードウェイ書籍（ランダムハウス社の一部門）、2003年ISBN 0-7679-1172-5
Appendix B. Acknowledgements
付録B.謝辞
The definitions in this document come from many sources, including a wide variety of IETF documents.
この文書の定義はIETFのドキュメントのさまざまなを含め、多くのソースから来ます。
James Seng contributed to the initial outline of RFC 3536. Harald Alvestrand and Martin Duerst made extensive useful comments on early versions. Others who contributed to the development of RFC 3536 include Dan Kohn, Jacob Palme, Johan van Wingen, Peter Constable, Yuri Demchenko, Susan Harris, Zita Wenzel, John Klensin, Henning Schulzrinne, Leslie Daigle, Markus Scherer, and Ken Whistler.
ジェームズ・ハンセンは、ハラルドAlvestrandとマーティンDuerstは初期バージョンで広範に有用なコメントをしたRFC 3536.の初期の輪郭に貢献しました。 RFC 3536の発展に貢献した他は、ダンコーン、ヤコブパルメ、ヨハン・バンWingen、ピーター・コンスタブル、ユーリDemchenko、スーザン・ハリス、ジータヴェンツェル、ジョン・クレンシン、ヘニングSchulzrinneと、レスリーDaigle氏、マーカス・シーラー、とケンウィスラーが含まれます。
Abdulaziz Al-Zoman, Tim Bray, Frank Ellermann, Antonio Marko, JFC Morphin, Sarmad Hussain, Mykyta Yevstifeyev, Ken Whistler, and others identified important issues with, or made specific suggestions for, this new version.
アブドゥルアジーズアルZoman、ティム・ブレイ、フランクEllermann、アントニオ・マルコ、JFCなMorphin、Sarmadフセイン、Mykyta Yevstifeyev、ケン・ウィスラー、そして他の人がして重要な問題を特定し、またはこの新しいバージョンのための具体的な提案をしました。
Appendix C. Significant Changes from
付録C.著しい変動があったから
This document mostly consists of additions to RFC 3536. The following is a list of the most significant changes.
この文書では、主に次のことが最も重要な変更のリストであるRFC 3536.に追加で構成されています。
o Changed the document's status to BCP.
O BCPへの文書のステータスを変更しました。
o Commonly used synonyms added to several descriptions and indexed.
O一般的に使用される同義語には、いくつかの説明とインデックス付きに加えました。
o A list of terms defined and used in IDNA2008 was added, with a pointer to RFC 5890. Those definitions have not been repeated in this document.
O IDNA2008で定義され、使用される用語のリストは、それらの定義は、この文書で繰り返されていないRFC 5890.へのポインタで、添加しました。
o The much-abused term "variant" is now discussed in some detail.
O大いに虐待用語「変異体」は今、いくつかの詳細に議論されます。
o A discussion of different subsets of the Unicode repertoire was added as Section 4.2 and associated definitions were included.
Oユニコードレパートリーの異なるサブセットの議論はセクション4.2のように加え、関連する定義が含まれていました。
o Added a new term, "writing style".
O新しい用語、「文体」が追加されました。
o Discussions of case-folding and mapping were expanded.
ケース・折り畳みおよびマッピングのOディスカッションが展開されました。
o Minor edits were made to some section titles and a number of other editorial improvements were made.
Oマイナーな編集は、いくつかのセクションタイトルに行われた、その他の編集多くの改良が行われました。
o The discussion of control codes was updated to include additional information and clarify that "control code" and "control character" are synonyms.
O制御コードの議論は、追加情報が含まれており、「制御コード」と「制御文字」は同義語であることを明確にするために更新されました。
o Many terms were clarified to reflect contemporary usage.
O多くの用語は、現代的な使用状況を反映するために明らかにしました。
o The index to terms by section in RFC 3536 was replaced by an index to pages containing considerably more terms.
O RFC 3536で部による用語のインデックスは、かなり多くの用語を含むページをインデックスに置き換えられました。
o The acknowledgments were updated.
oを確認応答を更新しました。
o Some of the references were updated.
O参照の一部が更新されました。
o The supplemental reading list was expanded somewhat.
補足読書リストoをやや拡大しました。
Index
指数
A A-label 31 ACE 30, 31 ACE Prefix 31 alphabetic 20 ANSI 13 ASCII 15 ASCII-compatible encoding 30, 31 ASN.1 text formats 30
A-ラベル31 ACE 30、31 ACEプレフィックス31アルファベット20 ANSI 13 ASCII 15 ASCIIコンパチブルエンコーディング30、31 ASN.1テキスト形式30
B Base64 29 Basic Multilingual Plane 13 bidi 26 bidirectional display 26 BMP 13 BMPString 30 BOCU-1 14 BOM 14 byte order mark 14
B Base64で29基本多言語面13双方向26双方向ディスプレイ26 BMP 13 BMPString 30 BOCU-1 14 BOM 14バイト順マーク14
C C-T-E 29 case 18 CCS 7 CEN/ISSS 13 character 6 character encoding form 7 character encoding scheme 8 character repertoire 7 charset 8 charset identification 28 CJK characters 34 code chart 19 code point 16 code table 19 coded character 6 coded character set 7 collation 18 combining character 16 combining character sequence 16 compatibility character 22 compatibility variant 22 composite sequence 16 content-transfer-encoding 29 control character 21 control code 21 control sequence 22
C CTE 29ケース18件のCCS 7 CEN / ISSS 13文字6文字コード形式7文字符号化スキーム8文字レパートリ7文字セット8文字セット識別28 CJK文字34コードチャート19コード・ポイント16コードテーブル19コード化文字6コード化文字は7照合18を設定します文字列を結合文字16を組み合わせる16互換キャラクタ22の互換性の変異体22複合シーケンス16コンテンツ転送エンコーディング29制御キャラクタ21制御コード21制御シーケンス22
D decomposed character 16 diacritic 21 displaying and rendering text 10 Domain Name Slot 31
Dは、テキスト10ドメイン名のスロット31を表示し、文字描画16分音21を分解しました
E encoding forms 13
Eエンコーディング13を形成します
F font 25 formatting character 22
Fフォント25フォーマット文字22
G glyph 7 glyph code 7 graphic symbol 25
Gグリフ7グリフコード7図形25
H Han characters 34
H漢字34
I i18n 9 IA5String 30 ideographic 20 IDN 31 IDNA 31 IDNA-valid string 31 IDNA2003 31 IDNA2008 31 IME 24 input method editor 24 input methods 24 internationalization 8 Internationalized Domain Name 31 Internationalized Label 31
I I18N 9 IA5String 30表意20 IDN 31 IDNA 31 IDNA、有効な文字列31 IDNA2003 31 IDNA2008 31 IME 24インプットメソッドエディタ24入力方法24国際8国際化ドメイン名31国際ラベル31
ISO 11 ISO 639 11 ISO 3166 11 ISO 8859 15 ISO TC 46 11
ISOのISO 11 639 ISO 11 3166 11 ISO 8859 15 ISO TC 46 11
J JIS 13 JTC 1 11
J JIS 13 JTC 1 11
L l10n 9 language 5 language identification 29 Latin characters 34 LDH Label 30 letters 23 Local and regional standards organizations 13 locale 33 localization 9
L 9言語5言語識別L10N 29ラテン文字34 LDHラベル30文字23ローカルおよび地域の標準化団体13ロケール33ローカリゼーション9
M MIME 29 multilingual 10
M MIME 29多言語10
N name spaces 28 Nameprep 31 NFC 17 NFD 17 NFKC 17 NFKD 17 non-ASCII 23 nonspacing character 21 normalization 17 NR-LDH label 31 NVT 15
N名前空間28 NAMEPREP 31 NFC 17 NFD 17 NFKC 17 NFKD 17非ASCII 23ノンスペーシング文字21の正規化17 NR-LDHラベル31 NVT 15
O on-the-wire encoding 28
Oオン・ザ・ワイヤエンコーディング28
P parsed text 28 precomposed character 16 PrintableString 30 private use charater 36 protocol elements 27 punctuation 21 Punycode 30, 31
Pは、テキスト28合成済みキャラクタ16はPrintableString 30私的使用charater 36プロトコル要素27句読点解析された21ピュニコード30、31
Q quoted-printable 29
Qは、quoted-printableの29
R regular expressions 36 rendering rules 24 repertoire 7 romanization 34
R正規表現36のレンダリングルール24レパートリー7ローマ字34
S SAC 13 script 5 SCSU 14 sorting 18 Stringprep 31 surrogate pair 14 symbol 21
S SAC 13スクリプト5 SCSU 14ソーティング18のstringprep 31サロゲートペア14シンボル21
T T61String 30 TeletexString 30 TES 29 transcoding 7 transcription 35 transfer encoding syntax 29 transformation formats 13 translation 35 transliteration 34, 35 typeface 25
T T61String 30 TeletexString 30のTES 29トランス7転写35転送符号化シンタックス29の変換フォーマット13翻訳35音訳34、35書体25
U U-label 31 UCS-2 13 UCS-4 13 undisplayable character 26 Unicode Consortium 12 US-ASCII 15 UTC 12 UTF-8 14
U U-ラベル31のUCS-2 13 UCS-4 13表示不可能な文字26ユニコードコンソーシアム12 US-ASCII 15 UTC 12 UTF-8 14
UTF-16 14 UTF-16BE 14 UTF-16LE 14 UTF-32 14 UTF8String 30
UTF-16 14 UTF-16BE 14 UTF-16LE 14 UTF-32 14 UTF8Stringを30
V variant 32
実施例32において
W W3C 13 World Wide Web Consortium 13 writing style 27 writing system 6
W W3C 13ワールド・ワイド・ウェブ・コンソーシアム13文体27ライティングシステム6
X XML 13, 30
Ｘ ＸＭＬ １３、 ３０
Authors' Addresses
著者のアドレス
Paul Hoffman VPN Consortium
ポール・ホフマンVPNコンソーシアム
EMail: paul.hoffman@vpnc.org
メールアドレス：paul.hoffman@vpnc.org
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
ジョン・S Clensin 1770マサチューセッツアベニュー、隣接する322ケンブリッジ、MA 02140彼
Phone: +1 617 245 1457 EMail: john+ietf@jck.com
電話：+1 617 245 1457 Eメール：john+ietf@jck.com