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、「レビューと勧告国際化ドメイン名のため（のIDN）」、およびその参考文献を認識する必要があります。
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.
この文書はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、それが展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFのレビューを受けていない特定のノートに、このドキュメントのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。
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。は、文字の形はセリフや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合字、有向グラフ、および最終フォームは、特殊な修飾子で構成されています。
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.
この文書では、文字のいくつかのタイプを定義します。これらの定義は、類似または同一の用語のUnicodeの定義と同じではないことに留意されたいです。
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,...
むしろ合成（重ね打ち）マーク、記号、または特別に設計されたベース文字との組み合わせで、文字から組み立てされるよりも、原子状として使用される任意の文字。単独で使用する場合、ベース文字は常にスペースを取ります。例えば、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」の文字が「<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.
コードは、4つを介して2つ以上の2例とスクリプトの差し迫った符号化のために予約されている値。 5は、以上の4例でスクリプトが特定された場合には、拡張のために予約されています。
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に比べて、ジョイナーのより豊富なセットは、ケース（半文字形成を含む）単語間結紮形成を区別するために使用されます。ユニコード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文字建具、コード値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ゼロ幅建具、コード値9（16進数）。
ZWNJ Zero-width non-joiner for words or word-like constructions, code value A (hexadecimal).
ZWNJゼロ幅単語または単語のような構造のために非ジョイナー、コード値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
多くの文字は、非スペーシングマークを使用して構築グリフによって定義されています。例えば、文字 "b" および "d" は、それぞれ、O <VerticalLine> <PositionLeft>およびO <VerticalLine> <PositionRight>としてコード化されます。アプリケーション（IDNA）[RFC3490]に国際化ドメイン名でいくつかの困難を引き起こしたカタロニア語の結紮は、L <ZWCJ> <> <PositionVMiddle> <ZWCJ> Lとして符号化されます
The initial table of positioning indicators is:
位置決め指標の最初のテーブルには、次のとおりです。
+-------------------+-----------+
| 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.
符号の小型のために、2つの反復インジケータは結紮又は特別なケースとして扱うことができる二重（Repeat2）及び（Repeat3）三重文字のために導入されています。文字の二つの連続した用途は、<Repeat2>に続く文字に等しい比較します。 Uの解釈は、<ZWCJ> U <Repeat3>読者の演習として残しています。
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.
大きな反復のために、これらの反復を組み合わせることができます。 <Repeat3> <Repeat2>は、5つのリピートを表す配列<Repeat2> <Repeat3>は6回の反復を表します。 「最短の文字列」の原則（第4章を参照）に続いて、Repeat1はこれまでRepeat2および/またはRepeat3との組み合わせ以外で現れてはなりません。他の数の生成は、読者のための課題として残されています。
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]で使用される理由を、以下、すべての文字（先頭ビットは常にゼロで、従来の3つのオクテットとして記憶されている）正確23ビットを占有します。 3と23の両方が素数であるため、この値は42とは異なり、選択されています。
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（10進数）との間のコード値は、セクション2.7を介して2.3節に記載の特殊文字形成コードのために予約されています。
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（10進数）の間のコード値は、非表意文字の文字形成のマーク用に予約されています。ほとんど、すべてではありませんが、これらの文字を（組み合わせ）非スペーシングされています。
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.その文字は、それに適用された位置の修飾子を続けることができます。垂直位置修飾子は、水平位置の修飾子に先行します。
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.
なぜなら組み合わせで選択されたラジカルや脳卒中を使用して文字を形成する従来のモデルの、ハン由来（「CJK」）の文字が、より自然にヨーロッパのものよりも、ここで指定されたシステムでは、あまり曖昧で、表現されています。 Unicode標準[UNICODE]の機構本明細書で使用され、表に示される（セクション8を参照）セクション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は、文字とコード表の実際のレジストリを維持するために要求されています。レジストリエントリは、文字名（一つが利用可能である場合、好ましくは、Unicode文字名に一致）、文字及び任意の記述的情報を表すために使用されるコード配列からなります。文字とコードセクション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.
ための方法のどれによって大文字形態は、符号化され、類似度が見る人の心に時々あるため、この仕様は完全に視覚的な混乱の機会を排除しないであろう。小文字はかなり異なっているので、例えば、LATIN CAPITAL LETTER AとギリシャCAPITAL LETTER ALPHAは、彼らは同じように見えていても、同じ比較することはありません。
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.の多くの貢献を認めるしたいと思います既存の工学原理の文脈の中で国際化の課題に対処しようとしているの不備を指摘しなMorphin。彼のコメントおよび関連のものは、ユニコードに基づいてドメイン名の国際化しようとする中で発生した問題との組み合わせで、ここでは文書化提案の大部分の基礎となる心のフレームに大きく貢献してきました。この符号化システムのための理論的枠組みは、Unicodeと名前とサンプルグリフのコレクションに部分的に基づくが、符号化システム自体に非常に異なるアプローチを示しています。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007. Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0
[ユニコード]のUnicodeコンソーシアム、 "Unicode標準、バージョン5.0"、2007年、ボストン、MA、USA：アディソン・ウェズリー。 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.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 491 5735 EMail: john+ietf@jck.com
電話：+1 617 491 5735 Eメール：john+ietf@jck.com
Harald Tveit Alvestrand Google Beddingen 10 Trondheim, 7014 Norway
ハラルド・トバイット・アルベストランドグーグルBeddingen 10トロンハイムノルウェー7014
EMail: harald@alvestrand.no
メールアドレス：harald@alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。