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

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” の一部を成す，この文書は、次に挙げる論題に取組む ⇒＃ 用語［ `文字$q, `符号化法$q, `文字列$q ］の~~用法, `§ 基準~処理~model$, `§ 文字~符号化法の選定と識別$, `§ 文字~escape法$, `§ 文字列の付番$ ◎ 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.

“~Webのための文字~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$ ）である。 この文書は、この普遍的な文字~集合の同義語として，語 `~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. 背景0

この節では、この仕様が取組む論題についての歴史的な背景0をいくつか述べる。 ◎ 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.

これらの開発により、［ ~Webのための文字~modelは~Unicodeに基づく ］とする要件が強まったことに加え，［ ~Webに対する~Unicodeの適用に対する，追加的な仕様 ］も必要になってきている。 ~Unicodeの側面のうち［ ~Web用に追加的な仕様を要求するもの ］には、次が含まれる： ◎ 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$が備わっていないと，これらに利用される文字が意図されたとおりに現れないので、そのような場合でも理解-可能になるよう~careされている。 一部の事例では，例示の結果が見えることが重要になるので、画像も併用されている。 ◎ Text has been used for examples to allow them to be cut and pasted by the reader. Characters used will not appear as intended unless you have the appropriate font, but care has been taken to annotate the examples so that they remain understandable even if you do not. In some cases it is important to see the result of an example, so images have been used; by clicking on the image it is possible to link to the text for these examples in C Example text.

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

3.1. 序論

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

文字（ `character$UT ） — (1) 言語が記されるときの，意味論上の値を成す最~小な成分であって、抽象的な意味や形状を参照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.

それらの仕様に基づく仕様や~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.

`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の一部の文字（句読点や長音など）は、縦書きと横書きで異なる~glyphが利用されよう。 記号~類のみならず、この仕様の~Persianの例には，単語~内の位置に応じて利用される~glyphが変化する例が挙げられている。 】

• 同じ`~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.4. 入力の単位

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

［ ~sortする／探索する ］ときに利用される文字列の比較は、一般に，符号化された文字と一対一に対応しない単位に基づいている。 そのような文字列~比較においては、次が生じることもある ⇒＃ 文字~並びが ~sort時の順序において自前の位置を持つような 1 個の照合c単位（ `collation unit^en ）に集成される／ 1 個の文字が複数個の照合c単位に分離される／ 文字の様々な側面（`文字大小$, `発音区別符$の有無, 等々）が判別され，別々に~sortされる（多段階な~sort法） ◎ 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など）では、~sort順序が，より高次な順序付け要因 — 発音体系や語源など — により統治され得る。 `照合c$（ `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.

`006-SI@cf 利用者のために~textを［ ~sortする／探索する ］~softwareは、関連な［ 言語や応用 ］に適切な［ 照合c単位と順序付け規則 ］に基づいて，それを行うベキである。 ◎ 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 動的に［ 探索する／~sortする ］所では、特に多言語~環境においては， “関連な言語” が現在の利用者のそれになるように（したがって利用者ごとに相違し得るように）決定するベキである ◎ 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を［ ~sortする／探索する ］ことを利用者に許容する~softwareは、［ 照合c単位と順序付け ］用に，代替な規則を選択することも利用者に許容するベキである。 ◎ 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 ［ ~sortする／探索する ］~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文字が含まれている場合でも、最低でも，照合c~algoが~~正常に~~働き続けることが要求されることに注意。 これは、［ すべての`用字系$に対応できる，複階的な~algo ］の全部的な実装を要求するものではない。 この要件を満たす有用な仕方として、［ すべての~Unicode文字を受持つ，既定の照合c~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照合c~algo$ ］は、ほとんどの言語に適応する`照合c$用の~modelを述べて，既定の照合c順序を供している。 それらは、［ `照合c$とその実装 ］の指針を供する，適切な基準になる。 いかなる文字が含まれようとも，文字列の［ 順序付けと比較 ］が予測-可能になることを確保するために、既定の照合c順序を［ 特定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の格納と通信は、情報の物理的な［ 格納／交換i ］単位 — ~bitや`~byte$（~octetとも呼ばれる 8-bit 単位）など — に依拠する。 仕様や実装にありがちな誤りは、物理的な格納~単位による文字の同等性比較である。 文字とそのような格納~単位との間の対応関係は、実際にはかなり複階的であり， `§ 文字~符号化法$にて論じられる。 ◎ 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.

この `§ 文字の知覚$では、用語 `文字$q とは必ずしも一致しない単位~用の用語 — `音素$, `~glyph$, `照合c$など — について論じた。 次節 `§ 文字~符号化法$では、符号化の単位（`符号位置$, `符号単位$, `~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.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^en” ）にされるが，一般には拡張可能（ “`open^en” ）なものもあり得る。 】

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に基づく場合に必要yな~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$, および文字~符号化法についての更なる詳細~についての論は、 `§ 文字~符号化法の識別$を見よ。 ◎ 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^e 要素による情報）を調整することもない。 ◎ 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 へのような並替ngも孕む： ◎ NOTE: Transcoding may involve one-to-one, many-to-one, one-to-many or many-to-many mappings. In addition, the storage order of characters varies between encodings: some, such as the Unicode encoding forms, prescribe logical ordering, while others use visual ordering; among encodings that have separate diacritics, some prescribe that they be placed before the base character, some after. Because of these differences in sequencing characters, transcoding may involve reordering: thus XYZ may map to yxz.

4.3. 基準~処理~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.

`~textな~data~obj@ （ `textual data object^en ）とは、全体が~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／形式 ］の仕様に定義される`~textな~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.

注記： `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）が挙げられる。 そこでは、次のような理由で，一部の文字を利用しないことが奨励されている ⇒＃ `~Unicode標準$により非推奨にされた。 追加的な~dataなしに~supportし得ない。 `~markup$の方がより良く取扱える。 等価な`~markup$と競合する。 ◎ 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: • They are deprecated in the Unicode Standard. • They cannot be supported without additional data. • They are better handled by markup. • They conflict with equivalent markup.

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

符号化された~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／形式／~API ］に基づく仕様, そのような［ ~protocol／形式 ］に基づく~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~sizeが小さいとき／仕様が実際の処理に近いとき ］には，有利になる。 ◎ 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に選好される名前 ］を利用するベキである。 ◎ 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に，どの文字~符号化法が 適切あるいは必要yであるか ］については，助言を供さない。 ◎ 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.

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.

注記： 文字列は、 `書記素~cluster@ （ `grapheme cluster$UT ）の並びとして見ることアリである。 `書記素~cluster$は、`文字~文字列$よりも，［ 【！視覚的に】描画された~textにおいて 利用者から知覚される文字の境界 ］に近い単位に~textを分割0する。 書記素~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?".

前節 `§ 文字列の概念$では、文字列が［ `文字~文字列$／ `符号単位~文字列$／ `~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の要件に依存して、数え方の単位は `§ 文字列の概念$にて与えた，文字列の様々な定義に対応し得る。 特に： ◎ 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 個の［ 文字／符号化 ］が成す単位を指定するベキでない。 ◎ 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には "ß" の大字 （ "ẞ" ）もあるので，この例は文脈によっては適切でないかもしれない。】 また， `§ 文字の知覚$にて述べたように、文字と［ 響き, 入力, 等々を成す単位 ］の間に一対一な対応関係があるとは限らないことにも注意。 ◎ 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.