[要約] RFC 6365は、IETFにおける国際化に関連する用語を定義しています。その目的は、国際化に関連する議論や仕様の一貫性を確保するための共通の用語を提供することです。
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
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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文字セットのポリシー仕様[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 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]
o 文字セットポリシー仕様[RFC2277]およびドメイン名国際化標準[RFC5890]を含むIETF RFCS
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]のコードポイントと名前の表記を使用します。たとえば、文字「a」は「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.
このセクションでは、IETFプロトコルを非ASCIIテキストにより親しみやすくすることに関与しているほとんどすべての人に必要な基本的なトピック（セクション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（Language Tag Registry Update）標準[RFC5646] [RFC4647]は、言語をより詳細に議論し、インターネットプロトコルで使用する言語の識別子を提供します。コンピューター言語はこの定義から明示的に除外されていることに注意してください。
script
脚本
A set of graphic characters used for the written form of one or more languages. <ISOIEC10646>
1つ以上の言語の書かれた形式に使用されるグラフィック文字のセット。<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.
国際化初心者が「言語」と「スクリプト」という用語を混同するのが一般的です。これは、2つを区別するプロトコルの問題になる可能性があります。非ASSASCIIテキスト取引を処理するように設計された（または再設計された）ほとんどすべてのプロトコル（書かれたシステム）または文字を処理しますが、実際に言語を扱うのは少ないです。
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
単一の名前は、言語またはスクリプトのいずれかを意味します。たとえば、「アラビア語」は言語の名前とスクリプトの名前の両方です。実際、多くのスクリプトが言語の名前から名前を借りています。さらに、複数の言語を書くために多くのスクリプトが使用されています。たとえば、ロシア語とブルガリア語はキリル文字に記載されています。一部の言語は、異なるスクリプトを使用して表現することも、異なる時期に異なるスクリプトで使用されました。モンゴル語は、モンゴル語またはキリル文字のいずれかで書くことができます。マレーは主にラテン語のスクリプトで主に書かれていますが、以前のアラビア語のスクリプトベースのJawaフォームはまだ使用されています。そして、多くの言語が変換されました
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".
人々がキャラクターについて話すとき、彼らは通常、最初の2つの定義の1つを意図します。「文字」という用語は、しばしば「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>
コード化された表現と一緒にキャラクター。<isoiec10646>
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、1対多、または多くのマッピングが含まれる場合があります。一部のレガシーマッピングはグリファイティックであるため、多くの人から順序付けされているだけでなく、順序でもある可能性があります。したがって、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.
この定義では、「Muly-One」とは、単一の文字にマッピングされた一連の文字を意味します。「多く」は、単一の文字にマッピングされる代替文字を意味するものではありません。
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.
一部のセスは単一のCCに関連付けられています。たとえば、UTF-8 [RFC3629]は、ISO/IEC 10646とUnicodeの同一のCCSにのみ適用されます。ISO 2022などの他のcessは、多くのCCSに関連付けられています。
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>
チャーセットは、オクテットのシーケンスを抽象文字のシーケンスにマッピングする方法です。憲章は、実際には、1つ以上のCCSとCESの組み合わせです。チャーセット名は、[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".
多くのプロトコル定義は、説明で「文字セット」という用語を使用しています。「Charset」または「文字エンコードスキーム」および「コーディングされた文字セット」という用語は、「文字セット」が他のコンテキストで、特にIETFの外側に他の定義があるため、「文字セット」という用語よりも強く好まれます。用語を定義せずに「文字セット」を使用するIETF標準を読み取る場合、通常は「1つのCCとCESの特定の組み合わせ」を意味します。特に「US-ASCII文字セット」について話している場合。
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-DEF]
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,
テキストを処理する多くのプロトコルは、1つのcharset（us-ascii）のみを処理するか、どのCCとエンコードがローカル推測に使用されるかという問題を残します（もちろん、相互運用性の問題につながります）。複数の充電器が許可されている場合、それらを明示的に特定する必要があります[RFC2277]。プロトコルに非ASCIIテキストを追加すると、プロトコルがより多くのスクリプトを処理できます。今日の世界では、
that is normally best accomplished by allowing Unicode encoded in UTF-8 only, thereby shifting conversion issues away from individual choices.
これは通常、UTF-8のみでエンコードされたUnicodeを許可することで最もよく達成され、それにより個々の選択から変換の問題をシフトすることができます。
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で説明されている「Locale」と「ローカリゼーション」を混同しないでください。
i18n, l10n
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」の「Internationalization」の「N」の間の文字の数であり、「10」は「L」の「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つの組み合わせマークがある場合など、組み合わせマークが互いに相互作用する場合に複雑な場合があります。文字のフォーマットは、レンダラーがテキストを表示する方法を変更することもできます。レンダリングは、アラビア語やINDICスクリプトなど、ベース文字の複雑な表示ルールを備えた一部のスクリプトでも困難です。
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で最も使用されるものは、一般に「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は、「ISO/IEC JTC 1/SC 2 WG2」と呼ばれるグループによって制御されており、多くの場合「SC2/WG2」または「WG2」と呼ばれます。ISO規格は、終了する前に多くのステップを経て、数年は、ユニコードの変更を追跡するために修正が発行されていますが、ベース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 = 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フォームで利用できます。標準を引用する方法の1つの例は、[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]は、国と領土の名前とコードの略語を指定し、国コードのトップレベルドメイン名の名前を含むいくつかのプロトコルとデータベースで使用されています。情報とドキュメントに関するISO TC 46の責任<http://www.iso.org/iso/standards_development/ technical_committees/list_of_iso_technical_committees/iso_technical_committee.htm？。
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/SC22/WG20でした。これは、国際文字列の注文など、JTC 1の国際化を担当していました。WG20およびその作業製品に関する情報は、<http://www.dkuug.dk/jtc1/sc22/wg20/>にあります。SC22/WG20の特定のタスクはSC22からSC2に移動し、それが発生して以来、ほとんど有意な活動はありませんでした。
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.
国際キャラクター標準の2番目の重要なグループは、Unicodeコンソーシアムです。Unicode Consortiumは、Unicode標準[Unicode]の促進に関心のある企業、政府、および他のグループの業界団体です。Unicode標準は、レパートリーとコードポイントがISO/IEC 10646と同一のCCSです。Unicodeコンソーシアムは、各文字の属性を定義するなど、プロトコルでより有用な機能をベース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コンソーシアムの実際の技術的および定義的作業は、Unicode Technical Committee（UTC）で行われます。「UTC」と「Unicodeコンソーシアム」という用語は、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 Consortiumは、Unicodeの技術レポートとしてUnicode標準への補遺を公開しています。成熟度のさまざまな段階では、多くの種類の技術レポートがあります。Unicode Standard and Affiliatedの技術レポートは、<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.
Unicode Consortiumと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
IETF文字セットポリシー[RFC2277]が確立され、この用語仕様の最初のバージョンが公開されたとき、IETFコミュニティでは、可能な場合はISO/IEC 10646（Unicodeではなく）への参照を強く好みました。その好みは、コンソーシアムからの仕様に関する確立されたオープンな国際基準を参照するためのより一般的なIETFの好みを主に反映しています。ただし、文字プロパティとクラスのユニコード定義はISO/IEC 10646の一部ではありません。IETF仕様はこれらの定義にますます依存しているため
(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.
（たとえば、セクション4.2の説明を参照）、Unicode仕様は便利な機械可読形式でオンラインで自由に利用できます。IETFの好みは、Unicode標準の参照にシフトしました。後者は、コードポイント（標準）とUnicodeプロパティ（Unicodeのみ）の間のバージョンの一貫性が必要な場合に特に重要です。
World Wide Web Consortium (W3C)
ワールドワイドウェブコンソーシアム（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).
多くのネイティブのCCSと充電器があるように、それらを作成およびサポートするための多くのローカルおよび地域の標準団体があります。これらの一般的な例は、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 CCの文字は、多くの方法で表現できます。歴史的に、「エンコーディングフォーム」はどちらも直接的なアドレス指定方法であり、「変換形式」はエンコードフォームをワイヤのビットとして表す方法です。その区別は近年ほとんど消えています。
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.
ISO/IEC 10646 CCの文字について議論するドキュメントは、特定の文字をリストする必要があることがよくあります。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用に歴史的に定義されている2つのエンコードフォームです。UCS-2はBMPのみに対処します。多くの有用なキャラクター（多くのHAN文字など）が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は、ISO/IEC 10646（ISO/IEC JTC 1 SC2とUnicodeコンソーシアムの間の一致、0..0x10FFFFの範囲）からのコードポイントの全範囲に対処します。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固有の定義は、Unicode標準の最近のバージョンの定義と同じです（例：バージョン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標準（バージョン6.0のセクション3.9および16.8）で定義されている3つの変換形式は、IETF標準では必要ありません。UTF-8よりもプロトコルでは少ない。BMPの文字は常に2つのオクテットとしてエンコードされ、BMPの外側の文字は「代理ペア」アレンジメントを使用して4オクテットとしてエンコードされます。後者はUCS-2の一部ではなく、UTF-16と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.
Unicode ConsortiumとISO/IEC JTC 1は、UTF-32を32ビットフィールドで正解した整数コードポイント値を組み込んだ変換形式として定義しています。UTF-16と同様に、バイトオーダーマーク（BOM）を使用でき、UTF-32BEとUTF-32LEが定義されています。UTF-32とUCS-4は本質的に同等であり、条件はしばしば同じ意味で使用されます。
SCSU and BOCU-1
SCSUおよびBOCU-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.
Unicodeコンソーシアムは、典型的なテキストに適した圧縮を提供するように設計されたエンコーディング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.)
Punycodeアルゴリズム[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が開発される前に、多くの国が独自のCCSと炭火を開発しました。これらのいくつかは、関連するスクリプトまたはライティングシステムの国際基準に採用されました。これらの多くは、今日インターネットで一般的に使用されています。例には、キリル語のISO 8859-5および日本のスクリプトのシフトJIが含まれます。
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プロトコルで使用する登録されたcharSet名の公式リストは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.
おそらく最もよく知られているネイティブCCはASCII [US-ASCII]です。このCCSは、多くのIETFプロトコルのキーワードとパラメーター名の基礎として、およびまだ国際化されていない多数のIETFプロトコルの唯一のCCとして使用されます。ASCIIは、ISO/IEC 646の基礎となりました。これにより、基本的なラテン文字と別のスクリプトのキャラクターを組み合わせたISO 8859シリーズなど、多くの国内および国際的な基準の基礎を形成しました。
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 Publicationは、充電器間の文字データのマッピングに関連する問題と、テーブルデータのマッピング用のXML形式[UTR22]を説明しています。
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].
非結合キャラクターで構成されるグラフィック文字のシーケンスに続いて、1つ以上の組み合わせ文字が続きます。コンポジットシーケンスのグラフィック記号は、一般に、シーケンス内の各文字のグラフィック記号の組み合わせで構成されています。Unicode標準は、多くの場合、「文字シーケンスを組み合わせて」という用語を使用して、複合シーケンスを参照します。複合シーケンスは文字ではないため、ISO/IEC 10646のレパートリーのメンバーではありません。<ISOIEC10646>ただし、Unicodeは、特に他の標準の用語と一致する必要がある場合に名前をそのようなシーケンスに割り当てるようになりました[UAX34]。
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".
一部のCCSでは、一部の文字は他の文字の組み合わせで構成されています。たとえば、「鋭いa」という文字は、2人のキャラクター「A」と「鋭い結合」の組み合わせであるか、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> <combining tilde>」や「<nとtilde>」などの同じ複合文字を形成することを目的とした異なる文字シーケンスを統合することを意味します（「<n>」はu 006e、 "<Tilde>を組み合わせることはu 0303であり、「<n with tilde>」は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> <Tilde> <o>を組み合わせて」と「<a> <nをTilde> <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では、「Canonicalization」または同様の用語を使用して、特定のタイプの正規化の等価性（「互換性の等価性」とは対照的に「標準等価」）を参照するため、用語はある程度注意して使用する必要があります。一部のCCSは、書かれた文字列の複数の等価表現を許可します。正規化は、文字列を比較する際に参照目的のベースとして複数の等価表現の1つを選択します。テキストの文字列では、これらのルールは通常、複合文字の分解または文字を組み合わせた文字を作成することに基づいています。Unicode Standard Annex＃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のマッピングがあります（常にではありませんが）。ただし、あるケースに存在するが、他のケースには対応する文字がない、またはトルコのドットレス「私」など、モディファイヤーを持つギリシャ文字など、特別なマッピングルールがある文字の例はたくさんあります。そして、ドイツのシャープ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>
照合は、テキスト情報の単位を注文するプロセスです。照合は通常、特定の言語または特定のアプリケーションまたはロケールにさえ固有です。アルファベット順は、ソートと照合の特別なケースにすぎませんが、アルファベット化として知られています。<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文字内であっても、「A、A、B、B、...」と「A、B、C、...、Z、A、B、」という2つの一般的で非常に異なる照合順序があります。.. "、小文字の追加のバリエーションと文字の前後に数字が追加されます。
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.
コードポイントの注文は通常、地元の学校システムによって教育を受けた人間が文字列が注文されることを期待する方法ではありません。人間の期待を注文する場合、「言語固有の」または「人間の言語」ソートがあります。コードポイントの順序へのソートは、同じ文字の異なる表現が異なるソートを行うため、ソートする前に文字列が正規化されない場合、一貫性がないように見えます。この問題は、言語固有の種類では小さくなる可能性があります。
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.
文字のタイプの次の定義は、各文字を1つのタイプに明確に描写したり、誰かが特定の文字に適用されるタイプを正確に予測することもできません。定義は、アプリケーションデザイナーがテキストの多くの（時には混乱する）プロパティについて考えるのを助けることを目的としています。
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プロパティ。組み合わせまたは非結合であろうと、アルファベットおよび/または音節の主要な単位であるキャラクター。これには、アルファベットのベース文字の組み合わせ文字シーケンスと1つ以上の組み合わせ文字の組み合わせ文字シーケンスに相当する標準的な複合文字が含まれます。アルファベット文字のコンテキストバリエーション。アルファベット文字の結晶;結晶の文脈的バリエーション。モディファイア文字;単一のアルファベット文字の互換性と同等の文字のような記号。およびその他の文字要素。<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>
サウンド（または発音）とは対照的に、主にアイデア（または意味）を示すシンボル、たとえば、中国語、日本、韓国語で使用されている電話やHAN文字を示すシンボル。<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や他の多くのシステムは、この用語を使用してすべてのHAN文字を参照していますが、厳密に言えば、これらのキャラクターのすべてが実際には表現撮影であるわけではありません。一部は絵文字（上記の電話の例など）、音声で使用されるなどもあります。ただし、条約は、スクリプトをアルファベットとは対照的であると表現撮影として説明することです。
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>
修正された値または新しい値を表す新しいシンボルを作成するために、記号に適用または添付されたマーク。また、そのシンボルの値を変更するかどうかに関係なく、シンボルにマークを適用することもできます。後者の場合、Diacriticは通常、独立した値（たとえば、アクセント、トーン、または他の言語情報など）を表します。また、ディアチカルマークまたはダイアクリティカルとも呼ばれます。<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>
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（フル幅の感嘆符）は、完全な幅および半幅の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のいくつかの努力は、互換性の相当量のマッピングをサポートすることは有用であり、他の互換性と他のグループではなく、数学的なバリエーションを保存または拒否しながら幅の変動をサポートまたはマッピングすること）をサポートすることが有用であると結論付けています。一例については、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はオープンエンドで、新しい文字定義があり、多くの場合新しいスクリプトが追加されていることを覚えておくことが重要です。年かそこら。したがって、たとえば、「大文字」などのASCIIサブセットは、コードポイントの範囲（その例では4/1〜5/10）として指定できますが、Unicodeの同様の定義は、いずれかで指定する必要があります。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レパートリーに登場する文字以外の文字を厳密に指します。実際には、Unicodeのようなレパートリーがコンテキストとして確立されている場合、「非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はユーザーインターフェイスを標準化していませんが、多くのプロトコルは、ユーザーがプロトコルで使用されているテキストをどのように入力または表示するかについて仮定します。Internationalizationは、さまざまなプロトコルを使用するアプリケーションで使用できる入力および出力デバイスのタイプと制限に関する仮定に挑戦します。したがって、ユーザーが通常、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.
テキストは、多くの点でコンピューターに入力できます。キーボードは使用される最も一般的なデバイスですが、多くの文字を1回のストロークで一般的なコンピューターキーボードに入力することはできません。多くのオペレーティングシステムには、ユーザーがキーボードで許可されているものの範囲外に文字を入力できるシステムソフトウェアが付属しています。
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.
たとえば、中国語、日本、韓国語のHANキャラクターには数十種類の入力方法があります。キーボードからの音声入力から始まるものもあれば、キャラクターのストローク数を使用するものもあります。また、単一のアルファベット文字に2つまたは3つのダイアティックスを持っているヨーロッパやベトナムのキャラクターなど、多くのディークリティクスを持つスクリプトにも入力方法が必要です。
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.
* アラビア語（および他の多く）などのスクリプト。文字が単独で立っているかどうか、単語の途中、または単語の途中、または最後に、文字の形式が隣接する文字に依存して変化します。語。レンダリングルールは、2つ以上のグリフから選択する必要があります。
* 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.
* インドのスクリプトなどのスクリプトは、特定の他の子音に隣接している場合、または保存および発音の方法とは異なる順序で表示される場合、子音がフォームを変更する場合があります。レンダリングルールは、2つ以上のグリフから選択する必要があります。
* 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.
* 一部のライティングシステムは、現在ユニコード標準で定義されているメカニズムを使用して、レンダリングルールを適切に定義することはできません。これらの言語はどれも、今日活動的ではないものではありません。
* 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>
フォントは、文字データの視覚的描写に使用されるグリフのコレクションです。フォントは、多くの場合、一連のパラメーター（サイズ、姿勢、重量、セリフネスなど）に関連付けられており、特定の値に設定すると、画像のコレクションが生成されます。<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
「フォント」という用語は、「書体」と同じ意味で使用されることがよくあります。タイポグラフィで歴史的に使用されているように、書体は、一般的な一般的なデザインを共有する1つ以上のフォントのファミリーです。たとえば、「Times Roman」は実際にはフォントのコレクションがある書体です
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.
「タイムズローマ太字」、「タイムズローマのミディアム」、「タイムズローマイタリック」などなど。一部のソースでは、書体内の異なるタイプサイズを異なるフォントであると考えています。これらの区別は国際化の目的ではめったに重要ではありませんが、例外があります。これらの仕様を書くことは、例外が曖昧さにつながる可能性のある場合の定義について非常に注意する必要があります。
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>
左から右へのテキストと左から左のテキストを単一行で混合したプロセスまたは結果は、双方向ディスプレイと呼ばれ、しばしば「bidi」と略されます。<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-Arabic Nastaliqueの執筆スタイルとアラビア語のNaskhライティングスタイルはどちらもアラビア語のスクリプトを使用していますが、レンダリングは非常に異なり、相互に理解できません。スタイルを書くことは、国際化に大きな影響を与える可能性があります。たとえば、Nastaliqueの執筆スタイルには、Naskhのライティングスタイルよりもはるかに多くのラインの高さが必要です。
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.
インターネットプロトコルの多くの項目は、名前を使用して特定のインスタンスまたは値を識別します。名前は（規定された規則によって）生成され、中央に登録されている（IANAなど）、DNSの名前などの分散登録および制御メカニズムがある場合があります。
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.
一部のプロトコルでは、テキストフィールドの無料テキストが解析される場合があります。たとえば、多くのメールユーザーエージェント（MUAS）は、「Re：」プレフィックスの後に表示されるものに基づいてスレッドに基づいてスレッドを試してみようとするフィールドの単語を解析します。
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.
このような慣習は、ローカリゼーションに非常に敏感です。たとえば、「Re：」のようなフォームが、送信者または受信者の言語を反映するために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".
同じ場所で複数のチャーセットを使用できるプロトコルでは、テキストを適切なcharsetで識別する必要があります。この識別がなければ、テキストを調べるプログラムは、テキストのcharsetを明確に識別することはできません。charset識別は「charsetタグ付け」とも呼ばれます。
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 (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は、RFCS 2045から2049、および最近のRFCで説明されています。<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>
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>
引用されたPrintableは、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（ISO/IEC 10646プレーン0のUTF-16BE形式の文字が含まれます。）、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互換のエンコードスキーム（実際に転送された構文）が、ホスト名やその他の目的を国際化するための可能なソリューションとして提案されています。彼らの目標は、ドメイン名の優先構文を使用して、ISO/IEC 10646文字の文字列をエンコードできることです（STD 13で説明されています）。この執筆時点では、Punycode [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].
レガシープロトコルを国際化するためのACEフォームの選択は、困難な副作用を引き起こす可能性があるため、注意して行う必要があります[RFC6055]。
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定義」として知られているこれらのドキュメントの最初のセクション2.3 [RFC5890]は、定義を提供し、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-Labelドメイン名スロットIDNA-VALID文字列国際化ドメイン名（IDN）国際化ラベルLDHラベル非予測LDHラベル（NR-LDHラベル）Uラベル
Two additional terms entered the IETF's vocabulary as part of the earlier IDN effort [RFC3490] (IDNA2003):
以前のIDN努力の一環として、IETFの語彙に2つの追加項が入力されました[RFC3490]（IDNA2003）：
Stringprep
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>
StringPrep [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.
これは、Unicodeで発現したネイティブキャラクター文字列からASCII互換エンコード（ACE）に発現するネイティブキャラクター文字列から、それ以外のValid 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:
最近では、この用語は、同等と認識される可能性のあるキャラクターや文字列の他のコレクションを説明するためにも使用されています。これらのコレクションには、以下を含む、それらを含む文字とラベルのいくつかのカテゴリの1つ以上が含まれています。
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コードポイントを割り当てた文字。これらのキャラクターは、一部の目的では「同じ」と見なされ、他のキャラクター（または他のユーザー）によって異なる場合があります。最も一般的に引用されている例の1つは、アラビアYehです。これは、その形の一部が異なる言語で異なるため、複数回エンコードされています。もう1つの例は、ギリシャの小文字シグマと最後のシグマです。後者が純粋に前者の位置表示のバリエーションと見なされている場合、別のコードポイントを割り当てるべきではありません。
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 それらを含む数字とラベル。文字とは異なり、10進数桁の「意味」は、それらが関連付けられているスクリプトに関係なく明確で明確です。一部のスクリプトは、そのスクリプトに固有のヨーロッパの数字と数字とほぼ同じ意味で使用されています。アラビア語のスクリプトには、2セットの数字（U 0660..U 0669およびU 06F0..U = 06F9）があり、3〜7〜9から9から9つまでゼロと書かれています。ヨーロッパの数字は他の地域で支配的です。ラベルで同じ数値を持つ数字の置換により、別のタイプのバリアントが生じる可能性があります。
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-umlautまたは「oe」などのドイツ語の単語などが含まれます。これらの関係の一部は、同じスクリプトを使用して他の言語には存在しない他のタイプの言語固有の知覚違いを作成する場合があります。たとえば、言葉の終わりにあるアラビア語の使用では、アラビア文字Teh Marbuta（U 0629）とアラビア文字Heh（U 0647）は異なって形をしています（1つは2つのドットがあります）が、それらは互換性があります。：フレーズの最後に発音された場合、それらは「聞こえる」ため、その文字は文字として書かれていることがあり、2つはその文脈で「混乱しやすい」と見なされます。
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での国際化の議論に登場した他の用語のホッジポッジです。
locale
ロケール
Locale is the user-specific location and cultural information managed by a computer. <RFC6365>
Localeは、コンピューターによって管理されるユーザー固有の場所と文化情報です。<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レパートリー全体を参照するためにさまざまなコンテキストで使用されているためです。Unicodeおよびその他のコレクションで定義されている拡張ラテンスクリプトのすべてのコードポイントは、可能であれば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文字とhan文字
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.
HANの文字には、日本語と韓国語で使用される音声キャラクターは含まれていないことに注意してください。「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では、HAN文字は「統一」されていました。つまり、同じ起源を持っていた日本、中国語、韓国語の各セットには、単一のコードポイントが割り当てられています。これの肯定的な結果は、HANを表すために必要なコードポイントがはるかに少ないことでした。これの否定的な結果は、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.
多くのスクリプトの音訳は正確であり、多くは完璧な往復マッピングを持っています。これの顕著な例外は、上記のローマ化です。音訳には、1つのスクリプトで表現されたテキストを別のスクリプトに変換することが含まれます。一般に文字ごとにレターごとに行われます。多くの公式および非公式の音訳基準があり、最も顕著なのは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コンソーシアムは、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>
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つのトークンを比較することが含まれ、それらのトークンの1つまたは両方がテキストである場合があります。したがって、いくつかの比較方法には、このドキュメントで用語が定義されている国際化の概念の一部を使用することが含まれる場合があります。
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。InternationalStandard -Information Technology -Universal Multis -OCTETコード化された文字セット（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 Consortium、「Unicode Standard、バージョン6.0」、（Mountain View、CA：The Unicode Consortium、2011。ISBN978-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、「World Wide Web 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.
[フレームワーク] 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：Alpha -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.、Stahl、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] Braden、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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Hoffman、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] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（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] Hoffman、P。およびM. Blanchet、「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] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、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] Konishi、K.、Huang、K.、Qian、H。、およびY. Ko、「国際化されたドメイン名の共同工学チーム（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] Phillips、A。およびM. Davis、「言語タグのマッチング」、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] Lee、X.、Mao、W.、Chen、E.、Hsu、N。、およびJ. Klensin、「中国ドメイン名の登録と管理の推奨事項」、RFC 4713、2006年10月。
[RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", BCP 137, RFC 5137, February 2008.
[RFC5137] Klensin、J。、「Unicode文字のASCII脱出」、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、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]クレンシン、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。、「アプリケーションのユニコードコードポイントと国際化ドメイン名（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] Resnick、P。およびP. Hoffman、「アプリケーションの国際化ドメイン名のマッピング文字（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] Thaler、D.、Klensin、J。、およびS. Cheshire、「国際化されたドメイン名のエンコーディングに関する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 Consortium、「Unicode Standard Annex＃34：Unicode named Character Sequences」、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 Consortium、「Unicode Standard Annex＃9：Unicode Biderectional Algorithm」、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、「コード化された文字セット - 情報交換のための7ビットアメリカ標準コード、ANSI X3.4-1986」、1986。
[UTN6] The Unicode Consortium, "Unicode Technical Note #5: BOCU-1: MIME-Compatible Unicode Compression", 2006, <http://www.unicode.org/notes/tn6/>.
[UTN6] Unicode Consortium、「Unicode Technical Note＃5：Bocu-1：MIME互換ユニコード圧縮」、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 Consortium、「Unicode Standard Annex＃15：Unicode Normazing Forms」、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 Consortium、「Unicode Standard Annex＃18：Unicode Reglemans Expressions」、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 Consortium、「Unicode Technical Standard＃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 Consortium、「Unicode Technical Standard＃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-DEF] W3C、「ローカリゼーション対国際化」、2010年9月、<http://www.w3.org/international/ question/qa-i18n.en>。
Barry, Randall, ed. ALA-LC Romanization Tables. Washington: U.S. Library of Congress, 1997. ISBN 0844409405
バリー、ランドール、編ALA-LCロマン化テーブル。ワシントン：米国議会図書館、1997年。ISBN0844409405
Coulmas, Florian. Blackwell Encyclopedia of Writing Systems. Oxford: Blackwell Publishers, 1999. ISBN 063121481X
クルマス、フロリアン。Blackwell Writing Systemsの百科事典。オックスフォード：Blackwell Publishers、1999。ISBN063121481X
Dalby, Andrew. Dictionary of Languages: The Definitive Reference to More than 400 Languages. New York: Columbia University Press, 2004. ISBN 978-0231115698
ダルビー、アンドリュー。言語辞書：400を超える言語への決定的な参照。ニューヨーク：コロンビア大学出版局、2004年。ISBN978-0231115698
Daniels, Peter, and William Bright. The World's Writing Systems. New York: Oxford University Press, 1996. ISBN 0195079930
ダニエルズ、ピーター、ウィリアムブライト。世界のライティングシステム。ニューヨーク：オックスフォード大学出版局、1996年。ISBN0195079930
DeFrancis, John. The Chinese Language: Fact and Fantasy. Honolulu: University of Hawaii Press, 1984. ISBN 0-8284-085505 and 0-8248-1058-6
デフランシス、ジョン。中国語：事実とファンタジー。ホノルル：ハワイ大学出版局、1984年。ISBN0-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年。ISBN0-500-28068-1
Fazzioli, Edoardo. Chinese Calligraphy. New York: Abbeville Press, 1986, 1987 (English translation). ISBN 0-89659-774-1
ファジオリ、エドアルド。中国の書道。ニューヨーク：Abbeville Press、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。、他過去を読む：cuneiformからアルファベットへの古代の執筆。ロンドン：British Museum Press、1990。ISBN0-7141-8077-7
Lunde, Ken. CJKV Information Processing. Sebastopol, CA: O'Reilly & Assoc., 1999. ISBN 1-56592-224-7
ルンデ、ケン。CJKV情報処理。セバストポル、カリフォルニア州：O'Reilly＆Assoc。、1999。ISBN 1-56592-224-7
Nakanishi, Akira. Writing Systems of the World. Rutland, VT: Charles E. Tuttle Company, 1980. ISBN 0804816549
中島、アキラ。世界のシステムを書く。バージニア州ラトランド：チャールズE.タトルカンパニー、1980年。ISBN0804816549
Robinson, Andrew. The Story of Writing: Alphabets, Hieroglyphs, & Pictograms. London: Thames & Hudson, 1995, 2000. ISBN 0-500-28156-4
ロビンソン、アンドリュー。執筆の物語：アルファベット、象形文字、および絵文字。ロンドン：テムズ＆ハドソン、1995、2000。ISBN0-500-28156-4
Sacks, David. Language Visible. New York: Broadway Books (a division of Random House, Inc.), 2003. ISBN 0-7679-1172-5
サックス、デビッド。言語が表示されます。ニューヨーク：ブロードウェイの本（ランダムハウス社の一部門）、2003年。ISBN0-7679-1172-5
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.
ジェームズ・センは、RFC 3536の最初の概要に貢献しました。ハラルド・アルベスランドとマーティン・デュエルストは、初期のバージョンについて広範な有用なコメントをしました。RFC 3536の開発に貢献した他の人には、ダンコーン、ジェイコブパルメ、ヨハンヴァンウィンゲン、ピーターコンスタブル、ユーリデムチェンコ、スーザンハリス、ジータウェンツェル、ジョンクレンシン、ヘニングシュルツリンヌ、レスリーデイグレ、マークスシェラー、ケンウィスラーが含まれます。
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.
Abdulaziz Al-Zoman、Tim Bray、Frank Ellermann、Antonio Marko、JFC Morphin、Sarmad Hussain、Mykyta Yevstifeyev、Ken Whistlerなどは、この新しいバージョンで重要な問題を特定するか、具体的な提案をしました。
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-Label 31 ACE 30、31 ACE Prefix 31 Alphabetic 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 Basic Multilingual Plane 13 Bidi 26 Bidirectional Display 26 BMP 13 BMPSTRING 30 BOCU-1 14 BOM 14 BYTE ORDER MARK 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
C C-T-E 29ケース18 CCS 7 CEN/ISS 13文字6文字エンコードフォーム7文字エンコードスキーム8文字レパートリー7チャーセット識別28 CJK文字34コードチャート19コードチャート16コード表19コード文字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
コード化された文字セット7照合18組み合わせキャラクター16キャラクターシーケンスを組み合わせた16互換性キャラクター22互換性バリアント22コンテンツシーケンス16コンテンツ転移エンコード29コントロールキャラクター21コントロールコード22 22 22
D decomposed character 16 diacritic 21 displaying and rendering text 10 Domain Name Slot 31
D分解された文字16 Diacritic 21テキスト10ドメイン名スロットの表示とレンダリング31
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 Glyph 7 Glyphコード7グラフィックシンボル25
H Han characters 34
H HAN文字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 IDEOGRAPHIC 20 IDN 31 IDNA 31 IDNA-VALID STRING 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 11 ISO 639 11 ISO 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 L10N 9言語5言語識別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 NONSASCII 23 NONSPACEING CHARACTER 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 PREComposed Character 16 PrintableString 30プライベート使用36プロトコル要素27句読点21 Punycode 30、31
Q quoted-printable 29
Q引用符で囲まれた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 Surrogateペア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-label 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
Vバリアント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
X XML 13、30
Authors' Addresses
著者のアドレス
Paul Hoffman VPN Consortium
ポール・ホフマンVPNコンソーシアム
EMail: paul.hoffman@vpnc.org
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、STE 322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 245 1457
EMail: john+ietf@jck.com