#?SuikaWiki/0.9 page-icon="字β" import="RFC訳語集,その他の訳語集,HTML訳語集,メッセージ訳語集" ''Character Set Considered Harmful [INS[文字集合は有害だと思われ]]'' -HTML Working Group -INTERNET-DRAFT -draft-ietf-html-charset-harmful-00.txt -Expires November, 1995 -D. Connolly -MIT/W3C -May 2, 1995 *Status of this Document >This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. >Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." >To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). >Distribution of this document is unlimited. Please send comments to the HTML working group (HTML-WG) of the Internet Engineering Task Force (IETF) at ;. Discussions of the group are archived at http://www.acl.lanl.gov/HTML_WG/archives.html . *Abstract [INS[概要]] >The term character set is often used to describe a ditigal representation of text. ASCII is perhaps the most widely deployed representation of text, and in the interest of interoperability, information systems on the Internet traditionally rely on it exclusively. 用語「文字集合」は、しばしば__&&text&&__の__&&digital&&__表現を現すのに使われます。 ASCII はおそらく最も広く用いられている__&&text&&__の表現で、相互通信性の観点で、__&&Internet&&__の__&&information system&&__は伝統的に専らこれに依存しています。 >The Multipurpose Internet Mail Extensions (MIME) introduces Internet Media Types, including text representations besides ASCII. The Hypertext Markup Language (HTML) used in the World-Wide Web is a proposed Internet Media Type. But HTML is also an application of Standard Generalized Markup Language (SGML). __&&Multipurpose Internet Mail Extensions&&__ (MIME) は ASCII 以外の__&&text&&__表現を含む__&&Internet Media Type&&__を導入しました。 __&&World Wide Web&&__で使われる__&&Hypertext Markup Language&&__ (HTML) は提案中の__&&Internet Media Type&&__です。 しかし HTML は__&&Standard Generalized Markup Language&&__ (SGML) の応用でもあります。 >In the MIME and SGML specifications, the discussion of characters representation is notoriously complex, and apparently subtly inconsistent or incompatible. This document presents a collection of terms intended to reconcile the two specifications and serve as a basis for rigorous discussion of characters and their digital representations. MIME 及び SGML の仕様において、文字の表現についての話題は極めて複雑であって、明白に巧妙に不一致或いは非互換になっています。 この文書は、2つの仕様を仲裁して文字とその__&&digital&&__表現についての厳密な議論を行うための基礎とすることを目的として、用語を集めて提示します。 *Introduction [INS[はじめに]] >The term character set is often used to describe a ditigal representation of text. The specification of such a representation typically involves identifying a sufficiently expressive collection of characters, and giving each of them a number. 用語[DFN[文字集合]] ([DFN[character set]]) は__&&text&&__の__&&digital&&__表現を表すのによく使われます。 そのような表現は典型的に十分豊富な文字の集合を識別しそのそれぞれに番号を与えることを含みます。 >In conventional mathematics terminology then, a "character set" is not just a set of characters, but a function whose domain is a set of integers, and whose range is a set of characters. 普通の数学用語では「文字集合」は単なる集合ではなく関数であり、 その定義域が整数の集合で値域が文字の集合なのです。 >Some standards documents, including the SGML standard, make little or no use of such conventional mathematical terms as function, domain and range. Perhaps the authors of those documents intend the documents to be comprehensible without a prior understanding of mathematics. But the specification of notions such as the conformance of an SGML document or SGML system are much more complex than the basics of logic and mathematics. SGML 規格を含む幾つかの標準文書は関数や定義域や値域のような普通の数学用語をほとんど全く使っていません。 おそらくその文書の著者は数学をあまり理解していなくても文書が理解可能にしているのでしょう。 しかし SGML 文書や SGML システムの適合性の記法の仕様は論理・数学の基本よりももっと複雑です。 >In his text on Calculus [Spivak] , Michael Spivak writes: Michael Spivak は自身の微積の文章でこう書いています。 >>Every aspect of this book was influenced by the desire to present calculus not merely as a prelude to but as the first real encounter with mathematics. Since the foundation of analysis provided the arena in which modern modes of mathematical thinking developed, calculus ought to be the place in which to expect, rather than avoid, the strengthening of insight with logic. In addition to developing the students' intuition about the beautiful concepts of analysis, it is surely equally important to persuade them that precision and rigor are neither deterrents to intuition, nor ends in themselves, but the natural medium in which to formulate and think about mathematical questions. この本のあらゆる部分に、微積分学を単に前奏曲としてではなく、数学との最初の本当の出会いとして示したいという願いが込められています。 分析の土台は現代の数学の考え方が発達してきた領域でしたから、 微積分学は論理と共に洞察力を強化することを、避けるよりもむしろ期待する場所であるべきです。 分析の美しき概念についての学生の直感を磨くことに加え、 正確さと厳しさはいずれも直感を妨げるものでもそれ自身に終わるものでもなく、数学的問題について考察する自然な手段であることを学生達に信じさせることも確かに等しく重要です。 >This document is not intended as the first real encounter with mathematics. But neither will we make any effort to avoid or apologize for mathematical terminology. The reader is referred to the large body of literature on logic and set theory, including a history of writings on math and logic[SET] and Douglas Hofstadter's fascinating book [GEB] . この文書は数学との最初の本当の出会いを目的としたものではありません。 しかし数学用語を避けたり弁明したりする努力をしようともしません。 読者は、数学及び論理の記述の歴史や Douglas Hofstandter の素晴らしい本などの論理学や集合論の分厚い本を参照してください。 *Coded Character Sets [INS[符号化文字集合]] >Using "character set" rather than something such as character table or even character sequence to denote the functions that maps integers to characters is unfortunate, but it is water under the bridge, and a lot of it by now. Rather than attempting to divert all that water at this point, we introduce the primitive notion of character and use it to define the term coded character set from [ISO10646] and other standards: 「文字集合」を文字表の類でないものに使うことや、 文字の列を整数を文字に対応付ける関数を示すのに使うことは不適切ですが、それは橋の下の水であって、現在多くあります。 その水をこの点から全てそらそうとするよりは、 原始的な文字の観念を導入してこれを ISO 10646 及び他の規格の用語[DFN[符号化文字集合]]を定義するのに使いましょう。 :character:An atom of information :coded character set:A function whose domain is a subset of the integers, and whose range is a set of characters. :文字:情報の単位 :符号化文字集合:定義域が整数の部分集合であって、その値域が文字の集合である関数。 >Note that by the term character, we do not mean a glyph, a name, a phoneme, nor a bit combination. A character is simply an atomic unit of communication. It is typically a symbol whose various representations are understood to mean the same thing by a community of people. この定義では、用語[DNF[文字]]は[RUBYB[図形] [glyph]]も名前も音素もビット組合せも含まないことに注意して下さい。 文字は単に意思疎通の基本的単位です。 これは典型的にはその種々の表現が人々の集団において同じものを意味すると理解される記号です。 >It might seem more intuitive to map from characters to integers, rather than the way it is defined here. But in practice there are some coded character sets that assign two different numbers to the same character [Lee] , and so the inverse is not a function in the general case. 文字から整数へ対応付ける方がここで定義する方法より直感的かもしれません。 しかし実際には2つの異なる数値に同じ文字を割当てる符号化文字集合もありますから、一般には逆は関数ではありません。 >There are two other terms used in standards such as [ISO10646] that we define in relation to the first two: 最初に定義した2つに関連して ISO 10646 などの規格では他にも2つの用語が使われます。 :code position:An integer. A coded character set and a code position from its domain determine a character. :character repertoire:A set of characters; that is, the range of a coded character set. :文字位置:整数。符号化文字集合とその定義域内の符号位置が文字を決定する。 :文字レパートリ:文字の集合。つまり、符号化文字集合の値の範囲。 *Character Encoding Schemes [INS[文字符号化方法, 文字符号化方式]] >The only practical means for exchanging information on the Internet is to represent it as a sequence of octets (bytes). __&&Internet&&__で情報を交換する唯一の実際の手段はオクテット (バイト) の列としてそれを表現することです。 >One way to transmit a sequence of characters is to agree on a coded character set and transmit the character numbers of each of the characters. 文字の連続を転送する1つの方法は、符号化文字集合と文字それぞれの文字番号の伝送を合意することです。 >But in practice, characters are encoded using a variety of optimizations of this brute-force approach: code switching techniques, escape sequences, etc. The encoding of a sequence of characters is not, in general, the result of encoding each character independently and then concatenating them. But it is sufficiently general to note that sequences of characters are encoded as a sequence of bytes. So we define: しかし実際には、文字は符号切替え技術, エスケープ・シーケンスなどの種々の brute-force 手法による最適化を使って符号化されます。 文字の連続の符号化は、一般には各文字を独立に符号化してそれを連結した結果とは異なります。 しかし文字の連続はバイトの連続として符号化されるのが大抵普通です。 ですからこう定義しましょう。 :octet:an element of the set {0, 1, 2, ..., 255} :character encoding scheme:a function whose domain is the set of sequences of octets, and whose range is the set of sequences of characters over some character repertoire. :オクテット:集合 {0, 1, 2, ..., 255} の要素 :文字符号化方法(方式):その定義域がオクテットの集合であり、その値の範囲が文字レパートリ中の文字の連続の集合である関数。 *Representation of SGML Text Entities [INS[SGML __&&text&&__実体の表現]] >An SGML document is made up of entities: a text entity called the document entity, and possibly some other text entities and data entities. SGML 文書は実体により構成されます。__&&text entity&&__は__&&document entity&&__を呼び、また他の__&&text entity&&__や__&&data entity&&__を呼ぶことが出来ます。 >A text entity is a sequence of characters. The representation of a text entity is not specified by the SGML standard. For the purpose of MIME-based interchange of SGML text entities, we define the following: __&&text entity&&__は文字の連続です。 __&&text entity&&__の表現は SGML 規格では既定されていません。 MIME を基にした SGML __&&text entity&&__の交換の目的では、 次のように定義します。 :text entity:a sequence of characters :message entity: a pair (T, OS) where T is an Internet Media Type and OS is a sequence of octets. :__&&text entity&&__:文字の連続 :メッセージ実体:組合せ ([VAR[T]], [VAR[OS]])。ここで、 [VAR[T]] は__&&Internet Media Type&&__, [VAR[OS]] はオクテットの連続。 >Note that each text/* media type has an associated charset parameter, which designates a character encoding scheme. The character encoding scheme maps the body -- a sequence of octets -- to a text entity -- a sequence of characters. Hence any message entity of type text/* is equivalent to a text entity. [CODE[text/*]] __&&media type&&__には関連付けられた [CODE[charset]] __&¶meter&&__があり、これは文字符号化方法を示します。 文字符号化方法は__&&body&&__ (オクテットの連続) から__&&text entity&&__ (文字の連続) に対応付けます。 よって型 [CODE[text/*]] のメッセージ実体は__&&text entity&&__と同等です。 *Numeric Character References [INS[数値文字参照]] >Numeric character references are a great source of confusion. The key insights are that: -Every SGML document has exactly one document character set, which is a coded character set -Numeric character references give code positions in the document character set [VAR[数値文字参照]]は、大きな混乱の元です。 鍵となる洞察は、 -全ての SGML 文書は1つの文書文字集合を持つ。これは符号化文字集合である。 -数値文字参照は文書文字集合中の符号位置を与える。 >Example: ISO2022 Encoding with ISO10646 Coded Character Set 例: ISO 10646 符号化文字集合の ISO 2022 符号化 >Consider the following message entity: 次のメッセージ実体を考えて見ます。 [PRE[ Date: Saturday, 29-Apr-95 03:53:33 GMT MIME-version: 1.0 Content-Type: text/html; charset=iso-2022-jp ... Here is some normal text. [INS[普通の__&&text&&__。]] Here is a 10646 numeric character reference ঀ. [INS[10646 数値文字参照 ঀ。]] Here is some ISO-2022-JP text: ... [INS[ISO-2022-JP の__&&text&&__。]] ]PRE] >To interpret the message entity, we notice that the Content-Type is text/html , so this represents a text entity. The charset parameter iso-2022-jp , along with the octet sequence of the body, determines a sequence of characters. The octets denoted above by '...' represent characters, as per iso-2022-jp . メッセージ実体を解釈するとき、 [CODE(MIME)[Content-Type]] が [CODE[text/html]] ですから、これは__&&text entity&&__を表します。 [CODE[charset]] __&¶meter&&__は[CODE[iso-2022-jp]] で、__&&body&&__のオクテットの連続から文字の連続を決定します。 上に示した「[SAMP[...]]」は [CODE[iso-2022-jp]] による文字列を示します。 >To parse the resulting text entity as per SGML, the sender and receiver must agree on an SGML declaration, since none is present in the document entity. For this example, we assume that SGML declaration specifies ISO10646 as the document character set. So the numeric character reference ঀ is resolved with respect to ISO10646. 結果の__&&text entity&&__を SGML により解析するのに、送信者と受信者は SGML 宣言により合意しなければなりません。 __&&document entity&&__で何も示されていないからです。 この例では、 SGML 宣言で ISO 10646 を文書文字集合と規定していると仮定します。 ですから数値文字集合 [SAMP(SGML)[ঀ]] は ISO 10646 により解決します。 >It may seem contradictory that the ISO-2022-JP character encoding scheme is defined in terms of a collection of coded character sets, none of which is ISO10646. But there is no contradiction. Each character encoded by ISO-2022-JP is in the repertoire of one of those coded character sets, each of which is a subset of the repertoire of ISO10646. ISO-2022-JP 文字符号化方法は ISO 10646 でない符号化文字集合の集合として定義されているのに矛盾するように見えるかもしれません。 しかし矛盾はありません。 ISO-2022-JP で符号化された文字それぞれはそれらの符号化文字集合の1つのレパートリ中にあり、そのそれぞれは ISO 10646 のレパートリの部分集合だからです。 >So while ISO-2022-JP is not sufficient for every ISO10646 document, it is the case that ISO10646 is a sufficient document character set for any entity encoded with ISO-2022-JP . ですから ISO-2022-JP が全ての ISO 10646 文書に十分ではなくても、 ISO 10646 は ISO-2022-JP で符号化された実体の十分な文書文字集合であるのです。 >Example: Reducing the Repertoire of an Entity 例: 実体のレパートリの縮小 >Suppose we have an SGML document D whose document character set is the coded character set ISO10646. We find the document entity DE in the form of sequence of octets OS in a disk file, encoded using the Unicode-UCS-2 character encoding scheme. SGML 文書 [VAR[D]] があってその文書文字集合は符号化文字集合 ISO 10646 だとします。__&&disk&&____&&file&&__において [CODE[Unicode-UCS-2]] 文字符号化方式を使って符号化されたオクテットの連続 [VAR[OS]] の形で文書実体 [VAR[DE]] があるとします。 Unicode-UCS-2(OS) = DE >We can reduce the character repertoire necessary to represent the document entity by replacing characters outside the ISO-646-IRV character repertoire with numeric character references: ISO 646 IRV 文字レパートリ外の文字を数値文字参照で置換することにより、__&&document entity&&__を表現するのに必要な文字レパートリ縮小する出来ます。 DE' = reduce(DE, ISO10646, ISO-646-IRV) >where reduce : SEQ(char) X Coded Character Set X Character Repertoire -> SEQ(char) >and reduce(c . rest, CCS, R) = if c in R, c . reduce(rest, CCS, R) else &#N; . reduce(rest, CCS, R) where CCS(N) = c >The resulting entity, DE' can then be endoded using US-ASCII 結果の実体 [VAR[DE']] は US-ASCII を使って符号化出来ます。 US-ASCII(OS') = DE' = reduce(DE, ISO10646, ISO-646-IRV) >Hence, we can represent the document D as a message entity whose content type is "text/plain; charset=US-ASCII" and whose body is OS'. 従って、文書 [VAR[D]] を__&&content type&&__が [CODE(MIME)[text/plain; charset=US-ASCII]] で__&&body&&__が [VAR[OS']] であるメッセージ実体として表現できます。 [INS[ 訳注: [CODE[text/html]] を意図していたのではないか。 ]INS] *Conclusion [INS[まとめ]] >It is critical to keep separate the notion of a simple table of characters and their numbers, i.e. a coded character set, separate from the various algorithms to encoded sequences of characters, i.e. character encoding schemes. This separation allows a representation of a text entity which is consistent with both the MIME and SGML specifications. *Acknowledgements [INS[謝辞]] >The idea for the title of this document actually came from John Klensin. The notion of character encoding scheme was inspired by the MIME specification by Ned Freed. James Clark, Ed Levinson, and several other members of the MIMESGML working group collaborated in discussions leading up to this draft. Liam Quin from SoftQuad and Gavin Nicol from EBT have provided guidance on these issues in the past. Erik Naggum has provided invaluable aid in understanding the SGML standard. *References [MIME] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." RFC 1521, Bellcore, Innosoft, September 1993. [ASCII] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. [ISO-8859] ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. [SGML] ISO 8879. Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML), 1986. [Nicol] The Multilingual World Wide Web , Gavin T. Nicol, Electronic Book Technologies, Japan gtn@ebt.com [Lee]Private communication with Liam Quin, from SoftQuad. [Spivak] Spivak, Michael. Calculus. 2nd Ed. 1967 ISBN 0-914098-77-2 [GEB]Hofstadter, Douglas R. Gödel, Escher, Bach: An Eternal Golden Braid, 1979 ISBN 0-394-75682-7 [SET]"Investigations in the foundations of set theory I", in Jean van Heijenoort (ed.) _From Frege to Godel: A Source Book in Mathematical Logic, 1879-1931_ (Harvard U.P., 1967) *Author: Dan Connolly 545 Technology Square Cambridge, MA 02139 617-258-8143 connolly@w3.org *License [[RFCのライセンス]] *メモ - [1] 正直なところ、あまり良い説明だと思えません。 [[RFC2130]] よりはずっとましではあると考えますが。