[要約] 要約：RFC 5242は、西ヨーロッパとCJK（中国語、日本語、韓国語）の文字コードを統一するための一般化された統一文字コードに関するものです。 目的：西ヨーロッパとCJKの文字コードを統一し、相互運用性と国際化を向上させることを目指しています。
Network Working Group J. Klensin
Request for Comments: 5242
Category: Informational H. Alvestrand
Google
1 April 2008
A Generalized Unified Character Code: Western European and CJK Sections
一般化された統一文字コード：西ヨーロッパとCJKセクション
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESGノート
This is not an IETF document. Readers should be aware of RFC 4690, "Review and Recommendations for Internationalized Domain Names (IDNs)", and its references.
これはIETFドキュメントではありません。読者は、RFC 4690、「国際化されたドメイン名（IDNS）のレビューと推奨事項」、およびその参照に注意する必要があります。
This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
このドキュメントは、インターネット標準のレベルの候補ではありません。IETFは、あらゆる目的のためにこのドキュメントのフィットネスに関する知識を放棄します。特に、セキュリティ、混雑制御、展開プロトコルとの不適切な相互作用などのIETFレビューはなかったことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。
Abstract
概要
Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set.
国際化されたドメイン名と同様の目的に汎用文字セットを使用することで、多くの問題が特定されています。このメモは、ラテン語、ギリシャ語、キリル語、中国語（CJK）文字に基づいたスクリプトの完全に統一されたコード化された文字セットについて説明しています。その文字セットの完全な仕様ではありません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Types of Characters . . . . . . . . . . . . . . . . . . . . . 4
2.1. Base Character . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Nonspacing Marks . . . . . . . . . . . . . . . . . . . . . 4
2.3. Case Indicators . . . . . . . . . . . . . . . . . . . . . 4
2.4. Joining Indicators . . . . . . . . . . . . . . . . . . . . 5
2.5. Character-Matrix Positioning Indicators . . . . . . . . . 5
2.6. Position Shaping Controls . . . . . . . . . . . . . . . . 6
2.7. Repetition Indicators . . . . . . . . . . . . . . . . . . 6
2.8. Control Characters . . . . . . . . . . . . . . . . . . . . 7
3. Code Assigment Groupings . . . . . . . . . . . . . . . . . . . 7
4. Canonical Form . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Examples of Graphic Element Codes . . . . . . . . . . . . . . 8
6. Composite Characters and Unicode Equivalences . . . . . . . . 10
7. Ideographic Characters . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo specifies a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese characters.
国際化されたドメイン名と同様の目的に汎用文字セットを使用することで、多くの問題が特定されています。このメモは、ラテン語、ギリシャ語、キリル語、漢字に基づいたスクリプトの完全に統一されたコード化された文字セットを指定します。
There are four important principles in this work:
この作業には4つの重要な原則があります。
1. If it looks alike, it is alike. The number of base characters and marks should be minimized. Glyphs are more important than character abstractions.
1. 似ているなら、似ています。ベース文字とマークの数を最小限に抑える必要があります。グリフは、キャラクターの抽象化よりも重要です。
2. If it is the same thing, it is the same thing. Two symbols that have the same semantic meaning in all contexts should be encoded in a way that allows their identity to be discovered by removing modifiers, rather than having to resort to external equivalence tables.
2. それが同じものであれば、それは同じことです。すべてのコンテキストで同じ意味の意味を持つ2つのシンボルは、外部の等価表に頼るのではなく、修飾子を削除することによってアイデンティティを発見できるようにする方法でエンコードする必要があります。
3. For simplicity, when a character form can be evaluated on the basis of either serif or sanserif fonts, the sanserif font is always preferred.
3. 簡単にするために、文字フォームをSerifまたはSanserifフォントのいずれかに基づいて評価できる場合、Sanserifフォントが常に推奨されます。
4. The use of combining characters and modifiers is preferred to adding more base characters.
4. キャラクターと修飾子を組み合わせた使用は、より多くのベース文字を追加する方が推奨されます。
Based on these principles, it becomes obvious that:
これらの原則に基づいて、それは明らかになります：
o Ligatures, digraphs, and final forms are constructed with special modifiers so that relationships to basic forms are obvious.
o 結晶、gigraph、および最終フォームは、基本的な形式との関係が明らかになるように特別な修飾子で構築されています。
o Symbols consisting of multiple marks are always constructed from combining characters and positional modifiers; thus, the "i" character is constructed from the vertical line symbol followed by a combining dot above. Similarly "f" is composed of a centered vertical line, a right hook in the top position, and an appropriately-positioned composing hyphen.
o 複数のマークで構成されるシンボルは、常に文字と位置修飾子を組み合わせることから構築されます。したがって、「i」文字は、垂直ラインシンボルから構成され、その後に上記の組み合わせドットが続きます。同様に、「F」は、中央の垂直線、上部の位置の右フック、適切に位置するハイフンで構成されています。
This document draws strongly from the design and terminology of Unicode [Unicode] but represents a radically different approach.
このドキュメントは、Unicode [Unicode]の設計と用語から強く描かれていますが、根本的に異なるアプローチを表します。
All special-use terms in this document, including descriptions of behaviors and related relationships, are used with their common-sense meanings.
行動や関連する関係の説明を含む、このドキュメントのすべての特別な用語は、それらの常識的な意味で使用されます。
Questions to, and contributions for, this coding system should be addressed to the mailing list unified-ccs@xn--iwem3b1f.xn--90ase1a.bogus.domain.name.
このコーディングシステムへの質問と貢献は、メーリングリストUnified-ccs@xn - iwem3b1f.xn - 90ase1a.bogus.domain.nameに宛ててください。
This document defines several types of characters. Note that these definitions are not the same as the Unicode definitions for similar or identical terms.
このドキュメントでは、いくつかのタイプの文字を定義します。これらの定義は、同様または同一の用語のユニコード定義と同じではないことに注意してください。
Any character that is used as an atomic shape, rather than being assembled from such a character in combination with combining (overstriking) marks, symbols, or specially-designed base characters. When used alone, base characters always take up space. For example, a, c, l,...
そのようなキャラクターから組み合わせて組み合わせて（オーバーストライキ）マーク、シンボル、または特別に設計されたベース文字を組み合わせて組み立てるのではなく、原子形として使用されるキャラクター。単独で使用すると、ベース文字は常にスペースを取ります。たとえば、a、c、l、...
Marks, symbols, and character components that are used to form characters when used in combination with base characters. They do not occupy separate character positions when displayed.
ベース文字と組み合わせて使用すると文字を形成するために使用されるマーク、シンボル、および文字コンポーネント。表示されたときに個別の文字位置を占有しません。
For example, the special combining symbols LeftUpperHook and RightLowerHook, described in Section 5, are nonspacing marks.
たとえば、セクション5で説明されている特別な組み合わせシンボルLeftupperhookとrightlowerhookは、マークのままです。
In scripts with case, only the lower-case characters are base characters. Upper-case forms are represented by using the UC modifier. So the traditional "A" character is represented by "a<UC>". Note that this means that case-independent comparisons are made simply by ignoring the <UC> modifiers rather than by complicated mapping operations.
ケースのスクリプトでは、低ケース文字のみがベース文字です。UC修飾子を使用して、上部ケースのフォームが表されます。したがって、伝統的な「a」キャラクターは「a <uc>」で表されます。これは、複雑なマッピング操作ではなく<uc>モディファイ因子を無視するだけで、ケースに依存しない比較が行われることを意味することに注意してください。
The initial set of case modifiers consists exclusively of:
ケース修飾子の初期セットは、次のようにのみ構成されています。
UC Upper-case, code value 1 (hexadecimal)
UCアッパーケース、コード値1（16進数）
The code values two through four are reserved for the impending encoding of scripts with more than two cases; five is reserved for expansion in case a script with more than four cases is identified.
コード値2〜4は、2つ以上のケースを持つスクリプトの差し迫ったエンコードのために予約されています。5つ以上のケースが識別されたスクリプトが特定された場合、5つは拡張のために予約されています。
Zero-width joiners are used to build characters, not only to separate or join words. As compared to Unicode, a richer set of joiners is used to distinguish between the inter-word and ligature-forming (including half-character forming) cases. Unicode ZWJ and ZWNJ are supplemented by ZWCJ, OJ, and ONJ. ZWCJ is used to modify a spacing basic character into a nonspacing role. For example, there is no "w" character, but only "u<ZWCJ>u". Upper-case "W" is coded as u<ZWCJ>u<UC> -- the CWCJ binds more tightly than the UC modifier.
ゼロ幅のジョイナーは、単語を分離または結合するだけでなく、文字を構築するために使用されます。Unicodeと比較して、より豊富な一連のジョイナーを使用して、単語間形成と結晶形成（ハーフキャラクター形成を含む）のケースを区別します。Unicode ZWJとZWNJには、ZWCJ、OJ、およびONJが補完されます。ZWCJは、間隔の基本文字を非歩行の役割に変更するために使用されます。たとえば、「w」文字はありませんが、「u <zwcj> u」のみがあります。上部ケース「W」はu <zwcj> u <uc>としてコード化されています - CWCJはUC修飾子よりもしっかりと結合します。
The initial set of joining indicators consists exclusively of:
結合インジケーターの初期セットは、次のようにのみ構成されています。
ZWCJ Character joiner (also known as "ligature joiner"), code value 6 (hexadecimal).
ZWCJキャラクタージョイナー（「ligature joiner」とも呼ばれます）、コード値6（16進数）。
OJ Overlay joiner (permits use of a subsequent character that would normally be spacing as nonspacing), code value 7 (hexadecimal).
OJオーバーレイジョイナー（通常は非歩行として間隔を置く後続の文字の使用を許可します）、コード値7（16進数）。
ONJ Overlay non-joiner (turns a nonspacing mark into a standalone character), code value 8 (hexadecimal). This joiner should not be necessary, and is normally prohibited by the "shortest string" rule. But there may be unanticipated cases.
ONJオーバーレイ非ジョイナー（非歩行マークをスタンドアロン文字に変換）、コード値8（16進数）。このジョイナーは必要ではなく、通常は「最短の文字列」ルールによって禁止されています。しかし、予期しないケースがあるかもしれません。
ZWJ Zero-width joiner for words or word-like constructions, code value 9 (hexadecimal).
ZWJ Zero-width単語または単語のような構造、コード値9（16進数）。
ZWNJ Zero-width non-joiner for words or word-like constructions, code value A (hexadecimal).
ZWNJ Zero-Width単語または単語のような構造のための非幅の非ジョイナー、コード値A（16進数）。
Many characters are defined by constructed glyphs using nonspacing marks. For example, the characters "b" and "d" are coded as o<VerticalLine><PositionLeft> and o<VerticalLine><PositionRight>, respectively. The Catalan ligature that has caused some difficulties in Internationalizing Domain Names in Applications (IDNA) [RFC3490] is coded as l<ZWCJ><.><PositionVMiddle><ZWCJ>l The initial table of positioning indicators is:
多くの文字は、非歩行マークを使用して構築されたグリフによって定義されます。たとえば、文字「b」と「d」は、それぞれo <verticalline> <positionleft>およびo <verticalline> <sostitionright>としてコーディングされます。アプリケーションの国際化ドメイン名（IDNA）[RFC3490]にいくつかの困難を引き起こしたカタロニアの結紮は、l <Zwcj> <。
+-------------------+-----------+
| Name | Hex value |
+-------------------+-----------+
| PositionLeft | 20 |
| PositionCenter | 21 |
| PositionRight | 22 |
| PositionTop | 30 |
| PositionVMiddle | 31 |
| PositionBottom | 32 |
| PositionDescender | 33 |
+-------------------+-----------+
These controls designate character form changes for initial or final-form characters. Where the distinction is important, medial-form characters are the default when no qualification occurs. As with case comparisons, comparisons are performed by ignoring these control functions.
これらのコントロールは、初期または最終型の文字の文字形式の変更を指定します。区別が重要な場合、資格が発生しない場合、内側形式の文字がデフォルトです。症例の比較と同様に、これらの制御機能を無視することにより、比較が実行されます。
+-------------+-----------+
| Name | Hex value |
+-------------+-----------+
| InitialForm | 71 |
| FinalForm | 72 |
+-------------+-----------+
For compactness of coding, two repetition indicators are introduced for double (Repeat2) and triple (Repeat3) characters that may be treated as ligatures or special cases. Two consecutive uses of a character compare equal to the character followed by <Repeat2>. The interpretation of u<ZWCJ>u<Repeat3> is left as an exercise for the reader.
コーディングのコンパクトさのために、二重（Repeat2）およびトリプル（Repeat3）文字について、字系または特別なケースとして扱われる可能性のある2つの繰り返し指標が導入されます。キャラクターの2つの連続した使用は、<prepot2>が続くキャラクターと等しいと比較されます。u <zwcj> u <propect3>の解釈は、読者の演習として残されています。
The initial table of repetition indicators is:
繰り返し指標の最初の表は次のとおりです。
+---------+-----------+
| Name | Hex value |
+---------+-----------+
| Repeat2 | 50 |
| Repeat3 | 51 |
| Repeat1 | 52 |
+---------+-----------+
For larger repeats, these repeats can be combined; the sequence <Repeat2><Repeat3> represents six repeats, while the <Repeat3><Repeat2> represents five repeats. Following the "shortest string" principle (see Section 4), Repeat1 must not ever appear except in combination with Repeat2 and/or Repeat3. The generation of other numbers is left as an exercise for the reader.
より大きな繰り返しの場合、これらの繰り返しを組み合わせることができます。シーケンス<Repeat2> <Repeat3>は6つのリピートを表し、<Repeat3> <Repeat2>は5つのリピートを表します。「最短文字列」の原則（セクション4を参照）に従って、Repeat2および/またはrepeat3との組み合わせを除いて、Repeat1が表示されてはいけません。他の数字の生成は、読者のための演習として残されています。
Because it is intended primarily for domain names, this specification has no provision for control or spacing characters.
主にドメイン名用に意図されているため、この仕様には制御または間隔の文字の規定はありません。
Following the reasoning used in Unicode [Unicode], every character occupies exactly 23 bits (conventionally stored as three octets, with the leading bit always zero). This value is chosen because both 3 and 23 are prime numbers, unlike 42.
Unicode [Unicode]で使用されている推論に続いて、すべてのキャラクターは正確に23ビットを占有します（従来は3オクテットとして保存され、先行ビットは常にゼロです）。この値は、42とは異なり、3と23の両方が素数であるために選択されます。
The code point value zero is permanently reserved and will not be used unless it is necessary to expand the code space.
コードポイント値ゼロは永久に予約されており、コードスペースを拡張する必要がない限り使用されません。
Code values between 1 and 255 (decimal) are reserved for the special character formation codes described in Section 2.3 through Section 2.7.
1〜255（小数）の間のコード値は、セクション2.3からセクション2.7で説明されている特別な文字形成コードに予約されています。
Code values between 256 and 511 (decimal) are reserved for character formation marks for non-ideographic characters. Most, but not all, of these are nonspacing (combining) characters.
256〜511（小数）の間のコード値は、非自証文字の文字形成マークのために予約されています。これらのすべてではありませんが、ほとんどの場合、ほとんどの場合、文字が非時代の（結合）文字です。
Code values between 512 and 1023 are reserved on general principles and in case it is necessary to invent new rules and make them retroactive.
512から1023の間のコード値は、一般原則に基づいて予約されており、新しいルールを発明して遡及的にする必要がある場合に備えています。
Code values of 1024 and above are to be allocated for characters, glyphs, and other character elements.
1024以上のコード値は、文字、グリフ、およびその他の文字要素に割り当てられます。
When glyphs are constructed using the mechanisms described here, there is a single canonical form for representing any given glyph. There are no exceptions to that form, and any sequence of characters and qualifiers that is not consistent with the form is invalid. If there are two possible ways to represent a given character, the shorter one (in octet count) is the only permitted form. If there are two possible ways that are of the same length, the only permitted form is the one that has the smaller value when the numeric values of all of the octets in each are summed.
ここで説明するメカニズムを使用してグリフが構築されると、特定のグリフを表すための単一の標準形式があります。そのフォームには例外はありません。また、フォームと一致しない文字と修飾子のシーケンスは無効です。特定の文字を表す方法が2つある場合、短い文字（オクテット数）が唯一の許可された形式です。同じ長さの2つの可能な方法がある場合、許可された唯一のフォームは、それぞれのすべてのオクテットの数値が合計されている場合に値が小さいものです。
The ordering rules are as follows:
注文ルールは次のとおりです。
1. A base character or composite character (see below) must come first.
1. 基本文字または複合文字（以下を参照）が最初に来る必要があります。
2. The base character may be followed by ZWCJ or OJ, but not both, followed by a base or nonspacing character or mark.
2. ベース文字の後にZWCJまたはOJが続くことができますが、両方ではなく、ベースまたはネズピースの文字またはマークが続きます。
3. If ZWCJ appears, the next character must be a base character or nonspacing mark.
3. ZWCJが表示される場合、次の文字はベース文字または非歩行マークでなければなりません。
4. If OJ appears, the next character must be a base character, since the function of OJ is to make a spacing base character into a nonspacing (overlay) character.
4. OJが表示される場合、OJの関数は間隔のベース文字を非歩行（オーバーレイ）文字にすることであるため、次の文字がベース文字でなければなりません。
5. That character can be followed by positional qualifiers that apply to it. Vertical positional qualifiers precede horizontal positional qualifiers.
5. そのキャラクターの後に、それに適用される位置の予選が続くことができます。垂直位置予選は、水平位置予選の前にあります。
6. That sequence of characters may be followed by a case qualifier.
6. その文字のシーケンスには、ケース予選が続く場合があります。
7. That entire sequence of characters forms a composite character. When the composite character is non-trivial, the rules may be applied to it recursively. If grouping is needed to distinguish between one composite character and the next, ZWNCJ may be used at the beginning of a composite character to identify a group boundary.
7. その一連の文字全体が複合文字を形成します。複合文字が自明でない場合、ルールは再帰的に適用される場合があります。1つの複合文字と次の文字を区別するためにグループ化が必要な場合、ZWNCJを複合文字の先頭に使用してグループ境界を識別できます。
The initial lists of positioning and combining controls appear above. This section shows codes for some base characters. Names in upper case are the Unicode names for the characters. These are followed, for information, by the Unicode code point designations. The code point list is informative, not normative, and may not be complete (especially since additional matching code points may be added to Unicode over time). Note that several Unicode characters that are considered different by Unicode are assigned the same code sequence in the system specified here.
位置決めと結合コントロールの最初のリストが上に表示されます。このセクションでは、一部のベース文字のコードを示しています。上品な名前は、文字のUnicode名です。これらには、情報のために、Unicodeコードポイント指定が続きます。コードポイントリストは有益であり、規範的ではなく、完全ではない場合があります（特に、追加の一致するコードポイントが時間の経過とともにUnicodeに追加される可能性があるため）。Unicodeによって異なると見なされるいくつかのUnicode文字には、ここで指定されたシステムに同じコードシーケンスが割り当てられていることに注意してください。
+------------------------+-------+----------------------------------+
| Name | Hex | Comment |
| | value | |
+------------------------+-------+----------------------------------+
| FULL STOP (U+002E) | 110 | Used as both base character (in |
| | | bottom center position) and as |
| | | movable dot with OJ and |
| | | positional qualifiers. |
| HYPHEN-MINUS (U+002D) | 108 | Used as a spacing base character |
| | | (in horizontally and vertically |
| | | centered position) and as a |
| | | movable half-width horizontal |
| | | line with OJ and positional |
| | | qualifiers. In the context of |
| | | this specification, should be |
| | | known as Half Horizontal Line. |
| LOW LINE (U+005F) | 109 | Used as a spacing base character |
| | | (in bottom position) and as a |
| | | movable full-width horizontal |
| | | line with OJ and positional |
| | | qualifiers. In the context of |
| | | this specification, should be |
| | | known as Horizontal Line. |
| VERTICAL LINE (U+007C) | 102 | As with the horizontal lines, |
| | | normally a spacing base |
| | | character (in the middle |
| | | position between left and |
| | | right), but can be used as a |
| | | right to left movable |
| | | full-height vertical line with |
| | | OJ and/or positional qualifiers. |
| HalfHeightVerticalLine | 105 | Similar to VERTICAL LINE, but |
| | | only half height. |
| SOLIDUS (U+002F) | 103 | Used only for character |
| | | formation; forward slash |
| REVERSE SOLIDUS | 104 | Used only for character |
| (U+005C) | | formation; reverse slash |
| RightUpperHook | 131 | Used only for character |
| | | formation; nonspacing mark. |
| LeftUpperHook | 132 | Used only for character |
| | | formation; nonspacing mark. |
| LeftLowerHook | 133 | Used only for character |
| | | formation; nonspacing mark. |
| RightLowerHook | 134 | Used only for character |
| | | formation; nonspacing mark. |
| HalfHeightHoop | 140 | Used only for character |
| | | formation; nonspacing mark. |
| HalfHeightInvertedHoop | 141 | Used only for character |
| | | formation; nonspacing mark. |
| DIGIT ZERO (U+0030) | 400 | |
| DIGIT ONE (U+0031) | 401 | |
| DIGIT TWO (U+0032) | 402 | |
| DIGIT NINE (U+0039) | 409 | |
| LATIN SMALL LETTER A | 40A | |
| (U+0061) | | |
| LATIN SMALL LETTER O | 418 | Unify with Greek Omicron |
| (U+006F, U+03BF) | | |
| LATIN SMALL LETTER C | 40C | Unifying C with Cyrillic ES |
| (U+0063, U+0441) | | |
| GREEK SMALL LETTER | 491 | |
| SIGMA (U+03C3) | | |
+------------------------+-------+----------------------------------+
This section provides examples of characters that are derived from or based on others, known as "composite characters".
このセクションでは、「複合文字」として知られる他の人に由来する、またはその他に基づいている文字の例を紹介します。
+------------------+--------------+---------------------------------+
| Name | Hex value | Comment |
+------------------+--------------+---------------------------------+
| LATIN SMALL | 418 007 102 | |
| LETTER B | 020 | |
| (U+0062) | | |
| LATIN SMALL | 418 007 102 | |
| LETTER D | 022 | |
| (U+0064) | | |
| LATIN SMALL | 40C 007 108 | |
| LETTER E | 031 | |
| (U+0065) | | |
| LATIN SMALL | 40A 006 40C | |
| LETTER AE | 007 108 031 | |
| (U+00E6) | | |
| LATIN SMALL | 102 131 030 | Note that 007 is not needed |
| LETTER F | 007 108 | before 131 because hooks are |
| (U+0066) | | exclusively nonspacing |
| | | (combining). |
| LATIN SMALL | 102 020 141 | |
| LETTER H | 021 032 | |
| (U+0068) | | |
| LATIN SMALL | 105 007 110 | |
| LETTER I | 021 030 | |
| (U+0069) | | |
| LATIN SMALL | 105 020 141 | |
| LETTER N | 021 032 | |
| (U+006E) | | |
| LATIN SMALL | 418 007 102 | Unified P, Greek Rho, Cyrillic |
| LETTER P | 033 020 033 | ER |
| (U+0070, U+03C1, | | |
| U+0440) | | |
| LATIN CAPITAL | 40A 001 | |
| LETTER A | | |
| (U+0041) | | |
| LATIN CAPITAL | 418 007 102 | |
| LETTER B | 020 001 | |
| (U+0042) | | |
| LATIN CAPITAL | 40C 001 | |
| LETTER C | | |
| (U+0043) | | |
| LATIN CAPITAL | 418 007 102 | |
| LETTER D | 022 001 | |
| (U+0044) | | |
| GREEK SMALL | 491 072 | |
| LETTER FINAL | | |
| SIGMA (U+03C2) | | |
+------------------+--------------+---------------------------------+
Because of the traditional model of forming characters using selected radicals and strokes in combination, Han-derived ("CJK") characters are even more naturally represented, with less ambiguity, in the system specified here than European ones. The mechanisms used in this specification and represented in the tables (see Section 8) are similar to those described as "Radicals" and "Strokes" in Section 5.1 and in Section 5.2 ("Ideographic Description Characters") of The Unicode Standard [Unicode]. Of course, following the same principles outlined above for European characters, only radicals, stroke, and description controls would be treated as base characters; no distinct compound precomposed ideographic characters are registered.
選択したラジカルと組み合わせでストロークを使用してキャラクターを形成する伝統的なモデルのため、HAN由来（「CJK」）文字は、ここで指定されているシステムでは、曖昧さが少なく、より自然に表現されます。この仕様で使用され、表で表されるメカニズム（セクション8を参照）は、ユニコード標準[Unicode]のセクション5.1およびセクション5.2（「アイデラフィック説明文字」）の「ラジカル」および「ストローク」と呼ばれるメカニズムと類似しています。。もちろん、ヨーロッパのキャラクターについて上記の同じ原則に従って、ラジカル、ストローク、および説明コントロールのみが基本文字として扱われます。登録されている明確な化合物の前駆的な表意文字はありません。
IANA is requested to keep the actual registry of characters and code tables. The registry entries consist of a character name (preferably matching the Unicode character name when one is available), the code sequence used to represent the character and optional descriptive information. The characters and codes identified in Section 2, Section 5, and Section 6 above should be used to initialize the table. Since the coding system is user-extensible, registrations should be accepted for new characters as long as they don't look like old ones. A designated expert with a background in calligraphy or abstract art, and considerable experience in evaluating claims about the count of angels on heads of pins, should be selected to advise IANA on "looks like".
IANAは、文字とコードテーブルの実際のレジストリを保持するように要求されています。レジストリエントリは、キャラクター名（できれば使用可能なときにユニコード文字名と一致することが望ましい）で構成され、文字とオプションの記述情報を表すために使用されるコードシーケンス。上記のセクション2、セクション5、およびセクション6で特定された文字とコードは、テーブルの初期化に使用する必要があります。コーディングシステムはユーザーが拡張可能であるため、古い文字のように見えない限り、新しい文字の登録を受け入れる必要があります。書道や抽象的な芸術の背景を持つ指定された専門家、そしてピンの頭の天使の伯爵に関する主張についての主張を評価するかなりの経験を、「見た目」についてIanaに助言するために選択する必要があります。
The representation of characters in this format should be a significant boon for security. It eliminates many possibilities of phishing attacks, since Principle 1 prevents the existence of two characters that look alike but are different.
この形式での文字の表現は、セキュリティにとって重要な恩恵である必要があります。原則1は、似ているが異なる2つのキャラクターの存在を防ぐため、フィッシング攻撃の多くの可能性を排除します。
By detaching the encoding of characters for domain names from the encoding of characters for other purposes, it also guarantees that reasonable-looking names will have been encoded by competent entities, thereby providing a significant degree of safety by obscurity.
他の目的のために文字のエンコードからドメイン名の文字のエンコーディングを分離することにより、合理的な名前が有能なエンティティによってエンコードされ、それにより不明瞭によってかなりの安全性を提供することが保証されます。
Because of the method by which upper-case forms are encoded and because similarity is sometimes in the mind of the beholder, this specification will not completely eliminate opportunities for visual confusion. For example, because the lower-case characters are quite different, LATIN CAPITAL LETTER A and GREEK CAPITAL LETTER ALPHA will never compare equal, even though they look alike.
上部ケースフォームがエンコードされている方法と、類似性が見る人の心の中にあることがあるため、この仕様は視覚的混乱の機会を完全に排除するものではありません。たとえば、低ケースのキャラクターはまったく異なるため、ラテン語のキャピタルレターAとギリシャの大文字のアルファは、似ていても等しく比較されません。
The authors would like to acknowledge the many contributions of J.F.C. Morphin for pointing out the inadequacies of trying to address the challenges of internationalization within the context of existing engineering principles. His comments and related ones, in combination with issues encountered in trying to internationalize domain names based on Unicode, have contributed greatly to the frame of mind underlying large parts of the proposal documented here. The theoretical framework for this coding system is based, in part, on Unicode and its collection of names and sample glyphs but represents a very different approach to the coding system itself.
著者は、J.F.C。の多くの貢献を認めたいと考えています。モルフィンは、既存のエンジニアリング原則の文脈の中で国際化の課題に対処しようとする不十分さを指摘したことです。彼のコメントと関連するものは、Unicodeに基づいてドメイン名を国際化しようとする際に遭遇した問題と組み合わせて、ここに記録された提案の大部分の基礎となる心の枠組みに大きく貢献しています。このコーディングシステムの理論的枠組みは、一部はUnicodeとその名前とサンプルのグリフのコレクションに基づいていますが、コーディングシステム自体とは非常に異なるアプローチを表しています。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007. Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0
[Unicode] Unicode Consortium、「Unicode Standard、バージョン5.0」、2007年。米国マサチューセッツ州ボストン：Addison-Wesley。ISBN 0-321-48091-0
[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月。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john+ietf@jck.com
Harald Tveit Alvestrand Google Beddingen 10 Trondheim, 7014 Norway
Harald Tveit Alvestrand Google Beddingen 10 Trondheim、7014 Norway
EMail: harald@alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびhttp://www.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。