RFC5242 日本語訳
5242 A Generalized Unified Character Code: Western European and CJKSections. J. Klensin, H. Alvestrand. April 1 2008. (Format: TXT=31314 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Klensin
Request for Comments: 5242
Category: Informational H. Alvestrand
Google
1 April 2008
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5242年のカテゴリ: 情報のH.Alvestrand Google2008年4月1日
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ドキュメントではありません。 読者はRFC4690、「国際化ドメイン名(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.
このドキュメントはインターネット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)キャラクタに基づくスクリプトのために完全に統一されたコード化文字集合について説明します。 それはその文字の組の完全な仕様ではありません。
Klensin & Alvestrand Informational [Page 1] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[1ページ]のRFC5242
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 議論. . . . . . . . . . . . . . . . . . . . . . . . 4 2。 キャラクター. . . . . . . . . . . . . . . . . . . . . 4 2.1のタイプ。 キャラクター. . . . . . . . . . . . . . . . . . . . . . 4 2.2を基礎づけてください。 マーク. . . . . . . . . . . . . . . . . . . . . 4 2.3をNonspacingします。 インディケータ. . . . . . . . . . . . . . . . . . . . . 4 2.4をケースに入れてください。 インディケータ. . . . . . . . . . . . . . . . . . . . 5 2.5を接合します。 キャラクターマトリクス位置決めインディケータ. . . . . . . . . 5 2.6。 形成コントロール. . . . . . . . . . . . . . . . 6 2.7を置いてください。 反復インディケータ. . . . . . . . . . . . . . . . . . 6 2.8。 制御文字. . . . . . . . . . . . . . . . . . . . 7 3。 Assigment組分け. . . . . . . . . . . . . . . . . . . 7 4をコード化してください。 標準形. . . . . . . . . . . . . . . . . . . . . . . . 7 5。 グラフィック要素コード. . . . . . . . . . . . . . 8 6に関する例。 キャラクターとユニコードの等価性. . . . . . . . 10 7を合成してください。 表意文字のキャラクター. . . . . . . . . . . . . . . . . . . . 11 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 11 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 12 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 13 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 13
Klensin & Alvestrand Informational [Page 2] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[2ページ]のRFC5242
1. Introduction
1. 序論
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. 同じく見るなら、似ています。 基本文字とマークの数は最小にされるべきです。 Glyphsはキャラクタ抽象化より重要です。
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. セリフかサンセリフ体の字体のどちらかに基づいてキャラクタフォームを評価できるとき、簡単さにおいて、サンセリフ体の字体はいつも好まれます。
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.
このドキュメントは、強くユニコード[ユニコード]のデザインと用語を引き出しますが、根本的に異なったアプローチを表します。
1.1. Terminology
1.1. 用語
All special-use terms in this document, including descriptions of behaviors and related relationships, are used with their common-sense meanings.
振舞いと関連する関係の記述を含むこのドキュメントのすべての特別な使用用語がそれらの常識の意味と共に使用されます。
Klensin & Alvestrand Informational [Page 3] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[3ページ]のRFC5242
1.2. Discussion
1.2. 議論
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
2. キャラクターのタイプ
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
2.1. 基本文字
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
2.2. マークをNonspacingします。
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
2.3. ケースインディケータ
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 Upper-ケース、コード値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〜fourは2つ以上のケースに伴うスクリプトの差し迫っているコード化のために予約されます。 5は場合における拡大のために予約されて、4つ以上のケースに伴うスクリプトが特定されるということです。
Klensin & Alvestrand Informational [Page 4] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[4ページ]のRFC5242
2.4. Joining Indicators
2.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.
無幅のjoinersは、単に単語を切り離すか、または接合するのではなく、キャラクタを造るのに使用されます。 ユニコードと比べて、joinersの、より豊かなセットは、相互単語とひもを形成する(半分キャラクタ形成を含んでいます)ケースを見分けるのに使用されます。 ユニコード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キャラクターjoiner(また、「ひもjoiner」として、知られている)、値6の(16進)をコード化してください。
OJ Overlay joiner (permits use of a subsequent character that would
normally be spacing as nonspacing), code value 7 (hexadecimal).
OJ Overlay joiner(「非-区切」るとしてその後のキャラクタの通常、スペースである使用を可能にする)、値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 Overlay非joiner(「非-区切」りマークをスタンドアロンキャラクタに変える)、値8の(16進)をコード化してください。 このjoinerは必要であるべきでなくて、通常、「最も脆いストリング」規則で禁止されています。 しかし、思いがけないケースがあるかもしれません。
ZWJ Zero-width joiner for words or word-like constructions, code
value 9 (hexadecimal).
単語か単語のような構造のためのZWJ Zero-幅のjoiner、コード値9(16進。)
ZWNJ Zero-width non-joiner for words or word-like constructions,
code value A (hexadecimal).
単語のための非joinerのZWNJ Zero-幅か単語のような構造、コードがA(16進)を評価します。
2.5. Character-Matrix Positioning Indicators
2.5. キャラクターマトリクス位置決めインディケータ
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
多くのキャラクタが、「非-区切」りマークを使用することで組み立てられたglyphsによって定義されます。 例えば、キャラクタ「b」と「d」はo<VerticalLine><PositionLeft>とo<VerticalLine><PositionRight>としてそれぞれコード化されます。 Applications(IDNA)[RFC3490]のInternationalizing Domain Namesにおける困難を引き起こしたカタロニア人のひもはl<ZWCJ><><PositionVMiddle><ZWCJ>lとしてコード化されます。
Klensin & Alvestrand Informational [Page 5] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[5ページ]のRFC5242
The initial table of positioning indicators is:
位置決めインディケータの初期のテーブルは以下の通りです。
+-------------------+-----------+
| Name | Hex value |
+-------------------+-----------+
| PositionLeft | 20 |
| PositionCenter | 21 |
| PositionRight | 22 |
| PositionTop | 30 |
| PositionVMiddle | 31 |
| PositionBottom | 32 |
| PositionDescender | 33 |
+-------------------+-----------+
+-------------------+-----------+ | 名前| 十六進法値| +-------------------+-----------+ | PositionLeft| 20 | | PositionCenter| 21 | | PositionRight| 22 | | PositionTop| 30 | | PositionVMiddle| 31 | | PositionBottom| 32 | | PositionDescender| 33 | +-------------------+-----------+
2.6. Position Shaping Controls
2.6. コントロールを形成する位置
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 |
+-------------+-----------+
+-------------+-----------+ | 名前| 十六進法値| +-------------+-----------+ | InitialForm| 71 | | FinalForm| 72 | +-------------+-----------+
2.7. Repetition Indicators
2.7. 反復インディケータ
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)のキャラクタのために紹介されます。 キャラクタの2つの連続した用途が<Repeat2>によって続かれたキャラクタと同輩を比較します。 u<ZWCJ>u<Repeat3>の解釈は読者のための運動として残されます。
The initial table of repetition indicators is:
反復インディケータの初期のテーブルは以下の通りです。
+---------+-----------+
| Name | Hex value |
+---------+-----------+
| Repeat2 | 50 |
| Repeat3 | 51 |
| Repeat1 | 52 |
+---------+-----------+
+---------+-----------+ | 名前| 十六進法値| +---------+-----------+ | Repeat2| 50 | | Repeat3| 51 | | Repeat1| 52 | +---------+-----------+
Klensin & Alvestrand Informational [Page 6] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[6ページ]のRFC5242
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は現れてはいけません。 他の数の世代は読者のための運動として出られます。
2.8. Control Characters
2.8. 制御文字
Because it is intended primarily for domain names, this specification has no provision for control or spacing characters.
主としてドメイン名のために意図するので、この仕様には、コントロールかスペースキャラクタへの支給が全くありません。
3. Code Assigment Groupings
3. コードAssigment組分け
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.
ユニコード[ユニコード]で使用される推理に続いて、すべてのキャラクタがちょうど23ビットを占領する、(3つの八重奏として主なビットで慣習上いつも格納される、ゼロ) 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年以上のコード値はキャラクタ、glyphs、および他のキャラクタ要素のために割り当てることです。
4. Canonical Form
4. 標準形
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.
glyphsがここで説明されたメカニズムを使用することで組み立てられるとき、glyphを考えて、いずれも表すためのただ一つの標準形があります。 そのフォームへの例外が全くありません、そして、キャラクタと資格を与える人のフォームと一致していないどんな系列も無効です。 与えられたキャラクタの代理をする2つの可能な方法があれば、短いものは唯一の受入れられたフォーム(八重奏カウントで)です。 同じ長さのものである2つの可能な方法があれば、唯一の受入れられたフォームがそれぞれの八重奏のすべての数値がまとめられるとき、より小さい値があるものです。
Klensin & Alvestrand Informational [Page 7] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[7ページ]のRFC5242
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は、作られた登場人物の始めにグループ限界を特定するのに使用されるかもしれません。
5. Examples of Graphic Element Codes
5. グラフィック要素コードに関する例
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.
コントロールを置いて、結合する初期のリストは上に現れます。 このセクションは何人かの基本文字のためにコードを示しています。 大文字の中の名前はキャラクタのためのユニコード名です。 ユニコードコードポイント名称は情報のためにこれらのあとに続いています。 コードポイントリストは、規範的であるのではなく、有益であり、完全でないかもしれません(特に追加合っているコード・ポイントが時間がたつにつれてユニコードに追加されるかもしれないので)。 ここで指定されたシステムの同じコード系列がユニコードによって異なると考えられる数人のユニコード文字に割り当てられることに注意してください。
Klensin & Alvestrand Informational [Page 8] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[8ページ]のRFC5242
+------------------------+-------+----------------------------------+ | 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. |
+------------------------+-------+----------------------------------+ | 名前| 十六進法| コメント| | | 値| | +------------------------+-------+----------------------------------+ | 終止符(U+002E)| 110 | そして両方がキャラクタを基礎づけて(| | | | 下部の、位置を中心に置いてください)使用する。| | | | そしてOJがある可動ドット。| | | | 位置の資格を与える人。 | | ハイフンマイナス(U+002D)| 108 | スペースベースキャラクタとして、使用されます。| | | | 中、(水平と垂直である、| | | | 中心に置かれた位置、) そして、aとして| | | | 可動半値幅水平面| | | | OJで位置で、立ち並んでください。| | | | 資格を与える人。 文脈| | | | この仕様、あるべきです。| | | | Half Horizontal線として、知られています。 | | 低線(U+005F)| 109 | スペースベースキャラクタとして、使用されます。| | | | (下部の位置の) そして、aとして| | | | 可動全幅水平面| | | | OJで位置で、立ち並んでください。| | | | 資格を与える人。 文脈| | | | この仕様、あるべきです。| | | | Horizontal線として、知られています。 | | 縦線(U+007C)| 102 | 水平な線のように| | | | 通常スペースベース| | | | キャラクタ(中央| | | | | | | | 左と右の間の位置の)aとして使用できて、| | | | 左への可動権利| | | | 垂直面が立ち並ぶフルハイト| | | | OJ、そして/または、位置の資格を与える人。 | | HalfHeightVerticalLine| 105 | しかし、縦線と同様| | | | ハーフハイトだけ。 | | ソリドゥス(U+002F)| 103 | キャラクタのためだけに、使用されます。| | | | 構成。 前方では、なでぎりしてください。| | ソリドゥスを逆にしてください。| 104 | キャラクタのためだけに、使用されます。| | (U+005C) | | 構成。 スラッシュを逆にしてください。| | RightUpperHook| 131 | キャラクタのためだけに、使用されます。| | | | 構成。 マークを「非-区切」ります。 | | LeftUpperHook| 132 | キャラクタのためだけに、使用されます。| | | | 構成。 マークを「非-区切」ります。 | | LeftLowerHook| 133 | キャラクタのためだけに、使用されます。| | | | 構成。 マークを「非-区切」ります。 | | RightLowerHook| 134 | キャラクタのためだけに、使用されます。| | | | 構成。 マークを「非-区切」ります。 | | HalfHeightHoop| 140 | キャラクタのためだけに、使用されます。| | | | 構成。 マークを「非-区切」ります。 |
Klensin & Alvestrand Informational [Page 9] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[9ページ]のRFC5242
| 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) | | | +------------------------+-------+----------------------------------+
| HalfHeightInvertedHoop| 141 | キャラクタのためだけに、使用されます。| | | | 構成。 マークを「非-区切」ります。 | | ケタゼロ(U+0030)| 400 | | | ケタ1(U+0031)| 401 | | | ケタTWO(U+0032)| 402 | | | ケタNINE(U+0039)| 409 | | | ラテン語の小文字A| 40A| | | (U+0061) | | | | ラテン語の小文字O| 418 | ギリシア語οと合わせてください。| | (U+006F、U+03BF) | | | | ラテン語の小文字C| 40C| キリル文字のESと共にCを統一します。| | (U+0063、U+0441) | | | | ギリシアの小文字| 491 | | | σ(U+03C3)| | | +------------------------+-------+----------------------------------+
6. Composite Characters and Unicode Equivalences
6. 作られた登場人物とユニコードの等価性
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) | | |
+------------------+--------------+---------------------------------+ | 名前| 十六進法値| コメント| +------------------+--------------+---------------------------------+ | ラテン語、小ささ| 418 007 102 | | | 文字B| 020 | | | (U+0062) | | | | ラテン語、小ささ| 418 007 102 | | | 文字D| 022 | | | (U+0064) | | | | ラテン語、小ささ| 40 C007 108| | | 文字E| 031 | | | (U+0065) | | | | ラテン語、小ささ| 40A006 40C| | | 手紙AE| 007 108 031 | | | (U+00 6ユーロ) | | | | ラテン語、小ささ| 102 131 030 | 007は必要でないことに注意してください。| | 文字F| 007 108 | 131の前、フックはそうです。| | (U+0066) | | 排他的に、「非-区切」ります。| | | | (結合します。) | | ラテン語、小ささ| 102 020 141 | | | 文字H| 021 032 | | | (U+0068) | | | | ラテン語、小ささ| 105 007 110 | | | 文字I| 021 030 | | | (U+0069) | | |
Klensin & Alvestrand Informational [Page 10] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[10ページ]のRFC5242
| 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) | | | +------------------+--------------+---------------------------------+
| ラテン、小ささ| 105 020 141 | | | 文字N| 021 032 | | | (U+006E) | | | | ラテン語、小ささ| 418 007 102 | 統一されたP、ギリシアのロー、キリール文字| | 文字P| 033 020 033 | えー| | (U+0070、U+03C1| | | | U+0440) | | | | ラテン語の首都| 40A001| | | 文字A| | | | (U+0041) | | | | ラテン語の首都| 418 007 102 | | | 文字B| 020 001 | | | (U+0042) | | | | ラテン語の首都| 40 C001| | | 文字C| | | | (U+0043) | | | | ラテン語の首都| 418 007 102 | | | 文字D| 022 001 | | | (U+0044) | | | | ギリシア、小ささ| 491 072 | | | 手紙決勝| | | | σ(U+03C2)| | | +------------------+--------------+---------------------------------+
7. Ideographic Characters
7. 表意文字のキャラクター
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を見ます)メカニズムはセクション5.1とユニコードStandard[ユニコード]のセクション5.2(「表意文字の記述キャラクター」)で「急進論者」と「ストローク」として記述されたものと同様です。 もちろん、ヨーロッパ人のキャラクタ、唯一の急進論者、ストローク、および記述コントロールのために上に概説された同じ次の原則は基本文字として扱われるでしょう。 どんな異なった化合物も示された表意文字のキャラクタを前構成しませんでした。
8. IANA Considerations
8. 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
IANAがキャラクタとコードテーブルの実際の登録を保つよう要求されています。 登録エントリーはキャラクタ名(1つが利用可能であるときに、望ましくは、ユニコード文字名を合わせます)(キャラクタと任意の記述的な情報の代理をするのに使用されるコード系列)から成ります。 上でセクション2、セクション5、およびセクション6で特定されたキャラクタとコードは、テーブルを初期化するのに使用されるべきです。 記号化体系がユーザ広げることができるので、彼らに似ていない限り、新しいキャラクタのために登録証明書を受け入れるべきです。
Klensin & Alvestrand Informational [Page 11] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[11ページ]のRFC5242
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にアドバイスするのに選ばれるべきです。
9. Security Considerations
9. セキュリティ問題
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.
この形式における、キャラクタの表現はセキュリティのための重要な恩恵であるべきです。 それはフィッシング攻撃の多くの可能性を排除します、Principle1が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とGREEK CAPITAL LETTER ALPHAは同輩を決して比較しないでしょう、彼らが同じく見ますが。
10. Acknowledgments
10. 承認
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の多くの貢献を承諾したがっています。 ユニコードに基づくドメイン名を国際的にしようとする際に遭遇する問題と組み合わせて、彼のコメントと関連するものはここに記録される提案の基本的なかなりの部分を気持ちに大いに寄付しました。 この記号化体系のための理論上の枠組みは、ユニコードとその名前とサンプルglyphsの収集に一部基づいていますが、記号化体系自体への非常に異なったアプローチを表します。
Klensin & Alvestrand Informational [Page 12] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[12ページ]のRFC5242
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
5.0", 2007.
Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0
[ユニコード] ユニコード共同体、「ユニコード規格、バージョン5インチ、2007。」 ボストン(MA)米国: アディソン-ウエスリー。 ISBN0-321-48091-0
11.2. Informative References
11.2. 有益な参照
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
Authors' Addresses
作者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 491 5735 EMail: john+ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: john+ ietf@jck.com
Harald Tveit Alvestrand Google Beddingen 10 Trondheim, 7014 Norway
7014年のハラルドTveit Alvestrand Google Beddingen10トロンヘイム(ノルウェー)
EMail: harald@alvestrand.no
メール: harald@alvestrand.no
Klensin & Alvestrand Informational [Page 13] RFC 5242 Unified CCS April 2008
CCS2008年4月に統一されたKlensin&Alvestrandの情報[13ページ]のRFC5242
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Klensin & Alvestrand Informational [Page 14]
Klensin&Alvestrand情報です。[14ページ]
一覧
スポンサーリンク
