はじめに
- この文書は RFC5242 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
A Generalized Unified Character Code: Western European and CJK Sections（一般化された統一文字コード：西ヨーロッパとCJK）
- Network Working Group
- Request for Comments: 5242
- Category: Informational
- J. Klensin
- H. Alvestrand
- 1 April 2008
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
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 "Review and Recommendations for Internationalized Domain Names (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
1. Introduction（序論）
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:
If it looks alike, it is alike. The number of base characters and marks should be minimized. Glyphs are more important than character abstractions.
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.
For simplicity, when a character form can be evaluated on the basis of either serif or sanserif fonts, the sanserif font is always preferred.
The use of combining characters and modifiers is preferred to adding more base characters.
これには、4つの重要な原則がある。
-
見た目が似ていれば（訳注：符号化結果も）似ている。 基となる文字やマークの数は最小限にすること。 文字の抽象度よりもグリフが重要である。
-
（訳注：意味が）同じものであれば、（訳注：符号化結果も）同じものである。 あらゆる文脈で同じ意味を持つ二つの記号は、外部の等価表に頼らず、修飾語を除去することでその同一性を発見できるように符号化されなければならない。
-
簡略化のため、ある文字形式がセリフフォントとサンセリフフォントのどちらかで評価できる場合は、常にサンセリフフォントが優先される。
-
基本文字を増やすより、結合文字や修飾子を使う方が望ましい。
Based on these principles, it becomes obvious that:
Ligatures, digraphs, and final forms are constructed with special modifiers so that relationships to basic forms are obvious.
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.
This document draws strongly from the design and terminology of Unicode [Unicode] but represents a radically different approach.
これらの原則に基づけば、次のことが明らかになる。
-
合字、二重音字、終止形は、基本形との関係が明白になるように特別な修飾子を用いて構成される。
-
複数のマークからなる記号は、常に結合文字と位置修飾子から構成される。したがって、「i」という文字は、垂直線記号とその上の結合点から構成される。 同様に、「f」は中央の縦線、上の位置の右フック、適切な位置の組み込みハイフンで構成されている。
この文書は、ユニコード [Unicode] のデザインと用語を強く意識しているが、根本的に異なるアプローチを示している。
1.1. Terminology（用語説明）
All special-use terms in this document, including descriptions of behaviors and related relationships, are used with their common-sense meanings.
本文書では、動作や関連する関係の記述を含め、特殊用途の用語はすべて常識的な意味で使用されている。
1.2. Discussion（議論）
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 まで。
2. Types of Characters（文字の型）
This document defines several types of characters.
Note that these definitions are not the same as the Unicode definitions for similar or identical terms.
この文書では、いくつかのタイプの文字を定義している。
これらの定義は、類似または同一の用語に対するユニコードの定義と同じではないことに注意すること。
2.1. Base Character（基底文字）
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,……。
2.2. Nonspacing Marks（非スペーシングマーク）
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 は、非スペーシングマークである。
2.3. Case Indicators（ケースインジケータ）
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.The initial set of case modifiers consists exclusively of:
UC Upper-case, code value 1 (hexadecimal)
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.
大文字と小文字の区別があるスクリプトでは、小文字のみが基底文字となる。
大文字は UC 修飾子を用いて表現する。
つまり、伝統的な「A」文字は a<UC> で表される。
これは、複雑なマッピング操作ではなく、<UC> 修飾子を無視することによって、大文字小文字に依存しない比較が単純に行われることを意味していることに注意されたい。
大文字小文字の初期セットは、以下のものだけで構成される。
UC 大文字、コード値 1 (16進数)
コード値2から4は、2つよりも多くのケースを持つスクリプトの符号化を間近に控えて予約されており、5は4つ以上のケースを持つスクリプトが確認された場合の拡張用として予約されている。
2.4. Joining Indicators（結合インジケータ）
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 asu<ZWCJ>u<UC>-- the CWCJ binds more tightly than the UC modifier.The initial set of joining indicators consists exclusively of:
ZWCJ Character joiner (also known as "ligature joiner"), code value 6 (hexadecimal).
OJ Overlay joiner (permits use of a subsequent character that would normally be spacing as nonspacing), code value 7 (hexadecimal).
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.
ZWJ Zero-width joiner for words or word-like constructions, code value 9 (hexadecimal).
ZWNJ Zero-width non-joiner for words or word-like constructions, code value A (hexadecimal).
ゼロ幅結合子は、単語の分離や結合だけでなく、文字を構築するために使用される。
ユニコードと比較して、単語間と合字（半文字を含む）を区別するために、より豊富な結合子セットが使用される。
ユニコードの ZWJ と ZWNJ は、ZWCJ、OJ、ONJ で補完されている。
ZWCJ は、スペーシングの基本文字を非スペーシングの役割に変更するために使用される。
例えば、「w」の文字はなく、u<ZWCJ>u のみが存在する。
大文字の「W」は u<ZWCJ>u<UC> としてコード化される —— CWCJはUC修飾子よりも強く結合される。
結合指示子の初期セットは、以下のものだけで構成される。
ZWCJ 文字結合子（「合字結合子」としても知られる）、コード値 6（16進数）。
OJ オーバーレイ結合子（通常スペーシングされる後続の文字を非スペーシングとして使用できる）、コード値 7（16進数）。
ONJ オーバーレイ非結合子（非スペーシングマークを独立した文字にする）、コード値8（16進数）。 この結合子は必要ないはずで、通常は「最短文字列」ルールで禁止されている。 しかし、予期せぬ場合があるかもしれない。
ZWJ 単語または単語に似た構文のためのゼロ幅結合子、コード値は9（16進数）。
ZWNJ 単語または単語に似た構文のためのゼロ幅非結合子、コード値 A（16 進数）。
2.5. Character-Matrix Positioning Indicators（文字・マトリックス位置インジケーター）
Many characters are defined by constructed glyphs using nonspacing marks.
For example, the characters "b" and "d" are coded aso<VerticalLine><PositionLeft>ando<VerticalLine><PositionRight>, respectively.
The Catalan ligature that has caused some difficulties in Internationalizing Domain Names in Applications (IDNA) [RFC3490] is coded asl<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 |
+-------------------+-----------+
2.6. Position Shaping Controls（位置形状制御）
These controls designate character form changes for initial or final-form characters.
Where the distinction is important, medial-formcharacters are the default when no qualification occurs.
As with case comparisons, comparisons are performed by ignoring these control functions.
以下の制御コードは、開始形 (initial-form) または終止形 (final-form) 文字に対する文字形の変更を指定する。
区別が重要な場合、修飾が行われないときは、中間形の文字がデフォルトとなる。
大文字小文字の比較と同様に、文字の比較はこれらの制御機構を無視して行われる。
+-------------+-----------+
| Name | Hex value |
+-------------+-----------+
| InitialForm | 71 |
| FinalForm | 72 |
+-------------+-----------+
2.7. Repetition Indicators（繰り返しインジケーター）
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 ofu<ZWCJ>u<Repeat3>is left as an exercise for the reader.
コンパクトな表記のため、合字や特殊なケースとして扱われるダブル（Repeat2）、トリプル（Repeat3）文字のために、2つの繰り返しインジケーターが導入された。
ある文字が2回連続して使用されたものと、文字の後に <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.
より大きな繰り返し回数は、これらの繰り返し機構を組み合わせることで実現できる。<Repeat2><Repeat3> というシーケンスは6回繰り返しを表し、一方 <Repeat3><Repeat2> は5回繰り返しを表す。
「最短文字列」の原則（4章参照）に従い、Repeat1 は Repeat2 や Repeat3 との組み合わせ以外では決して現れてはならない。
他の数字の生成は読者への課題とする。
2.8. Control Characters（制御文字）
Because it is intended primarily for domain names, this specification has no provision for control or spacing characters.
これは主にドメイン名を対象としているため、この仕様には制御文字や間隔文字は用意されていない。
3. Code Assigment Groupings（コード割り当てのグループ化）
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.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.
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.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.
Code values of 1024 and above are to be allocated for characters, glyphs, and other character elements.
ユニコード [Unicode] で使われている理由に従って、すべての文字は正確に23ビット（3オクテットとして格納され、先頭のビットは常にゼロ）を占める。
この値が選ばれたのは、42とは異なり、3 と 23 がともに素数だからである。
コードポイント値 0 は永久に予約されており、コード空間を拡張する必要がない限り使用されることはない。
1～255 (10 進数) のコード値は、2.3 節～2.7 節で説明する特殊文字形成コード用に予約されている。
256～511 (10進数) のコード値は、非英語文字用の文字形成符号として予約されている。
これらのほとんどは、非スペーシング(結合)文字である。
512～1023 のコード値は、一般原則と、新しい規則を考案してそれを遡及適用する必要がある場合のために予約されている。
1024 以上のコード値は、文字、グリフ、およびその他の文字要素に割り当てる。
4. Canonical Form（正準形）
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.The ordering rules are as follows:
A base character or composite character (see below) must come first.
The base character may be followed by ZWCJ or OJ, but not both, followed by a base or nonspacing character or mark.
If ZWCJ appears, the next character must be a base character or nonspacing mark.
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.
That character can be followed by positional qualifiers that apply to it. Vertical positional qualifiers precede horizontal positional qualifiers.
That sequence of characters may be followed by a case qualifier.
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.
ここで説明するメカニズムを使用してグリフを構築する場合、任意のグリフを表すための唯一の正準形が存在する。
この形式に例外はなく、この形式と一致しない文字と修飾子の並びは無効である。
ある特定の文字を表す方法が2通りある場合、許可される形式は(オクテット数で)短い方のみである。
同じ長さで2つの表現方法がある場合、それぞれのすべてのオクテットの数値を合計したときに値が小さい形式のみが、許可される形式である。
コードの並び順のルールは次のとおり：
-
基底文字または合成文字（以下を参照）が最初に来る必要がある。
-
基底文字の後に、ZWCJ または OJ を続けることができるが、両方を続けることはできない。その後に、基底文字または非スペーシング文字またはマークを続けることができる。
-
ZWCJ があった場合、次の文字は基底文字または非スペーシング文字あるいはマークである必要がある。
-
OJ があった場合、OJ の機能はスペーシング基底文字を非スペーシング（オーバーレイ）文字にすることであるため、次の文字は基底文字である必要がある。
-
その文字の後に、それに適用される位置修飾子を続けることができる。垂直位置修飾子は、水平位置修飾子の前におく。
-
その文字のシーケンスの後に、ケース修飾子をおくことができる。
-
文字のシーケンス全体が合成文字を形成する。合成文字が自明でない場合、ルールが再帰的に適用される場合がある。ある合成文字と次の合成文字を区別するためにグループ化が必要な場合は、合成文字の先頭で ZWNCJ を使用して、グループの境界を識別できる。
5. Examples of Graphic Element Codes（図形要素コードの例）
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 コードポイント表記がある。
このコードポイントリストは参考であり、規範ではないため完全ではありません（特にこのコードポイントはいずれユニコードに追加される可能性がある）。
ユニコードでは異なる文字とされているいくつかのユニコード文字が、ここで指定されたシステムでは同じコードシーケンスに割り当てられていることに注意すること。
+------------------------+-------+----------------------------------+
| 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) | | |
+------------------------+-------+----------------------------------+
| 名前 | 16進値 | コメント |
|---|---|---|
| FULL STOP (U+002E) | 110 | 基底文字（下中央の点）として、また OJ と位置修飾を伴う移動可能な点として使用される。 |
| HYPHEN-MINUS (U+002D) | 108 | スペーシング基底文字（水平および垂直方向の中央位置）、および OJ と位置修飾を伴う可動な半幅の水平線として使用される。本仕様では、半横線(Half Horizontal Line)と呼ぶ。 |
| LOW LINE (U+005F) | 109 | スペーシング基底文字（下段）、および OJ と位置修飾を伴う移動可能な全幅の水平線として使用される。 本仕様では、横線(Horizontal Line)と呼ぶ。 |
| VERTICAL LINE (U+007C) | 102 | 横線と同様、通常はスペーシング基底文字（左右の中間位置）であるが、OJ や位置修飾子を用いて左右に移動可能な全幅の縦線として使用することができる。 |
| HalfHeightVerticalLine | 105 | 縦線と似ているが、高さが半分である。 |
| SOLIDUS (U+002F) | 103 | 文字組みのときだけ使う；順スラッシュ |
| REVERSE SOLIDUS (U+005C) |
104 | 文字組みのときだけ使う；逆スラッシュ |
| RightUpperHook | 131 | 文字組みのときだけ使う；非スペーシングマーク |
| LeftUpperHook | 132 | 文字組みのときだけ使う；非スペーシングマーク |
| LeftLowerHook | 133 | 文字組みのときだけ使う；非スペーシングマーク |
| RightLowerHook | 134 | 文字組みのときだけ使う；非スペーシングマーク |
| HalfHeightHoop | 140 | 文字組みのときだけ使う；非スペーシングマーク |
| HalfHeightInvertedHoop | 141 | 文字組みのときだけ使う；非スペーシングマーク |
| DIGIT ZERO (U+0030) | 400 | |
| DIGIT ONE (U+0031) | 401 | |
| DIGIT TWO (U+0032) | 402 | |
| DIGIT NINE (U+0039) | 409 | |
| LATIN SMALL LETTER A (U+0061) |
40A | |
| LATIN SMALL LETTER O (U+006F, U+03BF) |
418 | ギリシャのオミクロンを統合 |
| LATIN SMALL LETTER C (U+0063, U+0441) |
40C | Cとキリル文字ESを統合 |
| GREEK SMALL LETTER SIGMA (U+03C3) |
491 |
6. Composite Characters and Unicode Equivalences（合成文字とUnicodeの対応）
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) | | |
+------------------+--------------+---------------------------------+
| 名前 | 16進値 | コメント |
|---|---|---|
| LATIN SMALL LETTER B (U+0062) |
418 007 102 020 |
|
| LATIN SMALL LETTER D (U+0064) |
418 007 102 022 |
|
| LATIN SMALL LETTER E (U+0065) |
40C 007 108 031 |
|
| LATIN SMALL LETTER AE (U+00E6) |
40A 006 40C 007 108 031 |
|
| LATIN SMALL LETTER F (U+0066) |
102 131 030 007 108 |
注：フックは専ら非スペーシング (結合) なので、131 の前に 007 は不要。 |
| LATIN SMALL LETTER H (U+0068) |
102 020 141 021 032 |
|
| LATIN SMALL LETTER I (U+0069) |
105 007 110 021 030 |
|
| LATIN SMALL LETTER N (U+006E) |
105 020 141 021 032 |
|
| LATIN SMALL LETTER P (U+0070, U+03C1, U+0440) |
418 007 102 033 020 033 |
P、ギリシャ文字 Rho、キリル文字 ER は統合 |
| LATIN CAPITAL LETTER A (U+0041) |
40A 001 | |
| LATIN CAPITAL LETTER B (U+0042) |
418 007 102 020 001 |
|
| LATIN CAPITAL LETTER C (U+0043) |
40C 001 | |
| LATIN CAPITAL LETTER D (U+0044) |
418 007 102 022 001 |
|
| GREEK SMALL LETTER FINAL SIGMA (U+03C2) |
491 072 |
7. Ideographic Characters（表意文字）
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」) は、ヨーロッパの文字よりもさらに自然に、曖昧さを抑えて表現することができる。
本仕様書で使用され、表(8章参照)で表現されているメカニズムは、The Unicode Standard [Unicode] の5.1節および5.2節（「Ideographic Description Characters」）で「Radicals」「Strokes」として説明されているものと同様である。
もちろん、ヨーロッパの文字について上で概説したのと同じ原則に従って、部首、画数、および記述制御だけが基底文字として扱われ、明確な合成前合成表意文字は登録されない。
8. IANA Considerations（IANAに関する考慮事項）
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に「似ている」ことについて助言させるべきである。
9. Security Considerations（セキュリティに関する考慮事項）
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.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.
この方式で文字を表現することは、セキュリティにとって大きな利点となるはずだ。
原則1では、似ているが異なる2つの文字が存在することを防いでいるので、フィッシング攻撃の多くの可能性を排除することができる。
また、ドメイン名の文字コードを他の目的の文字コードから切り離すことで、見た目が妥当な名前は有能なエンティティによってコード化されていることが保証され、不明瞭さによる安全性が大幅に向上する。
大文字を符号化する方法と類似性は見る人の心の中にあるため、この仕様によって視覚的な混乱が完全になくなるわけではない。
例えば、LATIN CAPITAL LETTER Aと GREEK CAPITAL LETTER ALPHA は、小文字が全く異なるため、見た目は似ていても決して比較することはできない。
10. Acknowledgments（謝辞）
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 の多くの貢献に対して謝意を表したい。
彼のコメントと関連するコメントは、ユニコードに基づくドメイン名の国際化を試みる際に遭遇した問題と相まって、ここで文書化された提案の大部分に基礎をなす心構えに大きく寄与している。
このコーディングシステムの理論的な枠組みは、部分的にはユニコードとその名前およびサンプルグリフのコレクションに基づいているが、コーディングシステム自体には非常に異なるアプローチを示している。
11. References
11.1. Normative References
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
5.0", 2007.
Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0
11.2. Informative References
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
Authors' Addresses
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john+ietf@jck.com
Harald Tveit Alvestrand
Google
Beddingen 10
Trondheim, 7014
Norway
EMail: harald@alvestrand.no
Full Copyright Statement
Copyright (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.
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.
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.
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.
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.