RFC 2070

RFC 2070: Internationalization of the Hypertext Markup Language

[1] RFC 2070RFC 2854 により廃止されました。

[2147483646] かつて RFC 2070 が規定していた領域は、現在は HTML Standard で規定されています。

[3] HTML 2.x も参照。

Internationalization of the Hypertext Markup Language

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.


The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.

ハイパーテキスト・マーク付け言語 (HTML) は、 ハイパーテキスト文書を作成するのに使用する、 環境独立なマーク付け言語です。はじめ、 World Wide Web での HTML の応用は、西欧言語にのみ適切な ISO-8859-1 符号化文字集合に依存して激しく制限されていました。 この制限にもかかわらず、 HTML は他の符号化文字集合や文字符号化を使って他の言語で (相互運用性を犠牲にして) 広く使われています。

This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world.

この文書は、 HTML の仕様書を拡張して、 適切な国際化 (i18n, i の後に18文字置いて n) 対応のための追加の勧告を行って HTML の国際化の問題に言及しようとしています。 もっとも重視したことは、 HTML を SGML の妥当な応用としながらも世界のすべての言語を使うことを可能にするという点であります。

Table of Contents

   1.  Introduction .................................................. 2
     1.1. Scope ...................................................... 2
     1.2. Conformance ................................................ 3
   2. The document character set ..................................... 4
     2.1. Reference processing model ................................. 4
     2.2. The document character set ................................. 6
     2.3. Undisplayable characters ................................... 8
   3. The LANG attribute.............................................. 8
   4. Additional entities, attributes and elements ................... 9
     4.1. Full Latin-1 entity set .................................... 9
     4.2. Markup for language-dependent presentation ................ 10
   5. Forms ..........................................................16
     5.1. DTD additions ..............................................16
     5.2. Form submission ............................................17
   6. External character encoding issues .............................18
   7. HTML public text ...............................................20
     7.1. HTML DTD ...................................................20
     7.2. SGML declaration for HTML ..................................35
     7.3. ISO Latin 1 character entity set ...........................37
   8. Security Considerations.........................................40
   Bibliography ......................................................40
   Authors' Addresses ................................................43

1. Introduction

The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, through various ad hoc extensions to the language [TAKADA].

ハイパーテキスト・マーク付け言語 (HTML) は、 ハイパーテキスト文書を作成するのに使用する、 環境独立なマーク付け言語です。はじめ、 World Wide Web での HTML の応用は、西欧言語にのみ適切な ISO-8859-1 符号化文字集合に依存して激しく制限されていました。 この制限にもかかわらず、 HTML は色々な特別な拡張によって他の符号化文字集合や文字符号化を使って他の言語で (相互運用性を犠牲にして) 広く使われています。

This document is meant to address the issue of the internationalization of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. It is in good part based on a paper by one of the authors on multilingualism on the WWW [NICOL]. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world.

この文書は、 HTML の仕様書を拡張して、 適切な国際化 (i18n, i の後に18文字置いて n) 対応のための追加の勧告を行って HTML の国際化の問題に言及しようとしています。 それは著者の一人の WWW の多言語主義に関する論文に基づいた良い点です。 もっとも重視したことは、 HTML を SGML の妥当な応用としながらも世界のすべての言語を使うことを可能にするという点であります。

The specific issues addressed are the SGML document character set to be used for HTML, the proper treatment of the charset parameter associated with the "text/html" content type and the specification of some additional elements and entities.

特に言及している問題は、 HTML で使用する SGML 文書文字集合、 text/html 内容型に関連付けられた charset 引数の適切な取扱い、 それに幾つか追加の要素と実体の規定です。

1.1 Scope

HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. This specification extends the capabilities of HTML 2.0 (RFC 1866), primarily by removing the restriction to the ISO-8859-1 coded character set [ISO-8859].

HTML は1990年から World Wide Web (WWW) 活動で使われてきました。 この仕様書は HTML 2.0 (RFC 1866) の能力を、 主として ISO-8859-1 への制限を取除くことによって拡張します。

HTML is an application of ISO Standard 8879:1986, Information Processing Text and Office Systems -- Standard Generalized Markup Language (SGML) [ISO-8879]. The HTML Document Type Definition (DTD) is a formal definition of the HTML syntax in terms of SGML. This specification amends the DTD of HTML 2.0 in order to make it applicable to documents encompassing a character repertoire much larger than that of ISO-8859-1, while still remaining SGML conformant.

HTML は ISO 規格 8859:1986 情報処理文章及び事務システム — 標準一般化マーク付け言語 (SGML) の応用です。 HTML 文書型定義 (DTD) は HTML 構文の SGML の言葉による正式な定義です。 この仕様書は HTML 2.0 の DTD を改訂して、 SGML に適合したままながらも ISO-8859-1 よりもずっと大きな文字レパートリの文書に適用可能にします。

Both formal and actual development of HTML are advancing very fast. The features described in this document are designed so that they can (and should) be added to other forms of HTML besides that described in RFC 1866. Where indicated, attributes introduced here should be extended to the appropriate elements.

HTML の正式な開発も実際の開発も非常に速く進みます。 この文書で記述する機能は RFC 1986 で記述されたものとは別の形の HTML にも追加できる (しするべきである) ように設計されています。 示されたところでは、ここで導入した属性は適切な要素に拡張するべきです。

1.2 Conformance

This specification changes slightly the conformance requirements of HTML documents and HTML user agents.

この仕様書は HTML 文書および HTML 利用者エージェントの適合性要件を甚だ変更致します。

1.2.1 Documents

All HTML 2.0 conforming documents remain conforming with this specification. However, the extensions introduced here make valid certain documents that would not be HTML 2.0 conforming, in particular those containing characters or character references outside of the repertoire of ISO 8859-1, and those containing markup introduced herein.

すべての HTML 2.0 適合文書は、この仕様書にも適合します。 しかし、ここで導入する拡張は HTML 2.0 に適合しないある種の文書、 特に ISO 8859-1 のレパートリ外の文字や文字参照を含む文書やここで導入するマークを含む文書を妥当にします。

1.2.2. User agents

In addition to the requirements of RFC 1866, the following requirements are placed on HTML user agents.

RFC 1866 の要件に加えて、次の要件を HTML 利用者エージェントに課します。

To ensure interoperability and proper support for at least ISO-8859-1 in an environment where character encoding schemes other than ISO-8859-1 are present, user agents MUST correctly interpret the charset parameter accompanying an HTML document received from the network.

ISO-8859-1 以外の文字符号化方式の環境で最低 ISO-8859-1 の相互運用性と適当な対応を確保するために、 利用者エージェントはネットワークから受信した HTML 文書に添えられた charset 引数を正しく解釈しなければなりません

Furthermore, conforming user-agents MUST at least parse correctly all numeric character references within the range of ISO 10646-1 [ISO-10646].

更に、適合利用者エージェントは、最低 ISO 10646-1 の範囲内のすべての数値文字参照を正しく解析しなければなりません

訳注: ISO/IEC 10646-1 の範囲だと ISO/IEC 10646 のすべての文字が含まれてしまいますが・・・。 (BMP すべてとでも言いたかったのでしょう。)

Conforming user-agents are required to apply the BIDI presentation algorithm if they display right-to-left characters. If there is no displayable right-to-left character in a document, there is no need to apply BIDI processing.

適合利用者エージェントは、右から左への文字を表示する時に BIDI 表現算法を適用する必要があります。文書に表示可能な左から右への文字がなければ、 BIDI 処理を適用する必要はありません。

2. The document character set

2.1. Reference processing model

This overview explains a reference processing model used for HTML, and in particular the SGML concept of a document character set. An actual implementation may widely differ in its internal workings from the model given below, but should behave as described to an outside observer.

この概観は、 HTML で使用する参照処理模型と、 特に SGML の文書文字集合の概念を説明します。 実際の実装は内部の作業が以降で説明する模型と大きく異なっていても構いませんが、 外から観たらここで説明するように振る舞っているべきです。

Because there are various widely differing encodings of text, SGML does not directly address how the sequence of characters that constitutes an SGML document in the abstract sense are encoded by means of a sequence of octets (or occasionally bit groups of another length than 8) in a concrete realization of the document such as a computer file. This encoding is called the external character encoding of the concrete SGML document, and it should be carefully distinguished from the document character set of the abstract HTML document. SGML views the characters as a single set (called a "character repertoire"), and a "code set" that assigns an integer number (known as "character number") to each character in the repertoire. The document character set declaration defines what each of the character numbers represents [GOLD90, p. 451]. In most cases, an SGML DTD and all documents that refer to it have a single document character set, and all markup and data characters are part of this set.

文章の符号化には多種多様なものがありますから、 SGML は抽象的な意味で SGML 文書を構成する文字列が計算機ファイルなどの文書の具体的な存在でどうオクテット列 (あるいは場合によっては8以外の数のビットの組) として符号化されているのかに直接言及していません。この符号化は具象 SGML 文書の外部文字符号化と呼び、抽象 HTML 文書の文書文字集合とは注意して区別するべきです。 SGML は文字を一つの集合 (文字レパートリと呼びます。) と整数 (文字番号といわれます。) をレパートリ中のそれぞれの文字に割当てた符号集合としてみます。 文書文字集合宣言は各文字番号が何を表現するかを定義します。 ほとんどの場合、 SGML DTD とそれを参照するすべての文書は一つの文書文字集合を持ち、 すべてのマークとデータはその集合の一部です。

HTML, as an application of SGML, does not directly address the question of the external character encoding. This is deferred to mechanisms external to HTML, such as MIME as used by the HTTP protocol or by electronic mail.

HTML は、 SGML 応用として、直接外部文字符号化の問題には言及していません。 これは HTML の外の仕組み、例えば HTTP プロトコルや電子メイルによって使われる MIME の範疇です。

For the HTTP protocol [RFC2068], the external character encoding is indicated by the "charset" parameter of the "Content-Type" field of the header of an HTTP response. For example, to indicate that the transmitted document is encoded in the "JUNET" encoding of Japanese [RFC1468], the header will contain the following line:

HTTP プロトコルでは、外部文字符号化は HTTP 応答の頭部の Content-Type 欄の charset 引数によって示します。例えば、転送される文書が日本の JUNET 符号化で符号化されていることを示すには、 頭部が次の行を含むことになります。

Content-Type: text/html; charset=ISO-2022-JP

The term "charset" in MIME is used to designate a character encoding, rather than merely a coded character set as the term may suggest. A character encoding is a mapping (possibly many-to-one) of sequences of octets to sequences of characters taken from one or more character repertoires.

MIME の用語 charset は、語感の通りの単なる符号化文字集合ではなく、 文字符号化を示すために使用されます。文字符号化はオクテットの列から一つ以上の文字レパートリから取った文字の列への (多対一のこともある) 写像です。

The HTTP protocol also defines a mechanism for the client to specify the character encodings it can accept. Clients and servers are strongly requested to use these mechanisms to assure correct transmission and interpretation of any document. Provisions that can be taken to help correct interpretation, even in cases where a server or client do not yet use these mechanisms, are described in section 6.

HTTP プロトコルはクライアントが受入れることのできる文字符号化を指定する仕組みも定義しています。 クライアントと鯖には、すべての文書の正しい転送と解釈を保証するために、 こうした仕組みを使うことを強く要求します。 鯖やクライアントがこのような仕組みを使っていなかったとしても正しい解釈を助けることができる準備については6章で説明します。

Similarly, if HTML documents are transferred by electronic mail, the external character encoding is defined by the "charset" parameter of the "Content-Type" MIME header field [RFC2045], and defaults to US-ASCII in its absence.

同様に、 HTML 文書が電子メイルで転送される場合も、 外部文字符号化は Content-Type MIME 頭欄の charset 引数で定義し、 存在しない場合には US-ASCII が既定値となります。

No mechanisms are currently standardized for indicating the external character encoding of HTML documents transferred by FTP or accessed in distributed file systems.

FTP で転送されたり分散ファイル・システムで access する HTML 文書の外部文字符号化を示す仕組みは現在のところ標準化されていません。

In the case any other way of transferring and storing HTML documents are defined or become popular, it is advised that similar provisions be made to clearly identify the character encoding used and/or to use a single/default encoding capable of representing the widest range of characters used in an international context.

他の HTML 文書を転送したり蓄積したりする方法が定義されたり好評を博したりする場合には、 同様な仕組みで使用する文字符号化を明確に識別するようにするか、 あるいは国際的な文脈で使われる広範囲の文字を表現する能力のある符号化だけを使ったり既定のものとしたりするか、 その両方とするよう助言致します。

Whatever the external character encoding may be, the reference processing model translates it to the document character set specified in Section 2.2 before processing specific to SGML/HTML. The reference processing model can be depicted as follows:

外部文字符号化が何であれ、参照処理模型はこれを SGML・HTML 固有の処理の前に2.2節で規定する文書文字集合に翻訳します。 参照処理模型は次の通り表すことができます。

    [resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display]
                           [manager]  [parser]
                                ^          |
                                |          |
    [  資源  ]->[復号器 ]->[実体   ]->[ SGML ]->[   応用    ]->[  表示 ]
                           [ 管理器]  [解析器]
                                ^          |
                                |          |

The decoder is responsible for decoding the external representation of the resource to the document character set. The entity manager, the parser, and the application deal only with characters of the document character set. A display-oriented part of the application or the display machinery itself may again convert characters represented in the document character set to some other representation more suitable for their purpose. In any case, the entity manager, the parser, and the application, as far as character semantics are concerned, are using the HTML document character set only.

復号器は資源の外部表現を文書文字集合に復号することに責任を持ちます。 実体管理器、解析器、応用は文書文字集合の文字のみを処理します。 応用の表示指向部分や表示機械自体は再び文書文字集合で表現した文字を他のより目的に沿った表現に変換して構いません。 どの場合でも、実体管理器、解析器、応用は文字の意味に関する限り、 HTML 文書文字集合のみを使います。

An actual implementation may choose, or not, to translate the document into some encoding of the document character set as described above; the behaviour described by this reference processing model can be achieved otherwise. This subject is well out of the scope of this specification, however, and the reader is invited to consult the SGML standard [ISO-8879] or an SGML handbook [BRYAN88] [GOLD90] [VANH90] [SQ91] for further information.

実際の実装は文書を前述の文書文字集合の符号化に翻訳するかしないかを選ぶことができます。 この参照処理模型で記述した振舞いは他の方法でも達成できます。 しかし、この主題はこの仕様書の適用範囲を明確にすることでありまして、 読者は詳しくは SGML 規格または SGML 手引きをご覧頂きたく存じます。

The most important consequence of this reference processing model is that numeric character references are always resolved with respect to the fixed document character set, and thus to the same characters, whatever the external encoding actually used. For an example, see Section 2.2.

この参照処理模型のもっとも重要な結果は、 数値文字参照が常に固定の文書文字集合に関して、 すなわち実際に使われている外部符号化に関わらず同じ文字に解決されることであります。

2.2. The document character set

The document character set, in the SGML sense, is the Universal Character Set (UCS) of ISO 10646:1993 [ISO-10646], as amended. Currently, this is code-by-code identical with the Unicode standard, version 1.1 [UNICODE].

SGML の意味での文書文字集合は、 ISO 10646:1993 および改正による国際符号化文字集合 (UCS) です。現在、 UCS は符号ごとに Unicode 規格 1.1 版と同一です。

NOTE -- implementers should be aware that ISO 10646 is amended from time to time; 4 amendments have been adopted since the initial 1993 publication, none of which significantly affects this specification. A fifth amendment, now under consideration, will introduce incompatible changes to the standard: 6556 Korean Hangul syllables allocated between code positions 3400 and 4DFF (hexadecimal) will be moved to new positions (and 4516 new syllables added), thus making references to the old positions invalid. Since the Unicode consortium has already adopted a corresponding amendment for inclusion in the forthcoming Unicode 2.0, adoption of DAM 5 is considered likely and implementers should probably consider the old code positions as already invalid. Despite this one-time change, the relevant standard bodies have committed themselves not to change any allocated code position in the future. To encode Korean Hangul irrespective of these changes, the conjoining Hangul Jamo in the range 1110-11F9 can be used.

備考: 実装者は、 ISO 10646 が時々刻々と改正されていることに注意するべきです。 1993年の最初の出版から4つの追補が採用されましたが、 いずれもこの仕様書的には重大ではありません。現在検討中の5つ目の追補は、 規格に非互換な変更を行う予定です。6556個の韓国のハングル音節が符号位置 34004DFF に割当てられていますが、 これが新しい位置に移動し、 (4516 個新しい音節が追加され、) 古い位置への参照が無効となります。 Unicode consortium は既に相当する改正を近日発行の Unicode 2.0 に取込んでいますから、 DAM 5 も同様に採用されるでしょうし、 実装者はおそらく既に古い符号位置は不当と考えるべきでしょう。 関係する標準化団体は、今回の一度だけの変更は別として、 将来は割当て済みの符号位置を変更しないことに合意しています。 韓国のハングルを変更に影響なく符号化するためには、 範囲 111011F9 の組合せハングル字母を使うことができます。

訳注: 後日、元のハングル音節にはまったく別の漢字が割当てられ、 古い文書はひどく文字化けするようになりました。 また、今後割当てを変更しないという約束も反古にされました。

ちなみに、代わりに使えば良いと書いてある組合せ用ハングル字母は、 現在でも UCS での実装は数えるほどしかなく、 RFC 2070 の当時は誰が使うのかと思われていたような代物です。

The adoption of this document character set implies a change in the SGML declaration specified in the HTML 2.0 specification (section 9.5 of [RFC1866]). The change amounts to removing the first BASESET specification and its accompanying DESCSET declaration, replacing them with the following declaration:

この文書文字集合の採用は、 HTML 2.0 仕様書で規定された SGML 宣言を変更することを意味しています。 変更は最初の BASESET 指定と付随する DESCSET 宣言を削除し、 次の宣言に置換えます。

     BASESET "ISO Registration Number 177//CHARSET
              ISO/IEC 10646-1:1993 UCS-4 with implementation level 3
              //ESC 2/5 2/15 4/6"
     DESCSET  0   9     UNUSED
              9   2     9
              11  2     UNUSED
              13  1     13
              14  18    UNUSED
              32  95    32
              127 1     UNUSED
              128 32    UNUSED
              160 2147483486 160

訳注: 実はこの改訂版 SGML 宣言は規格参照量集合の制限を超えていて SGML 不適合であることが後に分かっています。 SGML 宣言で8桁を超える数を記述することはできません。

Making the UCS the document character set does not create non-conformance of any expression, construct or document that is conforming to HTML 2.0. It does make conforming certain constructs that are not admissible in HTML 2.0. One consequence is that data characters outside the repertoire of ISO-8859-1, but within that of UCS-4 become valid SGML characters. Another is that the upper limit of the range of numeric character references is extended from 255 to 2147483645; thus, И is a valid reference to a "CYRILLIC CAPITAL LETTER I". [ERCS] is a good source of information on Unicode and SGML, although its scope and technical content differ greatly from this specification.

UCS を文書文字集合としましても、 HTML 2.0 に適合する表現や構造や文書が不適合となることはありません。 HTML 2.0 で認められなかったある種の項像が適合するようにはなります。 一つの結果として、 ISO-8859-1 のレパートリ外であって UCS-4 のレパートリ内である文字が妥当な SGML 文字となります。 他に、数値文字参照の上限が 255 から 2147483645 に引き上げられます。 従って、 ИCYRILLIC CAPITAL LETTER I への妥当な参照です。 ERCS はこの仕様書とは適用範囲と技術的内容が大きく異なりますが、 Unicode と SGML に関する良い情報源です。

NOTE -- the above SGML declaration, like that of HTML 2.0, specifies the character numbers 128 to 159 (80 to 9F hex) as UNUSED. This means that numeric character references within that range (e.g. ’) are illegal in HTML. Neither ISO 8859-1 nor ISO 10646 contain characters in that range, which is reserved for control characters.

備考: 前述の SGML 宣言は、 HTML 2.0 のものと同じく、 文字番号 128159 (16進数で 809F) を UNUSED としています。これは、 この範囲の数値文字参照 (例えば &#146:) が HTML では違法であることを意味します。 ISO 8859-1 も ISO 10646 もこの範囲には文字を含んでおらず、 制御文字に予約されています。

Another change was made from the HTML 2.0 SGML declaration, in the belief that the latter did not express its authors' true intent. The syntax character set declaration was changed from ISO 646.IRV:1983 to the newer ISO 646.IRV:1991, the latter, but not the former, being identical with US-ASCII. In principle, this introduces an incompatibility with HTML 2.0, but in practice it should increase interoperability by i) having the SGML declaration say what everyone thinks and ii) making the syntax character set a proper subset of the document character set. The characters that differ between the two versions of ISO 646.IRV are not actually used to express HTML syntax.

HTML 2.0 SGML 宣言に他にも変更が行われました。 これは著者の本来の意図を正しく表現していなかったことによるものです。 構文文字集合宣言は ISO 646.IRV:1983 から新しい ISO 646.IRV:1991 に変更しました。後者は US-ASCII と等しいですが、前者はそうではありません。 基本的にこれは HTML 2.0 と非互換になりますが、 実際上は i) SGML 宣言を誰もが考えていることを表すようにし、 ii) 構文文字集合を文書文字集合の適切な部分集合とすることから、 相互運用性を増すはずです。 ISO 646.IRV の2つの版の違う部分は実際には HTML 構文を表現するために使っていません。

ISO 10646-1:1993 is the most encompassing character set currently existing, and there is no other character set that could take its place as the document character set for HTML. If nevertheless for a specific application there is a need to use characters outside this standard, this should be done by avoiding any conflicts with present or future versions of ISO 10646, i.e. by assigning these characters to a private zone of the UCS-4 coding space [ISO-10646 section 11]. Also, it should be borne in mind that such a use will be highly unportable; in many cases, it may be better to use inline bitmaps.

ISO 10646-1:1993 は現在存在するもっとも大きな文字集合で、 HTML の文書文字集合とすることのできる文字集合は他にありません。 それでもこの規格の外の文字を使う必要がある特定分野では、 現在と将来の版の ISO 10646 との衝突を避けることで、 つまり UCS-4 符号領域の私用域にその文字を割当てることで行うべきです。 また、そうして使用することは非常に非過般であることを念頭に置くようにするべきです。 多くの場合には、行内ビット写像を使用する方がましかもしれません。

訳注: その UCS の私用面・私用群は数年後に削除されてしまいました。 使っていた人達には随分な仕打ちです。やはり行内画像の方がましでありました。

2.3. Undisplayable characters

With the document character set being the full ISO 10646, the possibility that a character cannot be displayed due to lack of appropriate resources (fonts) cannot be avoided. Because there are many different things that can be done in such a case, this document does not prescribe any specific behaviour. Depending on the implementation, this may also be handled by the underlaying display system and not the application itself. The following considerations, however, may be of help:

完全な ISO 10646 が文書文字集合でありますから、 適当な資源 (フォント) が無いために文字を表示できない可能性というものは避けることができません。 そうした場合に行うことのできることは色々ありますから、 この文書は特定の振舞いを規定することはしません。 実装によって使用している表示システムも処理して鷹揚自体は処理しないかもしれません。 しかし、次の考慮が補助となるかもしれません。

  • A clearly visible, but unobtrusive behaviour should be preferred. Some documents may contain many characters that cannot be rendered, and so showing an alert for each of them is not the right thing to do.
  • In case a numeric representation of the missing character is given, its hexadecimal (not decimal) form is to be preferred, because this form is used in character set standards [ERCS].
  • 明らかに可視ながらもうざくない振舞いを優先するべきです。 文書によってはレンダリングできない文字を沢山含んでいるかもしれませんから、 そのそれぞれに警告を出すのはするべきこととはいえません。
  • 欠けたる文字の数値表現を与える場合には、 (10進ではなく) 16進数を優先するべきです。16進数表現が文字集合規格では使われています。

3. The LANG attribute

Language tags can be used to control rendering of a marked up document in various ways: glyph disambiguation, in cases where the character encoding is not sufficient to resolve to a specific glyph; quotation marks; hyphenation; ligatures; spacing; voice synthesis; etc. Independently of rendering issues, language markup is useful as content markup for purposes such as classification and searching.

言語札は種々の方法でマーク付けされた文書のレンダリングを制御するために使うことができます。 グリフの決定を文字符号化が特定のグリフに解決するのに十分でない場合に行ったり、 引用符を決定したり、ハイフン付けを行ったり、 合字化したり、間隔付けしたり、音声合成に使ったり、その他色々な用途があります。 レンダリングの問題は別にしても、言語マークは分類や検索のような目的のための内容マークとしても有用です。

Since any text can logically be assigned a language, almost all HTML elements admit the LANG attribute. The DTD reflects this; the only elements in this version of HTML without the LANG attribute are BR, HR, BASE, NEXTID, and META. It is also intended that any new element introduced in later versions of HTML will admit the LANG attribute, unless there is a good reason not to do so.

論理的にはすべての文章に言語を割振ることができますから、 ほとんどすべての HTML 要素が lang 属性を使えます。 DTD はこれを反映しています。 この版の HTML で lang 属性がないのは、 br, hr, base, nextid, meta だけです。 今後の版の HTML で新たに導入する要素は、 lang 属性が要らないという理由が特になければ、 lang 属性を認めるつもりです。

The language attribute, LANG, takes as its value a language tag that identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded.

言語属性 lang は、その値として人間が他の人間と意思疎通するために話したり書いたりその他伝達される自然言語を識別する言語札を値として取ります。 計算機言語は陽に除外します。

The syntax and registry of HTML language tags is the same as that defined by RFC 1766 [RFC1766]. In summary, a language tag is composed of one or more parts: A primary language tag and a possibly empty series of subtags:

HTML 言語札の構文と登録簿は RFC 1766 で定義されたものと同じとします。要約すると、言語札は一つ以上の部分 (第一言語札と零個以上の亜札の系列) から構成します。

  • language-tag = primary-tag *( "-" subtag )
  • primary-tag = 1*8ALPHA
  • subtag = 1*8ALPHA

Whitespace is not allowed within the tag and all tags are case-insensitive. The namespace of language tags is administered by the IANA. Example tags include:

札の内側に空白は認めず、すべての札は大文字・小文字を区別しません。 言語札の名前空間は IANA が管理します。 例:

       en, en-US, en-cockney, i-cherokee, x-pig-latin

In the context of HTML, a language tag is not to be interpreted as a single token, as per RFC 1766, but as a hierarchy. For example, a user agent that adjusts rendering according to language should consider that it has a match when a language tag in a style sheet entry matches the initial portion of the language tag of an element. An exact match should be preferred. This interpretation allows an element marked up as, for instance, "en-US" to trigger styles corresponding to, in order of preference, US-English ("en-US") or 'plain' or 'international' English ("en").

HTML の文脈では、言語札は RFC 1766 の通り1つの字句として解釈するのではなく、 階層的に解釈します。例えば、言語に従ってレンダリングする利用者エージェントは、 スタイル・シート中の言語札項目が要素の言語札の最初の部分に一致した時には言語札が一致したと考えるべきです。 全体の一致は優先するべきです。この解釈によって、 要素を例えば en-US とマーク付けして、 優先度によって米語 (en-US) と普通のあるいは 国際的な英語 (en) とスタイルを切替ることができ ます。

NOTE -- using the language tag as a hierarchy does not imply that all languages with a common prefix will be understood by those fluent in one or more of those languages; it simply allows the user to request this commonality when it is true for that user.

備考: 言語札を階層的に使っても、 同じ接尾辞のすべての言語がそのうちの一つ以上に堪能な人が理解できるとは限りません。 そのような共通性がその利用者にとって真である時にこの共通性を利用者に要求することが認められるというただそれだけです。

The rendering of elements may be affected by the LANG attribute. For any element, the value of the LANG attribute overrides the value specified by the LANG attribute of any enclosing element and the value (if any) of the HTTP Content-Language header. If none of these are set, a suitable default, perhaps controlled by user preferences, by automatic context analysis or by the user's locale, should be used to control rendering.

要素のレンダリングに lang 属性が影響しても構いません。 どの要素でも、 lang 属性の値はその要素を囲む要素の lang 属性で指定された値と (あれば) HTTP Content-Language 頭で指定された値を上書きします。 いずれも設定されていなければ、適当な既定値、 おそらくは利用者が設定したものか自動文脈調査によるものか、 利用者のロケールによるものをレンダリングの制御に使うべきです。

4. Additional entities, attributes and elements

4.1. Full Latin-1 entity set

According to the suggestion of section 14 of [RFC1866], the set of Latin-1 entities is extended to cover the whole right part of ISO-8859-1 (all code positions with the high-order bit set), including the already commonly used  , © and ®. The names of the entities are taken from the appendices of SGML [ISO-8879]. A list is provided in section 7.3 of this specification.

RFC 1866 の14章の提案の通り、 Latin-1 実体を拡張して、 既に広く用いられている  , ©, ® を含めて ISO-8859-1 の右半分全体 (高次ビット集合のすべての符号位置) を覆うようにします。 実体の名前は SGML の附属書から取りました。 一覧はこの仕様書の7.3節にあります。

4.2. Markup for language-dependent presentation

4.2.1. Overview

For the correct presentation of text in certain languages (irrespective of formatting issues), some support in the form of additional entities and elements is needed.

ある言語の文章の正しい表示のため (書式付けの問題とは関係なく)、追加の実体と要素の形で幾分の対応が必要です。

In particular, the following features are dealt with:


  • Markup of bidirectional text, i.e. text where left-to-right and right-to-left scripts are mixed.
  • Control of cursive joining behaviour in contexts where the default behaviour is not appropriate.
  • Language-dependent rendering of short (in-line) quotations.
  • Better justification control for languages where this is important.
  • Superscripts and subscripts for languages where they appear as part of general text.
  • 双方向文章 (左から右への用字と右から左への用字が混ざった文章) のマーク。
  • 既定の振舞いが不適切な文脈での連綿連結の制御。
  • 短い (行内) 引用の言語依存のレンダリング。
  • 文字揃えが重要な言語でのより良い揃え制御。
  • 普通の文章の一部として上付き・下付きが出現する言語のための上付き・下付き。

Some of the above features need very little additional support; others need more. The additional features are introduced below with brief comments only. Explanations on cursive joining behaviour and bidirectional text follow later. For cursive joining behaviour and bidirectional text, this document follows [UNICODE] in that: i) character semantics, where applicable, are identical to [UNICODE], and ii) where functionality is moved to HTML as a higher level protocol, this is done in a way that allows straightforward conversion to the lower-level mechanisms defined in [UNICODE].

前記の機能の幾つかは非常にわずかな追加の支援だけが必要で、 他のものはもっと必要です。追加の機能は次に短い注釈と共に紹介します。 連綿連結動作と双方向文の説明は後に続けます。 連綿連結動作と双方向文については、この文書は Unicode 規格に従い、 i) 文字の意味は適用可能であれば Unicode と同じであり、 ii) 機能が HTML に高水準プロトコルとして移動したところでは、 Unicode で定義された低水準機構に直接変換して行うことができます。

4.2.2. List of entities, elements, and attributes

First, a generic container is needed to carry the LANG and DIR (see below) attributes in cases where no other element is appropriate; the SPAN element is introduced for that purpose.

最初に、他の要素が適切でない場合に lang 属性と dir 属性を伝達する一般包含子が必要です。 span 要素をこの目的で導入します。

A set of named character entities is added for use with bidirectional rendering and cursive joining control:


<!ENTITY zwnj CDATA "&#8204;"--=zero width non-joiner-->
<!ENTITY zwj  CDATA "&#8205;"--=zero width joiner-->
<!ENTITY lrm  CDATA "&#8206;"--=left-to-right mark-->
<!ENTITY rlm  CDATA "&#8207;"--=right-to-left mark-->

These entities can be used in place of the corresponding formatting characters whenever convenient, for example to ease keyboard entry or when a formatting character is not available in the character encoding of the document.

これらの実体は対応する書式付け文字の場所で、 有用な時、例えば鍵盤の入力を簡単にするためや書式付け文字が文書の文字符号化で利用可能でない時にはいつでも使うことができます。

Next, an attribute called DIR is introduced, restricted to the values LTR (left-to-right) and RTL (right-to-left), for the indication of directionality in the context of bidirectional text (see 4.2.4 below for details). Since any text and many other elements (e.g. tables) can logically be assigned a directionality, all elements except BR, HR, BASE, NEXTID, and META admit this attribute. The DTD reflects this. It is also intended that any new element introduced in later versions of HTML will admit the DIR attribute, unless there is a good reason not to do so.

次に、 dir という属性を導入します。 値は ltr (左から右) と rtl (右から左) で、双方向文の文脈で方向を指示します。 論理的に任意の文章や多くの他の要素 (例えば表) が方向性を割当てることができますから、 br, hr, base, nextid, meta を除くすべての要素がこの属性を認めます。 DTD はこれを反映しています。今後の版の HTML で新しい要素が導入される時には dir 属性を特にそうしない理由がない限り認めるつもりです。

A new phrase-level element called BDO (BIDI Override) is introduced, which requires the DIR attribute to specify whether the override is left-to-right or right-to-left. This element is required for bidirectional text control; for detailed explanations, see section 4.2.4.

新しい bdo (BIDI 上書き) という語句水準要素を導入します。 この要素は上書きが左から右か右から左かを指定する dir 属性を必須とします。この要素は双方向文制御のため必要です。 詳細な説明は4.2.4節を見て下さい。

The phrase-level element Q is introduced to allow language-dependent rendering of short quotations depending on language and platform capability. As the following examples show (rather poorly, because of the character set restriction of Internet specifications), the quotation marks surrounding the quotation are particularly affected: "a quotation in English", `another, slightly better one', ,,a quotation in German”, << a quotation in French >>. The contents of the Q element does not include quotation marks, which have to be added by the rendering process.

語句水準要素 q を言語依存な短い引用を言語と環境の能力によってレンダリングできるように導入します。 次の例が示す (のはインターネット仕様書の文字集合の制限で貧しい表現ではありますが。) ように、引用を囲む引用符は特に影響があります。例えば "a quotation in English", `another, slightly better one', ,,a quotation in German”, << フランス語の引用 >> のようにです。 q 要素の内容は引用符を含まず、 引用符はレンダリング処理で追加しなければなりません。

NOTE -- Q elements can be nested. Many languages use different quotation styles for outer and inner quotations, and this should be respected by user-agents implementing this element.

備考: q 要素は入れ子にできます。 多くの言語は外側と内側の引用で異なる引用様式を用いますから、 この要素を実装する利用者エージェントもこれを尊重するべきです。

NOTE -- minimal support for the Q element is to surround the contents with some kind of quotes, like the plain ASCII double quotes. As this is rather easy to implement, and as the lack of any visible quotes may affect the perceived meaning of the text, user-agent implementors are strongly requested to provide at least this minimal level of support.

備考: q 要素の最低限の対応は内容を普通の ASCII の二重引用符など何らかの引用符で囲むというものです。 これは簡単に実装できますし、可視引用符がないと文章の意味の理解に影響するかもしれませんから、 利用者エージェントの実装社には最低でもこの程度の対応を行うよう強く要求します。

Many languages require superscript text for proper rendering: as an example, the French "Mlle Dupont" should have "lle" in superscript. The SUP element, and its sibling SUB for subscript text, are introduced to allow proper markup of such text. SUP and SUB contents are restricted to PCDATA to avoid nesting problems.

多くの言語は適切なレンダリングのために上付き文を必要としています。 例えば、フランス語の Mlle Dupontlle が上付きになっているべきです。 sup 要素と兄弟で下付きの sub 要素は、このような文章を適切にマークすることができるように導入します。 supsub の内容は入れ子の問題を避けるために PCDATA に制限します。

Finally, in many languages text justification is much more important than it is in Western languages, and justifies markup. The ALIGN attribute, admitting values of LEFT, RIGHT, CENTER and JUSTIFY, is added to a selection of elements where it makes sense (the block-like P, HR, H1 to H6, OL, UL, DIR, MENU, LI, BLOCKQUOTE and ADDRESS). If a user-agent chooses to have LEFT as a default for blocks of left-to-right directionality, it should use RIGHT for blocks of right-to-left directionality.

最後に、多くの言語では西洋言語より文字揃えがずっと重要であり、 マークを揃えます。 align 属性を、 値として left, right, center, justify を認めて、これが意味を持つ要素 (ブロック状の p, hr, h1h6, ol, ul, dir, menu, li, blockquote, address) を選んで追加します。 利用者エージェントが左から右の方向のブロックに left を既定値として選ぶなら、右から左の方向のブロックには right を既定値として使うべきです。

NOTE -- RFC 1866 section 4.2.2 specifies that an HTML user agent should treat an end of line as a word space, except in preformatted text. This should be interpreted in the context of the script being processed, as the way words are separated in writing is script-dependent. For some scripts (e.g. Latin), a word space is just a space, but in other scripts (e.g. Thai) it is a zero-width word separator, whereas in yet other scripts (e.g. Japanese) it is nothing at all, i.e. totally ignored.

備考: RFC 1866 4.2.2 節は HTML 利用者エージェントが行末を整形済み文以外では語間隔として扱うように既定しています。 これは、筆記時に語を分離する方法は用字系依存ですから、 処理している用字系の文脈で解釈するべきです。幾つかの用字系 (例えば Latin) では語間隔は単なる間隔ですが、他の用字系 (例えばタイ文字) では零幅語分離子ですし、また他の用字系 (例えば日本語文字) では何もなし、つまり完全に無視です。

NOTE -- the SOFT HYPHEN character (U+00AD) needs special attention from user-agent implementers. It is present in many character sets (including the whole ISO 8859 series and, of course, ISO 10646), and can always be included by means of the reference &shy;. Its semantics are different from the plain HYPHEN: it indicates a point in a word where a line break is allowed. If the line is indeed broken there, a hyphen must be displayed at the end of the first line. If not, the character is not dispalyed at all. In operations like searching and sorting, it must always be ignored.

備考: SOFT HYPHEN 文字 (U+00AD) はり容赦エージェント実装者の特別な注意を必要とします。 この文字は多くの文字集合 (すべての ISO 8859 系列と、もちろん ISO 10646 を含みます。) に存在しますし、常に参照 &shy; として含めることができます。この意味は単なる HYPHEN とは異なります。 SOFT HYPHEN は語の中で改行が認められる位置を示します。 行がそこで割られる時には、最初の行の終わりにハイフンを表示しなければなりません。 そうでない時には、この文字はまったく表示されません。 検索や並替えのような処理では、常に無視しなければなりません。

In the DTD, the LANG and DIR attributes are grouped together in a parameter entity called attrs. To parallel RFC 1942 [RFC1942], the ID and CLASS attributes are also included in attrs. The ID and CLASS attributes are required for use with style sheets, and RFC 1942 defines them as follows:

DTD では、 lang 属性と dir 属性は attrs という引数実体に一緒にまとめています。 RFC 1942 と並行して、 attrs には id 属性と class 属性も含めています。 id 属性と class 属性はスタイル・シートと使用するために必要で、 RFC 1942 は次のように定義しています。

Used to define a document-wide identifier. This can be used for naming positions within documents as the destination of a hypertext link. It may also be used by style sheets for rendering an element in a unique style. An ID attribute value is an SGML NAME token. NAME tokens are formed by an initial letter followed by letters, digits, "-" and "." characters. The letters are restricted to A-Z and a-z.

文書内識別子を定義するために使います。 この識別子はハイパーテキスト・リンクの終点として文書中の位置に名前を付けるために使うことができます。 この識別子は要素を固有の様式でレンダリングするためにスタイル・シートで使うこともできます。 id 属性値は SGML の NAME 字句です。 NAME 字句は最初に文字 (letter) が来て、 その後に文字 (letter) 、数字、 -. の文字が続きます。文字 (letter) A-Za-z に制限されます。

A space separated list of SGML NAME tokens. CLASS names specify that the element belongs to the corresponding named classes. It allows authors to distinguish different roles played by the same tag. The classes may be used by style sheets to provide different renderings as appropriate to these roles.

SGML の NAME 字句の間隔分離の並びです。 class 名は対応する名前付き級に所属する要素を指定します。 class 名は著者が同じタグの異なる役割を区別するために使うことができます。 級はスタイル・シートで役割に応じた異なるレンダリングを行うために使っても構いません。

4.2.3. Cursive joining behaviour

Markup is needed in some cases to force cursive joining behavior in contexts in which it would not normally occur, or to block it when it would normally occur.

マークは場合によっては連綿連結動作が通常起こらない場所でこれを強制したり、 通常起こる場所でこれを妨害したりする必要があります。

The zero-width joiner and non-joiner (&zwj; and &zwnj;) are used to control cursive joining behaviour. For example, ARABIC LETTER HEH is used in isolation to abbreviate "Hijri" (the Islamic calendrical system); however, the initial form of the letter is desired, because the isolated form of HEH looks like the digit five as employed in Arabic script. This is obtained by following the HEH with a zero-width joiner whose only effect is to provide context. In Persian texts, there are cases where a letter that normally would join a subsequent letter in a cursive connection does not. Here a zero-width non-joiner is used.

零幅連結子と零幅非連結子 (&zwj;&zwnj;) は連綿連結動作を制御するために使います。例えば、 ARABIC LETTER HEHHijri (イスラム暦) を略して中立形で使われます。しかし、中立形の HEH はアラビア文字の数字の5と似ているので、 語頭形の方が望ましいのです。これは HEH に文脈を提供する効果だけがある零幅連結子を続けることで得られます。 ペルシャ語の文章では、通常なら後の文字と連綿で連結する文字をそうしない場合があります。 ここでは零幅非連結子を使います。

4.2.4. Bidirectional text

Many languages are written in horizontal lines from left to right, while others are written from right to left. When both writing directions are present, one talks of bidirectional text (BIDI for short). BIDI text requires markup in special circumstances where ambiguities as to the directionality of some characters have to be resolved. This markup affects the ability to render BIDI text in a semantically legible fashion. That is, without this special BIDI markup, cases arise which would prevent *any* rendering whatsoever that reflected the basic meaning of the text. Plain text may contain BIDI markup in the form of special-purpose formatting characters.

多くの言語は水平の行に左から右に書きますが、他には右から左に書くものもあります。 両方の書字方向が存在する時に、これを双方向文 (略して BIDI) と言います。 BIDI 文は特別な場合に文字の方向性を解決して曖昧性をなくするマークが必要です。 このマークは意味的に判読可能な様式の BIDI 文をレンダリングする能力に影響します。 つまり、特別な BIDI マークがなければ、 文章の基本的な意味を反映したレンダリングができないような場合があります。 平文は特殊目的書式付け文字の形で BIDI マークを含むことができます。

This is also possible in HTML, which includes the five BIDI-related formatting characters (202A - 202E) of ISO 10646. As an alternative, HTML provides equivalent SGML markup.

これは HTML でも可能で、 ISO 10646 の5つの BIDI 関連書式付け文字を含みます。 代替として、 HTML は等価な SGML マークを提供します。

BIDI is a complex issue, and conversion of logical text sequences to display sequences has to be done according to the algorithm and character properties specified in [UNICODE]. Here, explanations are given only as far as they are needed to understand the necessity of the features introduced and to define their exact semantics.

BIDI は複雑な問題であり、論理的な文章の順番から表示する順番への変換は Unicode で規定されいる算法と文字特性に従って行わなければなりません。 ここでは、説明は導入した機能が必要であることを理解するためと正確な意味を定義するために必要な程度にのみ行います。

The Unicode BIDI algorithm is based on the individual characters of a text being stored in logical order, that is the order in which they are normally input and in which the corresponding sounds are normally spoken. To make rendering of logical order text possible, the algorithm assigns a directionality property to each character, e.g. Latin letters are specified to have a left-to-right direction, Arabic and Hebrew characters have a right-to-left direction.

Unicode BIDI 算法は文章の個々の文字が論理順、 つまり通常入力が行われ、対応する音声が通常話される順序で蓄積されていると考えます。 論理順の文章のレンダリングを可能にするために、 この算法は各文字に方向性特性を割当てています。例えば Latin 文字は左から右の方向を持つと規定されており、アラビア文字とヘブライ文字は右から左の方向を持ちます。

The left-to-right and right-to-left marks (&lrm; and &rlm;) are used to disambiguate directionality of neutral characters. For example, when a double quote sits between an Arabic and a Latin letter, its direction is ambiguous; if a directional mark is added on one side such that the quotation mark is surrounded by characters of only one directionality, the ambiguity is removed. These characters are like zero width spaces which have a directional property (but no word/line break property).

左から右記号と右から左記号 (&lrm;&rlm;) は中立文字の方向性の曖昧性の解消に使います。例えば、 二重引用符がアラビア文字と Latin 文字の間にある時、 引用符の方向は曖昧です。方向性マークを片側に加えれば、 引用符が1つの方向性だけに囲まれることになるので、 曖昧性は除去されます。2つの幅は方向性特性を持つ (ものの語・行改特性は持たない) 零幅間隔のようなものです。

Nested embeddings of contra-directional text runs, due to nested quotations or to the pasting of text from one BIDI context to another, is also a case where the implicit directionality of characters is not sufficient, requiring markup. Also, it is frequently desirable to specify the basic directionality of a block of text. For these purposes, the DIR attribute is used.

逆方向文の入れ子の埋込みが入れ子の引用やある BIDI 文脈から他の文脈への文章の貼付けのために起こる場合も、 暗示的な文字の方向性は不十分であり、マークが必要です。 また、文章のブロックの基本方向性を指定するのが望ましいことも良くあります。 これらの目的で、 dir 属性を使います。

On block-type elements, the DIR attribute indicates the base directionality of the text in the block; if omitted it is inherited from the parent element. The default directionality of the overall HTML document is left-to-right.

ブロック型要素では、 dir 属性はブロック内の文章の基底方向性を示します。 省略されていれば親要素から継承します。 HTML 文書全体の既定方向性は左から右とします。

On inline elements, it makes the element start a new embedding level (to be explained below); if omitted the inline element does not start a new embedding level.

行内要素では、要素が新しい埋込み水準 (後述) を開始します。 省略されていれば行内要素は新しい埋込み水準を開始しません。

NOTE -- the PRE, XMP and LISTING elements admit the DIR attribute. Their contents should not be considered as preformatted with respect to bidirectional layout, but the BIDI algorithm should be applied to each line of text.

備考: pre 要素, xmp 要素, listing 要素も dir 属性を認めています。 これらの内容は双方向性配置に関しては整形済みとは考えるべきではなく、 BIDI 算法を各行毎に適用するべきです。

Following is an example of a case where embedding is needed, showing its effect:


Given the following latin (upper case) and arabic (lower case) letters in backing store with the specified embeddings:

次の Latin 文字 (大文字) とアラビア文字 (小文字) が指定された埋込みで蓄積されているとします。

      </SPAN> EF </SPAN>

One gets the following rendering (with [] showing the directional transitions):

次のレンダリングが得られます ([] は方向転換を示します)。

      [ AB [ wz [ CD ] yx ] EF ]

On the other hand, without this markup and with a base direction of LTR one gets the following rendering:

ところで、このマークがなく、基底方向性が ltr であれば、次のレンダリングが得られます。

      [ AB [ yx ] CD [ wz ] EF ]

Notice that yx is on the left and wz on the right unlike the above case where the embedding levels are used. Without the embedding markup one has at most two levels: a base directional level and a single counterflow directional level.

埋込み水準を使った前例とは異なり yx が左で wz が右であることに注意して下さい。埋込みマークがなければ、 基底方向水準と単一の逆流方向水準の高々2つの水準を持ちます。

The DIR attribute on inline elements is equivalent to the formatting characters LEFT-TO-RIGHT EMBEDDING (202A) and RIGHT-TO-LEFT EMBEDDING (202B) of ISO 10646. The end tag of the element is equivalent to the POP DIRECTIONAL FORMATTING (202C) character.

行内要素の dir 属性は ISO 10646 の書式付け文字 LEFT-TO-RIGHT EMBEDDING (202A) と RIGHT-TO-LEFT EMBEDDING (202B) と等価です。要素の終了タグは POP DIRECTIONAL FORMATTING (202C) 文字と等価です。

Directional override, as provided by the BDO element, is needed to deal with unusual short pieces of text in which directionality cannot be resolved from context in an unambiguous fashion. For example, it can be used to force left-to-right (or right-to-left) display of part numbers composed of Latin letters, digits and Hebrew letters.

bdo 要素が提供する方向性の上書きは、 普通ではない短い文章片で方向性が文脈から曖昧なく解決できない場合の対処として必要です。 例えば、 Latin 文字、数字とヘブライ文字を組合せて部番号を強制的に左から右へ (または右から左へ) 表示するために使うことができます。

The effect of BDO is to force the directionality of all characters within it to the value of DIR, irrespective of their intrinsic directional properties. It is equivalent to using the LEFT-TO-RIGHT OVERRIDE (202D) or RIGHT-TO-LEFT OVERRIDE (202E) characters of ISO 10646, the end tag again being equivalent to the POP DIRECTIONAL FORMATTING (202C) character.

bdo の効果はその中のすべての文字の方向性を内在方向性特性とは無関係に強制的に dir の値に変えてしまうことです。 bdo の効果は ISO 10646 の文字 LEFT-TO-RIGHT OVERRIDE (202D) や RIGHT-TO-LEFT OVERRIDE (202E) と等価で、終了タグはやはり POP DIRECTIONAL FORMATTING (202C) と等価です。

NOTE -- authors and authoring software writers should be aware that conflicts can arise if the DIR attribute is used on inline elements (including BDO) concurrently with the use of the corresponding ISO 10646 formatting characters.

備考: 著者と著述ソフトウェア筆者は、 行内要素 (bdo を含みます。) で dir 属性を対応する ISO 10646 の書式付け文字と並行して使うと衝突が起こることに注意するべきです。

Preferably one or the other should be used exclusively; the markup method is better able to guarantee document structural integrity, and alleviates some problems when editing bidirectional HTML text with a simple text editor, but some software may be more apt at using the 10646 characters. If both methods are used, great care should be exercised to insure proper nesting of markup and directional embedding or override; otherwise, rendering results are undefined.

どちらか一つだけを排他的に使用するべきです。 マーク方式の方が文書の構造との統合性をよく保証できますし、 双方向 HTML 文を単純文章編集器で編集する時の問題を軽減できますが、 ソフトウェアによっては 10646 文字を使った方がやりやすいかもしれません。 両方の方法を使う場合は、マークと方向性埋込み・上書きが適当に入れ子になるように十分気を付けるべきです。 そうしなければ、レンダリング結果は未定義です。

5. Forms

5.1. DTD additions

It is natural to expect input in any language in forms, as they provide one of the only ways of obtaining user input. While this is primarily a UI issue, there are some things that should be specified at the HTML level to guide behavior and promote interoperability.

フォームは利用者の入力を得るわずかな方法の1つですから、 どの言語でもフォームに入力されるのを期待するのが自然です。 これは主として UI の問題ではありますが、 振舞いを手引きして相互運用性を促進するために HTML の水準で規定するべきことも幾つかあります。

To ensure full interoperability, it is necessary for the user agent (and the user) to have an indication of the character encoding(s) that the server providing a form will be able to handle upon submission of the filled-in form. Such an indication is provided by the ACCEPT-CHARSET attribute of the INPUT and TEXTAREA elements, modeled on the HTTP Accept-Charset header (see [HTTP-1.1]), which contains a space and/or comma delimited list of character sets acceptable to the server. A user agent may want to somehow advise the user of the contents of this attribute, or to restrict his possibility to enter characters outside the repertoires of the listed character sets.

完全な相互運用性を確保するため、利用者エージェント (と利用者) は、フォームを提供する鯖が記入フォームの提出に際して取扱うことのできる文字符号化(群)を示されている必要があります。 この標示は、 input 要素と ODE(HTMLe)[textarea]] 要素の accept-charset 属性で行います。 この属性は HTTP の Accept-Charset 頭を参考にしておりまして、鯖が受入れる文字集合を間隔及び/又は読点で区切った並びを含みます。 利用者エージェントはこの属性の内容を利用者に何らかの形で助言するのも良いでしょうし、 列挙された文字集合のレパートリ外の文字を入力できないように制限するのも良いでしょう。

NOTE -- The list of character sets is to be interpreted as an EXCLUSIVE-OR list; the server announces that it is ready to accept any ONE of these character encoding schemes for each part of a multipart entity. The client may perform character encoding translation to satisfy the server if necessary.

備考: 文字集合の並びは、排他的論理和並びと解釈されます。 鯖は多部分実体の各部分の文字符号化方式としてどれか一つを受入れる準備ができていると告知しております。 クライアントは必要なら鯖を満足させるため文字符号化翻訳を行って構いません。

NOTE -- The default value for the ACCEPT-CHARSET attribute of an INPUT or TEXTAREA element is the reserved value "UNKNOWN". A user agent may interpret that value as the character encoding scheme that was used to transmit the document containing that element.

備考: input 要素および textarea 要素の accept-charset 属性の既定値は予約値 UNKNOWN です。利用者エージェントはこの値を、 その要素を含む文書が転送されるのに使われた文字符号化方式として解釈しても構いません。

5.2. Form submission

The HTML 2.0 form submission mechanism, based on the "application/x-www-form-urlencoded" media type, is ill-equipped with regard to internationalization. In fact, since URLs are restricted to ASCII characters, the mechanism is akward even for ISO-8859-1 text. Section 2.2 of [RFC1738] specifies that octets may be encoded using the "%HH" notation, but text submitted from a form is composed of characters, not octets. Lacking a specification of a character encoding scheme, the "%HH" notation has no well-defined meaning.

HTML 2.0 フォーム提出機構は application/x-www-form-urlencoded 媒体型に基づいておりますが、国際化に関しては力不足です。 実際には、 URL は ASCII 文字に制限されていますから、 この機構は ISO-8859-1 文に対しても酷いものです。 RFC 1738 の2.2節はオクテットを %HH 記法を使って符号化しても良いと規定していますが、 フォームから提出される文章は文字を構成したものであって、 オクテットではありません。文字符号化方式の規定がなければ、 %HH 記法はよく定義された意味を持ちません。

The best solution is to use the "multipart/form-data" media type described in [RFC1867] with the POST method of form submission. This mechanism encapsulates the value part of each name-value pair in a body-part of a multipart MIME body that is sent as the HTTP entity; each body part can be labeled with an appropriate Content-Type, including if necessary a charset parameter that specifies the character encoding scheme. The changes to the DTD necessary to support this method of form submission have been incorporated in the DTD included in this specification.

最善の策は、 RFC 1867 で説明されている multipart/form-data 媒体型をフォーム提出の POST method で使うことです。この仕組みはそれぞれの名前・値の組を値の部分を HTTP 実体として送られる MIME 多部分本体の本体部分にカプセル化します。 それぞれの本体部分は、必要なら文字符号化方式を指定する charset 引数を含めて適切な Content-Type で札付けできます。 この方式のフォーム提出に対応するために必要な DTD の変更はこの仕様書に含まれる DTD に取込んでいます。

A less satisfactory solution is to add a MIME charset parameter to the "application/x-www-form-urlencoded" media type specifier sent along with a POST method form submission, with the understanding that the URL encoding of [RFC1738] is applied on top of the specified character encoding, as a kind of implicit Content-Transfer-Encoding.

然程満足でもない解は、 RFC 1738 の URL 符号化は暗示的な Content-Transfer-Encoding の一種として特定の文字符号化の上に適用されるものとの理解で、 POST method フォーム提出で送られる application/x-www-form-urlencoded 媒体型指定子に MIME charset 引数を追加するというものです。

One problem with both solutions above is that current browsers do not generally allow for bookmarks to specify the POST method; this should be improved. Conversely, the GET method could be used with the form data transmitted in the body instead of in the URL. Nothing in the protocol seems to prevent it, but no implementations appear to exist at present.

これら両方の解決策の1つの問題は、現在のブラウザが栞に POST method を指定することを通常認めていないということです。 これは改善するべきです。逆に、 GET method で URL の中の代わりに本体を使ってフォーム・データを転送することもできるはずです。 プロトコル的には問題はないようですが、現時点で実装は存在しないようです。

How the user agent determines the encoding of the text entered by the user is outside the scope of this specification.


NOTE -- Designers of forms and their handling scripts should be aware of an important caveat: when the default value of a field (the VALUE attribute) is returned upon form submission (i.e. the user did not modify this value), it cannot be guaranteed to be transmitted as a sequence of octets identical to that in the source document -- only as a possibly different but valid encoding of the same sequence of text elements. This may be true even if the encoding of the document containing the form and that used for submission are the same.

備考: フォームとそれを扱うスクリプトの設計者には、 重大な警告があります。欄の既定値 (value 属性値) がフォーム提出で返される時 (つまりこの値を利用者が修正しなかった時)、 元の文書と同一のオクテット列が転送されることは保証できません。 文要素の同じ列の、異なるかもしれないものの妥当な符号化であることだけが保証されます。 これは、フォームを含む文書の符号化と提出に使う符号化が同じ時であっても真です。

Differences can occur when a sequence of characters can be represented by various sequences of octets, and also when a composite sequence (a base character plus one or more combining diacritics) can be represented by either a different but equivalent composite sequence or by a fully precomposed character. For instance, the UCS-2 sequence 00EA+0323 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT + COMBINING DOT BELOW) may be transformed into 1EC7 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT AND DOT BELOW), into 0065+0302+0323 (LATIN SMALL LETTER E + COMBINING CIRCUMFLEX ACCENT + COMBINING DOT BELOW), as well as into other equivalent composite sequences.

違いは一つの文字列が種々のオクテット列で表現可能な場合や合成列 (基底文字と一つ以上の結合発音区別符) が異なるものの等価な合成列で表現され得る場合や完全に合成済みの文字で表現され得る場合にも起こり得ます。 例えば、 UCS-200EA+0323 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT + COMBINING DOT BELOW) は 1EC7 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT AND DOT BELOW) や 0065+0302+0323 (LATIN SMALL LETTER E + COMBINING CIRCUMFLEX ACCENT + COMBINING DOT BELOW) や他の等価な合成列に変形できます。

6. External character encoding issues

Proper interpretation of a text document requires that the character encoding scheme be known. Current HTTP servers, however, do not generally include an appropriate charset parameter with the Content-Type header. This is bad behaviour, which is even encouraged by the continued existence of browsers that declare an unrecognized media type when they receive a charset parameter. User agent implementators are strongly encouraged to make their software tolerant of this parameter, even if they cannot take advantage of it. Proper labelling is highly desirable, but some preventive measures can be taken to minimize the detrimental effects of its absence:

文書の適切な解釈には文字符号化方式が既知であることが必要です。 しかし、現在の HTTP 鯖は、通常適切な charset 引数を Content-Type 頭に含めません。 これは悪い振舞いであり、 charset 引数を受け取った時に認識できない媒体型であるなどとのたまうブラウザが存在しつづけることを助長までしています。 利用者エージェント実装者は、ソフトウェアがたとえこの引数を優位に利用することができなくても頑強であるようにすることを強く推奨します。 適切な札付けは非常に望ましいですが、 たとえなくても有害な影響を最小限に抑えることができる予防策を講じることができます。

In the case where a document is accessed from a hyperlink in an origin HTML document, a CHARSET attribute is added to the attribute list of elements with link semantics (A and LINK), specifically by adding it to the linkExtraAttributes entity. The value of that attribute is to be considered a hint to the User Agent as to the character encoding scheme used by the resource pointed to by the hyperlink; it should be the appropriate value of the MIME charset parameter for that resource.

文書が起点 HTML 文書からのハイパーリンクで access される時には、リンク意味の要素 (alink) の属性並びに charset を (具体的には linkExtraAttributes 実体を通して) 追加します。この属性の値はハイパーリンクで示された資源に使われている文字符号化方式のヒントと利用者エージェントがみなします。 値はその資源の適切な MIME charset 値であるべきです。

In any document, it is possible to include an indication of the encoding scheme like the following, as early as possible within the HEAD of the document:

任意の文書で、文書の head 内のできるだけ速い場所で次のようにして符号化方式の標示を含めることができます。

<META HTTP-EQUIV="Content-Type"
 CONTENT="text/html; charset=ISO-2022-JP">

This is not foolproof, but will work if the encoding scheme is such that ASCII-valued octets stand for ASCII characters only at least until the META element is parsed. Note that there are better ways for a server to obtain character encoding information, instead of the unreliable META above; see [NICOL2] for some details and a proposal.

これは馬鹿でもできることではありませんが、 符号化方式が少なくても meta 要素が解析されるまでは ASCII 値のオクテットが ASCII 文字を表すようなものである時のみ機能します。 なお、このような当てにならない meta ではない、鯖が文字符号化情報を得るよりよい方法がありまして、 詳細と提案は [NICOL2] をご覧ください。

For definiteness, the "charset" parameter received from the source of the document should be considered the most authoritative, followed in order of preference by the contents of a META element such as the above, and finally the CHARSET parameter of the anchor that was followed (if any).

明確に、文書源から受信した charset 引数を最も決定的なものと考慮するべきであり、 それに続く優先順で前述の meta 要素の内容、最後に辿ったアンカーの charset 引数を (あれば) 使用するべきであります。

When HTML text is transmitted directly in UCS-2 or UCS-4 form, the question of byte order arises: does the high-order byte of each multi-byte character come first or last? For definiteness, this specification recommends that UCS-2 and UCS-4 be transmitted in big-endian byte order (high order byte first), which corresponds to the established network byte order for two- and four-byte quantities, to the ISO 10646 requirement and Unicode recommendation for serialized text data and to RFC 1641. Furthermore, to maximize chances of proper interpretation, it is recommended that documents transmitted as UCS-2 or UCS-4 always begin with a ZERO-WIDTH NON-BREAKING SPACE character (hexadecimal FEFF or 0000FEFF) which, when byte-reversed becomes number FFFE or FFFE0000, a character guaranteed to be never assigned. Thus, a user-agent receiving an FFFE as the first octets of a text would know that bytes have to be reversed for the remainder of the text.

HTML 文が直接 UCS-2 か UCS-4 の形式で転送される時は、 バイト順の問題がおきます。多バイト文字の高位バイトは最初に来るべきでしょうか、 最後に来るべきでしょうか。明確に、この仕様書は UCS-2 と UCS-4 を大エンディアン・バイト順 (高位バイトが先) で転送することを推奨します。 これは2バイト・4バイトの数についての確立されているネットワーク・バイト順や直列化文章データについての ISO 10646 の要件と Unicode の推奨、それに RFC 1641 に対応します。更に、適切な解釈の機会を最大化するために、 UCS-2 や UCS-4 で転送する文書は常に ZERO-WIDTH NON-BREAKING SPACE 文字 (16進で FEFF または 0000FEFF) で始めることを推奨します。この文字はバイトを逆にすると数 FFFE または FFFE0000 という、 文字が割当てられないと保証されているものになります。 ですから、 FFFE を文章の最初のオクテットとして受け取った利用者エージェントは文章の残りの部分が逆バイト順であると知ることができます。

There exist so-called UCS Transformation Formats than can be used to transmit UCS data, in addition to UCS-2 and UCS-4. UTF-7 [RFC1642] and UTF-8 [UTF-8] have favorable properties (no byte-ordering problem, different flavours of ASCII compatibility) that make them worthy of consideration, especially for transmission of multilingual text. Another encoding scheme, MNEM [RFC1345], also has interesting properties and the capability to transmit the full UCS. The UTF-1 transformation format of ISO 10646:1993 (registered by IANA as ISO-10646-UTF-1), has been removed from ISO 10646 by amendment 4, and should not be used.

UCS-2 や UCS-4 の他にも、いわゆる UCS 変形書式という UCS データを転送するために使用できるものがあります。 UTF-7 と UTF-8 は好かれる特性を持っております (バイト順問題がありませんし、 違った風味の ASCII 互換性があります) ため、 特に多言語文の転送に際しましては検討の価値があります。 他の符号化方式といたしましては、 MNEM も面白い特性と UCS を完全に転送する能力を持っています。 ISO 10646:1993 の UTF-1 変形書式 (IANA に ISO-10646-UTF-1 として登録されています。) は ISO 10646 から追補 4 で削除されていますから、使用するべきではありません。

7. HTML Public Text


This section contains a DTD for HTML based on the HTML 2.0 DTD of RFC 1866, incorporating the changes for file upload as specified in RFC 1867, and the changes deriving from this document.

この章は、 RFC 1866 の HTML 2.0 DTD を基にして、 RFC 1867 で規定されているファイルうpのための変更とこの文書による変更を取入れた DTD を含みます。

   <!--    html.dtd
           Document Type Definition for the HyperText Markup Language,
           extended for internationalisation (HTML DTD)
           Last revised: 96/08/07
        Authors: Daniel W. Connolly <connolly@w3.org>
                    Francois Yergeau <yergeau@alis.com>
        See Also:
   <!ENTITY % HTML.Version
           "-//IETF//DTD HTML i18n//EN"
           -- Typical usage:
               <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">
   <!--============ Feature Test Entities ========================-->
   <!ENTITY % HTML.Recommended "IGNORE"
        -- Certain features of the language are necessary for
           compatibility with widespread usage, but they may
           compromise the structural integrity of a document.
           This feature test entity enables a more prescriptive
           document type definition that eliminates
           those features.
   <![ %HTML.Recommended [
           <!ENTITY % HTML.Deprecated "IGNORE">
   <!ENTITY % HTML.Deprecated "INCLUDE"
        -- Certain features of the language are necessary for
           compatibility with earlier versions of the specification,
           but they tend to be used and implemented inconsistently,
           and their use is deprecated. This feature test entity
           enables a document type definition that eliminates
           these features.
   <!ENTITY % HTML.Highlighting "INCLUDE"
        -- Use this feature test entity to validate that a
           document uses no highlighting tags, which may be
           ignored on minimal implementations.
           -- Use this feature test entity to validate that a document
              contains no forms, which may not be supported in minimal
   <!--============== Imported Names ==============================-->
   <!ENTITY % Content-Type "CDATA"
           -- meaning an internet media type
              (aka MIME content type, as per RFC2045)
   <!ENTITY % HTTP-Method "GET | POST"
           -- as per HTTP specification, RFC2068
   <!--========= DTD "Macros" =====================-->
   <!ENTITY % heading "H1|H2|H3|H4|H5|H6">
   <!ENTITY % list " UL | OL | DIR | MENU " >
   <!ENTITY % attrs -- common attributes for elements --
            "LANG  NAME      #IMPLIED  -- RFC 1766 language tag --
             DIR  (ltr|rtl)  #IMPLIED  -- text directionnality --
             ID      ID      #IMPLIED  -- element identifier
                                          (from RFC1942) --
             CLASS   NAMES   #IMPLIED  -- for subclassing elements
                                          (from RFC1942) --">
   <!ENTITY % just -- an attribute for text justification --
            "ALIGN  (left|right|center|justify)  #IMPLIED"
            -- default is left for ltr paragraphs, right for rtl -- >
   <!--======= Character mnemonic entities =================-->
     "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
   <!ENTITY amp CDATA "&#38;"     -- ampersand          -->
   <!ENTITY gt CDATA "&#62;"      -- greater than       -->
   <!ENTITY lt CDATA "&#60;"      -- less than          -->
   <!ENTITY quot CDATA "&#34;"    -- double quote       -->
   <!--Entities for language-dependent presentation (BIDI and
       contextual analysis) -->
   <!ENTITY zwnj CDATA "&#8204;"-- zero width non-joiner-->
   <!ENTITY zwj  CDATA "&#8205;"-- zero width joiner-->
   <!ENTITY lrm  CDATA "&#8206;"-- left-to-right mark-->
   <!ENTITY rlm  CDATA "&#8207;"-- right-to-left mark-->
   <!--========= SGML Document Access (SDA) Parameter Entities =====-->
   <!-- HTML contains SGML Document Access (SDA) fixed attributes
   in support of easy transformation to the International Committee
   for Accessible Document Design (ICADD) DTD
         "-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
   ICADD applications are designed to support usable access to
   structured information by print-impaired individuals through
   Braille, large print and voice synthesis.  For more information on
           - ISO 12083:1993, Annex A.8, Facilities for Braille,
          large print and computer voice
           - ICADD ListServ
           - Usenet news group bit.listserv.easi
           - Recording for the Blind, +1 800 221 4792
          -- one to one mapping        -->
          -- context-sensitive mapping -->
          -- generated text prefix     -->
          -- generated text suffix     -->
          -- suspend transform process -->
   <!--========== Text Markup =====================-->
   <![ %HTML.Highlighting [
   <!ENTITY % font " TT | B | I ">
   <!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
   <!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">
   <!ELEMENT (%font;|%phrase) - - (%text)*>
           %SDAFORM; "Lit"
           %SDAFORM; "B"
   <!ATTLIST ( I | EM | CITE )
           %SDAFORM; "It"
   <!-- <TT>       Typewriter text                         -->
   <!-- <B>        Bold text                               -->
   <!-- <I>        Italic text                             -->
   <!-- <EM>       Emphasized phrase                       -->
   <!-- <STRONG>   Strong emphasis                         -->
   <!-- <CODE>     Source code phrase                      -->
   <!-- <SAMP>     Sample text or characters               -->
   <!-- <KBD>      Keyboard phrase, e.g. user input        -->
   <!-- <VAR>      Variable phrase or substitutable        -->
   <!-- <CITE>     Name or title of cited work             -->
   <!ENTITY % pre.content "#PCDATA|A|HR|BR|%font|%phrase|SPAN|BDO">
           %SDAPREF; "&#RE;"
   <!-- <BR>       Line break      -->
   <!ELEMENT SPAN - - (%text)*>
           %SDAFORM; "other #Attlist"
   <!-- <SPAN>             Generic inline container  -->
   <!-- <SPAN DIR=...>     New counterflow embedding -->
   <!-- <SPAN LANG="...">  Language of contents      -->
   <!ELEMENT Q - - (%text)*>
           %SDAPREF; '"'
           %SDASUFF; '"'
   <!-- <Q>         Short quotation              -->
   <!-- <Q LANG=xx> Language of quotation is xx  -->
   <!-- <Q DIR=...> New conterflow embedding     -->
   <!ELEMENT BDO - - (%text)+>
           LANG   NAME      #IMPLIED
           DIR    (ltr|rtl) #REQUIRED
           ID     ID        #IMPLIED
           CLASS  NAMES     #IMPLIED
           %SDAPREF "Bidi Override #Attval(DIR): "
           %SDASUFF "End Bidi"
   <!-- <BDO DIR=...>   Override directionality of text to value of DIR -->
   <!-- <BDO LANG=...>  Language of contents                            -->
           %SDAPREF "Superscript(#content)"
           %SDAPREF "Subscript(#content)"
   <!-- <SUP>      Superscript              -->
   <!-- <SUB>      Subscript                -->
   <!--========= Link Markup ======================-->
   <!ENTITY % linkType "NAMES">
   <!ENTITY % linkExtraAttributes
           "REL %linkType #IMPLIED
           REV %linkType #IMPLIED
   <![ %HTML.Recommended [
           <!ENTITY % A.content   "(%text)*"
           -- <H1><a name="xxx">Heading</a></H1>
                   is preferred to
              <a name="xxx"><H1>Heading</H1></a>
   <!ENTITY % A.content   "(%heading|%text)*">
   <!ELEMENT A     - - %A.content -(A)>
           %SDAPREF; "<Anchor: #AttList>"
   <!-- <A>       Anchor; source/destination of link -->
   <!-- <A NAME="..."> Name of this anchor           -->
   <!-- <A HREF="..."> Address of link destination        -->
   <!-- <A URN="...">  Permanent address of destination   -->
   <!-- <A REL=...>    Relationship to destination        -->
   <!-- <A REV=...>    Relationship of destination to this     -->
   <!-- <A TITLE="...">     Title of destination (advisory)         -->
   <!-- <A METHODS="...">   Operations on destination (advisory)    -->
   <!-- <A CHARSET="...">   Charset of destination (advisory)  -->
   <!-- <A LANG="...">     Language of contents btw <A> and </A>   -->
   <!-- <A DIR=...>        Contents is a new counterflow embedding -->
   <!--========== Images ==========================-->
           ALIGN (top|middle|bottom) #IMPLIED
           %SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
   <!-- <IMG>              Image; icon, glyph or illustration      -->
   <!-- <IMG SRC="...">    Address of image object                 -->
   <!-- <IMG ALT="...">    Textual alternative                     -->
   <!-- <IMG ALIGN=...>    Position relative to text               -->
   <!-- <IMG LANG=...>     Image contains "text" in that language  -->
   <!-- <IMG DIR=...>      Inline image acts as a RTL or LTR
                           embedding w/r to BIDI algorithm         -->
   <!-- <IMG ISMAP>        Each pixel can be a link                -->
   <!--========== Paragraphs=======================-->
   <!ELEMENT P     - O (%text)*>
           %SDAFORM; "Para"
   <!-- <P>             Paragraph                           -->
   <!-- <P LANG="...">  Language of paragraph text          -->
   <!-- <P DIR=...>     Base directionality of paragraph    -->
   <!-- <P ALIGN=...>   Paragraph alignment (justification) -->
   <!--========== Headings, Titles, Sections ===============-->
           %SDAPREF; "&#RE;&#RE;"
   <!-- <HR>       Horizontal rule -->
   <!ELEMENT ( %heading )  - -  (%text;)*>
           %SDAFORM; "H1"
           %SDAFORM; "H2"
           %SDAFORM; "H3"
           %SDAFORM; "H4"
           %SDAFORM; "H5"
           %SDAFORM; "H6"
   <!-- <H1>       Heading, level 1 -->
   <!-- <H2>       Heading, level 2 -->
   <!-- <H3>       Heading, level 3 -->
   <!-- <H4>       Heading, level 4 -->
   <!-- <H5>       Heading, level 5 -->
   <!-- <H6>       Heading, level 6 -->
   <!--========== Text Flows ======================-->
   <![ %HTML.Forms [
           <!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
   <!ENTITY % block.forms "BLOCKQUOTE">
   <![ %HTML.Deprecated [
           <!ENTITY % preformatted "PRE | XMP | LISTING">
   <!ENTITY % preformatted "PRE">
   <!ENTITY % block "P | %list | DL
           | %preformatted
           | %block.forms">
   <!ENTITY % flow "(%text|%block)*">
   <!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO">
   <!ELEMENT PRE - - (%pre.content)*>
           WIDTH NUMBER #implied
           %SDAFORM; "Lit"
   <!-- <PRE>              Preformatted text                    -->
   <!-- <PRE WIDTH=...>    Maximum characters per line          -->
   <!-- <PRE DIR=...>      Base direction of preformatted block -->
   <!-- <PRE LANG=...>     Language of contents                 -->
   <![ %HTML.Deprecated [
   <!ENTITY % literal "CDATA"
           -- historical, non-conforming parsing mode where
              the only markup signal is the end tag
              in full
   <!ELEMENT (XMP|LISTING) - -  %literal>
           %SDAFORM; "Lit"
           %SDAPREF; "Example:&#RE;"
           %SDAFORM; "Lit"
           %SDAPREF; "Listing:&#RE;"
   <!-- <XMP>              Example section         -->
   <!-- <LISTING>          Computer listing        -->
   <!ELEMENT PLAINTEXT - O %literal>
   <!-- <PLAINTEXT>        Plain text passage      -->
           %SDAFORM; "Lit"
   <!--========== Lists ==================-->
   <!ELEMENT DL    - -  (DT | DD)+>
           %SDAFORM; "List"
           %SDAPREF; "Definition List:"
   <!ELEMENT DT    - O (%text)*>
           %SDAFORM; "Term"
   <!ELEMENT DD    - O %flow>
           %SDAFORM; "LItem"
   <!-- <DL>               Definition list, or glossary    -->
   <!-- <DL COMPACT>       Compact style list              -->
   <!-- <DT>               Term in definition list         -->
   <!-- <DD>               Definition of term              -->
   <!ELEMENT (OL|UL) - -  (LI)+>
           %SDAFORM; "List"
           %SDAFORM; "List"
   <!-- <UL>               Unordered list                  -->
   <!-- <UL COMPACT>       Compact list style              -->
   <!-- <OL>               Ordered, or numbered list       -->
   <!-- <OL COMPACT>       Compact list style              -->
   <!ELEMENT (DIR|MENU) - -  (LI)+ -(%block)>
           %SDAFORM; "List"
           %SDAPREF; "<LHead>Directory</LHead>"
           %SDAFORM; "List"
           %SDAPREF; "<LHead>Menu</LHead>"
   <!-- <DIR>              Directory list                  -->
   <!-- <DIR COMPACT>      Compact list style              -->
   <!-- <MENU>             Menu list                       -->
   <!-- <MENU COMPACT>     Compact list style              -->
   <!ELEMENT LI    - O %flow>
           %SDAFORM; "LItem"
   <!-- <LI>               List item                       -->
   <!--========== Document Body ===================-->
   <![ %HTML.Recommended [
        <!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
        -- <h1>Heading</h1>
           <p>Text ...
             is preferred to
           Text ...
   <!ENTITY % body.content "(%heading | %text | %block |
                        HR | ADDRESS)*">
   <!ELEMENT BODY O O  %body.content>
   <!-- <BODY>          Document body                -->
   <!-- <BODY DIR=...>  Base direction of whole body -->
   <!-- <BODY LANG=...> Language of contents         -->
   <!ELEMENT BLOCKQUOTE - - %body.content>
           %SDAFORM; "BQ"
   <!-- <BLOCKQUOTE>       Quoted passage  -->
   <!ELEMENT ADDRESS - - (%text|P)*>
           %SDAFORM; "Lit"
           %SDAPREF; "Address:&#RE;"
   <!-- <ADDRESS> Address, signature, or byline -->
   <!--======= Forms ====================-->
   <![ %HTML.Forms [
   <!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
           METHOD (%HTTP-Method) GET
           ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
           %SDAPREF; "<Para>Form:</Para>"
           %SDASUFF; "<Para>Form End.</Para>"
   <!-- <FORM>                     Fill-out or data-entry form     -->
   <!-- <FORM ACTION="...">        Address for completed form      -->
   <!-- <FORM METHOD=...>          Method of submitting form       -->
   <!-- <FORM ENCTYPE="...">       Representation of form data     -->
   <!-- <FORM DIR=...>             Base direction of form          -->
   <!-- <FORM LANG=...>            Language of contents            -->
                           RADIO | SUBMIT | RESET |
                           IMAGE | HIDDEN | FILE )">
        TYPE %InputType TEXT
        ALIGN (top|middle|bottom) #IMPLIED
           ACCEPT CDATA #IMPLIED --list of content types --
           ACCEPT-CHARSET CDATA #IMPLIED --list of charsets accepted --
           %SDAPREF; "Input: "
   <!-- <INPUT>               Form input datum        -->
   <!-- <INPUT TYPE=...>           Type of input interaction    -->
   <!-- <INPUT NAME=...>           Name of form datum           -->
   <!-- <INPUT VALUE="...">   Default/initial/selected value -->
   <!-- <INPUT SRC="...">          Address of image        -->
   <!-- <INPUT CHECKED>            Initial state is "on"        -->
   <!-- <INPUT SIZE=...>           Field size hint         -->
   <!-- <INPUT MAXLENGTH=...>      Data length maximum          -->
   <!-- <INPUT ALIGN=...>          Image alignment         -->
   <!-- <INPUT ACCEPT="...">         List of desired media types    -->
   <!-- <INPUT ACCEPT-CHARSET="..."> List of acceptable charsets    -->
           %SDAFORM; "List"
           "<LHead>Select #AttVal(Multiple)</LHead>"
   <!-- <SELECT>            Selection of option(s)        -->
   <!-- <SELECT NAME=...>        Name of form datum       -->
   <!-- <SELECT SIZE=...>        Options displayed at a time   -->
   <!-- <SELECT MULTIPLE>        Multiple selections allowed   -->
           %SDAFORM; "LItem"
           "Option: #AttVal(Value) #AttVal(Selected)"
   <!-- <OPTION>            A selection option       -->
   <!-- <OPTION SELECTED>        Initial state            -->
   <!-- <OPTION VALUE="...">     Form datum value for this option-->
           ACCEPT-CHARSET CDATA #IMPLIED -- list of charsets accepted --
           %SDAFORM; "Para"
           %SDAPREF; "Input Text -- #AttVal(Name): "
   <!-- <TEXTAREA>               An area for text input        -->
   <!-- <TEXTAREA NAME=...> Name of form datum       -->
   <!-- <TEXTAREA ROWS=...> Height of area           -->
   <!-- <TEXTAREA COLS=...> Width of area            -->
   <!--======= Document Head ======================-->
   <![ %HTML.Recommended [
        <!ENTITY % head.extra "">
   <!ENTITY % head.extra "& NEXTID?">
   <!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
   <!ELEMENT HEAD O O  (%head.content) +(META|LINK)>
           %attrs;           >
   <!-- <HEAD>     Document head   -->
           %SDAFORM; "Ti"    >
   <!-- <TITLE>    Title of document -->
           %SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>"    >
   <!-- <LINK>         Link from this document            -->
   <!-- <LINK HREF="...">   Address of link destination        -->
   <!-- <LINK URN="...">    Lasting name of destination        -->
   <!-- <LINK REL=...> Relationship to destination        -->
   <!-- <LINK REV=...> Relationship of destination to this     -->
   <!-- <LINK TITLE="...">  Title of destination (advisory)         -->
   <!-- <LINK CHARSET="..."> Charset of destination (advisory)      -->
   <!-- <LINK METHODS="..."> Operations allowed (advisory)          -->
      "<Para>[Document is indexed/searchable.]</Para>">
   <!-- <ISINDEX>          Document is a searchable index          -->
           HREF CDATA #REQUIRED     >
   <!-- <BASE>             Base context document                   -->
   <!-- <BASE HREF="...">  Address for this document               -->
           N CDATA #REQUIRED     >
   <!-- <NEXTID>       Next ID to use for link name       -->
   <!-- <NEXTID N=...> Next ID to use for link name       -->
           NAME        NAME    #IMPLIED
           CONTENT     CDATA   #REQUIRED    >
   <!-- <META>                     Generic Meta-information        -->
   <!-- <META HTTP-EQUIV=...>      HTTP response header name       -->
   <!-- <META NAME=...>          Meta-information name           -->
   <!-- <META CONTENT="...">       Associated information          -->
   <!--======= Document Structure =================-->
   <![ %HTML.Deprecated [
           <!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
   <!ENTITY % html.content "HEAD, BODY">
   <!ELEMENT HTML O O  (%html.content)>
   <!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
           %SDAFORM; "Book"
   <!-- <HTML>              HTML Document  -->

7.2. SGML Declaration for HTML

   <!SGML  "ISO 8879:1986"
        SGML Declaration for HyperText Markup Language version 2.x
           (HTML 2.x = HTML 2.0 + i18n).
            BASESET  "ISO Registration Number 177//CHARSET
                      ISO/IEC 10646-1:1993 UCS-4 with
                      implementation level 3//ESC 2/5 2/15 4/6"
            DESCSET  0   9     UNUSED
                     9   2     9
                     11  2     UNUSED
                     13  1     13
                     14  18    UNUSED
                     32  95    32
                     127 1     UNUSED
                     128 32    UNUSED
                     160 2147483486 160
       In ISO 10646, the positions with hexadecimal
       values 0000D800 - 0000DFFF, used in the UTF-16
       encoding of UCS-4, are reserved, as well as the last
       two code values in each plane of UCS-4, i.e. all
       values of the hexadecimal form xxxxFFFE or xxxxFFFF.
       These code values or the corresponding numeric
       character references must not be included when
       generating a new HTML document, and they should be
       ignored if encountered when processing a HTML
                   TOTALCAP        150000
                   GRPCAP          150000
             ENTCAP         150000
            SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
              17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
            BASESET  "ISO 646IRV:1991//CHARSET
                      International Reference Version
                      (IRV)//ESC 2/8 4/2"
            DESCSET  0 128 0
                     RE            13
                     RS            10
                     SPACE         32
                     TAB SEPCHAR    9
            NAMING   LCNMSTRT ""
                     UCNMSTRT ""
                     LCNMCHAR ".-"
                     UCNMCHAR ".-"
                     NAMECASE GENERAL YES
                              ENTITY  NO
                     SHORTREF SGMLREF
            NAMES    SGMLREF
                     ATTSPLEN 2100
                     LITLEN   1024
                     NAMELEN  72    -- somewhat arbitrary; taken from
                                   internet line length conventions --
                     PILEN    1024
                     TAGLVL   100
                     TAGLEN   2100
                     GRPGTCNT 150
                     GRPCNT   64
       DATATAG  NO
       RANK     NO
       SIMPLE   NO
       CONCUR   NO
       SUBDOC   NO
       FORMAL   YES
     APPINFO    "SDA"  -- conforming SGML Document Access application

7.3. ISO Latin 1 entity set

The following public text lists each of the characters specified in the Added Latin 1 entity set, along with its name, syntax for use, and description. This list is derived from ISO Standard 8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire entity set, and adds entities for all missing characters in the right part of ISO-8859-1.

次の公開文は、追加 Latin 1 実体集合で規定される文字をそれぞれ名前、 使用する構文、説明と共に並べたものです。この一覧は ISO 規格 8879:1986//ENTITIES Added Latin 1//EN から派生しています。 HTML は実体集合全体を含めた上で ISO-8859-1 の右半分のすべての欠落文字の実体を追加しています。

    <!-- (C) International Organization for Standardization 1986
         Permission to copy in any form is granted for use with
         conforming SGML systems and applications as defined in
         ISO 8879, provided this notice is included in all copies.
    <!-- Character entity set. Typical invocation:
         <!ENTITY % ISOlat1 PUBLIC
           "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
    <!ENTITY nbsp   CDATA "&#160;" -- no-break space -->
    <!ENTITY iexcl  CDATA "&#161;" -- inverted exclamation mark -->
    <!ENTITY cent   CDATA "&#162;" -- cent sign -->
    <!ENTITY pound  CDATA "&#163;" -- pound sterling sign -->
    <!ENTITY curren CDATA "&#164;" -- general currency sign -->
    <!ENTITY yen    CDATA "&#165;" -- yen sign -->
    <!ENTITY brvbar CDATA "&#166;" -- broken (vertical) bar -->
    <!ENTITY sect   CDATA "&#167;" -- section sign -->
    <!ENTITY uml    CDATA "&#168;" -- umlaut (dieresis) -->
    <!ENTITY copy   CDATA "&#169;" -- copyright sign -->
    <!ENTITY ordf   CDATA "&#170;" -- ordinal indicator, feminine -->
    <!ENTITY laquo  CDATA "&#171;" -- angle quotation mark, left -->
    <!ENTITY not    CDATA "&#172;" -- not sign -->
    <!ENTITY shy    CDATA "&#173;" -- soft hyphen -->
    <!ENTITY reg    CDATA "&#174;" -- registered sign -->
    <!ENTITY macr   CDATA "&#175;" -- macron -->
    <!ENTITY deg    CDATA "&#176;" -- degree sign -->
    <!ENTITY plusmn CDATA "&#177;" -- plus-or-minus sign -->
    <!ENTITY sup2   CDATA "&#178;" -- superscript two -->
    <!ENTITY sup3   CDATA "&#179;" -- superscript three -->
    <!ENTITY acute  CDATA "&#180;" -- acute accent -->
    <!ENTITY micro  CDATA "&#181;" -- micro sign -->
    <!ENTITY para   CDATA "&#182;" -- pilcrow (paragraph sign) -->
    <!ENTITY middot CDATA "&#183;" -- middle dot -->
    <!ENTITY cedil  CDATA "&#184;" -- cedilla -->
    <!ENTITY sup1   CDATA "&#185;" -- superscript one -->
    <!ENTITY ordm   CDATA "&#186;" -- ordinal indicator, masculine -->
    <!ENTITY raquo  CDATA "&#187;" -- angle quotation mark, right -->
    <!ENTITY frac14 CDATA "&#188;" -- fraction one-quarter -->
    <!ENTITY frac12 CDATA "&#189;" -- fraction one-half -->
    <!ENTITY frac34 CDATA "&#190;" -- fraction three-quarters -->
    <!ENTITY iquest CDATA "&#191;" -- inverted question mark -->
    <!ENTITY Agrave CDATA "&#192;" -- capital A, grave accent -->
    <!ENTITY Aacute CDATA "&#193;" -- capital A, acute accent -->
    <!ENTITY Acirc  CDATA "&#194;" -- capital A, circumflex accent -->
    <!ENTITY Atilde CDATA "&#195;" -- capital A, tilde -->
    <!ENTITY Auml   CDATA "&#196;" -- capital A, dieresis or umlaut -->
    <!ENTITY Aring  CDATA "&#197;" -- capital A, ring -->
    <!ENTITY AElig  CDATA "&#198;" -- capital AE diphthong (ligature) -->
    <!ENTITY Ccedil CDATA "&#199;" -- capital C, cedilla -->
    <!ENTITY Egrave CDATA "&#200;" -- capital E, grave accent -->
    <!ENTITY Eacute CDATA "&#201;" -- capital E, acute accent -->
    <!ENTITY Ecirc  CDATA "&#202;" -- capital E, circumflex accent -->
    <!ENTITY Euml   CDATA "&#203;" -- capital E, dieresis or umlaut -->
    <!ENTITY Igrave CDATA "&#204;" -- capital I, grave accent -->
    <!ENTITY Iacute CDATA "&#205;" -- capital I, acute accent -->
    <!ENTITY Icirc  CDATA "&#206;" -- capital I, circumflex accent -->
    <!ENTITY Iuml   CDATA "&#207;" -- capital I, dieresis or umlaut -->
    <!ENTITY ETH    CDATA "&#208;" -- capital Eth, Icelandic -->
    <!ENTITY Ntilde CDATA "&#209;" -- capital N, tilde -->
    <!ENTITY Ograve CDATA "&#210;" -- capital O, grave accent -->
    <!ENTITY Oacute CDATA "&#211;" -- capital O, acute accent -->
    <!ENTITY Ocirc  CDATA "&#212;" -- capital O, circumflex accent -->
    <!ENTITY Otilde CDATA "&#213;" -- capital O, tilde -->
    <!ENTITY Ouml   CDATA "&#214;" -- capital O, dieresis or umlaut -->
    <!ENTITY times  CDATA "&#215;" -- multiply sign -->
    <!ENTITY Oslash CDATA "&#216;" -- capital O, slash -->
    <!ENTITY Ugrave CDATA "&#217;" -- capital U, grave accent -->
    <!ENTITY Uacute CDATA "&#218;" -- capital U, acute accent -->
    <!ENTITY Ucirc  CDATA "&#219;" -- capital U, circumflex accent -->
    <!ENTITY Uuml   CDATA "&#220;" -- capital U, dieresis or umlaut -->
    <!ENTITY Yacute CDATA "&#221;" -- capital Y, acute accent -->
    <!ENTITY THORN  CDATA "&#222;" -- capital Thorn, Icelandic -->
    <!ENTITY szlig  CDATA "&#223;" -- small sharp s, German (sz ligature) -->
    <!ENTITY agrave CDATA "&#224;" -- small a, grave accent -->
    <!ENTITY aacute CDATA "&#225;" -- small a, acute accent -->
    <!ENTITY acirc  CDATA "&#226;" -- small a, circumflex accent -->
    <!ENTITY atilde CDATA "&#227;" -- small a, tilde -->
    <!ENTITY auml   CDATA "&#228;" -- small a, dieresis or umlaut -->
    <!ENTITY aring  CDATA "&#229;" -- small a, ring -->
    <!ENTITY aelig  CDATA "&#230;" -- small ae diphthong (ligature) -->
    <!ENTITY ccedil CDATA "&#231;" -- small c, cedilla -->
    <!ENTITY egrave CDATA "&#232;" -- small e, grave accent -->
    <!ENTITY eacute CDATA "&#233;" -- small e, acute accent -->
    <!ENTITY ecirc  CDATA "&#234;" -- small e, circumflex accent -->
    <!ENTITY euml   CDATA "&#235;" -- small e, dieresis or umlaut -->
    <!ENTITY igrave CDATA "&#236;" -- small i, grave accent -->
    <!ENTITY iacute CDATA "&#237;" -- small i, acute accent -->
    <!ENTITY icirc  CDATA "&#238;" -- small i, circumflex accent -->
    <!ENTITY iuml   CDATA "&#239;" -- small i, dieresis or umlaut -->
    <!ENTITY eth    CDATA "&#240;" -- small eth, Icelandic -->
    <!ENTITY ntilde CDATA "&#241;" -- small n, tilde -->
    <!ENTITY ograve CDATA "&#242;" -- small o, grave accent -->
    <!ENTITY oacute CDATA "&#243;" -- small o, acute accent -->
    <!ENTITY ocirc  CDATA "&#244;" -- small o, circumflex accent -->
    <!ENTITY otilde CDATA "&#245;" -- small o, tilde -->
    <!ENTITY ouml   CDATA "&#246;" -- small o, dieresis or umlaut -->
    <!ENTITY divide CDATA "&#247;" -- divide sign -->
    <!ENTITY oslash CDATA "&#248;" -- small o, slash -->
    <!ENTITY ugrave CDATA "&#249;" -- small u, grave accent -->
    <!ENTITY uacute CDATA "&#250;" -- small u, acute accent -->
    <!ENTITY ucirc  CDATA "&#251;" -- small u, circumflex accent -->
    <!ENTITY uuml   CDATA "&#252;" -- small u, dieresis or umlaut -->
    <!ENTITY yacute CDATA "&#253;" -- small y, acute accent -->
    <!ENTITY thorn  CDATA "&#254;" -- small thorn, Icelandic -->
    <!ENTITY yuml   CDATA "&#255;" -- small y, dieresis or umlaut -->

8. Security Considerations

Anchors, embedded images, and all other elements which contain URIs as parameters may cause the URI to be dereferenced in response to user input. In this case, the security considerations of [RFC1738] apply.

アンカー、埋込み画像、その他すべての URI をを引数として持つ要素は、利用者の入力への応答で URI の参照解決を引起こすかもしれません。この場合、 RFC 1738 の保安についての考察が適用されます。

The widely deployed methods for submitting form requests -- HTTP and SMTP -- provide little assurance of confidentiality. Information providers who request sensitive information via forms -- especially by way of the `PASSWORD' type input field (see section 8.1.2 in [RFC1866]) -- should be aware and make their users aware of the lack of confidentiality.

フォーム要求を提出する方法として広く用いられている HTTP や SMTP は、機密性がほとんど保証されていません。 フォームで繊細な情報を世給する情報提供者は、 特に password 型入力欄を使う場合は、 機密性なきことに注意すると共に、利用者にも注意を促すべきです。


   [BRYAN88]      M. Bryan, "SGML -- An Author's Guide to the Standard
                  Generalized Markup Language", Addison-Wesley, Reading,
   [ERCS]         Extended Reference Concrete Syntax for SGML.
   [GOLD90]       C. F. Goldfarb, "The SGML Handbook", Y. Rubinsky, Ed.,
                  Oxford University Press, 1990.
   [HTTP-1.1]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                  and T. Berners-Lee, "Hypertext Transfer Protocol --
                  HTTP/1.1", RFC 2068, January 1997.
   [ISO-639]      ISO 639:1988. International standard -- Code for the
                  representation of the names of languages.  Technical
                  content in <http://www.sil.org/sgml/iso639a.html>
   [ISO-8859]     ISO 8859.  International standard -- Information pro-
                  cessing -- 8-bit single-byte coded graphic character
                  sets -- Part 1: Latin alphabet No. 1 (1987) -- Part 2:
                  Latin alphabet No. 2 (1987) -- Part 3: Latin alphabet
                  No. 3 (1988) -- Part 4: Latin alphabet No. 4 (1988) --
                  Part 5: Latin/Cyrillic alphabet (1988) -- Part 6:
                  Latin/Arabic alphabet (1987) -- Part : Latin/Greek
                  alphabet (1987) -- Part 8: Latin/Hebrew alphabet
                  (1988) -- Part 9: Latin alphabet No. 5 (1989) -- Part
                  10: Latin alphabet No. 6 (1992)
   [ISO-8879]     ISO 8879:1986. International standard -- Information
                  processing -- Text and office systems -- Standard gen-
                  eralized markup language (SGML).
   [ISO-10646]    ISO/IEC 10646-1:1993. International standard -- Infor-
                  mation technology -- Universal multiple-octet coded
                  character Sset (UCS) -- Part 1: Architecture and basic
                  multilingual plane.
   [NICOL]        G.T. Nicol, "The Multilingual World Wide Web",
                  Electronic Book Technologies, 1995,
   [NICOL2]       G.T. Nicol, "MIME Header Supplemented File Type", Work
                  in Progress, EBT, October 1995.
   [RFC1345]      Simonsen, K., "Character Mnemonics & Character Sets",
                  RFC 1345, Rationel Almen Planlaegning, June 1992.
   [RFC1468]      Murai, J., Crispin M., and E. van der Poel,
                  "Japanese Character Encoding for Internet Messages",
                  RFC 1468, Keio University, Panda Programming, June
   [RFC2045]      Freed, N., and N. Borenstein, "Multipurpose Internet
                  Mail Extensions (MIME) Part One: Format of Internet
                  Message Bodies", RFC 2045, Innosoft, First Virtual,
                  November 1996.
   [RFC1641]      Goldsmith, D., and M.Davis, "Using Unicode with MIME",
                  RFC 1641, Taligent inc., July 1994.
   [RFC1642]      Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe
                  Transformation Format of Unicode", RFC 1642, Taligent,
                  Inc., July 1994.
   [RFC1738]      Berners-Lee, T., Masinter, L., and M. McCahill,
                  "Uniform Resource Locators (URL)", RFC 1738, CERN,
                  Xerox PARC, University of Minnesota, October 1994.
   [RFC1766]      Alverstrand, H., "Tags for the Identification of
                  Languages", RFC 1766, UNINETT, March 1995.
   [RFC1866]      Berners-Lee, T., and D. Connolly, "Hypertext Markup
                  Language - 2.0", RFC 1866, MIT/W3C, November 1995.
   [RFC1867]      Nebel, E., and L. Masinter, "Form-based File Upload
                  in HTML", RFC 1867, Xerox Corporation, November 1995.
   [RFC1942]      Raggett, D., "HTML Tables", RFC 1942, W3C, May 1996.
   [RFC2068]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                  and T. Berners-Lee, "Hypertext Transfer Protocol --
                  HTTP/1.1", RFC 2068, January 1997.
   [SQ91]         SoftQuad, "The SGML Primer", 3rd ed., SoftQuad Inc.,
   [TAKADA]       Toshihiro Takada, "Multilingual Information Exchange
                  through the World-Wide Web", Computer Networks and
                  ISDN Systems, Vol. 27, No. 2, Nov. 1994 , p. 235-241.
   [TEI]          TEI Guidelines for Electronic Text Encoding and Inter-
                  change.  <http://etext.virgina.edu/TEI.html>
   [UNICODE]      The Unicode Consortium, "The Unicode Standard --
                  Worldwide Character Encoding -- Version 1.0", Addison-
                  Wesley, Volume 1, 1991, Volume 2, 1992, and Technical
                  Report #4, 1993.  The BIDI algorithm is in appendix A
                  of volume 1, with corrections in appendix D of volume
   [UTF-8]        ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS Transfor-
                  mation Format 8 (UTF-8).
   [VANH90]       E. van Hervijnen, "Practical SGML", Kluwer Academicq
                  Publishers Group, Norwell and Dordrecht, 1990.

Authors' Addresses

      Frangois Yergeau
      Alis Technologies
      100, boul. Alexis-Nihon, bureau 600
      Montrial  QC  H4M 2P2
      Tel: +1 (514) 747-2547
      Fax: +1 (514) 747-2561
      EMail: fyergeau@alis.com
      Gavin Thomas Nicol
      Electronic Book Technologies, Japan
      1-29-9 Tsurumaki,
      Tel: +81-3-3230-8161
      Fax: +81-3-3230-8163
      EMail: gtn@ebt.com, gtn@twics.co.jp
      Glenn Adams
      118 Magazine Street
      Cambridge, MA 02139
      Tel: +1 (617) 864-5524
      Fax: +1 (617) 864-4965
      EMail: glenn@spyglass.com
      Martin J. Duerst
      Department of Computer Science
      University of Zurich
      Winterthurerstrasse 190
      CH-8057 Zurich
      Tel: +41 1 257 43 16
      Fax: +41 1 363 00 35
      EMail: mduerst@ifi.unizh.ch


[2] RFC 2070 - Internationalization of the Hypertext Markup Language (2007-01-14 17:48:07 +09:00 版) <http://tools.ietf.org/html/rfc2070>