Web のための文字モデル 1.0:根本原則

Character Model for the World Wide Web 1.0: Fundamentals

© Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.


この概念的枠組み仕様は、[ 仕様の作者/~software開発者/内容~開発者 ]向けに、[ `~Unicode標準$( `Unicode Standard^en )と `ISO/IEC-10646$r の共同により定義された, Universal Character Set ]の上に築かれた,[ ~Web上の相互運用可能な~text操作~用の,共通の基準 ]を供する。 この文書は、次の論題について取組む: ⇒# 用語[ `文字$q, `符号化法$q, `文字列$q ]の用法, `基準~処理~model$sec, `文字~符号化法の選定と識別$sec, `文字~escape法$sec, `文字列の付番$sec( `indexing^en ) ◎ This Architectural Specification provides authors of specifications, software developers, and content developers with a common reference for interoperable text manipulation on the World Wide Web, building on the Universal Character Set, defined jointly by the Unicode Standard and ISO/IEC 10646. Topics addressed include use of the terms 'character', 'encoding' and 'string', a reference processing model, choice and identification of character encodings, character escaping, and string indexing.

文字列の正規化と同一性~合致については、姉妹~文書 `CharNorm$r ( “~Webのための文字~model 1.0 :正規化” )を見よ。 資源~識別子については、姉妹~文書 `CharIRI$r ( “~Webのための文字~model 1.0 :資源~識別子” )を見よ。 ◎ For normalization and string identity matching, see the companion document Character Model for the World Wide Web 1.0: Normalization [CharNorm]. For resource identifiers, see the companion document Character Model for the World Wide Web 1.0: Resource Identifiers [CharIRI].



1. 序論

1.1. 目標と視野

“~Webのための文字~model” の目標は、~W3Cが目標とする世界共通の~access — `W3C goal of universal access^cite — に則り、すべての人々から,彼らの[ 言語/`用字系$( `script^en )/`書記体系$/文化的慣習 ]に関わらず、~Web( `World Wide Web^en )を利用し易くすることである。 この目標を達成するための基本的要件は、世界中で利用されている文字を,きちんと定義され, 理解し易い仕方により,伝送-可能かつ処理-可能にすることである。 ◎ 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.

この仕様が対象にする他の読者には、[ ~software開発者/内容~開発者/~W3Cの外側で策定される仕様の作者 ]も含まれる。 [ ~software開発者/内容~開発者 ]は~W3C仕様を[ 実装する/利用する ]。 この仕様は、~W3C仕様を[ 実装する実装(~software)/利用する内容(作者) ]に対し,いくつかの適合性基準を定義する。 これはまた、~software開発者や内容~開発者たちが,~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.

この仕様に述べられる文字~modelは、 ~Web上の~text操作を,一貫性を備え, かつ相互運用可能なものにするための 共通の基準を、[ 仕様の作者/~software開発者/内容~開発者 ]に供する。 これら三者の協同により,より国際的な~Webを築くことが可能になる。 ◎ 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.

この “~Webのための文字~model” — `Character Model for the World Wide Web^en の根本原則 編 — では、次に挙げる論題に取組む ⇒# 用語[ `文字$q, `符号化法$q, `文字列$q ]の用法, `基準~処理~model$sec, `文字~符号化法の選定と識別$sec, `文字~escape法$sec, `文字列の付番$sec( `indexing^en ) ◎ 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$r )と IRI ( `Internationalized Resource Identifiers^en )の変換( `CharIRI$r )に取組む。 ◎ Other parts of the Character Model address normalization and string identity matching ([CharNorm]) and Internationalized Resource Identifiers (IRI) conventions ([CharIRI]).

まだ取組まれてないか,触れるだけにとどめている論題には、~fuzzy合致や, 言語の~tag付けなどがある。 これらの論題の一部については、この仕様の将来~versionにて取組まれるであろう。 ◎ 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.

~modelの中核を担うのは、 `~Unicode標準$と `ISO/IEC-10646$r の共同により定義された, `Universal Character Set^en ( `UCS$ )である。 この文書は、 Universal Character Set の同義語として,語 `~Unicode^q を利用する。 ~modelは、世界中の`用字系$(および様々な~platform)で著作された~Web文書を、世界中の~Web利用者が,やりとり, 読み取り, 探索できるようにする。 ◎ 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$の国際化 `RFC2070$r から始まり、~Webのための文字~modelの必要性が,~Webの~communityから認識されるようになった。 この~modelを築く第一歩は、~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:

  • 世界共通の文字~repertoireとして,唯一~可用であった ◎ is the only universal character repertoire available,
  • ~textの符号化法に依存しない,文字を参照する仕方を供している ◎ 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は `HTML40$r において,~HTML文書~用の`文字~集合$に~Unicodeを採用した。 後に,同じ~approachが `XML10$r や `CSS21$r などの仕様にも踏襲された。 ~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.

~Web上での~data転送が,まだ(~serverから~browserへの)単方向がほとんどであった,主な目的が文書の`具現化$であった頃は、追加的な詳細を指定しないままの~Unicodeの利用でも足りていた。 しかしながら、~Webは成長した: ◎ 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:

  • ~server, ~proxy, ~client間で、どの方向にも互いに~dataを転送し合う利用が増えている。 ◎ Data transfers among servers, proxies, and clients, in all directions, have increased.
  • US-ASCII `ISO/IEC-646$r `MIME-charset$r `~repertoire$に納まらない文字が利用される~~割合が更に高まっている。 ◎ Characters outside the US-ASCII [ISO/IEC 646][MIME-charset] repertoire are being used in more and more places.
  • 異なる[ ~protocol/形式 ]を成す要素(要素や属性の名前, URI の各種~成分, ~text内容など)による~data転送が増えている。 ◎ Data transfers between different protocol/format elements (such as element/attribute names, URI components, and textual content) have increased.
  • ~protocolや形式のみならず,~APIも続々と定義されてきている。 ◎ More and more APIs are defined, not just protocols and formats.

手短に言えば、~Webは 互いに独立な小さな応用の集合体ではなく,一つのとても巨大な応用のように見えてきている( `Nicol$r を見よ)。 ◎ 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を~Webのための文字~modelの基礎とする要件が強まったことに加え,~Unicodeの~Webへの応用に対する追加的な仕様を作成する必要も生じてきている。 ~Web用に追加的な仕様を要求するような,~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$ec / `UTF-16$ec / `UTF-32$ec )を選ぶこと。 ◎ 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).
  • 様々な目的での制御~codeの利用(例:`双方向性$の制御, `対称交換$, 等々)。 ◎ 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 による)以前の成果も踏まえ、~Webのための文字~modelが相互運用能を確保するための追加的な要件を示す。 ◎ 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標準$の最初の少数の章に,とても有用な背景~~情報が見られる。 また, `RFC2277$r には、 IETF により,~Internet上の`文字~集合$の利用~用に採択された施策が文書~化されている。 ◎ 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.

例の中では、読者が~cut&~pasteできるよう,~textが利用されている。 読者の環境に適切な`~font$が備わっていないと,これらに利用される文字が意図されたとおりに現れないので、そのような場合でも理解-可能になるよう配慮されている。 一部の事例では,例示の結果が見えることが重要になるので、画像も併用されている。 ◎ 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 から採用している。 】

2. 適合性

この節では、[[ 仕様 / ~software / ~Web内容 ]が,この仕様に適合すると主張-可能になる ]ために充足する必要がある条件が,どう記されるかについて説明する。 ◎ This section explains the conditions that specifications, software, and Web content have to fulfill to be able to claim conformance to this specification.

この文書の中で利用される次に挙げる句は、 `RFC2119$r に則って解釈するものとする ⇒# “〜しなければ(しては)ナラナイ( `MUST (NOT)^en )”, “〜するベキ(でない)( `SHOULD (NOT)^en )”, “推奨される( `RECOMMENDED^en )”, “〜してもヨイ( `MAY^en )” ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119].

注記: RFC 2119 には、[ “〜するベキ” ( `SHOULD^en )として記された要件は、任意選択( `OPTIONAL^en/ `MAY^en )ではなく,特に理由が無い限り従うもの ]と解釈されなければならないと,明瞭に記されている:

この語, および “推奨される” (形容詞としての `RECOMMENDED^en )は、[ 特定0の状況下では,特定0の~~条項を無視する妥当な理由が存在し得る ]が,[ 別の道を選ぶ前に,その全部的な含意を理解した上で 注意深く検討しなければならない ]ことを意味する。
◎ NOTE: RFC 2119 makes it clear that requirements that use SHOULD are not optional and must be complied with unless there are specific reasons not to: "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

この仕様は、 3 種の~~主体[ 仕様, ~software実装, ~Web内容 ]向けに適合性基準を定義する。 各 適合性基準には、関連する~~主体を指示する — `-S^cf / `-I^cf / `-C^cf — が前置される†。 これは、読者が,自身に関連する適合性基準を この文書~内から素早く探し出すことも可能にする††。 ◎ This specification defines conformance criteria for specifications, for software, and for Web content. To aid the reader, all conformance criteria are preceded by '[X]' where 'X' is one of 'S' for specifications, 'I' for software implementations, and 'C' for Web content. These markers indicate the relevance of the conformance criteria and allow the reader to quickly locate relevant conformance criteria by searching through this document.

【† これらは、原文では,略称[ [S][I][C] ]で表記されている。 】【†† 下の各 ~~見出しをクリックすると巡回できる。


仕様は、次をすべて満たすとき,この文書に適合する: ◎ A specification conforms to this document if it:

  • `-S^cf が前置されている適合性基準に違反していない。 ◎ does not violate any conformance criteria preceded by [S],
  • “〜するベキ”, “推奨される” と記された判定基準から逸脱する所では、その理由が文書~化されている。 ◎ documents the reason for any deviation from criteria where the imperative is SHOULD, SHOULD NOT, or RECOMMENDED,
  • 適用-可能な所では、当の仕様に適合する[ 実装/内容 ]に対し,この文書にも適合することを要求している。 ◎ where applicable, requires implementations conforming to the specification to conform to this document, ◎ where applicable, requires content conforming to the specification to conform to this document.

実装(~software)は、 `-I^cf が前置されている適合性基準に違反しないとき,この文書に適合する。 ◎ An implementation (software) conforms to this document if it does not violate any conformance criteria preceded by [I].

内容は、 `-C^cf が前置されている適合性基準に違反しないとき,この文書に適合する。 ◎ Content conforms to this document if it does not violate any conformance criteria preceded by [C].

注記: 仕様に課される要件は、それらの仕様に適合する実装や内容に対し,間接的に要件を課し得る。 同様に、内容に課される要件は、そのような内容を生産するよう設計された実装にも影響し得る,等々。 ◎ NOTE: Requirements placed on specifications might indirectly cause requirements to be placed on implementations or content that claim to conform to those specifications. Likewise, requirements placed on content may affect implementations designed to produce such content, and so on.

この仕様において処理に対し要件を課す所では、外部から見える挙動を指定していると解するものとする。 実装は、観測され得る挙動が影響されない限り,同じ結果を達成する他の手段を利用できる。 ◎ Where this specification places requirements on processing, it is to be understood as a way to specify the desired external behavior. Implementations can use other means of achieving the same results, as long as observable behavior is not affected.

3. 文字の知覚

3.1. 序論

`~Unicode標準$の `Unicode40$r の用語集には、次のように記されている: ◎ The glossary entry in the Unicode Standard [Unicode 4.0] gives:

文字( `character$UT ) — (1) 言語が記されるときの,意味論的な価値( `value^en )を持つ最小の成分であって、抽象的な意味や形状を参照rするもの… ◎ "Character. (1) The smallest component of written language that has semantic value; refers to the abstract meaning and/or shape ..."

語 `文字^q は、多くの文脈~下で,異なる意味を伴って利用されている。 様々な人間の文化で、根本的に異なる`書記体系$が利用されているため,文字の概念も根本的に異なっている。 そのような幅広い多様性の下では、末端利用者は,誤解を経験したり誤解を呼ぶことが多い。 この多様性は、~~不完全な技術に起因するものと誤認されがちであるが、人間の思考の多大な柔軟性と創造性,および 人々の文化継承の中で重要な部分を成す筆記の長い伝統から導出されたものである。 ~Latin, ~Cyrillic, ~Greekなどの`用字系$に利用されている`~alphabet$類は、そういった可能性の一つに過ぎない。 ◎ 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.

~Japaneseの[ `平仮名$/`片仮名$ ]`用字系$の文字は、`音節$(通例的に`子音$と`母音$の組合わせ)に対応する。 ◎ EXAMPLE: A character in Japanese hiragana and katakana scripts corresponds to a syllable (usually a combination of consonant plus vowel).

~Koreanの`~Hangul$は、言語の個々の音響に対応する記号を正方形の~~枠内に組合せて,そのそれぞれが 1 個の`音節$を表現する。 利用者と応用に依存して、個別の記号, あるいは音節~clusterが文字と見なされ得る。 ◎ 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.

~Indicの`用字系$は、各々の`子音$ `字l$が,[ `子音$と`母音$を~clusterの中で組合せるために,半規則的または不規則な仕方を利用して、脱落-/置換された ]内来的な`母音$を抱えている。 利用者や応用に依存して,[ 個々の`子音$や`母音$, あるいは[ `子音$や子音-母音 ]~cluster ]が文字として知覚され得る。 ◎ 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.

~Arabic, ~Hebrewでは、`母音$の音響は概して,全く書き記されない。 それらが書き記されるときは、子音的な`字l$の上/下に置かれる`結合~符$ 【`シャクル^, `ニクダー^】 の利用により指示される。 ◎ 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.

それらの仕様に基づく仕様や~softwareの開発者は、彼らが経験してきた用語 `文字$q の用法に,より馴染んでいて、国際的~文脈の下での多様な用法には疎くなりがちである。 更に、~computer利用の文脈の下では、文字は関係する概念と混同され,不完全あるいは不適切な仕様や~softwareが作り上げられることが多い。 ◎ 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. 聴覚的な具現化の単位

`用字系$には、文字と音素の関係性が深いものもあれば,文字が意味と深く関係しているものもある。 (`音素$( `phoneme^en )とは、特定0の音声言語の文脈の下で区別し得る最小の音響である)。 文字が音素に(ゆるく)対応する場合でも、この関係性は単純でないことが多く,文字と音素が一対一に対応することは稀である。 ◎ 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” では、 /s/, /z/ 両 `音素$とも,その表現に同じ文字 `s^ch が利用される。 ◎ 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.

~Englishの “`cool^s” の音素 /k/ は、 “`keel^s” の音素 /k/ と似ている。 ◎ EXAMPLE: In the English language the phoneme /k/ of "cool" is like the phoneme /k/ of "keel".

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

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

`001-SIC@cf 仕様, ~software, 内容は、言語の 文字と音響の一対一の対応関係に依存したり,それを要求してはナラナイ。 ◎ C001 [S] [I] [C] Specifications, software and content MUST NOT require or depend on a one-to-one correspondence between characters and the sounds of a language.

3.3. 視覚的な具現化の単位

文字の描画(視覚的な`具現化$)は、`~glyph$の認識概念( `notion^en )を導入する。 `ISO/IEC-9541-1$r によれば、 `~glyph@ ( `glyph$UT )とは, 認識し得る抽象的~graphic記号であって,特定の~designに依存しないもの として,定義されている。 文字と~glyphとの間には、一対一の対応関係が`あるわけではない^em: ◎ 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:

  • 1 個の文字は、複数の`~glyph$により表現され得る(各~glyphはその文字の表現の一部になる)。 これらの~glyphは,物理的に別々に分離され得る。 ◎ 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.
  • 1 個の`~glyph$は、複数個の文字が成す並びを表現し得る(例えば`合字$が該当する — 他にもいくつかある)。 ◎ A single glyph may represent a sequence of characters (this is the case with ligatures, among others).
  • 文字は文脈に依存して,全く異なる`~glyph$で描画され得る。 ◎ A character may be rendered with very different glyphs depending on the context.

    【 例えば~Japaneseの縦書きと横書きの下での,一部の文字(句読点や長音その他)。 記号に類するもののみならず、この仕様の~Persianの例には,単語~内の位置に応じて利用される~glyphが変化する例が示されている。 】

  • 1 個の`~glyph$は、異なる文字を表現し得る(例: ~Latin大文字 A ( `0041^U ), ~Greek大文字 Α ( `0391^U ), ~Cyrillic大文字 А ( `0410^U ) ◎ A single glyph may represent different characters (e.g. capital Latin A, capital Greek A and capital Cyrillic A).

`~glyph$の集合は `~font@ ( `font$UT )を成す。 文字が,符号化された~textを組織化するための基本的な単位を成すのと同じ様に、一連の~glyphも,~textの視覚的~描画を組織化するための基本的な単位を成すように構築され得る。 ◎ 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.

`002-SIC@cf 仕様, ~software, 内容は、文字と~textの表示~単位との一対一の対応関係に依存したり,それを要求してはナラナイ。 ◎ C002 [S] [I] [C] Specifications, software and content MUST NOT require or depend on a one-to-one mapping between characters and units of displayed text.

付録 B. 文字, ~keystroke, ~glyphの例 に、文字から`~glyph$への対応関係の複階性を示す例が挙げられている。 ◎ See the appendix B Examples of Characters, Keystrokes and Glyphs for examples of the complexities of character to glyph mapping.

3.3.1. 視覚的な具現化と論理~順序

一部の`用字系$, 特に~Arabicと~Hebrewは、右から左へ書かれる。 これらの`用字系$の文字が含まれた~textは、左右両~方向に流れ得るので,`双方向~text$と呼ばれる。 `~Unicode標準$では、文字が `論理~順序$( `logical order^en )で[ 格納する/交換する ]ことが要求される。 すなわち、ほぼ,~textが[ ~keyboardで打込まれた/話された ]順序に対応する(詳細な定義は `Unicode40$r, 2.2 節を見よ)。 `論理~順序$による順序付けは、~dataの相互運用能を確保するため, および[ ~accessibility, 探索, `照合$( `collation^en 【言語や文脈に依存する整列順序法】) ]の便益を得るためにも重要になる。 ◎ 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.

`003-SIC@cf [ ~protocol/形式/~API ]は、~text~dataを`論理~順序$で格納-, 交換-, 処理しなければナラナイ。 ◎ C003 [S] [I] [C] Protocols, data formats and APIs MUST store, interchange or process text data in logical order.

`双方向~text$の下では、アリな~text選択~modeが 2 つある。 先ず,論理的な選択~modeは、利用者の~mouse~gestureの両端の合間に`論理的^emに所在するすべての文字を選択する。 ◎ 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.\

次の図に,利用者が~Arabicの~text[ `عدد مارس ١٩٩٨^s ]を成す[ 2 個目の単語の 1 個目と 2 個目の`字l$の合間から, 年号( 3 個目の単語)の 2 桁目まで ]を選択した場合の,論理的な選択を視覚~表示とともに示す: ◎ 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:

論理的な選択により視覚的~範囲が不連続になる ( `双方向~text$の文脈~下における,~memory内の単独の論理的な選択と, その結果~得られる~screen上の 2 個の選択範囲を示す, 2 つの画像 ) ◎ 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)
視覚~表示 `論理~順序$
画像 同じ例で,選択~textが強調されたときの~screen上での表示を示す画像。
2 個の分離された文字~blockが強調される。
The same example, showing how the text would look on-screen when highlighted, showing two separate highlighted character ranges. 2 個の~Arabicの単語に年号が後続する文字列における論理~順序による文字~並び。
2 個目の単語の途中から年号の途中までの範囲に入る文字が選択されたとするとき、論理~選択~modeでは,強調される範囲が 1 個の連続的な文字~並びになる。
An example showing the logical order of characters in a string containing two Arabic words followed by a year number. In logical selection mode, the range of characters selected by starting the selection in the middle of the second word and ending in the middle of the year number is depicted using highlighting. The highlighting covers a single block of contiguous characters.
【~text】 `عدد مارس ١٩٩٨^s ع د د <space> م ا ر س <space> ١ ٩ ٩ ٨

したがって,`双方向~text$の下では、~memory内における連続的な論理的な選択が,`~screen上では不連続に現れる^emことになる。 この不連続性があるため、一部の利用者からは,~mouse~gestureの両端に挟まれる中の`視覚的^emに所在するすべての文字を選択する,視覚的な選択~modeも選好される。 ◎ 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.\

前の例と同じ~mouse~gestureによる結果は、次の図の様になる: ◎ With the same mouse gesture as before, we now obtain:

視覚的な選択により論理~範囲が不連続になる ( `双方向~text$の文脈~下における,~screen上の単独の視覚的な選択とその結果~得られる, ~memory内の 2 個の選択範囲を示す, 2 つの画像 ) ◎ 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)
視覚~表示 `論理~順序$
画像 同じ例で,選択~textが強調されたときの~screen上での表示を示す画像。単独の連続する文字~blockが強調される。
same example, showing how the text would look on-screen when highlighted, showing
a single highlighted block of contiguous characters. 2 個の~Arabicの単語に年号が後続する文字列における論理~順序による文字~並び。
2 個目の単語の途中から年号の途中までの範囲に入る文字が選択されたとするとき、視覚的な選択~modeでは,強調される範囲が 2 個の分離された文字~blockになる。
An example showing the logical order of characters in a string containing two Arabic words followed by a year number. In visual selection mode, the range of characters selected by starting the selection in the middle of the second word and ending in the middle of the year number is depicted using highlighting. The highlighting covers two separate blocks of characters.
【~text】 `عدد مارس ١٩٩٨^s ع د د <space> م ا ر س <space> ١ ٩ ٩ ٨

上の例に見られるように,視覚的な選択~modeにおいては、 1 個の視覚的な選択から`複数個^emの論理~範囲が得られ得るので、~protocol, ~API, 実装による適応の必要が生じ得る。 `双方向~text$用の~UIに関係する,他の側面としては、~caretの動き, [ `backspace^kbd`delete^kbd ]~keyの挙動などがある。 ◎ 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.

`075-I@cf 選択された文字は、実装の一部が[ 論理的な選択, 視覚的な選択 ]どちらを利用しようが,格納~域においては`論理~順序$が保たれなければナラナイ。 ◎ C075 [I]Independent of whether some implementation uses logical selection or visual selection, characters selected MUST be kept in logical order in storage.

`004-S@cf 範囲の選択を孕む~protocolや~APIの仕様は、[ 少なくとも ~screen上の視覚的な選択の実装を~supportするために必要な程度の,不連続な論理的な選択 ]を,それらの~protocolや~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. 入力の単位

~keyboard入力においては,~keystrokeと入力される文字に一対一の対応関係があるとは`限らない^em。 ~keyboardの~keyの個数は限られている。 一部の~keyboardは、 1 回の~key押下から複数個の文字を生成する。 ~keyが文字を生成する代わりに,後続の~key押下の結果に影響する事例もある(~dead-key)。 多くの`書記体系$は,~keyboardに納まり切らない多数の文字を備えるので、~keystroke並びを文字~並びに変換する,より複階的な~IME( `input-method^en )に依拠しなければならない。 一部の文字の入力には特殊な修飾keyが必要とされる言語もある。 自明でない入力の例については 付録 B. 文字, ~keystroke, ~glyphの例 を見よ。 ◎ 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.

`005-SI@cf 仕様, ~softwareは、次を要求したり, それに依存してはナラナイ ⇒# 1 回の~keystrokeから 1 個の文字が得られる / 1 個の文字は 1 回の~keystroke(修飾keyを伴うものも含む)で入力される / 世界中のどの~keyboardも同じである ◎ C005 [S] [I] Specifications and software MUST NOT require nor depend on a single keystroke resulting in a single character, nor that a single character be input with a single keystroke (even with modifiers), nor that keyboards are the same all over the world.

3.5. 照合の単位

整列や探索の際に利用される文字列の比較は、一般に,符号化された文字と一対一に対応しない単位に基づいている。 そのような文字列~比較では、[ 文字~並びが 整列~順序において自前の位置を持つような 1 個の照合~単位( `collation unit^en )に集成される/ 1 個の文字が複数個の照合~単位に分離される/ 文字の様々な側面(`文字大小$, `発音区別符$の有無, 等々)が判別されて別々に整列される(多段階 整列) ]こともある。 ◎ 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).

加えて、一定量の前処理が要求される場合もある。 また,一部の言語(~Japaneseや~Arabicなど)では、整列~順序が,発音体系や語源など,より高次の順序付け要因により統治され得る。 `照合$( `collation^en )の手法はまた,応用ごとに様々になり得る。 ◎ 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.

  • 【~Japaneseでは、`漢字$がその画数/偏/旁に基づいて整列されたり, 語句がその読み~~仮名の順で整列される場合もある。】
  • ~Spanishの伝統的な整列では、文字~並び `ch^ch, および `ll^ch は不可分な照合~単位として扱われる。 ~Spanishの整列やある~~範囲の日常~利用では `ch^ch が 1 個の単位と扱われれる一方で、現在の~digital符号化法では 2 個の文字として扱われ,~keyboardも同じに扱う(利用者は `c^kbd, `h^kbd を順に打込む)。 ◎ 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').
  • 一部の言語では、`字l$ `æ^ch が, 2 個の連続する照合~単位[ `a^ch, `e^ch ]として整列される。 ◎ EXAMPLE: In some languages, the letter 'æ' is sorted as two consecutive collation units: 'a' and 'e'.
  • ~~大文字・~~小文字の区別がある( `bicameral$UT な)`用字系$で書かれた~textを整列するときは、通例的に,最初の処理~passでは`文字大小$を無視することが要求され,後の処理~passの中で文字大小が仕分けに利用される。 ◎ 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.
  • 整列における`~accent$付きの`字l$の扱いは、対象の`用字系$や言語に依存する。 `字l$ `ö^ch は、~Frenchでは修飾された `o^ch として扱われる一方,~Swedishでは `o^ch と完全に独立な`字l$として扱われる(加えて,整列~順も `z^ch の後になる)。 ~Germanでは、一部の応用は `ö^ch を `oe^ch の並びであるかのように扱う。 ◎ 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'.
  • ~Thaiでは、 `ไก^ch (`0E44^U `0E01^U) 並びが `กไ^ch (`0E01^U `0E44^U) と記されているかのように整列されなければならない。 この種の並替えは、概して,前処理の段階で行われる。 ◎ 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.
  • ~Germanの辞書では、概して,[ `ä^ch / `ö^ch / `ü^ch ]が[ `a^ch / `o^ch / `u^ch ]と一緒にされて整列される。 一方で、~Germanの電話帳では、概して,[ `ä^ch / `ö^ch / `ü^ch / ]が[ `ae^ch / `oe^ch / `ue^ch ]と綴られているかのように整列される。 このように、利用される照合~algoは,応用に依存する。 ◎ 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.

`006-SI@cf 利用者のために~textを整列あるいは探索する~softwareは、関連する言語や応用に適切な照合~単位と順序付け規則に基づいて,それを行うベキである。 ◎ C006 [S] [I] Software that sorts or searches text for users SHOULD do so on the basis of appropriate collation units and ordering rules for the relevant language and/or application.

`007-SI@cf 探索や整列が動的に行われる所では、特に多言語~環境においては, “関連する言語” が現在の利用者のそれになるように(したがって利用者ごとに異なり得るように)決定されるベキである ◎ C007 [S] [I] Where searching or sorting is done dynamically, particularly in a multilingual environment, the 'relevant language' SHOULD be determined to be that of the current user, and may thus differ from user to user.

`066-SI@cf 利用者による~textの整列や探索が可能な~softwareは、照合~単位と順序付け用に,代替~規則も選択できるようにするベキである。 ◎ C066 [S] [I] Software that allows users to sort or search text SHOULD allow the user to select alternative rules for collation units and ordering.

`008-SI@cf [ 整列/探索 ]~algoの仕様と実装は、~textが~Unicodeのどの文字を含んでいても,適応するベキである。 ◎ C008 [S] [I] Specifications and implementations of sorting and searching algorithms SHOULD accommodate text that contains any character in Unicode.

したがって,~textに当の規則が受持たない~Unicode文字が含まれている場合でも、最低でも,照合~algoが~~正常に~~働き続けることが求められることに注意。 これは、すべての`用字系$に対応できるような複階的な~algoの全部的な実装を要求するものではない。 この要件を満たす有用な仕方として、すべての~Unicode文字を受持つ既定の照合~algoを適用することが挙げられる。 ◎ 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$r, および[ `UTR10$r による`~Unicode照合~algo$ ]は、ほとんどの言語に適応する`照合$用の~modelを述べて,既定の照合~順序を供している。 それらは`照合$とその実装の指針を供する,適切な基準になる。 いかなる文字が含まれようとも,予測-可能な文字列の順序付けと比較を確保するために、既定の照合~順序を,特定0の~locale用に誂えられた規則と併用できる。 ◎ 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. 格納の単位

~computerにおける~dataの格納と通信は、~bitや`~byte$(~octetとも呼ばれる 8-bit 単位)などの,情報の物理的な[ 格納/交換 ]の単位に依拠する。 仕様や実装にありがちな誤りは、物理的な格納~単位による文字の同等性比較である。 文字とそのような格納~単位との間の対応関係は、実際にはかなり複階的であり, `文字~符号化法$sec(次節)にて論じられる。 ◎ 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.

`009-SI@cf 仕様, ~software, 内容は、文字と物理的な格納~単位との一対一の対応関係に依存したり,それを要求してはナラナイ。 ◎ C009 [S] [I] Specifications, software and content MUST NOT require or depend on a one-to-one relationship between characters and units of physical storage.

3.7. 要約

用語 文字は,様々な文脈の下で異なる仕方で利用されるので、それらの文脈の外で利用された際に,混同を導くことが多い。 ~textの~digital表現の文脈においては、 `文字@ は,~textの小さな論理~単位として定義できる。 その上で、 `~text@ が文字たちが成す並びとして定義される。 そのような非公式的な定義は、多くの事例で,共通の理解を醸成する/獲得するに足るものではあるが、詳細が問題になり始めるや否や,誤解を醸成する道を開くに足るものにもなる。 実効な[ 仕様/~protocol実装/末端利用者~向け~software ]を書くためには、これらの誤解が生じ得ることを理解しておくことがとても重要である。 ◎ 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.

この`文字の知覚$sec節では、用語 `文字$q とは必ずしも一致しない単位 — `音素$, `~glyph$, `照合$など — 用の用語について論じた。 `文字~符号化法$sec(次節)では、符号化の単位(`符号位置$, `符号単位$, `~byte$)を精確に定義するために,`文字$qに代わって利用されるべき用語について述べる。 ◎ 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).

`010-S@cf 用語 `文字$qを利用する仕様は、それが意図する意味を定義しなければナラナイ。 ◎ C010 [S] When specifications use the term 'character' the specifications MUST define which meaning they intend.

`067-S@cf 仕様は、可用なときは,一般~用語 “文字” に代えて,特定の用語を利用するベキである。 ◎ C067 [S] Specifications SHOULD use specific terms, when available, instead of the general term 'character'.

4. 文字の~digital符号化法

4.1. 文字~符号化法

~Webにおいては、文字は,~computer利用~環境と同じく,どう利用するにしても符号化されなければならない。 ~textを符号化するために、多種多様な`文字~符号化法$が~~考案されている。 `文字~符号化法$とは、概ね,利用者が操作する文字~並びと~computerが操作する~bit列の間の対応関係として説明される。 ◎ 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.

~text符号化法の複階性と,~computerの時代を通して考案されてきた `文字~符号化法$用の多種多様な仕組みが与えられた下では、より公式的な符号化~処理-の記述が有用になる。 ~textの符号化~処理-を定義する過程は、次のように述べられる(より詳細な記述は `UTR17$r を見よ): ◎ 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. まず、 `~repertoire@ ( `repertoire$UT ) — 符号化される対象の文字【`抽象~文字$】が成す集合 — が同定される。 対象の文字は、[ いくつかの対象~言語の下で、~textを表出して,様々な~text処理を効率的に行える ]ように,実用的に選ばれる。 それらは、利用者が`字l$その他の文字として知覚しているものとは,精確に対応していないかもしれない。 ◎ 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.

    【 ~repertoireは、通例的には固定的( “closed” )にされるが,一般には拡張可能( “open” )なものもあり得る。 】

  2. 次に,`~repertoire$を成す各~文字は、 `符号位置@ ( `code point$UT ) — (数学的, 抽象的な)非負~整数 — に結付けられる。 その結果、 `有符号~文字~集合@ ( `coded character set$UT, 略称 `CCS^abbr ) — ~repertoireから非負~整数が成す集合への対応関係 — が得られる。 (符号位置は、 `character number^en あるいは `code position^en と呼ばれることもある。) ◎ 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 position^en” の対訳が “~~符号位置” になり, “`code point^en” の対訳は “~~符号点” になる所だが、~Unicodeの公式の対訳表に倣い, “`code point^en” の対訳には “~~符号位置” を採用している。 】

  3. ~computerにおける利用に相応しい,ある基底~data型(`~byte$や 16-bit などの格納~単位)が同定された上で、 `文字~符号化形式@ ( `character encoding form$UT, 略称 `CEF^abbr )が利用される — それは、`有符号~文字~集合$( `CCS^abbr )を成す抽象的な整数を[ `符号単位@ ( `code unit$UT )と呼ばれる,基底~data型の値 ]たちが成す並びへ符号化するための~~写像である。 `文字~符号化形式$は、ごく単純なもの(一例として, `CCS^abbr の整数を~computer~platformで選ばれた~data型による,整数の自然な表現に符号化するもの)から,いくらでも複階的なもの( 1 個の抽象的~整数を符号化した結果が,可変~個数の[ 整数から自明でない関数で得られる符号単位 ]からなるもの)にもなり得る。 ◎ 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. 最後に,~byte単位の伝送/格納を可能化するために、 `文字~符号化~scheme@ ( `character encoding scheme$UT, 略称 `CES^abbr )が利用される(直列化~scheme( `serialization scheme^en )とも呼ばれる)。 `文字~符号化~scheme$とは、`文字~符号化形式$の`符号単位$から~byte列へのきちんと定義された対応関係であり、~data型が複数~byteに基づく場合に必要とされる~byte順の指定や,一部の事例では,複数の文字~符号化~schemeの下での`符号単位$ごとの~schemeの切替も含まれる(例: ISO 2022 )。 ◎ 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).\

    【 “きちんと定義された( `well-defined^en )” — この語の~~解釈は注意を要する: 例えば対応関係が一対多で結果が一意でなくとも,元~dataを常に一意に復元-可能ならば、きちんと定義されたと見なされるかもしれない。 逆に、個々の対応関係が一対一であっても,全体として元~dataを一意に復元できない事例はあり得るので,その種のものは きちんと定義されたとは見なされないかもしれない(`~repertoire$の拡張が許容されている場合は、拡張されても きちんと定義され続ける必要がある)。 】

    `文字~符号化~scheme$と, それに伴って利用される`有符号~文字~集合$の組は, `文字~符号化法@ ( `character encoding^en )と呼ばれ、 IANA ~charset識別子などの,一意な識別子により識別される。 ~textを表現する~byte列と~charset識別子により識別される文字~符号化法が与えられれば、原理的には,~textを成す文字~並びを一義的に復元できるようになる。 ◎ 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.

    【 すなわち, CCS, CEF, CES をひっくるめた概念と捉えればよいであろう(文脈によっては,これらのうち一つを指すこともある)。 対訳としての “~~符号化法” には, “エンコーディング” が広く用いられているが、 “~~符号化形式” など この語を一部に含む対訳と揃えるため,この訳ではこの対訳を用いる。 `有符号~文字~集合$, `文字~符号化形式$とも一つに固定された文脈~下では(現今の~Web~platformの大部分は、~Unicode, `UTF-16$ec ( 16-bit `符号単位$)に基づいている)、`文字~符号化~scheme$を指すことが多い。 】

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

注記: 用語 文字~符号化法( `character encoding^en )は、文字を符号化する実際の処理を述べることもあれば,その処理を遂行するための特定0の仕方を指すときにも利用されることもあり,いくぶん多義的である(例えば “この~fileは X encoding である” 【“この~fileは, 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.

注記: 所与の[ 文字~並び, `文字~符号化法$ ]から,常に同じ並びの~byteが生産されるとは限らない。 特に, 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.

ごく単純な事例では、符号化~処理- 全体を文字から`~byte$への自明な一対一の対応関係として,一段で済ませられる。 一例として、 `US-ASCII$ec `ISO/IEC-646$r や `iso-8859-1^ec が該当する。 ◎ 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$ec / `UTF-16$ec / `UTF-32$ec ]に符号化された~textは `~Unicode符号化形式@ ( `Unicode encoding form$UT )と呼ばれる。 ◎ Text is said to be in a Unicode encoding form if it is encoded in UTF-8, UTF-16 or UTF-32.

4.2. 符号変換

ある文字~符号化法(`文字~符号化~scheme$)で符号化された~textを別の文字~符号化法へ変換する処理は `符号変換@ ( `transcoding$UT )と呼ばれる。 符号変換器は、~textを構文解析することなく,文字~符号化法の~levelでのみ働く。 したがって、数量的な文字~参照などの`文字~escape$を扱うことも,埋込まれた文字~符号化法の情報(一例として、`~XML宣言$や`~HTML$の `meta^c 要素による情報)を調整することもない。 ◎ 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符号化形式$のような一部のものは,`論理~順序$と規定しているが、`視覚~順序$を利用するものもある。 符号化法には、`発音区別符$を`基底~文字$の前に置くよう規定しているものもあれば,後に置くよう規定しているものもある。 これらの文字の並べ方の相違があるため、`符号変換$は, XYZ から ZYX へのような並替えも孕む: ◎ 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.

最初の例は “~Russian” を意味する~Russianの単語 “`Русский^s” を~Unicodeの `UTF-16$ec 符号化法から `ISO 8859-5^ec 符号化法へ`符号変換-$した場合を示している: ◎ EXAMPLE: This first example shows the transcoding of the Russian word 'Русский' meaning 'Russian' (language), from the UTF-16 encoding of Unicode to the ISO 8859-5 encoding:

`ISO 8859-5^ec から `UTF-16$ec への対応関係 ◎ table displaying the mapping from ISO 8859-5 to UTF-16
`UTF-16$ec `ISO 8859-5^ec
符号単位 (短縮)`文字~名$ 符号単位 (短縮)`文字~名$
0443 `SMALL U^cn E3 `SMALL U^cn
0441 `SMALL ES^cn E1 `SMALL ES^cn
0441 `SMALL ES^cn E1 `SMALL ES^cn
0438 `SMALL I^cn D8 `SMALL I^cn

次の例はずっと複階的で、 “平和” を意味する~Arabicの単語 “`السلام^s” が、 IBM CP864 符号化法により視覚的に順序付けられ, 文脈~付けられた状態から,~Unicodeの `UTF-16$ec 符号化法への`符号変換$を示す: ◎ EXAMPLE: This second example shows a much more complex case, where the Arabic word 'السلام', meaning 'peace', is transcoded from the visually-ordered, contextualized encoding IBM CP864 to the UTF-16 encoding of Unicode:

`UTF-16$ec から `IBM CP864^ec への対応関係 ◎ table displaying the mapping from UTF-16 to IBM CP864
`IBM CP864^ec `UTF-16$ec
符号単位 (短縮)`文字~名$ 符号単位 (短縮)`文字~名$
EF `FINAL MEEM^cn 0627 `ALEF^cn
9E `MEDIAN LAM-ALEF^cn 0644 `LAM^cn
D3 `MEDIAN SEEN^cn 0633 `SEEN^cn
E4 `MEDIAN LAM^cn 0644 `LAM^cn
C7 `INITIAL ALEF^cn 0627 `ALEF^cn
0645 `MEEM^cn

文字の順序が逆さにされていることに注意。 `CP864^ec の 1 個の `LAM-ALEF^cn が `UTF-16$ec においては `LAM^cn, `ALEF^cn の並びに変換され, また 元の符号化法の,`文脈に応じた異体字$(頭字/中字/尾字( `initial^en / `median^en / `final^en ))は、~~目的の符号化法においては,総称的な文字に変換されている。 ◎ Notice that the order of the characters has been reversed, that the single LAM-ALEF in CP864 has been converted to a LAM ALEF sequence in UTF-16, and that the contextual variants (initial, median or final) in the source encoding have been converted to generic characters in the target encoding.

4.3. 基準~処理~model

~Internet上の多くの~protocolや形式,特に,最も重要な~Web形式[ `~HTML$, ~CSS, `~XML$ ]は、~textに基づいている。 それらの形式は、~textのみからなるが、`素の~text$( `plain text^en, ~markupや~programming言語の文脈~下にない~text)自体が供するものに新たな機能性を加えるために、関連する仕様により,~textに構造が持ち込まれ, 一定の構成子に意味が与えられる。 `~HTML$と`~XML$は `~markup言語@ である。 すなわち、文書は全体が~textのみからなるものと規定されつつ,この~textを ~markupと文字~data に分離するための規約も伴なわれる。 `XML10$r 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内容は文字~dataと~markupの混成である…(中略)~markupでないすべての~textは、文書の文字~dataを成す。 ◎ "Text consists of intermingled character data and markup. [...] All text that is not markup constitutes the character data of the document."

この節の目的における重要な側面は、もっぱら`~text$(すなわち,文字~並び)である。 ◎ For the purposes of this section, the important aspect is that everything is text, that is, a sequence of characters.

`~textual-data~obj@ とは、全体が~textからなる[ ~protocol~message/文書 ]であるか, あるいは その中の[[ 格納/検索取得 ]など,外部とやりとりする目的で、別々に扱われる~text ]である。 例えば,`~XML$の外部~解析対象実体や, ~textによる[ ~MIME `entity body^en `MIME-entity$r ]などが挙げられる。 ◎ 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].

`013-SC@cf [ ~protocol/形式 ]の仕様に定義される`~textual-data~obj$は、`単独の^em`文字~符号化法$に~~統一されなければナラナイ。 ◎ C013 [S] [C] Textual data objects defined by protocol or format specifications MUST be in a single character encoding.

これは, ISO 2022 などの文字~集合 切替~schemeは利用できないことを含意するわけではないことに注意。 そのような~schemeでは、 1 つの`文字~符号化法$の下で`文字~集合$の切替が遂行される。 ◎ 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.

~Webにおける `基準~処理~model@ ( `Reference Processing Model^en )の開発は、草創期の頃から見られる。 初めて述べられたのは,`~HTML$を対象にした `RFC2070$r である。 この~modelは後に,`~XML$と~CSSに取り込まれた。 上で述べたように,それは~textに基づく どの[ 形式/~protocol ]にも適用-可能になる。 基準~処理~modelの本質は、~Unicodeを共通の基準に利用する所にある。 しかしながら,仕様における基準~処理~modelの利用は、その実装に実際に~Unicodeを利用することを要求するものではない — 実装に課される要件は、その処理が この~modelが述べるように挙動することに限られる。 また,この文書は、用語 `基準~処理~model$を利用して,その特性を処理の用語で述べるが、明示的に処理~modelを定義しない仕様にも,この~modelは適用される。 ◎ 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.


~text処理を孕むすべての仕様は、その処理を次に示す`基準~処理~model$に則って指定しなければナラナイ: ◎ C014 [S]All specifications that involve processing of text MUST specify the processing of text according to the Reference Processing Model, namely:

  1. `~byte$や`~glyph$ではなく,~Unicode文字の用語で~textを定義しなければナラナイ。 ◎ Specifications MUST define text in terms of Unicode characters, not bytes or glyphs.
  2. 仕様の`~textual-data~obj$に利用する`文字~符号化法$は、`~Unicode符号化形式$に`符号変換-$できるならば,どれを許容してもヨイ。 ◎ For their textual data objects specifications MAY allow use of any character encoding which can be transcoded to a Unicode encoding form.
  3. 一部の`文字~符号化法$を許容しないか非推奨にして,他のものを義務付けてもヨイ。 その挙動は、その仕様を実装する応用が — 実際に用いる文字~符号化法に依存することなく — 次に与える処理を`行ったのと同じになる^emように,指定しなければナラナイ: ◎ Specifications MAY choose to disallow or deprecate some character encodings and to make others mandatory. Independent of the actual character encoding, the specified behavior MUST be the same as if the processing happened as follows:

    • 応用は、受信した`~textual-data~obj$の`文字~符号化形式$を決定した上で,~Unicode文字~並びとして解釈しなければナラナイ。 これは、その~data~objを何らかの`~Unicode符号化形式$に`符号変換-$して — 必要なら文字~符号化法~labelも調整して — その`~Unicode符号化形式$で受信することに等価でなければナラナイ。 ◎ The character encoding of any textual data object received by the application implementing the specification MUST be determined and the data object MUST be interpreted as a sequence of Unicode characters - this MUST be equivalent to transcoding the data object to some Unicode encoding form, adjusting any character encoding label if necessary, and receiving it in that Unicode encoding form.
    • すべての処理は、この~Unicode文字~並びの下で行わなければナラナイ。 ◎ All processing MUST take place on this sequence of Unicode characters.
    • 応用が~textを出力する場合、それを成す~Unicode文字~並びは,[ 仕様にて許容されている,いずれかの`文字~符号化法$ ]を利用して符号化しなければナラナイ。 ◎ If text is output by the application, the sequence of Unicode characters MUST be encoded using a character encoding chosen among those allowed by the specification.
  4. 仕様が,複数の`~textual-data~obj$を孕んでいる場合(例えば外部~解析対象実体を参照rしている~XML文書など)、これらの~data~objそれぞれに異なる`文字~符号化法$が選ばれてもヨイ。 いずれにせよ、すべての`~textual-data~obj$に,`基準~処理~model$が適用されなければナラナイ。 ◎ If a specification is such that multiple textual data objects are involved (such as an XML document referring to external parsed entities), it MAY choose to allow these data objects to be in different character encodings. In all cases, the Reference Processing Model MUST be applied to all textual data objects.

注記: `XML10$r の応用を定義するすべての仕様は、自動的に,この基準~処理~modelを継承する。 `~XML$では、仕様~全体が~Unicode文字の用語で定義されており,解析対象実体には他の`文字~符号化法$も許容されつつ,【処理~modelにおいては】[ `UTF-8$ec / `UTF-16$ec ]文字~符号化法の利用が要求されている。 ◎ 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文字との対応関係が、実施において`符号変換$に利用される~softwareに依存することに,自覚するべきである。 そのような不一致については、例えば `XML-Japanese-Profile$r を見よ。 ◎ 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.

`070-S@cf 仕様は、全-範囲(すなわち, `0000^U 〜 `10FFFF^U )の `いかなる^em~Unicode`符号位置$も,除外するベキでない ◎ C070 [S] Specifications SHOULD NOT arbitrarily exclude code points from the full range of Unicode code points from U+0000 to U+10FFFF inclusive.

`077-S@cf 仕様は、 `10FFFF^U を越える符号位置を許容してはナラナイ。 ◎ C077 [S] Specifications MUST NOT allow code points above U+10FFFF.

~Unicodeには、[ 内部~利用~用(`非文字$など)/特殊な機能~用(`~surrogate符号位置$など) ]の符号位置も含まれている。 ◎ Unicode contains some code points for internal use (such as noncharacters) or special functions (such as surrogate code points).

`079-S@cf 仕様は、~Unicodeにより内部~利用~用に予約されている符号位置の利用を許容するベキでない。 ◎ C079 [S]Specifications SHOULD NOT allow the use of codepoints reserved by Unicode for internal use.

`078-S@cf 仕様は、`~surrogate符号位置$の利用を許容してはナラナイ。 ◎ C078 [S] Specifications MUST NOT allow the use of surrogate code points.

相当の理由も無く,一部の符号位置を除外することは、~W3Cの世界共通の~accessibilityの目標と競合する。 符号位置を除外すると、利用者その他の~communityにとって重要になり得る 一部の`用字系$を利用できなくする。 例えば、強い理由も無く,`基本多言語面$より先の符号位置を除外するとする裁定や, 符号位置を[ US-ASCII / Latin-1 ]`~repertoire$に制限することは適切でない。 また、`~Unicode標準$では,~softwareが どの符号位置に対しても壊れないことが要求されていることにも注意。 ◎ 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.

文字を除外する 合法的かつ恣意的でない理由としては、 `UXML$r (`~XML$その他の`~markup言語$における~Unicode)が挙げられる。 そこでは、次のような理由で,一部の文字を利用しないことが奨励されている: ◎ 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.
  • 追加的な~dataなしに~supportし得ない。 ◎ They cannot be supported without additional data.
  • `~markup$の方がより良く取扱える。 ◎ They are better handled by markup.
  • 等価な`~markup$と競合する。 ◎ They conflict with equivalent markup.

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

符号化された~textは,符号化法を知ることなしに解釈や処理を`行えない^emので、`文字~符号化法$は、~textが[ やりとり/格納-/処理- ]されるような既知のあらゆる所で,決定的に重要になる。 以下では、利用する`文字~符号化法$は,文脈に依存して[ `文字~符号化形式$( CEF ), `文字~符号化~scheme$( CES ) ]のいずれかを意味する。 ~textが~byte~streamとして[ 伝送される/格納される ]ときは(一例として、~protocolや~file~systemの中で)、適正に解釈されることを確保するため, CES の指定が要求される。 ~APIなどの文脈では、複数~byteの~byte順は,環境(概して,~processor~architecture)から指定されるので、 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.

`015-S@cf 仕様は、一意な`文字~符号化法$を指定するか, または ~textの符号化法が依拠-可能に識別されるような,`文字~符号化法$を識別するための仕組みを供さなければナラナイ。 ◎ C015 [S] Specifications MUST either specify a unique character encoding, or provide character encoding identification mechanisms such that the encoding of text can be reliably identified.

`016-S@cf 新たな[ ~protocol/形式/~API/仕様 ]が設計される際には、一意な`文字~符号化法$が要求されるベキである。 ◎ C016 [S] When designing a new protocol, format or API, specifications SHOULD require a unique character encoding.

`017-S@cf [ ~protocol/形式, あるいは ~protocol/形式 上の~API ]に基づく仕様や, `文字~符号化法$用の規則をすでに備えている~APIの仕様は、それらの規則を変更せずに,そのまま利用するベキである。 ◎ C017 [S] When basing a protocol, format, or API on a protocol, format, or API that already has rules for character encoding, specifications SHOULD use rather than change these rules.

`~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. 一意な文字~符号化法の義務化

一意な`文字~符号化法$の義務化は単純かつ効率的で堅牢になる。 符号化法~tagを[ 指定-/生産-/伝送-/解釈- ]する必要もなくなり、受信-側からは,文字~符号化法が常に解されることになる。 ~dataが非電子的に転送された後で,元の~digital表現に~~復元する必要が生じた場合でも、利用された文字~符号化法の多義性は生じない。 既存の[ ~data/~system/~protocol/応用 ]との互換性を得るために 複数の`文字~符号化法$が必要になる場合でも、それらは,[ ~protocol/形式/~API ]の境界や外側で取り扱われることが多い。 `DOM1$r は、これが行われている一例になる。 一意な`文字~符号化法$を選ぶ方が、少量の~textを扱うときや, 仕様が実際の処理に近いときには,有利になる。 ◎ 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.

`018-S@cf 一意な`文字~符号化法$が要求される場合、その文字~符号化法は[ `UTF-8$ec, `UTF-16$ec, `UTF-32$ec ]のうちいずれかでなければナラナイ。 ◎ C018 [S] When a unique character encoding is required, the character encoding MUST be UTF-8, UTF-16 or UTF-32.

`UTF-8$ec は `US-ASCII$ec の上位互換なので( `US-ASCII$ec 文字列は `UTF-8$ec 文字列でもある — `RFC3629$r を見よ)、 `US-ASCII$ec との互換性が欲される場合には `UTF-8$ec が適切になる。 他の状況 — 例えば ~APIなど — では、 `UTF-16$ec や `UTF-32$ec の方が適切になり得る。 これらを選ぶ理由には、内部~処理の効率性や, 他の処理との相互運用能などが挙げられる。 ◎ 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.

注記: `RFC2277$r には、 ~protocolは `UTF-8$ec `~charset$を利用できなければナラナイ と指定されている。 ◎ NOTE: The IETF Charset Policy [RFC 2277] specifies that on the Internet "Protocols MUST be able to use the UTF-8 charset".

注記: `XML10$r では、すべての適合~XML処理器に対し,[ `UTF-16$ec, `UTF-8$ec ]とも受容することを要求している。 ◎ 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$r `RFC2978$r の好例である。 ~MIME `charset^c ~parameterは、受信された~dataの~byte列を文字~並びに一意に復号するに足る情報を供するものとして、定義されている。 その値は IANA ~charset~registry `IANA$r から抜き出されたものになる。 ◎ 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識別子は、単独の一意な文字~符号化法を表現しておらず,小さな多様性を示す。 小さくても,その相違は重大になり得るし, 時を経れば変わり得る。 これらの識別子の下では、~byte並びから文字~並びへ復元する際に多義的になる。 例えば `Shift_JIS^ec では, 0x5C に符号化された文字は多義的になる。 この符号位置は `YEN SIGN^cn を表現することもあれば, `REVERSE SOLIDUS^cn を表現することもある。 この例についての詳細および,他の そのような多義的な~charset識別子については `XML-Japanese-Profile$r を見よ。 ◎ 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^en )に由来するもので,長い苦しみの歴史による結果を表出する(更なる論は `Connolly$r を見よ)。 ◎ NOTE: The term charset derives from 'character set', an expression with a long and tortured history (see [Connolly] for a discussion).

`020-S@cf 仕様は、用語 `文字~集合$や`~charset$を利用して`文字~符号化法$を参照rするのを避けるベキである。 ただし、後者については, ~MIME `charset^c ~parameterあるいは その IANA に登録-済みの値を参照rする際に利用される場合は除く。 用語 `文字~符号化法$,または 特定の事例には用語[ `文字~符号化形式$/`文字~符号化~scheme$ ]の利用が推奨される。 ◎ C020 [S] Specifications SHOULD avoid using the terms 'character set' and 'charset' to refer to a character encoding, except when the latter is used to refer to the MIME charset parameter or its IANA-registered values. The term 'character encoding', or in specific cases the terms 'character encoding form' or 'character encoding scheme', are RECOMMENDED.

注記: `~XML$においては、[ `~XML宣言$/`~text宣言$ ]に含められた `encoding^c 疑似属性から, 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~registryは、~Internet上の文字~符号化~scheme名とそれらの別名が含められている,公式のリストである。 ◎ The IANA charset registry is the official list of names and aliases for character encoding schemes on the Internet.

`021-S@cf 仕様は、一意な符号化法を採用しない場合には, IANA ~charset~registryに含まれる名前の利用を — 特に,[ ~protocol/形式/~API ]の`文字~符号化法$として指名する際には、その~registryの中の `~MIMEに選好される名前^q ( `MIME preferred names^en )として識別される名前の利用を — 要求するベキである。 ◎ C021 [S] If the unique encoding approach is not taken, specifications SHOULD require the use of the IANA charset registry names, and in particular the names identified in the registry as 'MIME preferred names', to designate character encodings in protocols, data formats and APIs.

`022-SIC@cf IANA ~registryに含まれていない`文字~符号化法$は、私的な合意が無い限り,利用されるベキでない。 ◎ C022 [S] [I] [C] Character encodings that are not in the IANA registry SHOULD NOT be used, except by private agreement.

`023-SIC@cf 登録-済みでない`文字~符号化法$を利用する場合、名前の先頭に `x-^l を付与する慣行に従わなければナラナイ。 ◎ C023 [S] [I] [C] If an unregistered character encoding is used, the convention of using 'x-' at the beginning of the name MUST be followed.

`049-IC@cf 内容の`文字~符号化法$は、できるだけ直に文字を表現できる(すなわち,`文字~escape$などの`~markup$により文字を表現する必要を最小限にする), かつ 受信者からは解されそうにない解り難い符号化法は避けるように選ばれるベキである。 ◎ C049 [I] [C] The character encoding of content SHOULD be chosen so that it maximizes the opportunity to directly represent characters (ie. minimizes the need to represent characters by markup means such as character escapes) while avoiding obscure encodings that are unlikely to be understood by recipients.

注記: ~Unicodeに基づく`文字~符号化法$は、巨大な`~repertoire$を備え, 広範からの~supportもあるので,文書の符号化として良い選択肢である。 ◎ 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.

`034-C@cf `文字~符号化法$を識別するための便宜性が提供されている場合、内容は,それを用立てなければナラナイ。 “提供されている” には、既定として定められたもの(例: `XML10$r によるもの)も含まれる。 そのような既定に依拠することでも、この識別~用の要件を満たすに足る。 ◎ C034 [C] If facilities are offered for identifying character encoding, content MUST make use of them; where the facilities offered for character encoding identification include defaults (e.g. in XML 1.0 [XML 1.0]), relying on such defaults is sufficient to satisfy this identification requirement.

`024-IC@cf [ 内容/~software ]は、~text~dataに~labelを付与するときは,[ 適切な仕様(例:~XML~textを編集する場合は~XML仕様)にて要求されている,いずれかの名前 ]を利用しなければナラナイ。 また、[ その~dataの`文字~符号化法$に結び付けられている,~MIMEに選好される名前 ]を利用するベキである。 【~labelという語は、利用されている文字~符号化法を識別する名前を指すときに,よく用いられる。】 ◎ C024 [I] [C] Content and software that label text data MUST use one of the names required by the appropriate specification (e.g. the XML specification when editing XML text) and SHOULD use the MIME preferred name of a character encoding to label data in that character encoding.

`025-IC@cf IANA に登録されたどの名前にも対応しない`文字~符号化法$を伴う~text~dataには、その~labelとして IANA に登録-済みの~charset名が利用されてはナラナイ。 ◎ C025 [I] [C] An IANA-registered charset name MUST NOT be used to label text data in a character encoding other than the one identified in the IANA registration of that name.

`026-S@cf 一意な符号化法を採用しない仕様は、少なくとも~Unicodeの[ `UTF-8$ec, `UTF-16$ec ]`符号化形式$いずれかを,適格な`文字~符号化法$として指名しなければナラナイ。 また、[ `UTF-8$ec, `UTF-16$ec ]いずれかを,要求される`符号化形式$(仕様の実装が~supportしなければナラナイ`符号化形式$)として採用するベキである。 ◎ C026 [S] If the unique encoding approach is not chosen, specifications MUST designate at least one of the UTF-8 and UTF-16 encoding forms of Unicode as admissible character encodings and SHOULD choose at least one of UTF-8 or UTF-16 as required encoding forms (encoding forms that MUST be supported by implementations of the specification).

`027-S@cf 既定の符号化法を要求する仕様は、[ `UTF-8$ec, `UTF-16$ec ]のうち一方を, あるいは それらの判別-用に相応しい手段を定義する場合は両者を,既定のそれとして定義しなければナラナイ。 ◎ C027 [S] Specifications that require a default encoding MUST define either UTF-8 or UTF-16 as the default, or both if they define suitable means of distinguishing them.

`028-S@cf 仕様は、~dataの符号化法を決定する方法に経験則の利用を提案してはナラナイ。 ◎ C028 [S] Specifications MUST NOT propose the use of heuristics to determine the encoding of data.

経験則の例としては、~byte(~pattern)や文字(~pattern)の頻度に対する統計的解析の利用が挙げられる。 経験則は,実装~間でふるまいが一貫しないので良くない。 `XML10$r, Appendix F にて与えられるような、きちんと定義された指示書きにより,`文字~符号化法$を一義的に決定する方法は、経験則とは見なされない。 【参考:~HTMLにおける符号化法の決定-法】 ◎ 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.

`029-I@cf `受信-側^emの~softwareは、~dataの符号化法を,可用な情報から適切な仕様に則って決定しなければナラナイ。 ◎ C029 [I] Receiving software MUST determine the encoding of data from available information according to appropriate specifications.

`030-I@cf IANA に登録-済みの~charset名が認識されたときは、受信-側の~softwareは、受信された~dataを IANA ~registryの中の その名前に結付けられている符号化法に則って,解釈しなければナラナイ。 ◎ C030 [I] When an IANA-registered charset name is recognized, receiving software MUST interpret the received data according to the encoding associated with the name in the IANA registry.

`031-I@cf ~charsetが供されていないときは、受信-側の~softwareは、仕様に指定されている既定の`文字~符号化法$を固守しなければナラナイ。 ◎ C031 [I] When no charset is provided receiving software MUST adhere to the default character encoding(s) specified in the specification.

受信-側の~softwareは、必要に応じて,任意数の[ `文字~符号化法$, および~charset名とその別名 ]を認識してよい。 ◎ Receiving software may recognize as many character encodings and as many charset names and aliases for them as appropriate.

`field-upgradeable^en 【?】の仕組みは、この目的に適切なものになる。 一部の`文字~符号化法$は、多少なりとも一定の言語に結付けられている(例: `Shift_JIS^ec と~Japanese)。 所与の言語や一定層の顧客の~supportは、一定の`文字~符号化法$の~supportの必要を意味することもある。 しかしながら,支持は得ていても要求されてはいない符号化法には、世界共通の~supportがあるとは見做せない。 ~supportが必要な`文字~符号化法$は,時を経れば変わり得る。 この文書は、[ 所与の言語の~supportに,どの文字~符号化法が 適切あるいは必要とされるか ]については,助言を供さない。 ◎ 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.

~Web~architectureは層の積み重ねであるので(例:~protocol越しに利用される形式)、`文字~符号化法$についての情報が複数あったり競合することが起こり得る。 ◎ Because of the layered Web architecture (e.g. formats used over protocols), there may be multiple and at times conflicting information about character encoding.

`035-S@cf 仕様は、`文字~符号化法$についての情報が複数あるか競合する場合には,それを解決する仕組み(例:優先順位)を定義しなければナラナイ。 ◎ C035 [S] Specifications MUST define conflict-resolution mechanisms (e.g. priorities) for cases where there is multiple or conflicting information about character encoding.

`033-I@cf ~softwareは、`文字~符号化法$の識別と競合の解決~用の仕組みを,完全に実装しなければナラナイ。 ◎ C033 [I] Software MUST completely implement the mechanisms for character encoding identification and conflict resolution.

4.5. 私用~符号位置

~Unicodeの中の一定範囲の`符号位置$ — `私用~領域$( `Private Use Area^en, 略称 `PUA^abbr, 範囲 `E000-F8FF^U )と 第 15 面( `F0000-FFFFD^U ), 第 16 面( `100000-10FFFD^U ) — は、`私用$用途として指名されている。 これらの符号位置は,標準の文字には決して割振られないことが保証されており、私的~合意の下での利用~用に可用にされている。 しかしながら,私的~合意は、異なるそれらの間で符号位置が衝突し得るので,~Web上まで拡大されることはない。 また、私的~合意であるがため,その符号位置の意味は急速に失われ易い。 ◎ Certain ranges of Unicode code points are designated for private use: the Private Use Area (PUA) (U+E000-F8FF) and planes 15 and 16 (U+F0000-FFFFD and U+100000-10FFFD). These code points are guaranteed to never be allocated to standard characters, and are available for use by private agreement. However, private agreements do not scale on the Web. Code points from different private agreements may collide. Also, a private agreement, and therefore the meaning of the code points, can quickly become lost.

`073-C@cf 公に交換される内容は、`私用~領域$の符号位置を利用するベキでない。 ◎ C073 [C] Publicly interchanged content SHOULD NOT use codepoints in the private use area.

注記: `私用~領域$の例外的な利用として代表的なものには、符号化されたことのない`用字系$(例:歴史的あるいは稀なもの)に対する符号化法の設計や~testが挙げられる。 ◎ NOTE: A typical exception would be the use of the PUA to design and test the encoding of not yet encoded (e.g. historic or rare) scripts.

`076-C@cf 内容は、符号位置を,その`有符号~文字~集合$に定義されている目的~以外に利用してはナラナイ。 ◎ C076 [C]Content MUST NOT use a code point for any purpose other than that defined by its coded character set.

したがって、例えば,[ `iso-8859-1^ec に符号化されるものとは実際には異なる[ `用字系$/文字/記号 ]を表現するために, ISO Latin 1 文字~集合の符号位置を誤用する ]ような`~font$の構築は、禁止される。 ◎ This prohibits, for example, the construction of fonts that misuse the codepoints in the ISO Latin 1 character set to represent different scripts, characters, or symbols than those actually encoded in iso-8859-1.

`038-S@cf 仕様は、[ `私用~領域$の文字に特定0の何かをアテガう ]ような利用を要求してはナラナイ。 ◎ C038 [S] Specifications MUST NOT require the use of private use area characters with particular assignments.

`039-S@cf 仕様は、`私用~符号位置$についての合意を定義する仕組みの利用を要求してはナラナイ。 ◎ C039 [S] Specifications MUST NOT require the use of mechanisms for defining agreements of private use code points.

`040-SI@cf 仕様と実装は、私的~合意による`私用~符号位置$の利用を禁じるベキでない。 ◎ C040 [S] [I] Specifications and implementations SHOULD NOT disallow the use of private use code points by private agreement.

例えば`~XML$は,`私用~符号位置$の利用を禁じていない。 ◎ As an example, XML does not disallow the use of private use code points.

`041-S@cf 仕様は、[ ~Unicodeに無い記号の伝送/~Unicode文字の特定の`異体字$の識別 ]を許容するための,`~markup$を定義してもヨイ。 ◎ C041 [S] Specifications MAY define markup to allow the transmission of symbols not in Unicode or to identify specific variants of Unicode characters.

`MathML2$r ( 3.2.9 節 )は、~Unicodeには無い数学-記号~用に `mglyph^c 要素を定義している。 ◎ EXAMPLE: MathML (see [MathML2] section 3.2.9) defines an element mglyph for mathematical symbols not in Unicode.

`SVG$r ( 10.14 節 を見よ)は、~Unicode文字の特定の表示異体の識別を可能にする, `altglyph^c 要素を定義する。 ◎ EXAMPLE: SVG (see [SVG] section 10.14) defines an element altglyph which allows the identification of specific display variants of Unicode characters.

`068-S@cf 仕様は、絵図や~graphic用に文字に基づく仕組みを利用-(または誤利用)する必要を無くすため、適切な所では,絵図や~graphicの内包や参照を許容するベキである。 ◎ C068 [S]Specifications SHOULD allow the inclusion of or reference to pictures and graphics where appropriate, to eliminate the need to (mis)use character-oriented mechanisms for pictures or graphics.

4.6. 文字~escape法

`~markup言語$や~programming言語では、ある種の文字が `構文文字@ ( `syntax-significant character^en, 略して `syntax-significant^en )として指名され,言語の中で特定の機能が与えられることが多い(例: `~HTML$, `~XML$では `<^ch と `&^ch が~markup区切子になる)。 そのため、これらの構文文字には — ~textの中では、他の文字と同じように自身を自身の表現に利用できないので — “~escapeする” 仕組みが必要になる。 また,これと同じか同様の仕組みで満たされることが多いが、特定0の文書や~program(`~markup$や~programming言語の~instance)用に選ばれた`文字~符号化法$の中では,直に表現できない文字も、表出できる必要がある。 ◎ Markup languages or programming languages often designate certain characters as syntax-significant, giving them specific functions within the language (e.g. '<' and '&' serve as markup delimiters in HTML and XML). As a consequence, these syntax-significant characters cannot be used to represent themselves in text in the same way as all other characters do, creating the need for a mechanism to "escape" their syntax-significance. There is also a need, often satisfied by the same or similar mechanisms, to express characters not directly representable in the character encoding chosen for a particular document or program (an instance of the markup or programming language).

公式的に述べるなら, `文字~escape@ とは、`~markup$や~programming言語により定義される 構文上の素子であって,以下のいずれかを許容するものである: ◎ Formally, a character escape is a syntactic device defined in a markup or programming language that allows one or more of:

  1. 言語における構文~上の有意性を失わせつつ,構文文字を表出する。 ◎ expressing syntax-significant characters while disregarding their significance in the syntax of the language, or
  2. 当の言語~用に選ばれた`文字~符号化法$では表現できない文字を表出する。 ◎ expressing characters not representable in the character encoding chosen for an instance of the language, or
  3. 一般の文字を,それに対応する`符号化d文字$を利用せずに表出する。 ◎ expressing characters in general, without use of the corresponding encoded characters.

文字を~escapeするとは、その文字が現れる[ 形式/~protocol ]に適切な構文上の素子を利用して,その文字を表出することを意味する。 `文字~escapeの展開^q(あるいは `unescaping^en )とは、それが表現する文字に置換することを意味する。 ◎ Escaping a character means expressing it using such a syntactic device, appropriate to the format or protocol in which the character appears; expanding a character escape (or unescaping) means replacing it with the character that it represents.

`~HTML$と`~XML$では、構文文字にも, 任意の~Unicode文字にも~escape法を許容する, 数量的な文字~参照( `Numeric Character References^en )が定義されている。 `&#x3C;^s あるいは `&#60;^s と表出された文字 `<^ch は、~markup区切子として構文解析されないようになる。 ◎ EXAMPLE: HTML and XML define 'Numeric Character References' which allow both the escaping of syntax-significance and the expression of arbitrary Unicode characters. Expressed as &#x3C; or &#60; the character '<' will not be parsed as a markup delimiter.

~programming言語 Java は、文字列の中の区切りに二重引用符 `"^ch を利用している。 文字列~内で二重引用符を表出するときは、 `\"^ch のように~escapeできる。 ◎ EXAMPLE: The programming language Java uses '"' to delimit strings. To express '"' within a string, one may escape it as '\"'.

`~XML$が定義する`~CDATA~section$では、その区切子で括られたすべての構文文字が~escapeされる。 ~CDATA~sectionの中では、数量的な文字~参照を利用して文字を表出することは,できなくなる。 ◎ EXAMPLE: XML defines 'CDATA sections' which allow escaping the syntax-significance of all characters between the CDATA section delimiters. CDATA sections prevent the expression of characters using numeric character references.

仕様が`文字~escape$を定義する仕方には、次に挙げる指針が適用される: ◎ The following guidelines apply to the way specifications define character escapes.

  • `042-S@cf 仕様は、適切なものがすでにあるならば,新たな~escape法の仕組みを考案するベキでない。 ◎ C042 [S] Specifications SHOULD NOT invent a new escaping mechanism if an appropriate one already exists.

  • `043-S@cf 文字を~escapeする仕方は,できるだけ少数に絞られるベキである(理想的には一種類に)。 ◎ C043 [S] The number of different ways to escape a character SHOULD be minimized (ideally to one).

    よく知られた反例として、`~HTML$も`~XML$も,歴史的な理由から冗長な 2 種類の`文字~escape$ — 10 進( `&#ddddd;^s )によるもの, 16 進( `&#xhhhh;^s )によるもの — を備えている。 ◎ A well-known counter-example is that for historical reasons, both HTML and XML have redundant decimal (&#ddddd;) and hexadecimal (&#xhhhh;) character escapes.

  • `044-S@cf ~escape構文は、各 `文字~escape$に対し,明示的な終端~区切子か一定個数の文字を要求するベキである。 `文字~escape$の終端が[ ~escapeの中では適格でない文字 ]により決定されるような~escape構文は、避けられるベキである。 ◎ C044 [S] Escape syntax SHOULD require either explicit end delimiters or a fixed number of characters in each character escape. Escape syntaxes where the end is determined by any character outside the set of characters admissible in the character escape itself SHOULD be avoided.

    これらの`文字~escape$は視覚的に明瞭でないため、編集~時に~spaceで単語が折返される所に誤って改行を挿入し易くなる。 `SPREAD$r の `&UABCD;^s 形や`~XML$の `&#xhhhh;^s 形のように,`文字~escape$が明示的に~semicolonで終了される方が、ずっと良い。 ◎ These character escapes are not clear visually, and can cause an editor to insert spurious line-breaks when word-wrapping on spaces. Forms like SPREAD's &UABCD; [SPREAD] or XML's &#xhhhh;, where the character escape is explicitly terminated by a semicolon, are much better.

  • `045-S@cf 仕様は、`文字~escape$を[ 数値を利用して文字を表現することも許容する ]ように定義するときは,その数値は 当の文字の~Unicode符号位置を表現しなければナラナイ。 また、その数値は 16 進~記法にされるベキである。 ◎ C045 [S] Whenever specifications define character escapes that allow the representation of characters using a number, the number MUST represent the Unicode code point of the character and SHOULD be in hexadecimal notation.

  • `046-S@cf ~escapeされた文字は、その~escapeされてない形が受容-可能な どこでも受容-可能になるベキである — これは、~escapeされた`構文文字$が構文における有意性を失えなくするものではない。 特に,ある文字が識別子や~comment内で受容-可能な場合、その文字の~escapeされた形も受容-可能になるべきである。 ◎ C046 [S] Escaped characters SHOULD be acceptable wherever their unescaped forms are; this does not preclude that syntax-significant characters, when escaped, lose their significance in the syntax. In particular, if a character is acceptable in identifiers and comments, then its escaped form should also be acceptable.

内容~開発者, およびその内容を生成する~softwareには、次に挙げる指針が適用される: ◎ The following guidelines apply to content developers, as well as to software that generates content:

  • `047-IC@cf ~escapeは、それが表出する文字が[ 文書の[ 形式/`文字~符号化法$ ]の下では直に表現できないとき, または 文字の視覚的~表現が不明瞭な所 ]に限り,利用されるベキである。 ◎ C047 [I] [C] Escapes SHOULD only be used when the characters to be expressed are not directly representable in the format or the character encoding of the document, or when the visual representation of the character is unclear.

    注記: 文字の視覚的~表現が不明瞭な例としては、`00A0^U `NO-BREAK SPACE^cn と通常の~spaceを判別するための, `&nbsp;^s の利用が挙げられる。 ◎ NOTE: An example of when the visual representation of the character is unclear is the use of &nbsp; to distinguish a non-breaking space from a normal space.

  • `048-IC@cf 内容は、`文字~escape$に 16 進, 10 進どちらの形も利用できるときは、16 進~形を利用するベキである。 ◎ C048 [I] [C] Content SHOULD use the hexadecimal form of character escapes rather than the decimal form when there are both.

    注記: 通例的に、文字~符号化法の標準(特に~Unicode)は,文字の符号値を 16 進~形として~listするので、 16 進~形の方が表引きが容易であり,選好される。 ◎ NOTE: The hexadecimal form is preferred because character encoding standards (in particular Unicode) usually list character numbers as hexadecimal, making lookup easier.

5. 互換y文字と書式~文字

この仕様は、`~markup言語$の利用における特定0の文字の適性については取組まない。 特に、`書式~文字$および`互換y等価$ — これらの文字の利用についての詳細な推奨は、 `UXML$r ( “`~XML$その他の~markup言語における~Unicode” )を見よ。 ◎ This specification does not address the suitability of particular characters for use in markup languages, in particular formatting characters and compatibility equivalents. For detailed recommendations about the use of compatibility and formatting characters, see Unicode in XML and other Markup Languages [UXML].

`050-S@cf 仕様は、それが定義する形式の構文上の要素(`~markup$, 区切子, 識別子)から,`互換y文字$を除外するベキである。 ◎ C050 [S] Specifications SHOULD exclude compatibility characters in the syntactic elements (markup, delimiters, identifiers) of the formats they define.

6. 文字列

6.1. 文字列の概念( `concept^en )

様々な仕様が `文字列^q ( `string^en )の認識概念( `notion^en )を利用するが、何を意味するか精確に定義されなかったり,他の仕様と異なるように定義されることもある。 実際、文字列には その認識概念に意図される利用に依存して,複数の適理な定義がある。 これらは、実際には同じ実在 — ~computer内に格納される~text片 — に対し,異なる見方を与えるものに過ぎないので、これら異なる認識概念のどれにも,用語 `文字列^q が利用されるのである。 ◎ 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.

【 “~~文字列” — 訳語としては,この語が定着しているが、英語として より一般には “`同じもの^em(同種のもの)の並び” を意味し, “`文字^emの列” よりも抽象的な概念を表す。 】

`~byte文字列@ ◎ Byte string:\
特定0の`文字~符号化法$の下で、文字を,それを表現する`~byte$列として捉えたときの文字列。 これは`文字~符号化~scheme$( CES )に対応する。 `~byte文字列$の~text処理は、それに利用されている特定0の符号化法に依存する。 符号化法が変更された場合,その処理も,新たな符号化法の構造が反映されるように変更されなければならなくなる。 そのような変更は、その`~byte文字列$が~textとして処理される際に利用される関数や~APIを,大きく設計し直すことを要求し得る。 したがって この定義が仕様において有用になるのは、文字列の~textとしての資質が重要ではない,文字列が単に~byte長を伴う “不透明な” ~data片と見なされるときに限られる(~bufferを複製するときなど)。 ◎ 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).
`011-S@cf 仕様は、文字列を`~byte文字列$として定義するベキでない。 ◎ C011 [S] Specifications SHOULD NOT define a string as a 'byte string'.
次の例は、文字列を`~byte文字列$と見なすことが問題になり得る理由の一つを~~説明するものである: `~big-endian$による~byte順で `UTF-16$ec に符号化された( `UTF-16BE^ec )文字 `233B4^U (“切り株” を意味する,~Chineseの文字)を含む~textを考える。 この~textは,~byte列 D8 4C DF B4 を含むことになる。 この~textが`~byte文字列$と見なされた場合、文字 `4CDF^U ( “不死鳥” を意味する別の~Chineseの文字)が探索される際に, `4CDF^U の `UTF-16BE^ec 表現である~byte列 4C DF に誤って合致することになる。 ◎ EXAMPLE: This is a counter-example, illustrating one reason why considering strings as byte strings may be problematic. Consider text containing the character U+233B4 (a Chinese character meaning 'stump of tree') encoded as UTF-16 in big-endian byte order (UTF-16BE). The text will contain the bytes D8 4C DF B4. If one searches this text, considered as a byte string, for the character U+4CDF (another Chinese character meaning 'phoenix'), an erroneous match will be found on the bytes 4C DF that are the UTF-16BE representation of U+4CDF.
`符号単位~文字列@ ◎ Code unit string:\
特定0の`文字~符号化法$の下で、文字を,それを表現する`符号単位$の並びとして捉えたときの文字列。 これは、`文字~符号化形式$に対応する。 符号単位~文字列の定義には、符号単位の~size(例: 16 ~bit), および 利用する文字~符号化法(例: `UTF-16$ec )を含める必要がある。 符号単位~文字列は、実装の候補になると見込まれる符号化形式について依拠-可能な知識に基づいた,文字列~dataの物理的な表現を公開する~APIにおいて有用になる。 例えば `DOM1$r では、広範な実装の実践に基づいて, `UTF-16$ec が選ばれている。 一般に, “符号単位~文字列” は、当の実装の候補が `UTF-16$ec または `UTF-32$ec である場合に限り有用になる。 ◎ 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.
`文字~文字列@ ◎ Character string:
それぞれが~Unicode `Unicode$r の`符号位置$で表現される,文字~並びとして捉えたときの文字列。 これは,~programmerたちが通例的に文字列と見なしているものである — ほとんどの利用者から知覚される文字とは正確に合致しないかもしれないが。 これが、ごく少ない実装の労力で相互運用能を確保できるような,最も高次の抽象化を成す層である。 “文字~文字列” の定義による文字列が、一般に最も有用になる。 この定義を利用する好例には `XML10$r の生成規則 “[2]”, `HTML401$r の SGML 宣言, `RFC2070$r の文字~modelなどが挙げられる。 ◎ 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^en ) — 訳語としては不自然な重複になってしまうが、この節の冒頭で注釈した様に, “文字列” という語自体が訳語として定着しているため、致し方ない所でも。 】
`012-S@cf ほとんどの仕様には`文字~文字列$の定義が利用されるベキである。 ◎ C012 [S] The 'character string' definition SHOULD be used by most specifications.

次の表の各行に、文字[ `233B4^U (“切り株” を意味する,~Chineseの文字), `2260^U `NOT EQUAL TO^cn, `0071^U `LATIN SMALL LETTER Q^cn, `030C^U `COMBINING CARON^cn ]からなる,~big-endian ~byte順で `UTF-16$ec に符号化された文字列に対し, `文字~文字列$, `符号単位~文字列$, `~byte文字列$ で捉えた様子を順に示す: ◎ 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:

[ 文字/`符号単位$/~byte ]並びとしての,文字列 ◎ table displaying a string viewed as characters, code units and bytes
~glyph(画像) 表意的かつ補足的な文字: “切り株” を意味する古代中国~文字(広東語では現在も利用されている)。
Ideographic supplementary character: Archaic Chinese character meaning "the stump of a tree" (still in current use in Cantonese) NOT EQUAL TO LATIN SMALL LETTER Q COMBINING CARON
【~glyph(~text)】 𣎴 q ̌
`文字~文字列$ `233B4^U `2260^U `0071^U `030C^U
`符号単位~文字列$ D84C DFB4 2260 0071 030C
`~byte文字列$ D8 4C DF B4 22 60 00 71 03 0C

注記: 文字列は、 `書記素~cluster@ ( `grapheme cluster$UT )の並びとして見ることアリである。 `書記素~cluster$は、`文字~文字列$に比して,[ 描画された~textにおいて 利用者から知覚される文字の境界 ]に より近い単位に,~textを分割する。 書記素~clusterについての論は `Unicode40$r の 2.10 節の末尾に与えられている。 公式的な定義は `UTR29$r にて与えられる。 `~Unicode標準$は、 `既定の^em 書記素~clusterを定義する。 一部の言語では、この既定をもっと`誂える^emことが要求される。 例えば,~Slovakの利用者は、既定では書記素~clusterの~pairを成す `ch^ch を,単独の書記素~clusterとして扱うよう望むであろう。 文字列~内容の言語と末端利用者の選好との間の相互作用は、複階的なものになり得ることに注意。 ◎ 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. 文字列の付番

~softwareの処理が 部分文字列, あるいは文字列の中の一点への~accessを必要とし,~index — すなわち,文字列の中の数量的な “位置” — を利用してそれを行う状況は数多くある。 そのような~indexが~Web上の~component間でやりとりされても,挙動の一貫性が保たれるためには、文字列の付番(文字列の中の各位置への~indexの振り方)について合意しておく必要がある。 文字列の付番~用の要件は `CharReq$r, 4 節 (文字列の同一性~合致~用の要件)にて論じられる。 主な問いは 2 つある: (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?".

前節 `文字列の概念$secでは、文字列が `文字~文字列$, `符号単位~文字列$, `~byte文字列$ として捉えられることを示した。 そのそれぞれが異なる単位に基づく付番を孕んでいる。 ◎ 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.

処理の特定0の要件に依存して、数え方の単位は`文字列の概念$secにて与えた,文字列の様々な定義に対応し得る。 特に: ◎ 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:

  • `051-SI@cf 文字列の付番は、`文字~文字列$に基づくものが推奨される。 ◎ C051 [S] [I] The character string is RECOMMENDED as a basis for string indexing.

    (例: `XPath$r)。 ◎ (Example: the XML Path Language [XPath]).

  • `052-SI@cf 内部~演算の効率性が`文字~文字列$に基づく付番に比して有意に向上する場合は、`符号単位~文字列$に基づく文字列の付番が利用されてもヨイ。 ◎ 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.

    (例: `DOM1$r における `UTF-16$ec の利用)。 ◎ (Example: the use of UTF-16 in [DOM Level 1]).

  • `071-SI@cf 利用者~対話が第一に懸念される応用においては、`書記素~cluster$に基づく文字列の付番が利用されてもヨイ。 ◎ C071 [S] [I] Grapheme clusters MAY be used as a basis for string indexing in applications where user interaction is the primary concern.

    `UTR29$r, Text Boundaries を見よ。 ◎ See Unicode Standard Annex #29, Text Boundaries [UTR #29].

    `074-S@cf `書記素~cluster$の用語で付番を定義する仕様は、次のいずれかにより定義しなければナラナイ ⇒# (a) `UTR29$r, Text Boundaries にて定義される既定の書記素~clusterの用語で,書記素~clusterを定義する/ (b) 付番~演算を,より適切な~~形に`誂える^em仕方を特定的に定義する。 ◎ 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.

  • `072-SI@cf `~byte文字列$に基づく付番は推奨されない。 ◎ 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.

`053-S@cf 部分文字列や 文字列の中の一点を識別する仕方を必要とする仕様は、この演算を遂行するためとして,文字列の付番 以外による仕方も供するベキである。 ◎ C053 [S] Specifications that need a way to identify substrings or point within a string SHOULD provide ways other than string indexing to perform this operation.

`054-IC@cf 仕様の利用者(~software開発者, 内容~開発者)は、部分文字列や文字列の中の一点を識別するときは,アリな所では 文字列の付番~以外の仕方を選ぶベキである。 ◎ C054 [I] [C] Users of specifications (software developers, content developers) SHOULD whenever possible prefer ways other than string indexing to identify substrings or point within a string.

経験から、個々の文字は,部分文字列の前/後の位置から識別される部分文字列として解された上で処理された方が、より 一般的, 柔軟, 堅牢 な仕様になることが判っている。 ~indexを数え方の単位の`狭間^emの位置と解することで、異なる文字列~定義による~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.

`055-S@cf 仕様は、 1 個の文字を部分文字列として解した上で処理し,選ばれた数え方の単位に関わらず,~indexをその単位の`狭間^emの位置として扱うベキである。 ◎ C055 [S] Specifications SHOULD understand and process single characters as substrings, and treat indices as boundary positions between counting units, regardless of the choice of counting units.

`056-S@cf ~APIの仕様は、 1 個の文字や 1 個の符号化の単位を,引数や返り値の型に指定するベキでない。 ◎ C056 [S] Specifications of APIs SHOULD NOT specify single characters or single 'units of encoding' as argument or return types.

仮に “大文字化” 関数 `uppercase^c の返り値~型が 1 個の文字として定義された場合、 `uppercase("ß")^c は,適正な結果( 2 文字からなる`文字~文字列$ `SS^ch )を返せなくなる。 【現在の~Unicodeには "ß" の大文字 ( "ẞ" )もあるので,この例は文脈によっては適切でないかもしれない。】 また,`文字の知覚$sec節にて述べたように、文字と[ 音響や入力, 等々を成す単位 ]の間に一対一の対応関係があるとは限らないことにも注意。 ◎ 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.

`057-S@cf 文字列の付番において単位の狭間の位置が数えられる場合、文字列の始端を~index 0 と定めることが推奨される。 その場合、最後の~indexは,文字列に含まれる単位の個数になる。 ◎ C057 [S] When the positions between the units are counted for string indexing, starting with an index of 0 for the position at the start of the string is the RECOMMENDED solution, with the last index then being equal to the number of counting units in the string.

7. ~Unicode標準や ISO/IEC 10646 を参照するとき

仕様は,`~Unicode標準$や国際標準 `ISO/IEC-10646$r を参照する必要が生じることが多い。 とりわけ,規範として参照するときは、注意深く行われなければならない。 考慮されるべき問いは: ◎ Specifications often need to make references to the Unicode Standard or International Standard ISO/IEC 10646. Such references must be made with care, especially when normative. The questions to be considered are:

  • どの標準が参照されるべきか? ◎ Which standard should be referenced?
  • 特定0の~versionはどのように参照するのか? ◎ How to reference a particular version?
  • どのようなときに,~version付きのものそうでないものを利用するのか? ◎ When to use versioned vs. unversioned references?

`ISO/IEC-10646$r は ISO (国際標準化機構)と IEC (国際電気標準会議)の共同により,開発され, 発行された。 `~Unicode標準$は Unicode Consortium (~~主要な~computer企業, ~software製作者, ~database~vendor, 各国政府, 研究機関, 国際的機関, 様々な利用者~groupや関心を持つ個人, … からなる組織)により開発され,発行された。 `~Unicode標準$の立ち~~位置は、~W3C勧告に相当する。 ◎ ISO/IEC 10646 is developed and published jointly by ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission). The Unicode Standard is developed and published by the Unicode Consortium, an organization of major computer corporations, software producers, database vendors, national governments, research institutions, international agencies, various user groups, and interested individuals. The Unicode Standard is comparable in standing to W3C Recommendations.

`ISO/IEC-10646$r と`~Unicode標準$は、正確に同じ[ `有符号~文字~集合$( CCS )(同じ`~repertoire$, 同じ`符号位置$)と符号化形式 ]を定義する。 それらは、各 技術委員会どうしの情報交換やメンバの重なり合いの中で活動的に保守されている。 共同で定義された CCS と符号化形式に加えて、`~Unicode標準$では[ 各種 文字~propの規範的な(および参考情報の)~list, 文字の[ `等価性$/`正規化$ ]の規範的な仕様, `双方向~text$用の規範的な~algo, 実装に有用な数多の情報 ]も追加している。 手短に言えば、`~Unicode標準$は `ISO/IEC-10646$r が単に列挙している文字に意味論を追加している。 `~Unicode標準$への適合性は `ISO/IEC-10646$r への適合性も含意する。 `Unicode40$r Appendix C を見よ。 ◎ ISO/IEC 10646 and the Unicode Standard define exactly the same coded character set (CCS) (same repertoire, same code points) and encoding forms. They are actively maintained in synchrony by liaisons and overlapping membership between the respective technical committees. In addition to the jointly defined CCS and encoding forms, the Unicode Standard adds normative and informative lists of character properties, normative character equivalence and normalization specifications, a normative algorithm for bidirectional text and a large amount of useful implementation information. In short, the Unicode Standard adds semantics to the characters that ISO/IEC 10646 merely enumerates. Conformance to the Unicode Standard implies conformance to ISO/IEC 10646, see [Unicode 4.0] Appendix C.

`062-S@cf 一般に、仕様は,利用する文字とそれに結付けられている意味論を定義する必要があるので、 `ISO/IEC-10646$r への参照を含めようが含めまいが、`~Unicode標準$への参照は含めるベキである。 ◎ C062 [S] Since specifications in general need both a definition for their characters and the semantics associated with these characters, specifications SHOULD include a reference to the Unicode Standard, whether or not they include a reference to ISO/IEC 10646.

`~Unicode標準$への参照を供することにより、実装者は,その標準, および Unicode Consortium ~Web~siteが供する豊富な情報による便益を得られる。 ◎ By providing a reference to the Unicode Standard implementers can benefit from the wealth of information provided in the standard and on the Unicode Consortium Web site.

`ISO/IEC-10646$r と`~Unicode標準$は(同調的に)発展し続けているので、~version付けの課題も生じる: 仕様は、標準の特定の~versionを参照rすべきか? それとも,規範的な参照が[ 当の仕様が`読まれている時点^emの~version ]を指すようにするために,総称的な参照にすべきか? — 一般に、その答えは`両者^emである。 ◎ The fact that both ISO/IEC 10646 and the Unicode Standard are evolving (in synchrony) raises the issue of versioning: should a specification refer to a specific version of the standard, or should it make a generic reference, so that the normative reference is to the version current at the time of reading the specification? In general the answer is both.

`063-S@cf 仕様の発行-後に割振られた文字が,その仕様で利用-可能になることが欲される場合には、`~Unicode標準$への総称的な参照が含められなければナラナイ。 特定0の~versionに依存する機能性がいつでも可用, かつ時を経ても変化しないことを確保するために、特定の`~Unicode標準$への参照が含められてもヨイ。 ◎ C063 [S] A generic reference to the Unicode Standard MUST be made if it is desired that characters allocated after a specification is published are usable with that specification. A specific reference to the Unicode Standard MAY be included to ensure that functionality depending on a particular version is available and will not change over time.

例えば、 `XML10$r における, `Name^P 文字として受容-可能な文字の集合 — それは、構文解析器が名前を検証するために実装しなければならない文字を列挙した~listである。 ◎ An example would be the set of characters acceptable as Name characters in XML 1.0 [XML 1.0], which is an enumerated list that parsers must implement to validate names.

注記: `~Unicode標準$の特定の~versionを参照するための指針については https://www.unicode.org/unicode/standard/versions/#Citations を見よ。 ◎ NOTE: See http://www.unicode.org/unicode/standard/versions/#Citations for guidance on referring to specific versions of the Unicode Standard.

総称的な参照の公式的な仕方には,次の 2 つがある: ◎ A generic reference can be formulated in two ways:

  1. 仕様の参照文献 節に “`総称的^emな” 項目を明示的に含ませた上で、単純に仕様の本文から,その項目を参照する。 そのような総称的な項目には “…これは、時と伴に改訂-または改正され得る” などの~textを含ませる。 ◎ By explicitly including a generic entry in the bibliography section of a specification and simply referring to that entry in the body of the specification. Such a generic entry contains text such as "... as it may from time to time be revised or amended".
  2. 参照文献に “`特定の^em” 項目を含ませた下では、仕様の本文の中で参照を与える所に, “…これは時と伴に改訂-または改正され得るので…” などの~textを含ませる。 ◎ By including a specific entry in the bibliography and adding text such as "... as it may from time to time be revised or amended" at the point of reference in the body of the specification.

これら 2 つの公式化のどちらを利用するかは、各~仕様の編集上の~~裁量に委ねられる。 前者の公式化の例は、この仕様の参照文献に見出せる( `ISO/IEC-10646$r, `Unicode$r を見よ)。 後者の例, および[ `UCS$ 符号化法~用の~MIME `charset^c ~parameterに対する~version付けの課題 ]に関する論は、 `RFC3629$r, `RFC2781$r に見出せる。 ◎ It is an editorial matter, best left to each specification, which of these two formulations is used. Examples of the first formulation can be found in the bibliography of this specification (see the entries for [ISO/IEC 10646] and [Unicode]). Examples of the latter, as well as a discussion of the versioning issue with respect to MIME charset parameters for UCS encodings, can be found in [RFC 3629] and [RFC 2781].

`064-S@cf `~Unicode標準$へのすべての`総称的^emな参照は、仕様の発行~日に可用な~Unicode標準の最新の~versionを参照rしなければナラナイ。 ◎ C064 [S] All generic references to the Unicode Standard [Unicode] MUST refer to the latest version of the Unicode Standard available at the date of publication of the containing specification.

`065-S@cf `ISO/IEC-10646$r へのすべての`総称的^emな参照は、仕様の発行~日に可用な ISO/IEC 10646 の最新の~versionを参照rしなければナラナイ。 ◎ C065 [S] All generic references to ISO/IEC 10646 [ISO/IEC 10646] MUST refer to the latest version of ISO/IEC 10646 available at the date of publication of the containing specification.

B. 文字, ~keystroke, ~glyphの例(参考)

~computerにおけるこのような~textの複階性(そのほとんどは、人々の`書記体系$の複階性を反映する)の全体像の把握に役立つであろう,少数の例を挙げる。 ◎ A few examples will help make sense all this complexity of text in computers (which is mostly a reflection of the complexity of human writing systems). Let us start with a very simple example:\

最初はごく単純な例から: US-English ~keyboardを使う利用者が “`F^kbd`o^kbd`o^kbd” と打込んだとする。 ~computerでは 16-bit 値として符号化され( ~Unicodeの `UTF-16$ec 符号化法), ~screenに表示される。 ◎ a user, equipped with a US-English keyboard, types "Foo", which the computer encodes as 16-bit values (the UTF-16 encoding of Unicode) and displays on the screen.

Basic Latin の例 ( U.S. ~keyboardで `F^kbd`o^kbd`o^kbd が打込まれたときの~keystroke, 入力~文字, 符号化された文字, その表示の一覧 ) ◎ Example: Basic Latin (Table showing keystrokes, input characters, encoded characters and display for user typing Foo on a U.S. keyboard)
~keystroke Shift-f o o
入力~文字 F o o
`符号化d文字$(16 進~byte値) 0046 006F 006F
~text `Foo^kbd

唯一,大文字の `F^ch を入力するために修飾key( `Shift^kbd )を利用する所だけ、単純でない。 ◎ The only complexity here is the use of a modifier (Shift) to input the capital 'F'.

もう少し複階的な例を示す。 利用者が伝統的~French-Canadian~keyboardで `çé^kbd ( `¸^kbd`c^kbd`é^kbd )と打込んだとする(ここでも,~computer上では `UTF-16$ec に符号化されて表示されると見做す)。 ここでは、この~computerが `UTF-16$ec による全部的に組成済みの【`分解-可能$な】形( `composed form^en )を利用していると見做す。 ◎ A slightly more complex example is a user typing 'çé' on a traditional French-Canadian keyboard, which the computer again encodes in UTF-16 and displays. We assume that this particular computer uses a fully composed form of UTF-16.

`発音区別符$を伴う~Latinの例 ( ~French-Canadian~keyboardで `çé^kbd が打込まれたときの~keystroke, 入力~文字, 符号化された文字, その表示の一覧 ) ◎ Example: Latin with diacritics (Table showing keystrokes, input characters, encoded characters and display for user typing çé on a French-Canadian keyboard)
~keystroke ¸ c é
入力~文字 ç é
`符号化d文字$(16 進~byte値) 00E7 00E9
~text `çé^kbd

注目される点が少しばかりある: まず,利用者が`~cedilla$( `¸^kbd )を打込んでも、~keyboard~driverの状態が変化することを除いて,何も起きない — `~cedilla$は~dead-keyである。 続いて,~driverにて~keystroke `c^kbd が~~検知されると、 1 個の 16-bit `符号単位$として表現される完全な文字 `ç^ch が~systemに供され,`~glyph$ `ç^ch が表示される。 次に,利用者が専用の `é^kbd ~keyを押下げた場合も、 2 個の~byteで表現される 1 個の文字になる。 ほとんどの~systemは,これを 1 個の~glyphで表示するが、 2 個の~glyph(基底 `字l$と`~accent$)を組合せて同じ描画を得ることもアリである。 ◎ A few interesting things are happening here: when the user types the cedilla ('¸'), nothing happens except for a change of state of the keyboard driver; the cedilla is a dead key. When the driver gets the c keystroke, it provides a complete 'ç' character to the system, which represents it as a single 16-bit code unit and displays a 'ç' glyph. The user then presses the dedicated 'é' key, which results in, again, a character represented by two bytes. Most systems will display this as one glyph, but it is also possible to combine two glyphs (the base letter and the accent) to obtain the same rendering.

~Japaneseの例: 利用者が~romaji~IMEを利用して “`~~日本語^kbd” ( `65E5^U, `672C^U, `8A9E^U )と打込んで,~computer上では、 `UTF-16$ec に符号化されて表示されるとする。 ◎ On to a Japanese example: our user employs a romaji input method to type '日本語' (U+65E5, U+672C, U+8A9E), which the computer encodes in UTF-16 and displays.

~Japaneseの例 ( ~Japanese ~romaji~IMEで `n^kbd`i^kbd`h^kbd`o^kbd`n^kbd`g^kbd`o^kbd が打込まれたときの~keystroke, 入力~文字, 符号化された文字, その表示の一覧 ) ◎ Example: Japanese (Table showing keystrokes, input characters, encoded characters and display for user typing nihongo in a Japanese Romaji input method)
~keystroke n i h o n g o <space> <return>
入力~文字 ~~日 ~~本 ~~語
`符号化d文字$(16 進~byte値) 65E5 672C 8A9E
表示(~text) `~~日本語^s

ここで注目される点は入力である: 利用者が打込んだ~Latin文字は、まず(ここには示されないが)その場で仮名に変換される。 利用者は~~望むだけ `space^kbd ~keyを押下げて,それを変換する。 最終的に 利用者が `return^kbd ~keyを押下げたとき,その`漢字$が応用に送信される。 この 3 文字は自明な形では生産されず,それまでには 9 回の~keystrokeを要し、それが符号化され, 表示される。 ◎ The interesting aspect here is input: the user types Latin characters, which are converted on the fly to kana (not shown here), and then to kanji when the user requests conversion by pressing <space>; the kanji characters are finally sent to the application when the user presses <return>. The user has to type a total of nine keystrokes before the three characters are produced, which are then encoded and displayed rather trivially.

~Arabic`用字系$の下での~Persianでは,また異なる様相を呈する: ◎ A Persian example, using Arabic script, will show different phenomena:

~Persianの例 ( ~Arabic~keyboardで打込まれたときの~keystroke, 入力~文字, 符号化された文字, その表示の一覧 ) ◎ Example: Persian (Table showing keystrokes, input characters, encoded characters and display for user typing on an Arabic keyboard)
【~keystroke(~text)】 ل ا ی ی
入力~文字 ل ا ل ا ی ی
`符号化d文字$(16 進~byte値) 0644 0627 0644 0627 06CC 06CC
表示(画像) 表示される出力は右から左の順に現れる:
2 個の lam-alef 合字に続き,farsi yeh ~glyphと尾字形の farsi yeh ~glyph。
The displayed output appears, from right to left, as: two lam-alef ligatures, and initial farsi yeh glyph attached to a final farsi yeh glyph.
【表示(~text)】 `لالایی^s

ここでは最初の 2 回の~keystrokeそれぞれが 1 個の入力~文字を経て 1 個の符号化された文字を生産するが、その~pairは 1 個の`~glyph$として表示される( `لا^ch — `合字$ `lam-alef^en )。 次の~keystrokeは,一部の~Arabic用字系~keyboardに備わる `lam-alef^kbd であり, 1 回の~keystrokeで同じ 2 個の文字を生産し,前と同じように表示される。 この 2 個目の lam-alef は、表示においては, 1 個目のそれの`左^emに置かれる。 最後の 2 回の~keystrokeは 2 個の同一な文字を生産するが, 2 個の異なる~glyphで描画される(中字形( `medial form^en )に後続して,その左に尾字形( `final form^en ))。 したがって、 5 回の~keystrokeから 6 個の文字が生産され, 4 個の~glyphが右から左へ~~配置される。 ◎ Here the first two keystrokes each produce an input character and an encoded character, but the pair is displayed as a single glyph ('', a lam-alef ligature). The next keystroke is a lam-alef, which some Arabic script keyboards have; it produces the same two characters which are displayed similarly, but this second lam-alef is placed to the left of the first one when displayed. The last two keystrokes produce two identical characters which are rendered by two different glyphs (a medial form followed to its left by a final form). We thus have 5 keystrokes producing 6 characters and 4 glyphs laid out right-to-left.

最後に~Tamilの例。 ISCII ~keyboardで打込まれ,追加的な様相が見られる: ◎ A final example in Tamil, typed with an ISCII keyboard, will illustrate some additional phenomena:

~Tamilの例 ( Tamil ISCII ~keyboardで打込まれたときの~keystroke, 入力~文字, 符号化された文字, その表示の一覧 ) ◎ Example: Tamil (Table showing keystrokes, input characters, encoded characters and display for user typing on a Tamil ISCII keyboard)
`符号化d文字$(16 進~byte値) 0B9F 0BBE 0B99 0BCD 0B95 0BCB
表示(画像) タミル語の字による 'Tango'
【表示(~text)】 `டாங்கோ^s

ここでは入力~自体は素直であるが、前掲の`~accent$付きの~Latinの例とは逆に,`~virama$の`発音区別符$ `்^ch (`0BCD^U) が,その適用-対象の `ங^ch (`0B99^U) の`後に^em入力される。 また、最後の 2 個の文字の描画が特徴的である: 最後のもの `ோ^ch (`0BCB^U) は明らかに 2 個の`~glyph$からなり,最後の手前の文字 `க^ch (`0B95^U) の`~glyph$を`囲っている^em。 ◎ Here input is straightforward, but note that contrary to the preceding accented Latin example, the virama diacritic '்' (U+0BCD) is entered after the 'ங' (U+0B99) to which it applies. Rendering is interesting for the last two characters. The last one 'ோ' (U+0BCB) clearly consists of two glyphs which surround the glyph of the next to last character 'க' (U+0B95).

C. ~textの例(参考)

以下に、この文書で画像により例示された文字列や文字の~text~versionを挙げる。 【この訳では、各例に~text~versionも含めているので,以下は省略する。】 ◎ The following are textual versions of strings or characters used in image-based examples in this document. …

D. 適合性基準の一覧(参考)

以下に、文書~順に並べられたこの仕様の適合性基準を挙げる 【が、この訳では省略する】 。 [ 仕様/実装/内容 ]は、この仕様への適合性を検査する際に,この~listを利用できる。 ◎ This is a list of the conformance criteria in this specification, in document order. This list can be used to check specifications, implementations, and content for conformance to this specification.

その際には,次に挙げる点が念頭に置かれるべきである: ◎ When doing so, the following points should be kept in mind:

  • 最初にこの文書~全体をよく読んで意味を理解しておくこと。 この~listは、~textの本文の文脈の下で これらの適合性基準を読んだ上で,初めて、早見表の用をなす。 ◎ To ensure that you understand the meaning, read the whole document first. Use this list as a quick reference only after having first read the conformance criteria in context in the main body of the text.
  • この~listにおける適合性基準の意味が、それを囲んでいる,この文書の本文~textを読んだ上でも不明瞭ならば、メーリングリスト(冒頭のメタデータ内)に~commentを寄せることも考慮されたし。 ◎ If the meaning of a conformance criterion in this list is still unclear after referring back to the surrounding text in the main body of the document, consider sending a comment to www-i18n-comments@w3.org (publicly archived).
  • すべての適合性基準が,すべての[ 仕様/実装/内容 ]に適用されるわけではない。 実際の適合性を検査する前に,適用し得るものかどうか検査されるべきである。 例えば `010-$cf は,仕様に対してのみ適用される。 別の例として, `002-$cf は[ 仕様, 実装, 内容 ]いずれにも適用されるが、それは 文字と表示される~textの単位との対応関係が扱われる場合に限られる。 ◎ Not all conformance criteria apply to all specifications, implementations, or content. Before checking for actual conformance, applicability should be checked. As an example, C010 only applies to specifications. As another example, C002 applies to specifications, implementations, and content, but only if it deals with mapping between characters and units of displayed text.

E. 勧告案からの変更点(参考)

  • 参照文献 節の少数の~linkと参照を更新した。 ◎ A small number of links and references were updated in the references section.
  • `076-$cf の直後の段落を明確化するための編集上の変更 ⇒ “`iso-8859-1^ec で符号化される~repertoire” → “ISO Latin 1 文字~集合の符号位置” ◎ Minor editorial change to paragraph after C076 to clarify: "This prohibits, for example, the construction of fonts that misuse the repertoire encoded by iso-8859-1 to represent different scripts, characters, or symbols than what is actually encoded in iso-8859-1." changed to "This prohibits, for example, the construction of fonts that misuse the codepoints in the ISO Latin 1 character set to represent different scripts, characters, or symbols than those actually encoded in iso-8859-1.".

F. 謝辞(参考)

`Tim Berners-Lee^en と `James Clark^en 氏からは、~URIに関する節に重要な詳細を供していただいた。 `Asmus Freytag^en, `Addison Phillips^en 氏, および早期~段階での `Ian Jacobs^en 氏からは、著作と編集~過程に大きく貢献していただいた。 多くの方々や~W3C の I18N WG と IG から、有益な~commentと示唆を供していただいた。 ◎ Tim Berners-Lee and James Clark provided important details in the section on URIs. Asmus Freytag , Addison Phillips, and in early stages Ian Jacobs, provided significant help in the authoring and editing process. The W3C I18N WG and IG, as well as many others, provided many helpful comments and suggestions.