ウェブのための文字モデル 1.0：根本原則

1.1. 目標と視野

“ウェブのための文字モデル” の目標は、W3C が目指す世界共通のアクセス — W3C goal of universal access に則り、すべての人々から，彼らの 言語／用字系（用字, 文字体系）／表記体系／文化的慣習 に関わらず、ウェブ（ World Wide Web ）を利用し易くすることである。 この目標に欠かせない基本的な条件は、世界で利用されている文字を，矛盾無く定義しつつ, 理解し易い方法により，伝送／処理を行えるようにすることである。 The goal of the Character Model for the World Wide Web is to facilitate use of the Web by all people, regardless of their language, script, writing system, and cultural conventions, in accordance with the W3C goal of universal access. One basic prerequisite to achieve this goal is to be able to transmit and process the characters used around the world in a well-defined and well-understood way.

この仕様の主な読者には、 W3C 仕様の開発者が想定されている。 この仕様あるいはその一部分は、他の W3C 仕様から参照され得る。 これは、他の仕様とともに W3C 仕様に対する適合性基準を定める。 The main target audience of this specification is W3C specification developers. This specification and parts of it can be referenced from other W3C specifications. It defines conformance criteria for W3C specifications as well as other specifications.

この仕様が想定している他の読者には、 ソフトウェア開発者／内容開発者／ W3C の外側で策定される仕様の作成者 も含まれている。 ソフトウェア開発者と内容開発者は W3C 仕様を実装し, 利用する。 この仕様は、 W3C 仕様を実装し, 利用する，実装（ソフトウェア）, および内容に対し、いくつかの適合性基準を定める。 これはまた、ソフトウェア開発者や内容開発者­達が， W3C 仕様に含まれる文字に関する規定を理解するための助けにもなる。 Other audiences of this specification include software developers, content developers, and authors of specifications outside the W3C. Software developers and content developers implement and use W3C specifications. This specification defines some conformance criteria for implementations (software) and content that implement and use W3C specifications. It also helps software developers and content developers to understand the character-related provisions in W3C specifications.

この仕様に述べられる文字モデルは、 ウェブ上のテキスト操作を，一貫性を備えた, 相互運用可能なものにするための 共通の基準を、 仕様の作成者／ソフトウェア開発者／内容開発者 に提供する。 これら三者の協同により，より国際的なウェブを築くことが可能になる。 The character model described in this specification provides authors of specifications, software developers, and content developers with a common reference for consistent, interoperable text manipulation on the World Wide Web. Working together, these three groups can build a more international Web.

この “ウェブのための文字モデル” — Character Model for the World Wide Web の根本原則 編で取り挙げられる論題には次のものがある： 語［ “文字”, “符号化法” “文字列” ］の用法, 基準処理モデル, 文字符号化法の選定と識別, 文字エスケープ法, 文字列の付番 Topics addressed in this part of the Character Model for the World Wide Web include use of the terms 'character', 'encoding' and 'string', a reference processing model, choice and identification of character encodings, character escaping, and string indexing.

Character Model の他の部分は、正規化と文字列の同一性­合致検出（ [CharNorm] ）と IRI （ Internationalized Resource Identifiers ）の変換（ [CharIRI] ）からなる。 Other parts of the Character Model address normalization and string identity matching ([CharNorm]) and Internationalized Resource Identifiers (IRI) conventions ([CharIRI]).

まだ全く, あるいは ほんの触りしか取り挙げられてない論題には、曖昧照合や, 言語のタグ付けなどがある。 これらの論題の一部については、この仕様の将来バージョンにて，解決されるものと期待される。 Topics as yet not addressed or barely touched include fuzzy matching, and language tagging. Some of these topics may be addressed in a future version of this specification.

モデルの中核を担うのは、 Unicode 標準 [Unicode] と ISO/IEC 10646 [ISO/IEC 10646] の協同により定義された， Universal Character Set （ UCS ）である。 この文書は、 Universal Character Set の同義語として，語 Unicode を用いる。 モデルは、世界の用字系（および様々なプラットフォーム）で作成されたウェブ文書を、世界のウェブ利用者の間で，交換, 読み取り, 検索できるようにする。 At the core of the model is the Universal Character Set (UCS), defined jointly by the Unicode Standard [Unicode] and ISO/IEC 10646 [ISO/IEC 10646]. In this document, Unicode is used as a synonym for the Universal Character Set. The model will allow Web documents authored in the world's scripts (and on different platforms) to be exchanged, read, and searched by Web users around the world.

1.2. 背景

この節では、この仕様で取り挙げられる論題についての歴史的な背景をいくつか述べる。 This section provides some historical background on the topics addressed in this specification.

HTML の国際化 — Internationalization of the Hypertext Markup Language [RFC 2070] から始まり、ウェブのための文字モデルの必要性が，ウェブのコミュニティから認識されるようになった。 このモデルを築き上げる最初の段階では、 HTML 文書のための文字集合として Unicode を採用する所から取り掛かられた。 Starting with Internationalization of the Hypertext Markup Language [RFC 2070], the Web community has recognized the need for a character model for the World Wide Web. The first step towards building this model was the adoption of Unicode as the document character set for HTML.

Unicode が選定されたのは、次を備えていたからである： The choice of Unicode was motivated by the fact that Unicode:

• 世界共通の文字レパートリとして，唯一利用できるものであったこと, is the only universal character repertoire available,
• 文字を参照する方法に，テキストの符号化法から独立なものを供していること, provides a way of referencing characters independent of the encoding of the text,
• 綿密に更新／補完されてきたこと, is being updated/completed carefully,
• 広く受け入れられ，産業界で実装されてきたこと is widely accepted and implemented by industry.

W3C は [HTML 4.0] において， HTML 文書のための文字集合に Unicode を採用した。 後に，同じアプローチが XML 1.0 [XML 1.0] や CSS2 [CSS21] などの仕様にも踏襲された。 W3C 仕様とアプリケーションは今や、共通の基準となる文字集合に，Unicode を利用している。 W3C adopted Unicode as the document character set for HTML in [HTML 4.0]. The same approach was later used for specifications such as XML 1.0 [XML 1.0] and CSS2 [CSS2]. W3C specifications and applications now use Unicode as the common reference character set.

ウェブ上でのデータ転送が，まだ（サーバからブラウザへの）単方向が大部分を占めていた，主な目的が文書の描画であった頃は、追加の詳細を指定しないままの Unicode の利用でも足りていた。 しかしながら、ウェブは成長した： When data transfer on the Web remained mostly unidirectional (from server to browser), and where the main purpose was to render documents, the use of Unicode without specifying additional details was sufficient. However, the Web has grown:

• サーバ, プロキシ, クライアント間で、どの方向にも互いにデータを転送し合う利用が増加している。 Data transfers among servers, proxies, and clients, in all directions, have increased.
• US-ASCII [ISO/IEC 646][MIME-charset] レパートリに納まらない文字が利用される割合が更に高まっている。 Characters outside the US-ASCII [ISO/IEC 646][MIME-charset] repertoire are being used in more and more places.
• 異なる プロトコル／データ形式 の要素（要素／属性の名前, URI の各種­成分, テキスト内容など）によるデータ転送が増加している。 Data transfers between different protocol/format elements (such as element/attribute names, URI components, and textual content) have increased.
• プロトコルやデータ形式のみならず，更に多数の API が定められてきている。 More and more APIs are defined, not just protocols and formats.

要約すれば、ウェブは 互いに独立な小さなアプリケーションの集合体ではなく，一つのとても巨大なアプリケーションのように見えてきている（ [Nicol] 参照）。 In short, the Web may be seen as a single, very large application (see [Nicol]), rather than as a collection of small independent applications.

これらの開発により、 Unicode がウェブのための文字モデルの基礎になるための要求が強まる一方で， Unicode のウェブへの応用について 追加の仕様を作成する必要も生じてきている。 ウェブのために Unicode に要する追加の仕様には、次のものが挙げられる： While these developments strengthen the requirement that Unicode be the basis of a character model for the Web, they also create the need for additional specifications on the application of Unicode to the Web. Some aspects of Unicode that require additional specification for the Web include:

• Unicode 符号化形式（ UTF-8 ／ UTF-16 ／ UTF-32 ）の選定。 Choice of Unicode encoding forms (UTF-8, UTF-16, UTF-32).
• 可変長の文字符号化法や, 結合文字の下での、文字­数や, 文字列の長さの算出。 Counting characters, measuring string length in the presence of variable-length character encodings and combining characters.
• 文字の多重的な符号化法（例えば 合成済か分解済か）。 Duplicate encodings of characters (e.g. precomposed vs decomposed).
• 種々の目的のための制御文字の利用（例えば 双方向テキストの制御, 対称交換, 等々）。 Use of control codes for various purposes (e.g. bidirectionality control, symmetric swapping, etc.).

この種の側面は，種々の符号化法にも存在し、多くの場合，何らかの方法で あるいは別の形で Unicode に受け継がれていることも、挙げておくべきであろう。 It should be noted that such aspects also exist in various encodings, and in many cases have been inherited by Unicode in one way or another from these encodings.

この仕様の残りの部分では、（ W3C, ISO, IETF による）以前の成果も踏まえ、ウェブのための文字モデルが相互運用性を確保するための追加の要件を示す。 The remainder of this specification presents additional requirements to ensure an interoperable character model for the Web, taking into account earlier work (from W3C, ISO and IETF).

Unicode 標準 [Unicode] の最初の少数の章に，とても有用な背景 情報が見られる。 Internet 上の文字集合の利用のために IETF により採択された施策が [RFC 2277] にて文書­化されている。 The first few chapters of the Unicode Standard [Unicode] provide very useful background reading. The policies adopted by the IETF for on the use of character sets on the Internet are documented in [RFC 2277].

1.3. 記法

Unicode 符号位置は U+hhhh のように記される。 ここで “hhhh” は、4 〜 6 個の 16 進数字の並びである。 Unicode code points are denoted as U+hhhh, where "hhhh" is a sequence of at least four, and at most six hexadecimal digits.

例の中では、読者によるカット＆ペーストが行えるようにテキストが用いられている。 読者の環境に適切なフォントが備わっていないと，これらに利用される文字が 意図された通りに現れないので、そのような場合でも理解し得るように配慮されている。 一部の例では，例示の結果が見えることが重要になるので、画像が利用されている。 それらの画像には、それぞれの例に対応するテキストへのリンク（ 付録 C：テキストの例 の中の例示へのリンク）も張られている。 【 この訳ではすべての例示にテキストも添えているので、前述の節は余分なものになっている。 】 Text has been used for examples to allow them to be cut and pasted by the reader. Characters used will not appear as intended unless you have the appropriate font, but care has been taken to annotate the examples so that they remain understandable even if you do not. In some cases it is important to see the result of an example, so images have been used; by clicking on the image it is possible to link to the text for these examples in C Example text.

【 用語の対訳について： Unicode 関連のものは Unicode Terminology English - Japanese から採用している。 】

3.1. 序論

Unicode 標準 [Unicode 4.0] の索引項目には次のように記されている： The glossary entry in the Unicode Standard [Unicode 4.0] gives:

文字 — (1) 言語が記されるときの，意味を持つ最小の成分であって、抽象的な，意味／形を参照するもの... "Character. (1) The smallest component of written language that has semantic value; refers to the abstract meaning and/or shape ..."

語 “文字” は、多くの文脈下で，異なる意味を伴って利用されている。 様々な人間の文化で、文字の概念を始め，根本的に異なる表記体系が利用されている。 そのような幅広い多様性の下では、末端利用者は，誤解を経験したり, しばしば誤解につながる結果も産み出すことがある。 この多様性は、不完全な技術に起因するものと誤認されがちであるが、人間の思考の多大な柔軟性と創造性，および 人々の文化継承の中で重要な地位を占める筆記の長い伝統に、由来するものである。 Latin, Cyrillic, Greek などの用字系に利用されているアルファベットは、そういった可能性の中の一つに過ぎない。 The word 'character' is used in many contexts, with different meanings. Human cultures have radically differing writing systems, leading to radically differing concepts of a character. Such wide variation in end user experience can, and often does, result in misunderstanding. This variation is sometimes mistakenly seen as the consequence of imperfect technology. Instead, it derives from the great flexibility and creativity of the human mind and the long tradition of writing as an important part of the human cultural heritage. The alphabetic approach used by scripts such as Latin, Cyrillic and Greek is only one of several possibilities.

例： 日本語の 平仮名／片仮名 用字系の文字は、音節（通常は子音と母音の組み合わせ）に対応する。 EXAMPLE: A character in Japanese hiragana and katakana scripts corresponds to a syllable (usually a combination of consonant plus vowel).

例： 韓国語のハングルは、言語の個々の声音に対応する記号を正方形の枠内に組み合わせ，そのそれぞれが１個の音節を表現する。 利用者とアプリケーションに依存して、個別の記号, あるいは音節クラスタが文字と見なされ得る。 EXAMPLE: Korean Hangul combines symbols for individual sounds of the language into square blocks, each of which represents a syllable. Depending on the user and the application, either the individual symbols or the syllabic clusters can be considered to be characters.

例： インド語派の用字系は、各々の子音 字が，［ 子音と母音をクラスタの中で組み合わせるために，半規則的または不規則な方法を用いて、脱落／置換された ］固有の母音を抱えている。 利用者やアプリケーションに依存して，［ 個々の子音や母音, あるいは［ 子音や子音-母音 ］クラスタ ］が文字として知覚され得る。 EXAMPLE: In Indic scripts each consonant letter carries an inherent vowel that is eliminated or replaced using semi-regular or irregular ways to combine consonants and vowels into clusters. Depending on the user and the application, either individual consonants or vowels, or the consonant or consonant-vowel clusters can be perceived as characters.

例： アラビア語とヘブライ語では、母音 声音は概して，全く書き記されない。 それらが書き記されるときは、子音的な字の上／下に置かれる結合マーク 【 シャクル, ニクダー 】 の利用により指示される。 EXAMPLE: In Arabic and Hebrew vowel sounds are typically not written at all. When they are written they are indicated by the use of combining marks placed above and below the consonantal letters.

それらの仕様に基づく仕様の開発者／ソフトウェアの開発者は、彼らが経験してきた 語 “文字” の用法に，より馴染んでいて、国際的­文脈の下での多様な用法には疎くなりがちである。 更に、コンピュータ利用の文脈では、文字はしばしば関連の概念と混同され，不十分あるいは不適切な仕様やソフトウェアが作り上げられることがある。 The developers of specifications, and the developers of software based on those specifications, are likely to be more familiar with usages of the term 'character' they have experienced and less familiar with the wide variety of usages in an international context. Furthermore, within a computing context, characters are often confused with related concepts, resulting in incomplete or inappropriate specifications and software.

この節では、これらのうちいくつかの 文脈, 意味, 混同 について考察する。 This section examines some of these contexts, meanings and confusions.

3.2. 聴覚レンダリングの単位

ある種の用字系では、文字は音素と深く結びついている。 （ 音素 とは、特定の音声言語の文脈の下で区別し得る最小の声音である）。 一方，他のものでは、文字は意味と深く結びついている。 文字が（大まかに）音素に対応する場合でも、この関係は単純でないことが多く，文字と音素の関係が一対一になることは稀である。 In some scripts, characters have a close relationship to phonemes (a phoneme is a minimally distinct sound in the context of a particular spoken language), while in others they are closely related to meanings. Even when characters (loosely) correspond to phonemes, this relationship may not be simple, and there is rarely a one-to-one correspondence between character and phoneme.

例： 英文の “They were too close to the door to close it.” では、 /s/, /z/ いずれの音素の表現にも同じ文字 s が利用される。 EXAMPLE: In the English sentence, "They were too close to the door to close it." the same character 's' is used to represent both /s/ and /z/ phonemes.

例： 英語の “cool” の音素 /k/ は “keel” の音素 /k/ と似ている。 EXAMPLE: In the English language the phoneme /k/ of "cool" is like the phoneme /k/ of "keel".

例： 多くの用字系で、例えば日本語の平仮名の音節­文字のように，１個の文字が一連の音素の並びを表現し得る。 EXAMPLE: In many scripts a single character may represent a sequence of phonemes, such as the syllabic characters of Japanese hiragana.

例： 多くの表記体系は、例えば “thing” の th や ng のように、複数個の文字の並びが１個の音素を表現し得る。 EXAMPLE: In many writing systems a sequence of characters may represent a single phoneme, for example 'th' and 'ng' in "thing".

3.3. 視覚レンダリングの単位

文字の描画（視覚的レンダリング）は、 グリフ の認識概念（ notion ）をもたらす。 ISO/IEC 9541-1 [ISO/IEC 9541-1] によれば、 グリフ とは， 認識し得る抽象的グラフィック記号であって，特定のデザインに依存しないもの として，定義されている。 文字とグリフとの間には、一対一の対応関係は成り立たない： Visual rendering introduces the notion of a glyph. Glyphs are defined by ISO/IEC 9541-1 [ISO/IEC 9541-1] as "a recognizable abstract graphic symbol which is independent of a specific design". There is not a one-to-one correspondence between characters and glyphs:

• １個の文字は、複数のグリフにより表現され得る（各グリフはその文字の表現の一部になる）。 これらのグリフは，物理的に別々に分離され得る。 A single character can be represented by multiple glyphs (each glyph is then part of the representation of that character). These glyphs may be physically separated from one another.
• １個のグリフは、複数個の文字の並びを表現し得る（例えば合字など — 他にもいくつかある）。 A single glyph may represent a sequence of characters (this is the case with ligatures, among others).

• 文字は文脈に依存して，全く異なるグリフで描画され得る。 A character may be rendered with very different glyphs depending on the context.

  【 例えば日本語の縦書きと横書きの下での，一部の文字（句読点や長音その他）。 記号に類するもののみならず、この仕様のペルシャ語の例には，文章内の位置に応じて利用されるグリフが変化する例が示されている。 】

• １個のグリフは、異なる文字を表現し得る（例えば Latin 大文字 A （ U+0041 ）, Greek 大文字 Α （ U+0391 ）, Cyrillic 大文字 А （ U+0410 ） A single glyph may represent different characters (e.g. capital Latin A, capital Greek A and capital Cyrillic A).

グリフの集合は フォント を構成する。 文字が，符号化されたテキストを組織化するための基本的な単位をなすのと同じ様に、一連のグリフも，テキストの視覚的­描画を組織化するための基本的な単位をなすように構築され得る。 A set of glyphs makes up a font. Glyphs can be construed as the basic units of organization of the visual rendering of text, just as characters are the basic unit of organization of encoded text.

付録 B：文字, キーストローク, グリフの例 に、文字からグリフへの対応関係の複雑さを示す例が挙げられている。 See the appendix B Examples of Characters, Keystrokes and Glyphs for examples of the complexities of character to glyph mapping.

3.3.1. 視覚レンダリングと論理順

一部の用字系, 特にアラビア語とヘブライ語は、右から左へ書かれる。 これらの用字系の文字が含まれたテキストは、左右双方向に流れ得るので，双方向テキストと呼ばれる。 Unicode 標準 [Unicode] では、文字が 論理順 で格納／交換されることが要求される。 すなわち、ほぼ，テキストがキーボードでタイプされた順番, あるいは話された順番に対応する（詳細な定義は [Unicode 4.0], 2.2 節を参照）。 論理順による順序付けは、データの相互運用性を確保するため, および アクセス性の向上, 検索, 照合のためにも重要になる。 Some scripts, in particular Arabic and Hebrew, are written from right to left. Text including characters from these scripts can run in both directions and is therefore called bidirectional text. The Unicode Standard [Unicode] requires that characters be stored and interchanged in logical order, i.e. roughly corresponding to the order in which text is typed in via the keyboard or spoken (for a more detailed definition see [Unicode 4.0], Section 2.2). Logical ordering is important to ensure interoperability of data, and also benefits accessibility, searching, and collation.

C003[仕様][実装][内容]

プロトコル／データ形式／ API は、テキストデータを論理順で格納, 交換, 処理しなければならない。 C003 [S] [I] [C] Protocols, data formats and APIs MUST store, interchange or process text data in logical order.

双方向テキストの下では、テキスト選択には２つのモードがある。 最初に挙げる 論理的選択モード は、利用者のマウスの動きの両端の間に 論理的に 位置するすべての文字を選択する。 下の図にて，利用者が２番目の単語の先頭の字とその次の字の合間から, 年号の２桁目まで選択した場合の，論理的な選択は、図の２段目のようになる： In the presence of bidirectional text, two possible selection modes can be considered. The first is logical selection mode, which selects all the characters logically located between the end-points of the user's mouse gesture. Here the user selects from between the first and second letters of the second word to the middle of the number. Logical selection looks like this:

論理的選択により視覚的­範囲が不連続になる （双方向テキストの文脈下における，メモリ内の単独の論理的選択と, その結果得られるスクリーン上の２個の選択範囲を示す，２つの画像） Logical selection resulting in discontiguous visual ranges (Two images contrasting a single logical selection in memory and the resulting two selections on screen, in a bidi context)

視覚表示
論理順
【テキスト】	عدد مارس ١٩٩٨

したがって，双方向テキストの下では、メモリ内における連続的な論理的選択が， スクリーン上では不連続に見え得る ことになる。 この不連続性があるため、一部の利用者からは，マウスの動きの両端に挟まれる中の 視覚的に 位置するすべての文字を選択する， 視覚的選択モード も好まれる。 前の例と同じマウスの動きによる結果は、次の図の様になる： It is a consequence of the bidirectionality of the text that a single, continuous logical selection in memory results in a discontinuous selection appearing on the screen. This discontinuity makes some users prefer a visual selection mode, which selects all the characters visually located between the end-points of the user's mouse gesture. With the same mouse gesture as before, we now obtain:

視覚的選択により論理範囲が不連続になる （双方向テキストの文脈下における，スクリーン上の単独の視覚的選択とその結果得られる, メモリ内の２個の選択範囲を示す，２つの画像） Visual selection resulting in discontiguous logical ranges (Two images contrasting a single visual selection on screen and the resulting two selections in memory, in a bidi context)

視覚表示
論理順
【テキスト】	عدد مارس ١٩٩٨

上の例に見られるように，視覚的選択モードにおいては、 １個の視覚的選択­範囲から 複数個 の論理範囲が得られ得るので、プロトコル, API, 実装による適応の必要が生じ得る。 双方向テキストのための利用者インタフェースに関連する，他の側面としては、キャレットの動き, backspace／delete キーのふるまいなどがある。 In visual selection mode, as seen in the example above, a single visual selection range may result in two or more logical ranges, which may have to be accommodated by protocols, APIs and implementations. Other, related aspects of a user interface for bidirectional text include caret movement, behavior of backspace/delete keys, and so on.

現時点では、大部分の実装が論理的選択を提供しており，視覚的選択を提供しているものはごく限られている。 Currently, most implementations provide logical selection, while only very few provide visual selection.

C075[実装]

選択された文字は、実装の一部が論理的選択／視覚的選択いずれを利用するかに関わらず，格納域においては論理順で保持されなければならない。 C075 [I]Independent of whether some implementation uses logical selection or visual selection, characters selected MUST be kept in logical order in storage.

C004[仕様]

範囲の選択を孕むプロトコルと API の仕様は、それらのプロトコルや API を通して，少なくとも スクリーン上の視覚的選択の実装をサポートするために必要な程度の，不連続な論理的選択を提供するべきである。 C004 [S] Specifications of protocols and APIs that involve selection of ranges SHOULD provide for discontiguous logical selections, at least to the extent necessary to support implementation of visual selection on screen on top of those protocols and APIs.

3.4. 入力の単位

キーボード入力においては，キーストロークと入力される文字に一対一の対応関係があるとは限らない。 キーボードのキーの個数は限られている。 一部のキーボードは、１回のキー押下から複数個の文字を生成する。 キーが文字を生成する代わりに，後続のキー押下の結果に影響する場合もある（ “デッドキー” ）。 多くの表記体系は，キーボードに納まり切らない多数の文字を備えるので、キーストロークの並びを文字の並びに変換する，より複雑な IME （ input-methods ）に頼らなければならない。 一部の文字の入力には特殊な修飾キーを要する言語もある。 自明でない入力の例については 付録 B：文字, キーストローク, グリフの例 を見よ。 In keyboard input, it is not always the case that keystrokes and input characters correspond one-to-one. A limited number of keys can fit on a keyboard. Some keyboards will generate multiple characters from a single keypress. In other cases ('dead keys') a key will generate no characters, but affect the results of subsequent keypresses. Many writing systems have far too many characters to fit on a keyboard and must rely on more complex input methods, which transform keystroke sequences into character sequences. Other languages may make it necessary to input some characters with special modifier keys. See B Examples of Characters, Keystrokes and Glyphs for examples of non-trivial input.

3.5. 照合の単位

整列や検索の際に利用される文字列の比較は、一般的に，符号化された文字に一対一に対応しない単位に基づいている。 その種の文字列­比較では、文字­並びが，整列­順序において固有の位置付けを持つような１個の 照合単位 にまとめられたり, １個の文字が複数個の照合単位に分離されたり, 文字の種々の側面（文字の大小, ダイアクリティカルマークの有無, 等々）が判別されて別々に整列される（多段階 整列）こともある。 String comparison as used in sorting and searching is based on units which do not in general have a one-to-one relationship to encoded characters. Such string comparison can aggregate a character sequence into a single collation unit with its own position in the sorting order, can separate a single character into multiple collation units, and can distinguish various aspects of a character (case, presence of diacritics, etc.) to be sorted separately (multi-level sorting).

加えて、一定量の前処理を要する場合もある。 また，一部の言語（日本語やアラビア語など）では、整列­順序が，発音体系や語源†など，より高次の順序付け因子に支配され得る。 照合の手法はまた，アプリケーションごとに様々になり得る。 In addition, a certain amount of pre-processing may also be required, and in some languages (such as Japanese and Arabic) sort order may be governed by higher order factors such as phonetics or word roots. Collation methods may also vary by application.

例： 【 日本語では、漢字がその画数／偏／旁に基づいて整列されたり, 語句がその読み仮名の順で整列される場合もある。 】

例： スペイン語の伝統的な整列では、文字­並び ch と ll が不可分な照合単位として扱われる。 スペイン語の整列や一定範囲の日常利用では ch が１個の単位と見なされる一方で、現在のデジタル符号化法では２個の文字として扱われ，キーボードも同様になる（利用者は c, h を順にタイプする）。 EXAMPLE: In traditional Spanish sorting, the character sequences 'ch' and 'll' are treated as atomic collation units. Although Spanish sorting, and to some extent Spanish everyday use, treat 'ch' as a single unit, current digital encodings treat it as two characters, and keyboards do the same (the user types 'c', then 'h').

例： 一部の言語では、字 æ が，２個の連続する照合単位： a, e と見なされた上で整列される。 EXAMPLE: In some languages, the letter 'æ' is sorted as two consecutive collation units: 'a' and 'e'.

例： 大文字・小文字の区別がある用字系（ “bicameral” 用字系）で書かれたテキストの整列では、通常，最初の処理パスでは文字­大小の同一視を要し，後続の処理パスの中で文字の大小が仕分けに利用される。 EXAMPLE: The sorting of text written in a bicameral script (i.e. a script which has distinct upper and lower case letters) is usually required to ignore case differences in a first pass; case is then used to break ties in a later pass.

例： 整列におけるアクセントマーク付きの字の扱いは、対象の用字系や言語に依存する。 字 ö は、フランス語においては o の修飾形として扱われる一方，スウェーデン語では o と完全に独立な字として扱われる（加えて，整列­順も z の後になる）。 ドイツ語では、一部のアプリケーションが ö を oe の並びであるかのように扱う。 EXAMPLE: Treatment of accented letters in sorting is dependent on the script or language in question. The letter 'ö' is treated as a modified 'o' in French, but as a letter completely independent from 'o' (and sorting after 'z') in Swedish. In German certain applications treat the letter 'ö' as if it were the sequence 'oe'.

例： タイ語では、 ไก (U+0E44 U+0E01) の並びが กไ (U+0E01 U+0E44) と記されているかのように整列されなければならない。 再順序付けは，概して前処理の段階で行われる。 EXAMPLE: In Thai the sequence 'ไก' (U+0E44 U+0E01) must be sorted as if it were written 'กไ' (U+0E01 U+0E44). Reordering is typically done during an initial pre-processing stage.

例： ドイツ語の辞書では、一般に， ä ／ ö ／ ü がそれぞれ a ／ o ／ u と一緒にされて整列される。 一方で、ドイツ語の電話帳では、一般に， ä ／ ö ／ ü ／ がそれぞれ ae ／ oe ／ ue と綴られているかのように整列される。 このように、利用される照合アルゴリズムは，アプリケーションに依存する。 EXAMPLE: German dictionaries typically sort 'ä', 'ö' and 'ü' together with 'a', 'o' and 'u' respectively. On the other hand, German telephone books typically sort 'ä', 'ö' and 'ü' as if they were spelled 'ae', 'oe' and 'ue'. Here the application is affecting the collation algorithm used.

したがって，テキストに規則の対象外の Unicode 文字が含まれている場合でも、最低でも，照合アルゴリズムが正常に機能し続けることが求められることに注意。 これは、すべての用字系に対応できるような複雑なアルゴリズムの完全な実装を要求するものではない。 この要件を満たす有用な方法として、すべての Unicode 文字が対象にされる，既定の照合アルゴリズムの適用が挙げられる。 Note that this requires, as a minimum, that a collation algorithm does not break down if the text contains Unicode characters that are not covered by its rules. It does not necessarily require full implementation of complex algorithms for all scripts. One useful way of satisfying the requirement is to apply a default collation algorithm that covers all Unicode characters.

ISO/IEC 14651 [ISO/IEC 14651] および Unicode 技術報告 #10, Unicode 照合アルゴリズム [UTR #10] は、大多数の言語に適応する照合のためのモデルを述べ，既定の照合­順序を提供している。 それらは照合とその実装の指針を提供する，適切な基準になる。 いかなる文字が含まれようとも，予測可能な文字列の順序付けと比較を確保するために、既定の照合­順序を，特定のロケールにあつらえの規則と組み合わせて利用できる。 ISO/IEC 14651 [ISO/IEC 14651] and Unicode Technical Report #10, the Unicode Collation Algorithm [UTR #10], describe a model for collation that accommodates most languages and provide a default collation order. They are appropriate references for collation and provide implementation guidelines. The default collation order can be used in conjunction with rules tailored for a particular locale to ensure a predictable ordering and comparison of strings, whatever characters they include.

3.6. 格納の単位

コンピュータにおけるデータの格納と通信は、ビットやバイト（オクテットとも呼ばれる 8-bit 単位）などの，情報の物理的な 格納／交換 の単位に依拠する。 仕様や実装にありがちな誤りは、物理的な格納単位に基づく文字の同等性比較である。 文字とその種の格納単位との間の対応関係は、実際には極めて複雑であり， 次の 4.1 節：文字符号化法 にて論じられる。 Computer storage and communication rely on units of physical storage and information interchange, such as bits and bytes (8-bit units, also called octets). A frequent error in specifications and implementations is the equating of characters with units of physical storage. The mapping between characters and such units of storage is actually quite complex, and is discussed in the next section, 4.1 Character Encoding.

3.7. 要約

語 文字は，種々の文脈の下で異なる仕方で利用されるので、それらの文脈の外で利用された際に，しばしば混同が生じる。 テキストのデジタル表現の文脈の下では、 文字 は，テキストの小さな論理単位として定義し得るものになる。 しかる後、 テキスト が文字の並びとして定義される。 その種の非公式的な定義は、多くの場合，共通の理解を醸成または獲得するに足るものではあるが、詳細が問題にされ始めるや否や，容易に誤解の源になる。 実際に機能する 仕様／プロトコル実装／末端利用者のためのソフトウェア を書くためには、これらの誤解が生じ得ることについて理解しておくことがとても重要である。 The term character is used differently in a variety of contexts and often leads to confusion when used outside of these contexts. In the context of the digital representations of text, a character can be defined as a small logical unit of text. Text is then defined as sequences of characters. While such an informal definition is sufficient to create or capture a common understanding in many cases, it is also sufficiently open to create misunderstandings as soon as details start to matter. In order to write effective specifications, protocol implementations, and software for end users, it is very important to understand that these misunderstandings can occur.

この 3 節：文字の知覚 では、語 “文字” とは必ずしも一致しない単位 — 音素, グリフ, 照合など — のための用語について論じた。 次の 4.1 節：文字符号化法では、 符号化の単位 （符号位置, 符号単位, バイト）を精確に定義するために， “文字” に代わって利用されるべき用語について述べる。 This section, 3 Perceptions of Characters, has discussed terms for units that do not necessarily overlap with the term 'character', such as phoneme, glyph, and collation unit. The next section, 4.1 Character Encoding, lists terms that should be used rather than 'character' to precisely define units of encoding (code point, code unit, and byte).

4.1. 文字符号化法

WWW においては、文字は，コンピュータ利用­環境と同様に，どう利用するにしても 符号化されなければならない。 テキストを符号化するために、多種多様な文字符号化法が考案されている。 文字符号化法とは、概ね，利用者が取り扱う文字の並びとコンピュータが取り扱うビットの並びとの間の対応関係として説明される。 On the WWW, as in any computing environment, characters must be encoded to be of any use. To achieve text encoding, a large variety of character encodings have been devised. Character encodings can loosely be explained as mappings between the character sequences that users manipulate and the sequences of bits that computers manipulate.

与えられたテキスト符号化法の複雑さと，コンピュータの時代を通して考案されてきた 文字符号化法のための多種多様な仕組みの下では、より公式的な符号化処理の記述が有用になる。 テキストの符号化処理を定義する過程は、次のように述べられる（より詳細な記述は “Unicode 技術報告 #17: 文字符号化モデル” [UTR #17] を参照）： Given the complexity of text encoding and the large variety of mechanisms for character encoding invented throughout the computer age, a more formal description of the encoding process is useful. The process of defining a text encoding can be described as follows (see Unicode Technical Report #17: Character Encoding Model [UTR #17] for a more detailed description):

1. まず、符号化の対象になる文字【抽象文字】の集合が選定される。 対象の文字は、１つ以上の対象言語の下で，テキストを表記し, 種々のテキスト処理が効率的に行えるように、実用的に選ばれる。 それらは、利用者が字その他の文字として知覚しているものとは，精確に対応していないかもしれない。 この文字の集合は レパートリ 呼ばれる。 A set of characters to be encoded is identified. The characters are pragmatically chosen to express text and to efficiently allow various text processes in one or more target languages. They may not correspond precisely to what users perceive as letters and other characters. The set of characters is called a repertoire.

   【 レパートリは、通例は固定的（ “closed” ）にされるが，一般的には拡張も可能（ “open” ）にされ得る。 】

2. 次に、レパートリ内の各­文字は， 符号位置 と呼ばれる （数学的, 抽象的な）非負整数に結び付けられる。 その結果、 符号化文字集合 （ CCS ）と呼ばれる，レパートリから非負整数の集合への対応関係が得られる。 （符号位置（ code point ）は、 character-number あるいは code-position と呼ばれることもある。） Each character in the repertoire is then associated with a (mathematical, abstract) non-negative integer, the code point (also known as a character number or code position). The result, a mapping from the repertoire to the set of non-negative integers, is called a coded character set (CCS).

   【 逐語訳的には，“code point” ／ “code position” の対訳はそれぞれ “符号点” ／ “符号位置” になる所であるが、Unicode の公式の対訳表に倣い， “code point” の対訳には “符号位置” を採用している。 】

3. コンピュータ上での利用に適するような， 【固定的な】 基本データ型（バイトや 16-bit などの格納単位）が選定された上で、 文字符号化形式 （ CEF ）と呼ばれる，［ 符号化文字集合（ CCS ）の抽象的­整数を，［ 符号単位 と呼ばれる，基本データ型による値 ］の並びへ符号化するための写像 ］が利用される。 文字符号化形式は、ごく単純なもの（例えば， CCS の整数をコンピュータ プラットフォームで選定されたデータ型による，整数の自然な表現に符号化するもの）から，いくらでも複雑なもの（例えば，１個の抽象的­整数を符号化した結果が、可変個の符号単位からなり，そのそれぞれの値がその整数の自明でない関数で与えられるもの）にもなり得る。 To enable use in computers, a suitable base datatype is identified (such as a byte, a 16-bit unit of storage or other) and a character encoding form (CEF) is used, which encodes the abstract integers of a coded character set (CCS) into sequences of the code units of the base datatype. The character encoding form can be extremely simple (for instance, one which encodes the integers of the CCS into the natural representation of integers of the chosen datatype of the computing platform) or arbitrarily complex (a variable number of code units, where the value of each unit is a non-trivial function of the encoded integer).

4. 最後に，バイト単位の伝達／格納のために、 文字符号化スキーム （ CES, 直列化スキーム とも呼ばれる）が利用される。 文字符号化スキームとは、文字符号化形式（ CEF ）の符号単位から well-defined なバイト列への対応関係であり、データ型が複数バイトに基づく場合に必要になるバイト順の指定や，一部の場合には，複数の文字符号化スキーム（例えば ISO 2022 ）の下での符号単位ごとのスキームの切替も織り込まれる。

   【 “well-defined” — この語の解釈は注意を要する： 例えば対応関係が一対多で結果が一意的に定まらないものであっても，常に，元データを一意的に復元可能ならば、 well-defined と見なされ得るかもしれない。 逆に、個々の対応関係が一対一であっても，全体として元データを一意的に復元できないケースはあり得るので，その種のものは well-defined とは見なされないであろう（レパートリの拡張が許容されている場合は、拡張された際の well-defined の維持も考慮されるべきであろう）。 】

   文字符号化スキームと, それに伴って利用される符号化文字集合の組は， 文字符号化法 （ “character encoding” ）と呼ばれ、 IANA charset 識別子などの，一意的な識別子により識別される。 テキストを表現するバイト列と charset 識別子により識別される文字符号化法が与えられれば、原理的には，テキストの文字­並びを一義的に復元できるようになる。

   【 “文字符号化法” — 訳語としては CES の同義語として用いられることが多いが，この訳ではこの対訳を用いる†。 上に述べられているように， CCS, CEF, CES をひっくるめた概念と捉えればよいであろう（文脈によっては “文字符号化­処理” 等々）。 CCS と CEF が１つに固定された文脈下では（例えば現今のウェブ­プラットフォームの大部分は（その内部­処理モデルが） Unicode と UTF-16 （ 16-bit 符号単位）に基づいている）， CES と同義になる。 （ † — 実際の所、一般には “（文字）エンコーディング” 以外の対訳は見当たらない。 他の “encoding …” については、“符号化…” の対訳があるにも関わらず。） 】

   To enable transmission or storage using byte-oriented devices, a serialization scheme or character encoding scheme (CES) is next used. A character encoding scheme is a mapping of the code units of a character encoding form (CEF) into well-defined sequences of bytes, taking into account the necessary specification of byte-order for multi-byte base datatypes and including in some cases switching schemes between the code units of multiple character encoding schemes (an example is ISO 2022). A character encoding scheme, together with the coded character sets it is used with, is called a character encoding, and is identified by a unique identifier, such as an IANA charset identifier. Given a sequence of bytes representing text and a character encoding identified by a charset identifier, one can in principle unambiguously recover the sequence of characters of the text.

注記： 用語 “charset” および文字符号化法についての更なる詳細についての論は、 4.4.2 節：文字符号化法の識別 を見よ。 NOTE: See 4.4.2 Character encoding identification for a discussion of the term 'charset' and further details on character encodings.

注記： 語 “encoding” （符号化法）は、文字を符号化する実際の処理を指すときや，その処理を遂行するための特定の方法を指すときにも利用されることがあり，いくぶんの曖昧さを孕む（例えば “このファイルは X encoding である” 【 “このファイルは， X という名称から識別される符号化法に規定されている符号化の方法により符号化­処理が施された結果を内容とする” 】）。 これらの用法の区別は、その違いが念頭にありさえすれば，通常は文脈から推定し得るものになる。 NOTE: The term 'character encoding' is somewhat ambiguous, as it is sometimes used to describe the actual process of encoding characters and sometimes to denote a particular way to perform that process (as in "this file is in the X character encoding"). Context normally allows the distinction of those uses, once one is aware of the ambiguity.

注記： 与えられた 文字の並び, および “文字符号化法” から，常に同じ並びのバイトが生成されるとは限らない。 特に， ISO 2022 に基づく符号化法では、符号化処理の過程でいくつかの選択肢をとり得る。 NOTE: Given a sequence of characters, a given 'character encoding' may not always produce the same sequence of bytes. In particular for encodings based on ISO 2022, there may be choices available during the encoding process.

最も単純な場合では、例えば US-ASCII [ISO/IEC 646] や ISO-8859-1 のように，符号化処理 全体が文字からバイトへの自明な一対一の対応関係として、一段で済ませられる。 In very simple cases, the whole encoding process can be collapsed to a single step, a trivial one-to-one mapping from characters to bytes; this is the case, for instance, for US-ASCII [ISO/IEC 646] and ISO-8859-1.

UTF-8 ／ UTF-16 ／ UTF-32 に符号化されたテキストは Unicode 符号化形式 と呼ばれる。 Text is said to be in a Unicode encoding form if it is encoded in UTF-8, UTF-16 or UTF-32.

4.2. 符号変換

テキストをある 文字符号化法 【で符号化された状態】 から別のそれへ変換する処理は 符号変換 と呼ばれる。 符号変換器は、テキストを構文解析せずに、文字符号化法のレベルでのみ働く。 従って、数値文字参照（ 4.6 節：文字エスケープ法 を見よ）などの 文字エスケープ を扱うこともなく，埋め込まれている文字符号化法の情報（例えば XML 宣言や HTML の meta 要素の中の）にも対応しない。 Transcoding is the process of converting text from one character encoding to another. Transcoders work only at the level of character encoding and do not parse the text; consequently, they do not deal with character escapes such as numeric character references (see 4.6 Character Escaping) and do not adjust embedded character encoding information (for instance in an XML declaration or in an HTML meta element).

注記： 符号変換は 一対一, 多対一, 一対多, 多対多 いずれの対応関係も孕み得る。 加えて，文字の格納順序も符号化法の間で変わり得る。 Unicode 符号化形式のような一部のものは，論理順と規定する一方、視覚順を利用するものもある。 符号化法には、ダイアクリティカルマークを基底文字の前に置くよう規定されているものもあれば，後に置くようにするものもある。 これらの文字の並べ方の相違があるため、符号変換は，順序の入れ替わりも孕む： NOTE: Transcoding may involve one-to-one, many-to-one, one-to-many or many-to-many mappings. In addition, the storage order of characters varies between encodings: some, such as the Unicode encoding forms, prescribe logical ordering, while others use visual ordering; among encodings that have separate diacritics, some prescribe that they be placed before the base character, some after. Because of these differences in sequencing characters, transcoding may involve reordering: thus XYZ may map to yxz.

4.3. 基準処理モデル

Internet 上の大部分のプロトコルやデータ形式，特に，最も重要なウェブ­データ形式［ HTML, CSS, XML ］は、テキストに基づいている。 それらのデータ形式は、テキストのみからなるが、 プレーンテキスト （“素のテキスト” — マークアップやプログラミング言語の文脈下にないテキスト）自体が供するものに新たな機能性を加えるために、関連の仕様により，テキストに構造が持ち込まれ, 一定の構成子に意味が与えられる。 HTML と XML は マークアップ言語 である。 すなわち、文書は全体がテキストのみからなるものと規定されつつ，このテキストを マークアップ と 文字データ に分離するための規約も伴なわれる。 XML 1.0 仕様 [XML 1.0] 2.4 節 からの引用： Many Internet protocols and data formats, most notably the very important Web formats HTML, CSS and XML, are based on text. In those formats, everything is text but the relevant specifications impose a structure on the text, giving meaning to certain constructs so as to obtain functionality in addition to that provided by plain text (text that is not in the context of markup or a programming language). HTML and XML are markup languages, defining documents entirely composed of text but with conventions allowing the separation of this text into markup and character data. Citing from the XML 1.0 specification [XML 1.0], section 2.4:

テキスト内容は文字データとマークアップの混成である…（中略）マークアップでないすべてのテキストは、文書の文字データをなす。 "Text consists of intermingled character data and markup. [...] All text that is not markup constitutes the character data of the document."

この節では、もっぱら テキスト （すなわち，文字の並び）の取り扱いについて焦点をあてる。 For the purposes of this section, the important aspect is that everything is text, that is, a sequence of characters.

テキストデータオブジェクト とは、全体がテキストからなるプロトコル­メッセージや文書であるか, あるいは その中の，格納／取得など 外部とのやりとりの目的で別々に扱われるテキストを意味する。 例えば， XML の外部解析対象実体や テキストの MIME entity body [MIME-entity] などが例として挙げられる。 A textual data object is a whole text protocol message or a whole text document, or a part of it that is treated separately for purposes of external storage and retrieval. Examples include external parsed entities in XML and textual MIME entity bodies [MIME-entity].

これは， ISO 2022 のような文字集合 切替スキームが利用できないことを意味するわけではないことに注意。 その種のスキームでは、１つの文字符号化法の下で文字集合の切替が遂行される。 Note that this does not imply that character set switching schemes such as ISO 2022 cannot be used, since such schemes perform character set switching within a single character encoding.

草創期の頃から、ウェブでは 基準処理モデル の開発が行われてきた。 初めて述べられたのは， HTML を対象にした RFC 2070 [RFC 2070] である。 このモデルは後に， XML と CSS に取り込まれた。 上に述べられたように，それはテキストに基づくどんなデータ形式／プロトコルにも適用し得る。 基準処理モデルの本質は、 Unicode を共通の基準に利用する所にある。 仕様による基準処理モデルの利用は、しかしながら，実装が実際に Unicode を利用することを要求するわけではない。 実装には，その処理がモデルの記述に沿って行われるかのようにふるまうことのみが、要件として課される。 また、この文書は語 基準処理モデルを利用し，その処理の内容を通して その特性を述べるが、明示的に処理モデルを規定しない仕様にも，このモデルは適用される。 Since its early days, the Web has seen the development of a Reference Processing Model, first described for HTML in RFC 2070 [RFC 2070]. This model was later embraced by XML and CSS. It is applicable to any data format or protocol that is text-based as described above. The essence of the Reference Processing Model is the use of Unicode as a common reference. Use of the Reference Processing Model by a specification does not, however, require that implementations actually use Unicode. The requirement is only that the implementations behave as if the processing took place as described by the Model. Also, while this document uses the term Reference Processing Model and describes its properties in terms of processing, the model also applies to specifications that do not explicitly define a processing model.

注記： XML 1.0 仕様 [XML 1.0] のアプリケーションを定義するすべての仕様は、自動的に，この基準処理モデルを継承する。 XML では、仕様­全体が Unicode 文字を通して定義されており，解析対象実体には他の文字符号化法も許容されつつ，【 処理モデルにおいては 】 UTF-8 ／ UTF-16 文字符号化法の利用が要求されている。 NOTE: All specifications which define applications of the XML 1.0 specification [XML 1.0] automatically inherit this Reference Processing Model. XML is entirely defined in terms of Unicode characters and requires the UTF-8 and UTF-16 character encodings while allowing any other character encoding for parsed entities.

注記： 仕様において Unicode 符号化形式でない文字符号化法が許容される場合、実装者は，その種の符号化法の文字と Unicode 文字との対応関係が、実施において 符号変換 に利用されるソフトウェアに依存することに，留意するべきである。 その種の不一致については、例えば 日本語 XML Profile [XML Japanese Profile] を参照されたし。 NOTE: When specifications choose to allow character encodings other than Unicode encoding forms, implementers should be aware that the correspondence between the characters of such encodings and Unicode characters may in practice depend on the software used for transcoding. See the Japanese XML Profile [XML Japanese Profile] for examples of such inconsistencies.

Unicode の中には、内部­利用（非文字など）や特殊な機能のための符号位置（代用符号位置など）が一部含まれている。 Unicode contains some code points for internal use (such as noncharacters) or special functions (such as surrogate code points).

相当の理由も無く，一部の符号位置を除外することは、 W3C の世界共通のアクセス性の目標と競合する。 符号位置の除外は、利用者その他のコミュニティにとって重要になり得る 一部の用字系を利用できなくする。 例えば、大きな理由も無く，基本多言語面より先の符号位置を除外するとする裁定や, 符号位置を US-ASCII ／ Latin-1 レパートリに制限することは適切でない。 また、 Unicode 標準では，ソフトウェアが どの符号位置に対しても壊れないことが要求されていることにも注意。 Excluding code points without good reason conflicts with the W3C goal of universal accessibility. Excluding code points would prevent some scripts from being used which may be important to a user community or communities. For example, without strong reasons to do so, decisions to exclude code points above the Basic Multilingual Plane or to limit code points to the US-ASCII or Latin-1 repertoire are inappropriate. Also, please note that the Unicode Standard requires software to not corrupt any code points.

文字を除外する 合法的かつ恣意的でない理由としては、 Unicode in XML and other Markup Languages [UXML] が挙げられる。 そこでは、一部の文字の利用が次のような理由で抑止されている： Other examples of legitimate and non-arbitrary reasons to exclude characters can be seen in Unicode in XML and other Markup Languages [UXML], where the use of certain characters is discouraged for reasons such as:

• それらは Unicode 標準により廃止予定にされた。 They are deprecated in the Unicode Standard.
• それらは 追加のデータなしにサポートされ得ない。 They cannot be supported without additional data.
• それらは マークアップの方がより上手く取り扱える。 They are better handled by markup.
• それらは 等価なマークアップと競合する。 They conflict with equivalent markup.

4.4. 文字符号化法の選定と識別

符号化されたテキストは，符号化法を知ることなしに 解釈／処理 を行えないので、文字符号化法（ 4.1 節：文字符号化法 を見よ）は、テキストが 交換／格納／処理されるような既知のあらゆる所で，決定的に重要になる。 以下では、利用する “文字符号化法” は，文脈に依存して 文字符号化形式 (CEF) または 文字符号化スキーム (CES) のいずれかを意味する。 テキストがバイト­ストリームとして伝送／格納されるときは（例えばプロトコルやファイルシステムの中で）、正しく解釈されることを確保するため， CES の指定が要求される。 API などの文脈では、複数バイトのバイト順は，環境（概して，プロセッサ­アーキテクチャ）から指定されるので、 CEF の指定で足る。 Because encoded text cannot be interpreted and processed without knowing the encoding, it is vitally important that the character encoding (see 4.1 Character Encoding) is known at all times and places where text is exchanged, stored or processed. In what follows we use 'character encoding' to mean either character encoding form (CEF) or character encoding scheme (CES) depending on the context. When text is transmitted or stored as a byte stream, for instance in a protocol or file system, specification of a CES is required to ensure proper interpretation. In contexts such as an API, where the environment (typically the processor architecture) specifies the byte order of multibyte quantities, specification of a CEF suffices.

例： XML に基づくデータ形式が外部実体の文字符号化法を選定／決定する際には、新たなものを考案せずに，既存の XML 規則を利用するべきである。 EXAMPLE: An XML-based format should use the existing XML rules for choosing and determining the character encoding of external entities, rather than invent new ones.

4.4.1. 一意的な文字符号化法の義務付け

一意的な文字符号化法の義務付けは単純かつ効率的で堅牢になる。 符号化法タグを 指定／生成／伝送／解釈 する必要もなくなり、受信側からは，文字符号化法が常に解されることになる。 データが非電子媒体を通して転送された後で，元のデジタル表現に復元する必要が生じた場合でも、利用された文字符号化法についての曖昧さは生じない。 既存のデータ, システム, プロトコル, アプリケーションとの互換性のために 複数の文字符号化法が必要になる場合でも、それらは，しばしば プロトコル, データ形式, API の境界, あるいはそれらの外側で取り扱い得る。 DOM [DOM Level 1] は、これが行われている例になる。 一意的な文字符号化法の選定により、少量のテキストを扱うときや, 仕様が実際の処理に密接なときには，より大きな優位性が得られる。 Mandating a unique character encoding is simple, efficient, and robust. There is no need for specifying, producing, transmitting, and interpreting encoding tags. At the receiver, the character encoding will always be understood. There is also no ambiguity as to which character encoding to use if data is transferred non-electronically and later has to be converted back to a digital representation. Even when there is a need for compatibility with existing data, systems, protocols and applications, multiple character encodings can often be dealt with at the boundaries or outside a protocol, format, or API. The DOM [DOM Level 1] is an example of where this was done. The advantages of choosing a unique character encoding are greater when text sizes are small or the specification is close to the actual processing.

UTF-8 は US-ASCII の上位互換なので（ US-ASCII 文字列は UTF-8 文字列でもある — [RFC 3629] を見よ）、 US-ASCII との互換性が望まれる場合には UTF-8 が適切になる。 他の状況，例えば API などでは、 UTF-16 や UTF-32 がより適切なものになり得る。 これらを選定する際に考慮される理由には、内部­処理の効率性や, 他の処理との相互運用性などが挙げられる。 US-ASCII is upwards-compatible with UTF-8 (an US-ASCII string is also a UTF-8 string, see [RFC 3629]), and UTF-8 is therefore appropriate if compatibility with US-ASCII is desired. In other situations, such as for APIs, UTF-16 or UTF-32 may be more appropriate. Possible reasons for choosing one of these include efficiency of internal processing and interoperability with other processes.

注記： IETF Charset Policy [RFC 2277] には、 プロトコルは UTF-8 charset を利用できなければならない と指定されている。 NOTE: The IETF Charset Policy [RFC 2277] specifies that on the Internet "Protocols MUST be able to use the UTF-8 charset".

注記： XML 1.0 仕様 [XML 1.0] では、すべての適合 XML プロセッサに対し， UTF-16 と UTF-8 のいずれも受け入れることを要求している。 NOTE: The XML 1.0 specification [XML 1.0] requires all conforming XML processors to accept both UTF-16 and UTF-8.

4.4.2. 文字符号化法の識別

MIME Internet 仕様は、文字符号化法を識別するための仕組み [MIME-charset] [RFC 2978] の好例である。 MIME charset パラメタは、受信されたデータのバイト列を 文字の並びに一意的に復号するに足る情報を供するものとして、定義されている。 その値は IANA charset レジストリ [IANA] から抜き出されたものになる。 The MIME Internet specification provides a good example of a mechanism for character encoding identification [MIME-charset][RFC 2978]. The MIME charset parameter definition is intended to supply sufficient information to uniquely decode the sequence of bytes of the received data into a sequence of characters. The values are drawn from the IANA charset registry [IANA].

注記： 具合が悪いことに、一部の charset 識別子は，単一の, 一意的な文字符号化法を表現していない。 これらの識別子は小さな多様性を孕んでいる。 小さくても，その違いは重大になり得るし, 時の経過と伴に変わり得る。 これらの識別子の下では、バイト並びから文字­並びへ復元する際に確定できない部分が生じる。 例えば Shift_JIS では， 0x5C に符号化された文字が確定できない。 この符号位置は YEN SIGN を表現することもあれば， REVERSE SOLIDUS を表現することもある。 この例についての詳細および，他のその種の曖昧性を孕む charset 識別子については [XML Japanese Profile] を参照。 NOTE: Unfortunately, some charset identifiers do not represent a single, unique character encoding. Instead, these identifiers denote a number of small variations. Even though small, the differences may be crucial and may vary over time. For these identifiers, recovery of the character sequence from a byte sequence is ambiguous. For example, the character encoded as 0x5C in Shift_JIS is ambiguous. This code point sometimes represents a YEN SIGN and sometimes represents a REVERSE SOLIDUS. See the [XML Japanese Profile] for more detail on this example and for additional examples of such ambiguous charset identifiers.

注記： 語 charset は、 “文字集合” （ character set ）に由来するもので，長く込み入った歴史を伴う表記である（更なる論は [Connolly] を参照）。 NOTE: The term charset derives from 'character set', an expression with a long and tortured history (see [Connolly] for a discussion).

注記： XML においては、 XML 宣言／テキスト宣言に含められた encoding 疑似属性から， IANA charset を利用する文字符号化法が識別される。 NOTE: In XML, the XML declaration or the text declaration contains the encoding pseudo-attribute which identifies the character encoding using the IANA charset.

IANA charset レジストリは、 Internet 上の文字符号化スキーム名とそれらの別名が含められている，公式のリストである。 The IANA charset registry is the official list of names and aliases for character encoding schemes on the Internet.

注記： 巨大なレパートリを備え, 広範からのサポートもある Unicode に基づく文字符号化法は、文書の符号化として好ましい選定である。 NOTE: Due to Unicode's large repertoire and wide base of support, a character encoding based on Unicode is a good choice to encode a document.

経験則の例としては、バイト（パタン）や文字（パタン）の頻度に対する統計的解析の利用が挙げられる。 経験則は実装­間でふるまいが一貫しないので好ましくない。 XML 1.0 [XML 1.0], Appendix F にて与えられるような、明確な指示書きにより，文字符号化法を一義的に決定する方法は、経験則とは見なされない。 Examples of heuristics include the use of statistical analysis of byte (pattern) frequencies or character (pattern) frequencies. Heuristics are bad because they will not work consistently across different implementations. Well-defined instructions of how to unambiguously determine a character encoding, such as those given in XML 1.0 [XML 1.0], Appendix F, are not considered heuristics.

受信側のソフトウェアは、必要に応じて，任意数の 文字符号化法および charset 名とその別名 を認識してよい。 Receiving software may recognize as many character encodings and as many charset names and aliases for them as appropriate.

field-upgradeable 【具体的には何？】 の仕組みは、この目的に適切なものになる。 一部の文字符号化法は、ある程度 一定の言語との結び付きが強い（例えば Shift_JIS と日本語）。 与えられた言語や一定層の顧客のサポートは、一定の文字符号化法のサポートの必要を意味し得る。 しかしながら、支持は得ているが要求されてはいない符号化法に対する世界共通サポートが必要と見なされているわけではない。 サポートを要する文字符号化法は，時の経過に伴い変わり得る。 この文書は、与えられた言語のサポートに，どの文字符号化法が適切／必要であるかについてのアドバイスは供さない。 A field-upgradeable mechanism may be appropriate for this purpose. Certain character encodings are more or less associated with certain languages (e.g. Shift_JIS with Japanese). Trying to support a given language or set of customers may mean that certain character encodings have to be supported. However, one cannot assume universal support for a favoured but non-required encoding. The character encodings that need to be supported may change over time. This document does not give any advice on which character encoding may be appropriate or necessary for the support of any given language.

ウェブ­アーキテクチャは層の積み重ねであるので（例えばプロトコルを通して利用されるデータ形式）、文字符号化法についての情報が複数あったり競合することが起こり得る。 Because of the layered Web architecture (e.g. formats used over protocols), there may be multiple and at times conflicting information about character encoding.

6.1. 文字列の概念（ concept ）

様々な仕様が “文字列” の認識概念（ notion ）を利用するが、その意味の定義が精確に与えられなかったり，他の仕様と異なるように定義されることもある。 実際、文字列には その認識概念の意図される利用に依存して，複数の理に適った定義がある。 これらは、実際には同じ実在 — コンピュータ内に格納されるテキスト片 — に対し，異なる見方を与えるものに過ぎないので、これら異なる認識概念のどれにも，語 “文字列” が利用されるのである。 Various specifications use the notion of a 'string', sometimes without defining precisely what is meant and sometimes defining it differently from other specifications. The reason for this variability is that there are in fact multiple reasonable definitions for a string, depending on one's intended use of the notion; the term 'string' is used for all these different notions because these are actually just different views of the same reality: a piece of text stored inside a computer.

【 文字列（ string ） — 訳語としては，この語が定着しているが、本来は “同じもの（同種のもの）の並び” を意味し、 “文字の列” よりも抽象的な概念としても用いられる。 】

バイト文字列： 特定の文字符号化法の下で、文字を，それを表現するバイト列として捉えたときの文字列。 これは 文字符号化スキーム (CES) に対応する。 バイト文字列のテキスト処理は、それに利用されている特定の符号化法に依存する。 符号化法が変更された場合，その処理も，新たな符号化法の構造が反映されるように変更されなければならなくなる。 その種の変更は、そのバイト文字列がテキストとして処理される際に利用される関数や API に対し，大きな設計変更を要し得る。 したがって この定義は、文字列のテキストとしての特質が重要ではない，文字列が単にバイト長を伴う “不透明な” データ片と見なされるときにのみ（バッファを複製するときなど）、仕様において有用になる。 Byte string: A string viewed as a sequence of bytes representing characters in a particular character encoding. This corresponds to a character encoding scheme (CES). Text processing of a byte string is dependent on the particular encoding used. When the encoding changes the processing must also be changed to reflect the stucture of the new encoding. Such a change could require significant redesign of the functions or API used to process the byte strings as text. Therefore, this definition is only useful in specifications when the textual nature of a string is unimportant and the string is considered only as a piece of opaque data with a length in bytes (such as when copying a buffer).

符号単位文字列： 特定の文字符号化法の下で、文字を，それを表現する 符号単位 の並びとして捉えたときの文字列。 これは 文字符号化形式 (CEF) に対応する。 符号単位文字列を定義するためには、符号単位のサイズ（例えば 16 ビット）, および 利用される文字符号化法（例えば UTF-16 ）の選定を要する。 符号単位文字列は、実装の候補にされている符号化形式について依拠できる知識に基づいた，文字列データの物理的­表現を公開する API において有用になる。 例えば， DOM [DOM Level 1], では、広範な実装の実践に基づいて， UTF-16 が選定されている。 一般的に、“符号単位文字列” は， UTF-16 または UTF-32 が実装の候補にされている場合にのみ有用になる。 Code unit string: A string viewed as a sequence of code units representing characters in a particular character encoding. This corresponds to a character encoding form (CEF). A definition of a code unit string needs to include the size of the code units (e.g. 16 bits) and the character encoding used (e.g. UTF-16). Code unit strings are useful in APIs that expose a physical representation of string data based on reliable knowledge of the encoding forms that are likely candidates for implementation. Example: For the DOM [DOM Level 1], UTF-16 was chosen based on widespread implementation practice. In general, 'code unit string' is only useful if the implementation candidates are likely to be either UTF-16 or UTF-32.

文字文字列 ： それぞれが Unicode [Unicode] の 符号位置 で表現される，文字の並びとして捉えたときの文字列。 これは，大方の利用者が知覚する文字と正確には一致しないかもしれないが、プログラマたちが通常，文字列とみなしているものである。 これが、ごく少ない実装の労力で相互運用性を確保できるような，最も高次の抽象化­層である。 “文字文字列” の定義による文字列が、一般的に最も有用になる。 この定義を利用する好例には XML 1.0 [XML 1.0] の生成規則 “[2]”, HTML 4.0 [HTML 4.01] の SGML 宣言, RFC 2070 [RFC 2070] の文字モデルなどが挙げられる。 Character string: A string viewed as a sequence of characters, each represented by a code point in Unicode [Unicode]. This is usually what programmers consider to be a string, although it may not match exactly what most users perceive as characters. This is the highest layer of abstraction that ensures interoperability with very low implementation effort. The 'character string' definition of a string is generally the most useful. Good examples using this definition include the Production [2] of XML 1.0 [XML 1.0], the SGML declaration of HTML 4.0 [HTML 4.01], and the character model of RFC 2070 [RFC 2070].

【 文字文字列（ character string ） — 訳語としては不自然な重複になってしまうが、この節の冒頭で注釈した様に， “文字列” という語自体が訳語として定着しているため、致し方ない所でも。 】

例： 次の表の各行に、文字［ U+233B4 （“切り株” を意味する，中国語の文字）, U+2260 NOT EQUAL TO, U+0071 LATIN SMALL LETTER Q, U+030C COMBINING CARON ］からなる，ビッグエンディアン バイト順で UTF-16 に符号化された文字列に対し， 文字文字列, 符号単位文字列, バイト文字列 で捉えた様子を順に示す： EXAMPLE: Consider the string comprising the characters U+233B4 (a Chinese character meaning 'stump of tree'), U+2260 NOT EQUAL TO, U+0071 LATIN SMALL LETTER Q and U+030C COMBINING CARON, encoded in UTF-16 in big-endian byte order. The rows of the following table show the string viewed as a character string, code unit string and byte string, respectively:

文字­並び／符号単位 列／バイト列としての，文字列 table displaying a string viewed as characters, code units and bytes

グリフ（画像）
【グリフ（テキスト）】	𣎴				≠		q		̌
文字文字列	U+233B4				U+2260		U+0071		U+030C
符号単位文字列	D84C		DFB4		2260		0071		030C
バイト文字列	D8	4C	DF	B4	22	60	00	71	03	0C

注記： 文字列は、 書記素クラスタ の並びとして見ることもできる。 書記素クラスタは、 文字文字列 に比して，描画されたテキストにおいて 利用者から知覚される文字の境界に より近似する単位に，テキストを分離する。 書記素クラスタについての論は Unicode 標準, バージョン 4 [Unicode 4.0] の 2.10 節の末尾に与えられている。 公式的な定義は Unicode 標準 Annex #29 [UTR #29] にて与えられる。 Unicode 標準は 既定の 書記素クラスタを定義する。 一部の言語は、この既定をより適切な形にあつらえることを要する。 例えば，スロヴァキア語の利用者からは、書記素クラスタの既定のペア ch が単独の書記素クラスタとして扱われることが望まれるであろう。 文字列­内容の言語と末端利用者の選好との間の相互作用は複雑なものになり得ることに注意。 NOTE: It is also possible to view a string as a sequence of grapheme clusters. Grapheme clusters divide the text into units that correspond more closely than character strings to the user's perception of where character boundaries occur in a visually rendered text. A discussion of grapheme clusters is given at the end of Section 2.10 of the Unicode Standard, Version 4 [Unicode 4.0]; a formal definition is given in Unicode Standard Annex #29 [UTR #29]. The Unicode Standard defines default grapheme clustering. Some languages require tailoring to this default. For example, a Slovak user might wish to treat the default pair of grapheme clusters "ch" as a single grapheme cluster. Note that the interaction between the language of string content and the end-user's preferences may be complex.

6.2. 文字列の付番

ソフトウェアの処理が 部分文字列, あるいは文字列の中の一点へのアクセスを必要とし， index — すなわち，数値による文字列の中の “位置” — を利用してそれを行う状況は頻繁にある。 その種の index がウェブ上のコンポーネント間でやりとりされても，ふるまいの一貫性が保たれるためには、文字列の付番（文字列の中の各位置への番号の振り方）について予め合意される必要がある。 文字列の付番のための要件は “文字列の同一性­合致検出のための要件” — Requirements for String Identity Matching [CharReq], 4 節 にて論じられる。 主要な問いは２つある： (1) “どのような単位に基づいて数えるか？” (2) “0 か 1 どちらを起点にするか？” There are many situations where a software process needs to access a substring or to point within a string and does so by the use of indices, i.e. numeric "positions" within a string. Where such indices are exchanged between components of the Web, there is a need for an agreed-upon definition of string indexing in order to ensure consistent behavior. The requirements for string indexing are discussed in Requirements for String Identity Matching [CharReq], section 4. The two main questions that arise are: "What is the unit of counting?" and "Do we start counting at 0 or 1?".

前の 6.1 節：文字列の概念 では、文字列が 文字文字列, 符号単位文字列, バイト文字列 として捉えられることを示した。 そのそれぞれが異なる単位に基づく付番を孕んでいる。 The example in the previous section, 6.1 String concepts, shows a string viewed as a character string, code unit string and byte string, respectively, each of which involves different units for indexing.

処理の特定の要件に依存して、数え方の単位は 6.1 節：文字列の概念 にて与えられた，文字列の種々の定義に対応し得る。 特に： Depending on the particular requirements of a process, the unit of counting may correspond to definitions of a string provided in section 6.1 String concepts. In particular:

• C051[仕様][実装]

  文字列の付番は、 文字文字列 に基づくものが推奨される。 C051 [S] [I] The character string is RECOMMENDED as a basis for string indexing.

  （例： XML Path 言語 [XPath] ）。 (Example: the XML Path Language [XPath]).

• C052[仕様][実装]

  内部­演算の効率性が 文字文字列 に基づく付番に比して大幅に向上する場合は、 符号単位文字列 に基づく文字列の付番が利用されてもよい。 C052 [S] [I] A code unit string MAY be used as a basis for string indexing if this results in a significant improvement in the efficiency of internal operations when compared to the use of character string.

  （例： [DOM Level 1] における UTF-16 の利用）。 (Example: the use of UTF-16 in [DOM Level 1]).

• C071[仕様][実装]

  利用者との対話が主要な部分を占めるアプリケーションにおいては、 書記素クラスタ に基づく文字列の付番が利用されてもよい。 C071 [S] [I] Grapheme clusters MAY be used as a basis for string indexing in applications where user interaction is the primary concern.

  Unicode 標準 Annex #29, Text Boundaries [UTR #29] を参照。 See Unicode Standard Annex #29, Text Boundaries [UTR #29].

  C074[仕様]

  書記素クラスタを通して付番を定義する仕様は、次のいずれかにより定義しなければならない： a) Unicode 標準 Annex #29, Text Boundaries [UTR #29] にて定義される既定の書記素クラスタを通して，書記素クラスタを定義する, または b) 付番­演算を，より適切な形にあつらえる方法を特に詳細に規定する。 C074 [S]Specifications that define indexing in terms of grapheme clusters MUST either: a) define grapheme clusters in terms of default grapheme clusters as defined in Unicode Standard Annex #29, Text Boundaries [UTR #29], or b) define specifically how tailoring is applied to the indexing operation.

• C072[仕様][実装]

  バイト文字列 に基づく付番は推奨されない。 C072 [S] [I] The use of byte strings for indexing is NOT RECOMMENDED.

数値を通さずに部分文字列を識別しつつ，都合の良い特性を備えるような、特記すべき方法もある。 例えば、文字列­合致検出に基づく部分文字列は，小さな編集に対し十全に堅牢であり、文書­構造に基づく部分文字列（ XML のような構造的なデータ形式）は，編集に対し, あるいは別の自然言語への翻訳においてすらも，より堅牢である。 It is noteworthy that there exist other, non-numeric ways of identifying substrings which have favorable properties. For instance, substrings based on string matching are quite robust against small edits; substrings based on document structure (in structured formats such as XML) are even more robust against edits and even against translation of a document from one human language to another.

経験から、個々の文字は，部分文字列の前／後の位置から識別される部分文字列として解された上で処理された方が、より 汎用, 柔軟, 堅牢 な仕様になることが判っている。 index を数え方の単位の狭間の位置と解することで、異なる文字列­定義による index にも関連付け易くなる。 Experience shows that more general, flexible and robust specifications result when individual characters are understood and processed as substrings, identified by a position before and a position after the substring. Understanding indices as boundary positions between the counting units also makes it easier to relate the indices resulting from the different string definitions.

例： 仮に “大文字化” 関数 uppercase の返り値型が１個の文字として定義された場合、 uppercase("ß") は，正しい結果（長さ２の文字文字列 SS ）を返せなくなる。 【 現在の Unicode には "ß" の大文字 （ "ẞ" ）もあるので，この例は文脈によっては適切でないかもしれない。 】 また， 3 節：文字の知覚 にて述べたように、文字と，声音／入力 の単位, 等々の間に一対一の対応関係が成り立つとは限らないことにも注意。 EXAMPLE: The function uppercase("ß") cannot return the proper result (the two-character string 'SS') if the return type of the uppercase function is defined to be a single character. Note, also, that there is not necessarily a one-to-one mapping between characters and units of sound, input, etc. as described in 3 Perceptions of Characters.

index の起点，すなわち 0, 1 のいずれから数えるかについて — この問題は、実際には，単位それ自身を数えるか 単位の狭間の位置を数えるかの裁定が下された後にのみ，発生する。 The issue of index origin, i.e. whether we count from 0 or 1, actually arises only after a decision has been made on whether it is the units themselves that are counted or the positions between the units.

A.1. 参照文献（規範的）

[IANA]

Internet Assigned Numbers Authority, Official Names for Character Sets. (See http://www.iana.org/assignments/character-sets.)

[ISO/IEC 10646]

ISO/IEC 10646:2003, Information technology -- Universal Multiple-Octet Coded Character Set (UCS), as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. (See http://www.iso.org/iso/en/ISOOnline.openerpage for the latest version.)

[MIME-entity]

N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions (MIME). Part One: Format of Internet Message Bodies, RFC 2045, November 1996, http://www.ietf.org/rfc/rfc2045.txt.

[MIME-charset]

Multipurpose Internet Mail Extensions (MIME). Part Two: Media Types, N. Freed, N. Borenstein, RFC 2046, November 1996, http://www.ietf.org/rfc/rfc2046.txt.

[RFC 2119]

S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119. (See http://www.ietf.org/rfc/rfc2119.txt.)

[Unicode]

The Unicode Consortium, The Unicode Standard, Version 4, ISBN 0-321-18578-1, as updated from time to time by the publication of new versions. (See http://www.unicode.org/unicode/standard/versions for the latest version and additional information on versions of the standard and of the Unicode Character Database).

[Unicode 3.2]

The Unicode Consortium, The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (see http://www.unicode.org/reports/tr27) and by the Unicode Standard Annex #28: Unicode 3.2 (see http://www.unicode.org/reports/tr28).

[Unicode 4.0]

The Unicode Consortium. The Unicode Standard, Version 4.0, Reading, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1. (See http://www.unicode.org/versions/Unicode4.0.0/)

A.2. 他の参照文献

[CharNorm]

Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin, Addison Phillips Character Model for the World Wide Web 1.0: Normalization, W3C Working Draft. (See http://www.w3.org/TR/charmod-norm.)

[CharIRI]

Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin, Character Model for the World Wide Web 1.0: Resource Identifiers, W3C Candidate Recommendation. (See http://www.w3.org/TR/charmod-resid.)

[CharReq]

Martin J. Dürst, Requirements for String Identity Matching and String Indexing, W3C Working Draft. (See http://www.w3.org/TR/WD-charreq.)

[Connolly]

D. Connolly, Character Set Considered Harmful, W3C Note. (See http://www.w3.org/MarkUp/html-spec/charset-harmful.)

[CSS21]

Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Eds., Cascading Style Sheets, level 2 (CSS2 Specification), W3C Recommendation. (See http://www.w3.org/TR/REC-CSS2.)

[DOM Level 1]

Vidur Apparao et al., Document Object Model (DOM) Level 1 Specification, W3C Recommendation. (See http://www.w3.org/TR/REC-DOM-Level-1.)

[HTML 4.0]

Dave Raggett, Arnaud Le Hors, Ian Jacobs, Eds., HTML 4.0 Specification, W3C Recommendation, 18-Dec-1997 (See http://www.w3.org/TR/REC-html40-971218.)

[HTML 4.01]

Dave Raggett, Arnaud Le Hors, Ian Jacobs, Eds., HTML 4.01 Specification, W3C Recommendation. (See http://www.w3.org/TR/html401.)

[ISO/IEC 646]

ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange. This standard defines an International Reference Version (IRV) which corresponds exactly to what is widely known as ASCII or US-ASCII. ISO/IEC 646 was based on the earlier standard ECMA-6. ECMA has maintained its standard up to date with respect to ISO/IEC 646 and makes an electronic copy available at http://www.ecma-international.org/publications/standards/Ecma-006.htm

[ISO/IEC 9541-1]

ISO/IEC 9541-1:1991, Information technology -- Font information interchange -- Part 1: Architecture. (See http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17277 for the latest version.)

[ISO/IEC 14651]

ISO/IEC 14651:2000, Information technology -- International string ordering and comparison -- Method for comparing character strings and description of the common template tailorable ordering as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. (See http://www.iso.org/iso/en/ISOOnline.openerpage for the latest version.)

[MathML2]

David Carlisle, Patrick Ion, Robert Miner, Nico Poppelier, Eds., Mathematical Markup Language (MathML) Version 2.0, W3C Recommendation. (See http://www.w3.org/TR/MathML2.)

[Nicol]

Gavin Nicol, The Multilingual World Wide Web, Chapter 2: The WWW As A Multilingual Application. (See http://www.mind-to-mind.com/library/papers/multilingual/multilingual-www.html.)

[RFC 2070]

F. Yergeau, G. Nicol, G. Adams, M. Dürst, Internationalization of the Hypertext Markup Language, IETF RFC 2070, January 1997. (See http://www.ietf.org/rfc/rfc2070.txt.)

[RFC 2277]

H. Alvestrand, IETF Policy on Character Sets and Languages, IETF RFC 2277, BCP 18, January 1998. (See http://www.ietf.org/rfc/rfc2277.txt.)

[RFC 2978]

N. Freed, J. Postel, IANA Charset Registration Procedures, IETF RFC 2978, BCP 19, October 2000. (See http://www.ietf.org/rfc/rfc2978.txt.)

[RFC 3629]

F. Yergeau, UTF-8, a transformation format of ISO 10646, IETF RFC 3629, STD 63, November 2003. (See http://www.ietf.org/rfc/rfc3629.txt.)

[RFC 2781]

P. Hoffman, F. Yergeau, UTF-16, an encoding of ISO 10646, IETF RFC 2781, February 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)

[SPREAD]

SPREAD - Standardization Project for East Asian Documents Universal Public Entity Set. (See http://www.ascc.net/xml/resource/entities/index.html)

[SVG]

Jon Ferraiolo, 藤沢 淳 (FUJISAWA Jun), Dean Jackson, Ed., Scalable Vector Graphics (SVG) 1.1 Specification, W3C Recommendation. (See http://www.w3.org/TR/SVG.)

[UTR #10]

Mark Davis, Ken Whistler, Unicode Collation Algorithm, Unicode Technical Report #10. (See http://www.unicode.org/unicode/reports/tr10.)

[UTR #17]

Ken Whistler, Mark Davis, Character Encoding Model, Unicode Technical Report #17. (See http://www.unicode.org/unicode/reports/tr17.)

[UTR #29]

Mark Davis, Text Boundaries, Unicode Standard Annex #29. (See http://www.unicode.org/unicode/reports/tr29 for the latest version).

[UXML]

Martin Dürst and Asmus Freytag, Unicode in XML and other Markup Languages, Unicode Technical Report #20 and W3C Note. (See http://www.w3.org/TR/unicode-xml.)

[XML 1.0]

Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, Eds., Extensible Markup Language (XML) 1.0, W3C Recommendation. (See http://www.w3.org/TR/REC-xml.)

[XML Japanese Profile]

MURATA Makoto Ed., XML Japanese Profile, W3C Note. (See http://www.w3.org/TR/japanese-xml.)

[XPath]

James Clark, Steve DeRose, Eds, XML Path Language (XPath) Version 1.0, W3C Recommendation. (See http://www.w3.org/TR/xpath.)