RFC2070 日本語訳
2070 Internationalization of the Hypertext Markup Language. F.Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format: TXT=91887 bytes) (Obsoleted by RFC2854) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Yergeau
Request for Comments: 2070 Alis Technologies
Category: Standards Track G. Nicol
Electronic Book Technologies
G. Adams
Spyglass
M. Duerst
University of Zurich
January 1997
Yergeauがコメントのために要求するワーキンググループF.をネットワークでつないでください: 2070年のAlis技術カテゴリ: 規格は1997年1月にチューリッヒのG.ニコル電子ブック技術G.アダムススパイグラスM.Duerst大学を追跡します。
Internationalization of the Hypertext Markup Language
ハイパーテキストマークアップランゲージの国際化
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
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)はプラットホーム独立者であるハイパーテキストドキュメントを作成するのに使用されるマークアップ言語です。 初めは、WWWにおける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の仕様を広げていて、適切な国際化サポートのための追加推薦を与えることによって、HTMLの国際化(i18n、nがあとに続いた18個の手紙でiは続いた)の問題を扱うことになっています。 最前の考慮は世界のすべての言語で使用を可能にしている間、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
1. 序論… 2 1.1. 範囲… 2 1.2. 順応… 3 2. ドキュメント文字集合… 4 2.1. 参照処理モデル… 4 2.2. ドキュメント文字集合… 6 2.3. 表示できないキャラクタ… 8
Yergeau, et. al. Standards Track [Page 1] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[1ページ]。
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
3. ラング属性… 8 4. 追加実体、属性、および要素… 9 4.1. 完全なラテン語-1実体はセットしました… 9 4.2. 言語依存するプレゼンテーションのためのマーク付け… 10 5. 形成します…16 5.1. DTD追加…16 5.2. 服従を形成してください…17 6. 外部の文字符号化問題…18 7. HTMLの公共のテキスト…20 7.1. HTML DTD…20 7.2. HTMLのためのSGML宣言…35 7.3. ISOラテン語1キャラクタ実体はセットしました…37 8. セキュリティ問題…40図書目録…40人の作者のアドレス…43
1. Introduction
1. 序論
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)はプラットホーム独立者であるハイパーテキストドキュメントを作成するのに使用されるマークアップ言語です。 初めは、WWWにおける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の仕様を広げていて、適切な国際化サポートのための追加推薦を与えることによって、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ドキュメント文字集合と、「テキスト/html」content typeに関連しているcharsetパラメタの適切な治療といくつかの追加要素と実体の仕様です。
1.1 Scope
1.1 範囲
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].
1990年以来HTMLはWWW(WWW)のグローバルな情報イニシアチブで使用中です。 この仕様はHTML2.0(RFC1866)の能力を広げています、主としてISO-8859-1コード化文字集合[ISO-8859]に制限を移すことによって。
Yergeau, et. al. Standards Track [Page 2] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[2ページ]。
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 Standardのアプリケーションです。8879:1986 情報Processing TextとオフィスSystems--標準のGeneralized Markup Language(SGML)[ISO-8879]。 HTML Document Type Definition(DTD)はSGMLに関するHTML構文の公式の定義です。 この仕様は、それをまだSGML conformantのままで残っている間にISO-8859-1のものよりはるかに大きいキャラクタレパートリーを包含するドキュメントに適切にするようにHTML2.0のDTDを修正します。
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の同様に実際の開発は非常に速く進んでいます。 特徴、本書では説明されて、他のフォームのHTMLに追加されて、RFC1866でそんなに説明されているので、それらがそうすることができる設計されたそうは(and should)です。 示されるところでは、ここで導入された属性は適切な要素に広げられるべきです。
1.2 Conformance
1.2 順応
This specification changes slightly the conformance requirements of HTML documents and HTML user agents.
この仕様はHTMLドキュメントとHTMLユーザエージェントの順応要件をわずかに変えます。
1.2.1 Documents
1.2.1 ドキュメント
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.
すべてのHTML2.0が、この仕様に従いながら、残っています従うのが、ドキュメントである。 しかしながら、ここで導入された拡大は有効なあるそうしないドキュメントをHTMLにします。2.0が従って、特にキャラクタかキャラクタを含む人がISOのレパートリーの外で8859-1、およびここに導入されたマーク付けを含むものに参照をつけます。
1.2.2. User agents
1.2.2. ユーザエージェント
In addition to the requirements of RFC 1866, the following requirements are placed on HTML user agents.
RFC1866の要件に加えて、以下の要件は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.
少なくともISO8859-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].
その上、ユーザエージェントを従わせると、ISO10646-1[ISO-10646]の範囲の中のすべての番号文字参照が正しく少なくとも分析されなければなりません。
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処理を適用する必要は全くありません。
Yergeau, et. al. Standards Track [Page 3] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[3ページ]。
2. The document character set
2. ドキュメント文字集合
2.1. Reference processing model
2.1. 参照処理モデル
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.
テキストの様々なはなはだしく異なったencodingsがあるので、SGMLはドキュメントのコンピュータファイルなどの具体的な実現で直接、抽象的な意味でSGMLドキュメントを構成するキャラクタの系列が八重奏の系列によってどうコード化されるかを(別の長さのグループに時折、8より噛み付きました)扱いません。 このコード化はコンクリートのSGMLドキュメントの外部の文字符号化と呼ばれます、そして、それは抽象的なHTMLドキュメントのドキュメント文字集合と慎重に区別されるべきです。 SGMLは、1セット(「キャラクタレパートリー」と呼ばれる)としてキャラクタを見なして、レパートリーで整数(「キャラクタ番号」として、知られている)を各キャラクタに割り当てる「コードセット」を見なします。 ドキュメント文字集合宣言はそれぞれのキャラクタ番号が表すことを定義します。[GOLD90、p。 451]. 多くの場合、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.
SGMLのアプリケーションとして、HTMLは直接外部の文字符号化の問題を扱いません。 これは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プロトコル[RFC2068]において、外部の文字符号化はHTTP応答のヘッダーの「コンテントタイプ」分野の"charset"パラメタによって示されます。 例えば、伝えられたドキュメントが日本語[RFC1468]の「JUNET」コード化でコード化されるのを示すために、ヘッダーは以下の系列を含むでしょう:
Content-Type: text/html; charset=ISO-2022-JP
コンテントタイプ: テキスト/html。 charset=ISO2022JP
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.
"charset"というMIMEにおける用語は、用語が示すかもしれないように単にコード化文字集合よりむしろ文字符号化を指定するのに使用されます。 文字符号化は1つ以上のキャラクタレパートリーから取られたキャラクタの系列への八重奏の系列に関するマッピング(ことによると1つへの多く)です。
The HTTP protocol also defines a mechanism for the client to specify the character encodings it can accept. Clients and servers are
また、クライアントがそれが受け入れることができる文字符号化を指定するように、HTTPプロトコルはメカニズムを定義します。 クライアントとサーバはそうです。
Yergeau, et. al. Standards Track [Page 4] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[4ページ]。
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.
正しいトランスミッションと解釈にどんなドキュメントも保証するのにこれらのメカニズムを使用するよう強く要求されています。 サーバかクライアントがまだこれらのメカニズムを使用していない場合でさえ、正しい解釈を助けるために取ることができる条項はセクション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ドキュメントを移すなら、外部の文字符号化は、「コンテントタイプ」MIMEヘッダーフィールド[RFC2045]の"charset"パラメタによって定義されて、不在における米国ASCIIをデフォルトとします。
No mechanisms are currently standardized for indicating the external character encoding of HTML documents transferred by FTP or accessed in distributed file systems.
メカニズムに、全く現在、HTMLドキュメントの外部の文字符号化がFTPで移されたのを示すために標準化されないか、または分散ファイルシステムでアクセスしません。
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
実際の実装は上で説明されるようにドキュメント文字集合のいくつかのコード化にドキュメントを翻訳するために選ばれるかもしれません。 別の方法でこの参照処理モデルによって説明されたふるまいは達成できます。 しかしながら、この仕様の範囲のかなり外にこの対象はあります、そして、読者は招待されます。
Yergeau, et. al. Standards Track [Page 5] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[5ページ]。
consult the SGML standard [ISO-8879] or an SGML handbook [BRYAN88] [GOLD90] [VANH90] [SQ91] for further information.
詳細のために、SGML規格[ISO-8879]かSGMLハンドブック[BRYAN88][GOLD90][VANH90][SQ91]を参照してください。
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を見てください。
2.2. The document character set
2.2. ドキュメント文字集合
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のUniversal文字コード(UCS)です。10646:1993 修正されるように[ISO-10646。] 現在、これはコード、おいてユニコード規格と同じであるバージョン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.
注意--implementersはISO10646が時々修正されるのを意識しているべきです。 初期の1993年の公表以来4つの修正が採用されます。そのいずれもこの仕様にかなり影響しません。 現在、考慮で、5番目の修正は非互換な変化を規格に紹介するでしょう: コード位置3400と4DFF(16進)の間に割り当てられた6556の韓国のハングル音節が新しい所定の位置に動かされるでしょう(4516の新しい音節が加えました)、その結果、古い位置を無効であるのを参照します。 ユニコード共同体が既に今度のユニコード2.0での包含のための対応する修正を採用したので、DAM5の採用はありそうであると考えられます、そして、implementersは旧法位置が既に無効であるとたぶんみなすはずです。 この1回の変化にもかかわらず、関連標準のボディーは、将来少しの割り当てられたコード位置も変えないように立場を明らかにしました。 これらの変化、結合の如何にかかわらず韓国のハングルをコード化するために、1110-11 範囲F9のハングルJamoを使用できます。
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:
このドキュメント文字集合の採用は、SGML宣言における変化がHTML2.0仕様([RFC1866]のセクション9.5)で指定したのを含意します。 変化は、それらを以下の宣言に取り替えて、最初のBASESET仕様とその付随のDESCSET宣言を取り除くのに等しいです:
Yergeau, et. al. Standards Track [Page 6] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[6ページ]。
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
BASESET、「ISO Registration Number177//CHARSET ISO/IEC10646-1: 実装平らな3 //ESC2/5 2/15 4/6インチDESCSET0 9UNUSED9 2 9 11 2UNUSED13 1 13 14 18UNUSED32 95 32 127 1UNUSED128 32UNUSED160 2147483486 160がある1993UCS-4」
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をドキュメント文字集合にするのはHTML2.0に一致しているどんな式、構造物またはドキュメントの非順応も作成しません。 それはHTML2.0で容認できない従うある構造物を作ります。 1つの結果がISO-8859-1のレパートリーの外でそのデータキャラクタですが、UCS-4のものの中では、有効なSGMLキャラクタになってください。 別のものは番号文字参照の範囲の上限が255〜2147483645まで広げられるということです。 その結果、И。 「キリル文字の大文字I」には有効な参照がありますか? 範囲と技術的な内容はこの仕様から大きな開きがありますが、[ERCS]はユニコードと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.
注意--HTML2.0のもののように、上のSGML宣言はUNUSEDとしてキャラクタNo.128〜159(80〜9F十六進法)を指定します。 これは、その範囲(例えば、’)の中の番号文字参照がHTMLで不法であることを意味します。 ISO8859-1もISO10646もその範囲にキャラクタを保管していません。(それは、制御文字のために予約されます)。
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.0SGML宣言。 構文文字集合宣言は1983年からISO 646.IRV:前者ではなく、より新しいISO 646.IRV:1991、後者に変わりました、米国-ASCIIと同じであることで。 原則として、これはHTML2.0で不一致を導入しますが、実際には、SGML宣言に構文文字集合をドキュメント文字集合の真部分集合にしながら皆が考えることとii)を言わせながら、それはi)で相互運用性を増強するべきです。 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
ISO10646-1:1993は現在そこに存在する最も多くの取り囲む文字集合がHTMLのためのドキュメント文字集合として代わりをすることができた他の文字集合でないということです。 それにもかかわらず、この規格の外にキャラクタを使用する必要が特定のアプリケーションのためにあれば、プレゼントとのどんな闘争も避けることによって、これをするべきです。
Yergeau, et. al. Standards Track [Page 7] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[7ページ]。
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.
または、すなわち、UCS-4コード化スペース[ISO-10646部11]の個人的なゾーンにこれらのキャラクタを選任するのによるISO10646の将来のバージョン。 また、そのような使用が非常に「非-携帯用」になるのが覚えておかれるべきです。 多くの場合、インラインビットマップを使用しているほうがよいかもしれません。
2.3. Undisplayable characters
2.3. 表示できないキャラクタ
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:
完全なISO10646であるドキュメント文字集合で、適切なリソース(フォント)の不足のためキャラクタを見せることができない可能性を避けることができません。 このような場合にはできる多くのいろいろなものがあるので、このドキュメントは少しの特定のふるまいも定めません。 実装によって、また、これはアプリケーションではなく、下盛ディスプレイ・システム自体によって扱われるかもしれません。 しかしながら、以下の問題は役に立つかもしれません:
- 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].
- 行方不明のキャラクタの数値表現を与えるといけないので、16進(10進でない)フォームは好まれることです、このフォームが文字集合規格[ERCS]に使用されるので。
3. The LANG attribute
3. ラング属性
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.
いろいろドキュメントにマークされたaのレンダリングを制御するのに言語タグを使用できます: 文字符号化が特定のglyphに決議するために十分でない場合におけるglyph曖昧さの解消。 引用符。 ハイフン付き。 ひも。 スペース。 音声合成。 など レンダリング問題の如何にかかわらず、言語マークアップは分類や探すことなどの目的のための満足しているマーク付けとして役に立ちます。
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要素がラング属性を認めます。 DTDはこれを反映します。 ラング属性のないHTMLのこのバージョンにおける唯一の要素が、BRと、HRと、基地と、NEXTIDと、METAです。 また、HTMLの後のバージョンで紹介されたどんな新しい要素もラング属性を認めることを意図します、そうしないようにもっともな理由がない場合。
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.
言語属性(ラング)は値として話されたか、書かれたか、または情報に関するコミュニケーションのために別の方法で人間によって他の人間まで運ばれた自然言語を特定する言語タグをみなします。 コンピュータ言語は明らかに除かれます。
Yergeau, et. al. Standards Track [Page 8] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[8ページ]。
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の構文と登録はRFC1766[RFC1766]によって定義されたそれと同じです。 概要では、言語タグは1つ以上の部品で構成されます: プライマリ言語タグと「副-タグ」のことによると空のシリーズ:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
言語タグ=プライマリタグ*(「-」subtag)プライマリタグ=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
アン、アン米国の、そして、アンロンドン子のi-cherokee、xブタラテン
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の文脈では、RFC1766に従ってただ一つのトークンにもかかわらず、階層構造として言語タグを解釈してはいけません。 例えば、言語に応じてレンダリングを調整するユーザエージェントは、スタイルシートエントリーにおける言語タグが要素の言語タグの初期の部分に合っているとそれが競技すると考えるべきです。 完全な一致は好まれるべきです。 この解釈で、例えば、「アン米国」として値上げされた要素は好みの順に米国にイギリスの(「アン米国」)的、または、'明瞭である'か'国際的な'イギリスの(「アン」)に対応するスタイルの引き金となることができます。
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.
注意--階層構造として言語タグを使用するのは、一般的な接頭語があるすべての言語がそれらの言語の1つ以上が流暢なそれらに解釈されるのを含意しません。 そのユーザにとって、それが本当であるときに、それで、ユーザは単にこの共通点を要求できます。
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.
要素のレンダリングはラング属性で影響を受けるかもしれません。 どんな要素のためにも、ラング属性の値はどんな同封要素のラング属性とHTTP Content-言語ヘッダーの値(もしあれば)によっても指定された値をくつがえします。 これらのいずれも設定されないなら、適当な恐らくユーザー選択、自動文脈処理またはユーザの現場によって制御されたデフォルトは、レンダリングを制御するのに使用されるべきです。
4. Additional entities, attributes and elements
4. 追加実体、属性、および要素
4.1. Full Latin-1 entity set
4.1. 完全なラテン語-1エンティティ・セット
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.
[RFC1866]のセクション14の提案に従って、ラテン語-1実体のセットはISO8859-1の右の全体の部分をカバーするために広げられます(高位のビットがあるすべてのコード位置がセットしました)、既に一般的に使用された 、©、および®を含んでいて。実体の名前はSGML[ISO-8879]の付録から抜粋されます。 この仕様のセクション7.3にリストを提供します。
Yergeau, et. al. Standards Track [Page 9] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[9ページ]。
4.2. Markup for language-dependent presentation
4.2. 言語依存するプレゼンテーションのためのマーク付け
4.2.1. Overview
4.2.1. 概要
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].
上記の特徴のいくつかがほとんど追加的支援を必要としません。 他のものは以上を必要とします。 以下で簡単な感想だけで付加的な機能を導入します。 ふるまいに参加する草書と双方向のテキストに関する説明は後で続きます。 ふるまいに参加する草書と双方向のテキストのために、このドキュメントはそれで[ユニコード]に続きます: i)キャラクタ意味論、適切などこが機能性が、より高い平らなプロトコルとしてHTMLに動かされて、これが[ユニコード]で定義された低レベルメカニズムに簡単な変換を許す方法で行われる[ユニコード]、およびii)と同じであるか。
4.2.2. List of entities, elements, and attributes
4.2.2. 実体、要素、および属性のリスト
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.
まず最初に、ジェネリックコンテナが場合におけるラングとDIR(以下を見る)属性を他の要素がないのが適切であるところまで運ぶのに必要です。 SPAN要素はそのために紹介されます。
Yergeau, et. al. Standards Track [Page 10] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[10ページ]。
A set of named character entities is added for use with bidirectional rendering and cursive joining control:
双方向のレンダリングと草書がコントロールに参加している状態で、1セットの命名されたキャラクタ実体は使用のために加えられます:
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
= いなくなっている正しいマーク><!実体rlm CDATA""が権利から左のマークと等しいという= 幅がないことの非joiner><!実体zwj CDATA""が幅がないことのjoinerと等しいという<!ENTITY zwnj CDATA""><!実体lrm CDATA"">。
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に紹介されて、制限されています(左に正しい)、双方向のテキストの文脈における、方向性のしるしのために(見る、4.2、.4、詳細のための下) どんなテキストと他の多くの要素(例えば、テーブル)にも方向性を論理的に割り当てることができるので、BR、HR、基地、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 Override)と呼ばれる新しい句レベル要素(オーバーライドが右から右への左かそれとも左であるかを指定するために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は、言語とプラットホーム能力による短い引用の言語依存するレンダリングを許容するために紹介されます。 以下の例が示すように(かなりインターネット仕様の文字集合制限のために気分の悪い)、引用を囲む引用符は特に影響を受けます: 「「英語の引用」、'別のものの、そして、わずかに良い1つ'、ドイツ語の引用、」、フランスの>>Q要素のコンテンツにおける<<a引用は引用符(レンダリングプロセスによって加えられなければならないもの)を含んでいません。
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要素を入れ子にすることができます。 多くの言語が外側の、そして、内側の引用に異なった引用スタイルを使用します、そして、これは、この要素を実装しながら、ユーザエージェントによって尊敬されるべきです。
Yergeau, et. al. Standards Track [Page 11] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[11ページ]。
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デュポン」は上付き文字で"lle"を持つべきです。 SUP要素、および添字テキストのための兄弟SUBは、そのようなテキストの適切なマーク付けを許容するために紹介されます。 SUPとSUBコンテンツは、問題を入れ子にするのを避けるために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、センター、およびJUSTIFY)は、それが理解できるいくつかの要素(ブロックのようなP、HR、H6へのH1、OL、UL、ディル、MENU、李、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.
注意--RFC1866部4.2 .2 前フォーマットされたテキストを除いて、HTMLユーザエージェントが単語スペースとして行末を扱うべきであると指定します。 これは処理されるスクリプトの文脈で解釈されるべきです、単語が文章で切り離される方法がスクリプト依存しているとき。 いくつかのスクリプト(例えば、ラテン語)、スペースがただスペースであるのにもかかわらずの、他のスクリプト(例えば、タイ語)で、それが無幅であるという単語に関しては、まだ他のスクリプト(例えば、日本語)でそれが全く何でもありませんが、すなわち、完全に無視されていた状態で分離符を言い表してください。
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
­. 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)はユーザエージェントimplementersから特別な注意を必要とします。 それは、多くの文字集合(8859年の全体のISOシリーズともちろんISO10646を含んでいる)で存在していて、参照によっていつも含むことができます。意味論は明瞭なHYPHENと異なっています: それは、一言で言えば、ラインブレイクがどこに許容されているかをポイント示します。 系列が本当にそこで壊れているなら、最初の行の終わりにハイフンを表示しなければなりません。 そうでなければ、キャラクタは全くdispalyedされません。 探すのとソーティングのような操作では、それをいつも無視しなければなりません。
Yergeau, et. al. Standards Track [Page 12] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[12ページ]。
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では、ラングとDIR属性はattrsと呼ばれるパラメタ実体で一緒に分類されます。 また、RFC1942[RFC1942]、IDとCLASSに沿うように、属性はattrsに含まれています。 IDとCLASS属性が使用にスタイルシートで必要です、そして、RFC1942は以下の通りそれらを定義します:
ID 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 Used。 ハイパーテキストリンクの目的地としてドキュメントの中に位置を任命するのにこれを使用できます。 また、それは、ユニークなスタイルに要素を表すのにスタイルシートによって使用されるかもしれません。 ID属性値はSGML NAMEトークンです。 「NAMEトークンは」 . 」 手紙、ケタ、「-」、およびキャラクタによって従われた大文字で形成されます。 手紙は、A-Zに制限されるのと1zです。
CLASS 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.
CLASS AスペースはSGML NAMEトークンのリストを切り離しました。 CLASS名は、要素がクラスという対応に属すと指定します。 それで、作者は同じタグによってプレーされた異なる役割を区別できます。 クラスはスタイルシートによって使用されて、適宜異なったレンダリングをこれらの役割に提供するかもしれません。
4.2.3. Cursive joining behaviour
4.2.3. 草書接合のふるまい
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 (‍ and ‌) 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.
無幅のjoinerと非joiner、(zwj、; zwnj) 草書接合のふるまいを制御するために、使用されます。 例えば、ARABIC LETTER HEHは"Hijri"(イスラム教のcalendricalシステム)を簡略化するのに分離して使用されます。 しかしながら、手紙の初期のフォームは望まれています、HEHの孤立形がアラビア文字で使われるようにケタfiveに似ているので。 文脈を提供する唯一の効果がことである無幅のjoinerでHEHに続くことによって、これを得ます。 ペルシアのテキストには、通常、その後の手紙に草書接続で加わる手紙がそうしないケースがあります。 ここで、無幅の非joinerは使用されています。
4.2.4. Bidirectional text
4.2.4. 双方向のテキスト
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
多くの言語が左から右まで水平な線に書かれていますが、他のものは左への権利から書かれます。 ともに書いている方向が存在しているとき、人は双方向のテキスト(略してBIDI)について話します。 BIDIテキストは何人かのキャラクタの方向性に関するあいまいさが取り除かれなければならない特殊事情のマーク付けを必要とします。 このマークアップは意味的に読みやすいファッションでテキストをBIDIに表す能力に影響します。 すなわち、この特別なBIDIマークアップがなければ、*を防ぐケースが起こる、全くどんな*レンダリング
Yergeau, et. al. Standards Track [Page 13] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[13ページ]。
that reflected the basic meaning of the text. Plain text may contain BIDI markup in the form of special-purpose formatting characters.
それはテキストの基本的な意味を反映しました。 プレーンテキストは専用形式キャラクタの形に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で可能です。(それは、ISO10646のBIDI関連の5形式文字(202A--202E)を含んでいます)。 代替手段として、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は複雑な問題です、そして、[ユニコード]で指定されたアルゴリズムとキャラクタの特性に従って、系列を表示する論理的なテキスト系列の変換をしなければなりません。 ここに、単にそれらが導入された特徴の必要性を理解して、それらの正確な意味論を定義するのが必要である限り、説明をします。
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.
ユニコードBIDIアルゴリズムはすなわち、論理的順序に保存される、テキストの個性、通常、それらが入力されて、通常、対応する音が話されるオーダーに基づいています。 論理的順序テキストのレンダリングを可能にするように、アルゴリズムは例えば各キャラクタへの方向性の特性を割り当てます。ヘブライ人のキャラクタには、ラテン語の手紙は左から右への方向を持つために指定されます、アラビアであり、右から左への方向があります。
The left-to-right and right-to-left marks (‎ and ‏) 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) 公平無私のキャラクタの方向性のあいまいさを除くために、使用されます。 二重引用文がアラビアの手紙とラテン語の手紙の間に座るとき、例えば、方向はあいまいです。 半面の上で方向のマークを加えるなら、引用符が1つの方向性だけ、あいまいさのキャラクタによって囲まれるようなものを取り除きます。 これらのキャラクタは方向の特性(しかし、単語/ラインブレイクの特性がない)を持っているどんな幅の空間にも似ていません。
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.
contra方向のテキストの入れ子にされた埋め込みが入れ子にされた引用のため稼働していますか、またはマーク付けを必要として、テキストを1つのBIDI文脈から別の文脈までの貼るのに、ケースもキャラクタの暗黙の方向性が十分でないところにありますか? また、1ブロックのテキストの基本的な方向性を指定するのも頻繁に望ましいです。 これらの目的のために、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.
インライン要素の上では、それで、要素は新しい埋め込みレベル(以下で説明される)を始めます。 省略されるなら、インライン要素は新しい埋め込みレベルを始めません。
Yergeau, et. al. Standards Track [Page 14] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[14ページ]。
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:
支援の以下のラテン(大文字)とarabic(小文字)手紙を考えて、指定された埋め込みで以下を保存してください。
<SPAN DIR=LTR> AB <SPAN DIR=RTL> xy <SPAN DIR=LTR> CD </SPAN> zw
</SPAN> EF </SPAN>
LTR>AB<SPAN DIR=RTL>xy<<SPAN DIR=SPAN DIRはLTR>CD</SPAN>zw</SPAN>EF</SPAN>と等しいです。
One gets the following rendering (with [] showing the directional
transitions):
1つは以下のレンダリング(方向の変遷を示している[]での)を得ます:
[ AB [ wz [ CD ] yx ] EF ]
[AB[wz[CD]yx]EF]
On the other hand, without this markup and with a base direction
of LTR one gets the following rendering:
他方では、このマークアップなしでベースで、LTR1の方向は以下のレンダリングを得ます:
[ AB [ yx ] CD [ wz ] EF ]
[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に埋め込みレベルが使用されている上のケースと異なっているのに注意してください。 埋め込みがなければ、マークアップ1はほとんどの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.
ISO10646の形式キャラクタのLEFT-TO-RIGHT EMBEDDING(202A)とRIGHT-TO-LEFT EMBEDDING(202B)に、インライン要素のDIR属性は同等です。 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要素で提供する方向のオーバーライドが、明白なファッションによる文脈から方向性を決議できないテキストの珍しい小品に対処するのに必要です。 例えば、左から右(または、右から左)へのラテン語の手紙、ケタ、およびヘブライ文字で構成された部品番号のディスプレイを強制するのにそれを使用できます。
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の値に強制することです、彼らの本質的な方向の特性の如何にかかわらず。 それはISO10646(POP DIRECTIONAL FORMATTING(202C)キャラクタには、再び同等な終了タグ)のLEFT-TO-RIGHT OVERRIDE(202D)かRIGHT-TO-LEFT OVERRIDE(202E)キャラクタを使用するのに同等です。
Yergeau, et. al. Standards Track [Page 15] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[15ページ]。
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.
注意--作者とオーサリングソフト作家はDIR属性が同時にインライン要素(BDOを含んでいる)の上で対応するISO10646形式キャラクタの使用で使用されるなら闘争が起こることができるのを意識しているべきです。
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.
望ましくは、1かもう片方が排他的に使用されるべきです。 マークアップ方式は、構造的な保全をドキュメントによりよく保証できて、簡単なテキストエディタで双方向のHTMLテキストを編集するとき、いくつかの問題を軽減しますが、10646のキャラクタを使用するところでは、何らかのソフトウェアが、よりしやすいかもしれません。 両方のメソッドが使用されているなら、高度の注意はマーク付けと方向の埋め込みかオーバーライドの適切な巣篭もりを保障するのに運動させられるべきです。 さもなければ、レンダリング結果は未定義です。
5. Forms
5. フォーム
5.1. DTD additions
5.1. DTD追加
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.
最大限のインターオペラビリティを確実にするために、ユーザエージェント(そして、ユーザ)にはフォームを提供するサーバが記入している形式の服従のときに扱うことができる文字符号化のしるしがあるのが必要です。 サーバに許容できる文字集合のスペース、そして/または、コンマの区切られたリストを含むHTTP Accept-Charsetヘッダー([HTTP-1.1]を見る)に似せられたINPUTとTEXTAREA要素の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.
注意--文字集合のリストはEXCLUSIVE-ORリストとして解釈されることです。 サーバは、それを複合実体の各部分のこれらの文字符号化体系のどんなONEも受け入れる準備ができていると発表します。 クライアントは、必要なら、サーバを満たすために文字符号化翻訳を実行するかもしれません。
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属性のためのデフォルト値は予約された値の「未知」です。 ユーザエージェントはその要素を含むドキュメントを伝えるのに使用された文字符号化体系としてその値を解釈するかもしれません。
Yergeau, et. al. Standards Track [Page 16] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[16ページ]。
5.2. Form submission
5.2. フォーム服従
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.
「urlencodedされたx wwwアプリケーション/フォーム」メディアタイプに基づくHTML2.0フォーム服従メカニズムは国際化に関してほとんど備えられていません。 事実上、URLがASCII文字に制限されるので、メカニズムはISO-8859-1テキストさえのためのakwardです。 「[RFC1738]のセクション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.
最も良いソリューションは[RFC1867]でフォーム服従のポストメソッドで説明された「複合かデータを形成している」メディアタイプを使用することです。 このメカニズムはHTTP実体として送られる複合MIME身体の身体部分でそれぞれの名前価値の組の値の部をカプセル化します。 適切なコンテントタイプでそれぞれの身体の部分をラベルできます、必要なら文字符号化体系を指定するcharsetパラメタを含んでいて。 フォーム服従のこのメソッドをサポートするのに必要な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.
それほど満足できないソリューションは「x-wwwフォームはアプリケーション/urlencodedしている」メディア型指定子へのMIME charsetパラメタがポストのメソッドフォーム提案と共に発信したと言い足すことです、[RFC1738]のURLコード化が指定された文字符号化の上で適用されるという条件で、一種の暗黙のContent転送コード化として。
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つの問題は一般に、現在のブラウザが、ブックマークがポストメソッドを指定するのを許容しないということです。 これは改良されるべきです。 逆に、URLの代わりにボディーで伝えられるフォームデータと共にGETメソッドを使用できました。 プロトコルの何もそれを防ぐように思えませんが、実装は全く現在のところ存在するように見えません。
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属性)のデフォルト値がフォーム服従のときに返されるとき(すなわち、ユーザはこの値を変更しませんでした)、ソースドキュメントがそれと同じ八重奏の系列、テキスト要素の同じ系列のことによると異なりましたが、有効なコード化としてだけ伝えられるのは保証されているはずがありません。 フォームを含むドキュメントのコード化と服従に使用されるそれが同じであっても、これは本当であるかもしれません。
Yergeau, et. al. Standards Track [Page 17] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[17ページ]。
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.
キャラクタの系列が様々な系列で八重奏について表して、また、異なりましたが、同等なコンポジット・シーケンスか完全に前構成されたキャラクタがコンポジット・シーケンス(基本文字と1かさらに結合した区別的発音符)を表すことができるとき表すことができるとき、違いは起こることができます。 例えば、UCS-2系列00EA+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
6. 外部の文字符号化問題
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サーバはContentタイプヘッダーがある適切なcharsetパラメタを含んでいません。 これは悪いふるまいです。(そのふるまいはそれらであるときに、認識されていないメディアタイプがcharsetパラメタを受け取ると宣言するブラウザの存続によって奨励さえされます)。 ユーザエージェントimplementatorsで彼らのソフトウェアがこのパラメタにおいて許容性があるようになるよう強く奨励されます、彼らがそれを利用できないでも。 適切なラベルは非常に望ましいのですが、不在の有害な影響を最小にするためにいくつかの予防策を取ることができます:
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ドキュメントのハイパーリンクからアクセスされる場合では、CHARSET属性はリンク意味論(AとLINK)で要素の属性リストに追加されます、特にlinkExtraAttributes実体にそれを加えることによって。 その属性の値はハイパーリンクによって示されたリソースによって使用される文字符号化体系に関するUserエージェントへのヒントであると考えられることです。 それはそのリソースのための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">
「コンテントタイプ」<メタHTTP-EQUIV=内容は「テキスト/html」と等しいです。 charset=ISO2022JP">"
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]を見てください。
Yergeau, et. al. Standards Track [Page 18] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[18ページ]。
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バイトの量のための既存のネットワークバイトオーダーに対応する大きいエンディアンバイトオーダー(高値は最初に、バイトを命令する)で伝えられることを勧めます、連載されたテキストデータとRFC1641へのISO10646要件とユニコード推薦に。 その上、適切な解釈の機会を最大にするために、推薦されて、バイトによって逆にされると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 Transformation FormatsはUCS-2とUCS-4に加えたUCSデータを送るのに使用できるより存在しています。 UTF-7[RFC1642]とUTF-8[UTF-8]には、それらを考慮にふさわしくする好ましい特性(バイト順問題がない、ASCIIの互換性の異なった風味)があります、特に多言語テキストの送信のために。 また、別のコード化体系(MNEM[RFC1345])には、興味深い特性と完全なUCSを伝える能力があります。 ISOのUTF-1変換形式、10646:1993 (ISO10646-UTF-1としてIANAによって登録される)です、ISO10646から修正4で取り除いて、使用するべきではありません。
Yergeau, et. al. Standards Track [Page 19] RFC 2070 HTML Internationalization January 1997
et Yergeau、アル。 規格はHTML国際化1997年1月にRFC2070を追跡します[19ページ]。
7. HTML Public Text
7. HTMLの公共のテキスト
7.1. HTML DTD
7.1. HTML DTD
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.
このセクションはRFC1866のHTML2.0DTDに基づくHTMLのためのDTDを含みます、RFC1867の指定されるとしてのファイルアップロード、およびこのドキュメントに由来している変化のために変化を取り入れて。
<!-- html.dtd
<!--html.dtd
Document Type Definition for the HyperText Markup Language,
extended for internationalisation (HTML DTD)
国際化のために広げられたハイパーテキストマークアップランゲージのためのドキュメントType Definition(HTML DTD)
Last revised: 96/08/07
最後に改訂されています: 96/08/07
Authors: Daniel W. Connolly <connolly@w3.org>
Francois Yergeau <yergeau@alis.com>
See Also:
http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
作者: ダニエルW. Connolly <connolly@w3.org 、gt;、フランソア Yergeau <yergeau@alis.com 、gt;、参照: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html -->。
<!ENTITY % HTML.Version
"-//IETF//DTD HTML i18n//EN"
<!実体%、HTML.Version「-//IETF//DTD HTML i18n//アン」
-- Typical usage:
-- 典型的な用法:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">
<html>
...
</html>
--
>
<!DOCTYPE HTML公衆、「-//IETF//DTD HTML i18n//アン「>の<のhtml>…」 </html>-->。
<!--============ 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.Recommended [
<!ENTITY % HTML.Deprecated "IGNORE">
]]>
<![%HTML.Recommended、[<!実体%HTML.Deprecated、「「>] >」を無視してください。
Yergeau, et. al. Standards Track [Page 20] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 20] RFC 2070 HTML Internationalization January 1997
<!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.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.
-->
<!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. -->
<!ENTITY % HTML.Forms "INCLUDE"
-- Use this feature test entity to validate that a document
contains no forms, which may not be supported in minimal
implementations
-->
<!ENTITY % HTML.Forms "INCLUDE" -- Use this feature test entity to validate that a document contains no forms, which may not be supported in minimal implementations -->
<!--============== Imported Names ==============================-->
<!--============== Imported Names ==============================-->
<!ENTITY % Content-Type "CDATA"
-- meaning an internet media type
(aka MIME content type, as per RFC2045)
-->
<!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
-->
<!ENTITY % HTTP-Method "GET | POST" -- as per HTTP specification, RFC2068 -->
<!--========= DTD "Macros" =====================-->
<!--========= DTD "Macros" =====================-->
<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
<!ENTITY % list " UL | OL | DIR | MENU " >
<!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 % 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"
<!ENTITY % just -- an attribute for text justification -- "ALIGN (left|right|center|justify) #IMPLIED"
Yergeau, et. al. Standards Track [Page 21] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 21] RFC 2070 HTML Internationalization January 1997
-- default is left for ltr paragraphs, right for rtl -- >
-- default is left for ltr paragraphs, right for rtl -- >
<!--======= Character mnemonic entities =================-->
<!--======= Character mnemonic entities =================-->
<!ENTITY % ISOlat1 PUBLIC
"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;
<!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML"> %ISOlat1;
<!ENTITY amp CDATA "&" -- ampersand --> <!ENTITY gt CDATA ">" -- greater than --> <!ENTITY lt CDATA "<" -- less than --> <!ENTITY quot CDATA """ -- double quote -->
<!ENTITY amp CDATA "&" -- ampersand --> <!ENTITY gt CDATA ">" -- greater than --> <!ENTITY lt CDATA "<" -- less than --> <!ENTITY quot CDATA """ -- double quote -->
<!--Entities for language-dependent presentation (BIDI and
contextual analysis) -->
<!ENTITY zwnj CDATA "‌"-- zero width non-joiner-->
<!ENTITY zwj CDATA "‍"-- zero width joiner-->
<!ENTITY lrm CDATA "‎"-- left-to-right mark-->
<!ENTITY rlm CDATA "‏"-- right-to-left mark-->
<!--Entities for language-dependent presentation (BIDI and contextual analysis) --> <!ENTITY zwnj CDATA ""-- zero width non-joiner--> <!ENTITY zwj CDATA ""-- zero width joiner--> <!ENTITY lrm CDATA ""-- left-to-right mark--> <!ENTITY rlm CDATA ""-- right-to-left mark-->
<!--========= SGML Document Access (SDA) Parameter Entities =====-->
<!--========= 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
SDA & ICADD:
- ISO 12083:1993, Annex A.8, Facilities for Braille,
large print and computer voice
- ICADD ListServ
<ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
- Usenet news group bit.listserv.easi
- Recording for the Blind, +1 800 221 4792
-->
<!-- 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 SDA & ICADD: - ISO 12083:1993, Annex A.8, Facilities for Braille, large print and computer voice - ICADD ListServ <ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu> - Usenet news group bit.listserv.easi - Recording for the Blind, +1 800 221 4792 -->
<!ENTITY % SDAFORM "SDAFORM CDATA #FIXED"
-- one to one mapping -->
<!ENTITY % SDARULE "SDARULE CDATA #FIXED"
-- context-sensitive mapping -->
<!ENTITY % SDAPREF "SDAPREF CDATA #FIXED"
-- generated text prefix -->
<!ENTITY % SDASUFF "SDASUFF CDATA #FIXED"
-- generated text suffix -->
<!ENTITY % SDASUSP "SDASUSP NAME #FIXED"
<!ENTITY % SDAFORM "SDAFORM CDATA #FIXED" -- one to one mapping --> <!ENTITY % SDARULE "SDARULE CDATA #FIXED" -- context-sensitive mapping --> <!ENTITY % SDAPREF "SDAPREF CDATA #FIXED" -- generated text prefix --> <!ENTITY % SDASUFF "SDASUFF CDATA #FIXED" -- generated text suffix --> <!ENTITY % SDASUSP "SDASUSP NAME #FIXED"
Yergeau, et. al. Standards Track [Page 22] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 22] RFC 2070 HTML Internationalization January 1997
-- suspend transform process -->
-- suspend transform process -->
<!--========== Text Markup =====================-->
<!--========== Text Markup =====================-->
<![ %HTML.Highlighting [
<![ %HTML.Highlighting [
<!ENTITY % font " TT | B | I ">
<!ENTITY % font " TT | B | I ">
<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
<!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">
<!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">
<!ELEMENT (%font;|%phrase) - - (%text)*>
<!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
%attrs;
%SDAFORM; "Lit"
>
<!ELEMENT (%font;|%phrase) - - (%text)*> <!ATTLIST ( TT | CODE | SAMP | KBD | VAR ) %attrs; %SDAFORM; "Lit" >
<!ATTLIST ( B | STRONG )
%attrs;
%SDAFORM; "B"
>
<!ATTLIST ( I | EM | CITE )
%attrs;
%SDAFORM; "It"
>
<!ATTLIST ( B | STRONG ) %attrs; %SDAFORM; "B" > <!ATTLIST ( I | EM | CITE ) %attrs; %SDAFORM; "It" >
<!-- <TT> Typewriter text --> <!-- <B> Bold text --> <!-- <I> Italic text -->
<!-- <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 -->
<!-- <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">
<!ENTITY % pre.content "#PCDATA|A|HR|BR|%font|%phrase|SPAN|BDO">
]]>
]]>
<!ENTITY % text "#PCDATA|A|IMG|BR|SPAN|Q|BDO|SUP|SUB">
<!ENTITY % text "#PCDATA|A|IMG|BR|SPAN|Q|BDO|SUP|SUB">
<!ELEMENT BR - O EMPTY> <!ATTLIST BR
<!ELEMENT BR - O EMPTY> <!ATTLIST BR
Yergeau, et. al. Standards Track [Page 23] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 23] RFC 2070 HTML Internationalization January 1997
%SDAPREF; "&#RE;"
>
%SDAPREF; "&#RE;" >
<!-- <BR> Line break -->
<!-- <BR> Line break -->
<!ELEMENT SPAN - - (%text)*>
<!ATTLIST SPAN
%attrs;
%SDAFORM; "other #Attlist"
>
<!ELEMENT SPAN - - (%text)*> <!ATTLIST SPAN %attrs; %SDAFORM; "other #Attlist" >
<!-- <SPAN> Generic inline container --> <!-- <SPAN DIR=...> New counterflow embedding --> <!-- <SPAN LANG="..."> Language of contents -->
<!-- <SPAN> Generic inline container --> <!-- <SPAN DIR=...> New counterflow embedding --> <!-- <SPAN LANG="..."> Language of contents -->
<!ELEMENT Q - - (%text)*>
<!ATTLIST Q
%attrs;
%SDAPREF; '"'
%SDASUFF; '"'
>
<!ELEMENT Q - - (%text)*> <!ATTLIST Q %attrs; %SDAPREF; '"' %SDASUFF; '"' >
<!-- <Q> Short quotation --> <!-- <Q LANG=xx> Language of quotation is xx --> <!-- <Q DIR=...> New conterflow embedding -->
<!-- <Q> Short quotation --> <!-- <Q LANG=xx> Language of quotation is xx --> <!-- <Q DIR=...> New conterflow embedding -->
<!ELEMENT BDO - - (%text)+>
<!ATTLIST BDO
LANG NAME #IMPLIED
DIR (ltr|rtl) #REQUIRED
ID ID #IMPLIED
CLASS NAMES #IMPLIED
%SDAPREF "Bidi Override #Attval(DIR): "
%SDASUFF "End Bidi"
>
<!ELEMENT BDO - - (%text)+> <!ATTLIST BDO 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 -->
<!-- <BDO DIR=...> Override directionality of text to value of DIR --> <!-- <BDO LANG=...> Language of contents -->
<!ELEMENT (SUP|SUB) - - (#PCDATA)>
<!ATTLIST (SUP)
%attrs;
%SDAPREF "Superscript(#content)"
>
<!ATTLIST (SUB)
%attrs;
%SDAPREF "Subscript(#content)"
>
<!ELEMENT (SUP|SUB) - - (#PCDATA)> <!ATTLIST (SUP) %attrs; %SDAPREF "Superscript(#content)" > <!ATTLIST (SUB) %attrs; %SDAPREF "Subscript(#content)" >
Yergeau, et. al. Standards Track [Page 24] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 24] RFC 2070 HTML Internationalization January 1997
<!-- <SUP> Superscript --> <!-- <SUB> Subscript -->
<!-- <SUP> Superscript --> <!-- <SUB> Subscript -->
<!--========= Link Markup ======================-->
<!--========= Link Markup ======================-->
<!ENTITY % linkType "NAMES">
<!ENTITY % linkType "NAMES">
<!ENTITY % linkExtraAttributes
"REL %linkType #IMPLIED
REV %linkType #IMPLIED
URN CDATA #IMPLIED
TITLE CDATA #IMPLIED
METHODS NAMES #IMPLIED
CHARSET NAME #IMPLIED
">
<!ENTITY % linkExtraAttributes "REL %linkType #IMPLIED REV %linkType #IMPLIED URN CDATA #IMPLIED TITLE CDATA #IMPLIED METHODS NAMES #IMPLIED CHARSET NAME #IMPLIED ">
<![ %HTML.Recommended [
<!ENTITY % A.content "(%text)*"
<![ %HTML.Recommended [ <!ENTITY % A.content "(%text)*"
-- <H1><a name="xxx">Heading</a></H1>
is preferred to
<a name="xxx"><H1>Heading</H1></a>
-->
]]>
-- <H1><a name="xxx">Heading</a></H1> is preferred to <a name="xxx"><H1>Heading</H1></a> --> ]]>
<!ENTITY % A.content "(%heading|%text)*">
<!ENTITY % A.content "(%heading|%text)*">
<!ELEMENT A - - %A.content -(A)>
<!ATTLIST A
%attrs;
HREF CDATA #IMPLIED
NAME CDATA #IMPLIED
%linkExtraAttributes;
%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 -->
<!ELEMENT A - - %A.content -(A)> <!ATTLIST A %attrs; HREF CDATA #IMPLIED NAME CDATA #IMPLIED %linkExtraAttributes; %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 ==========================-->
<!--========== Images ==========================-->
Yergeau, et. al. Standards Track [Page 25] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 25] RFC 2070 HTML Internationalization January 1997
<!ELEMENT IMG - O EMPTY>
<!ATTLIST IMG
%attrs;
SRC CDATA #REQUIRED
ALT CDATA #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
ISMAP (ISMAP) #IMPLIED
%SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
>
<!ELEMENT IMG - O EMPTY> <!ATTLIST IMG %attrs; SRC CDATA #REQUIRED ALT CDATA #IMPLIED ALIGN (top|middle|bottom) #IMPLIED ISMAP (ISMAP) #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 -->
<!-- <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=======================-->
<!--========== Paragraphs=======================-->
<!ELEMENT P - O (%text)*>
<!ATTLIST P
%attrs;
%just;
%SDAFORM; "Para"
>
<!ELEMENT P - O (%text)*> <!ATTLIST P %attrs; %just; %SDAFORM; "Para" >
<!-- <P> Paragraph --> <!-- <P LANG="..."> Language of paragraph text --> <!-- <P DIR=...> Base directionality of paragraph --> <!-- <P ALIGN=...> Paragraph alignment (justification) -->
<!-- <P> Paragraph --> <!-- <P LANG="..."> Language of paragraph text --> <!-- <P DIR=...> Base directionality of paragraph --> <!-- <P ALIGN=...> Paragraph alignment (justification) -->
<!--========== Headings, Titles, Sections ===============-->
<!--========== Headings, Titles, Sections ===============-->
<!ELEMENT HR - O EMPTY>
<!ATTLIST HR
%just;
%SDAPREF; "&#RE;&#RE;"
>
<!ELEMENT HR - O EMPTY> <!ATTLIST HR %just; %SDAPREF; "&#RE;&#RE;" >
<!-- <HR> Horizontal rule -->
<!-- <HR> Horizontal rule -->
<!ELEMENT ( %heading ) - - (%text;)*>
<!ATTLIST H1
%attrs;
%just;
%SDAFORM; "H1"
<!ELEMENT ( %heading ) - - (%text;)*> <!ATTLIST H1 %attrs; %just; %SDAFORM; "H1"
Yergeau, et. al. Standards Track [Page 26] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 26] RFC 2070 HTML Internationalization January 1997
>
<!ATTLIST H2
%attrs;
%just;
%SDAFORM; "H2"
>
<!ATTLIST H3
%attrs;
%just;
%SDAFORM; "H3"
>
<!ATTLIST H4
%attrs;
%just;
%SDAFORM; "H4"
>
<!ATTLIST H5
%attrs;
%just;
%SDAFORM; "H5"
>
<!ATTLIST H6
%attrs;
%just;
%SDAFORM; "H6"
>
> <!ATTLIST H2 %attrs; %just; %SDAFORM; "H2" > <!ATTLIST H3 %attrs; %just; %SDAFORM; "H3" > <!ATTLIST H4 %attrs; %just; %SDAFORM; "H4" > <!ATTLIST H5 %attrs; %just; %SDAFORM; "H5" > <!ATTLIST H6 %attrs; %just; %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 -->
<!-- <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 ======================-->
<!--========== Text Flows ======================-->
<![ %HTML.Forms [
<!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
]]>
<![ %HTML.Forms [ <!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX"> ]]>
<!ENTITY % block.forms "BLOCKQUOTE">
<!ENTITY % block.forms "BLOCKQUOTE">
<![ %HTML.Deprecated [
<!ENTITY % preformatted "PRE | XMP | LISTING">
]]>
<![ %HTML.Deprecated [ <!ENTITY % preformatted "PRE | XMP | LISTING"> ]]>
<!ENTITY % preformatted "PRE">
<!ENTITY % preformatted "PRE">
Yergeau, et. al. Standards Track [Page 27] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 27] RFC 2070 HTML Internationalization January 1997
<!ENTITY % block "P | %list | DL
| %preformatted
| %block.forms">
<!ENTITY % block "P | %list | DL | %preformatted | %block.forms">
<!ENTITY % flow "(%text|%block)*">
<!ENTITY % flow "(%text|%block)*">
<!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO">
<!ELEMENT PRE - - (%pre.content)*>
<!ATTLIST PRE
%attrs;
WIDTH NUMBER #implied
%SDAFORM; "Lit"
>
<!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO"> <!ELEMENT PRE - - (%pre.content)*> <!ATTLIST PRE %attrs; 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 -->
<!-- <PRE> Preformatted text --> <!-- <PRE WIDTH=...> Maximum characters per line --> <!-- <PRE DIR=...> Base direction of preformatted block --> <!-- <PRE LANG=...> Language of contents -->
<![ %HTML.Deprecated [
<![ %HTML.Deprecated [
<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the end tag
in full
-->
<!ENTITY % literal "CDATA" -- historical, non-conforming parsing mode where the only markup signal is the end tag in full -->
<!ELEMENT (XMP|LISTING) - - %literal>
<!ATTLIST XMP
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Example:&#RE;"
>
<!ATTLIST LISTING
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Listing:&#RE;"
>
<!ELEMENT (XMP|LISTING) - - %literal> <!ATTLIST XMP %attrs; %SDAFORM; "Lit" %SDAPREF; "Example:&#RE;" > <!ATTLIST LISTING %attrs; %SDAFORM; "Lit" %SDAPREF; "Listing:&#RE;" >
<!-- <XMP> Example section --> <!-- <LISTING> Computer listing -->
<!-- <XMP> Example section --> <!-- <LISTING> Computer listing -->
<!ELEMENT PLAINTEXT - O %literal> <!-- <PLAINTEXT> Plain text passage -->
<!ELEMENT PLAINTEXT - O %literal> <!-- <PLAINTEXT> Plain text passage -->
<!ATTLIST PLAINTEXT
%attrs;
%SDAFORM; "Lit"
<!ATTLIST PLAINTEXT %attrs; %SDAFORM; "Lit"
Yergeau, et. al. Standards Track [Page 28] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 28] RFC 2070 HTML Internationalization January 1997
>
]]>
> ]]>
<!--========== Lists ==================-->
<!--========== Lists ==================-->
<!ELEMENT DL - - (DT | DD)+>
<!ATTLIST DL
%attrs;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "Definition List:"
>
<!ELEMENT DL - - (DT | DD)+> <!ATTLIST DL %attrs; COMPACT (COMPACT) #IMPLIED %SDAFORM; "List" %SDAPREF; "Definition List:" >
<!ELEMENT DT - O (%text)*>
<!ATTLIST DT
%attrs;
%SDAFORM; "Term"
>
<!ELEMENT DT - O (%text)*> <!ATTLIST DT %attrs; %SDAFORM; "Term" >
<!ELEMENT DD - O %flow>
<!ATTLIST DD
%attrs;
%SDAFORM; "LItem"
>
<!ELEMENT DD - O %flow> <!ATTLIST DD %attrs; %SDAFORM; "LItem" >
<!-- <DL> Definition list, or glossary --> <!-- <DL COMPACT> Compact style list --> <!-- <DT> Term in definition list --> <!-- <DD> Definition of term -->
<!-- <DL> Definition list, or glossary --> <!-- <DL COMPACT> Compact style list --> <!-- <DT> Term in definition list --> <!-- <DD> Definition of term -->
<!ELEMENT (OL|UL) - - (LI)+>
<!ATTLIST OL
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!ATTLIST UL
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!-- <UL> Unordered list -->
<!-- <UL COMPACT> Compact list style -->
<!-- <OL> Ordered, or numbered list -->
<!-- <OL COMPACT> Compact list style -->
<!ELEMENT (OL|UL) - - (LI)+> <!ATTLIST OL %attrs; %just; COMPACT (COMPACT) #IMPLIED %SDAFORM; "List" > <!ATTLIST UL %attrs; %just; COMPACT (COMPACT) #IMPLIED %SDAFORM; "List" > <!-- <UL> Unordered list --> <!-- <UL COMPACT> Compact list style --> <!-- <OL> Ordered, or numbered list --> <!-- <OL COMPACT> Compact list style -->
Yergeau, et. al. Standards Track [Page 29] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 29] RFC 2070 HTML Internationalization January 1997
<!ELEMENT (DIR|MENU) - - (LI)+ -(%block)>
<!ATTLIST DIR
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Directory</LHead>"
>
<!ATTLIST MENU
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Menu</LHead>"
>
<!ELEMENT (DIR|MENU) - - (LI)+ -(%block)> <!ATTLIST DIR %attrs; %just; COMPACT (COMPACT) #IMPLIED %SDAFORM; "List" %SDAPREF; "<LHead>Directory</LHead>" > <!ATTLIST MENU %attrs; %just; COMPACT (COMPACT) #IMPLIED %SDAFORM; "List" %SDAPREF; "<LHead>Menu</LHead>" >
<!-- <DIR> Directory list --> <!-- <DIR COMPACT> Compact list style --> <!-- <MENU> Menu list --> <!-- <MENU COMPACT> Compact list style -->
<!-- <DIR> Directory list --> <!-- <DIR COMPACT> Compact list style --> <!-- <MENU> Menu list --> <!-- <MENU COMPACT> Compact list style -->
<!ELEMENT LI - O %flow>
<!ATTLIST LI
%attrs;
%just;
%SDAFORM; "LItem"
>
<!ELEMENT LI - O %flow> <!ATTLIST LI %attrs; %just; %SDAFORM; "LItem" >
<!-- <LI> List item -->
<!-- <LI> List item -->
<!--========== Document Body ===================-->
<!--========== Document Body ===================-->
<![ %HTML.Recommended [
<!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
-- <h1>Heading</h1>
<p>Text ...
is preferred to
<h1>Heading</h1>
Text ...
-->
]]>
<![ %HTML.Recommended [ <!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*" -- <h1>Heading</h1> <p>Text ... is preferred to <h1>Heading</h1> Text ... --> ]]>
<!ENTITY % body.content "(%heading | %text | %block |
HR | ADDRESS)*">
<!ENTITY % body.content "(%heading | %text | %block | HR | ADDRESS)*">
<!ELEMENT BODY O O %body.content>
<!ATTLIST BODY
%attrs;
<!ELEMENT BODY O O %body.content> <!ATTLIST BODY %attrs;
Yergeau, et. al. Standards Track [Page 30] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 30] RFC 2070 HTML Internationalization January 1997
>
>
<!-- <BODY> Document body --> <!-- <BODY DIR=...> Base direction of whole body --> <!-- <BODY LANG=...> Language of contents -->
<!-- <BODY> Document body --> <!-- <BODY DIR=...> Base direction of whole body --> <!-- <BODY LANG=...> Language of contents -->
<!ELEMENT BLOCKQUOTE - - %body.content>
<!ATTLIST BLOCKQUOTE
%attrs;
%just;
%SDAFORM; "BQ"
>
<!ELEMENT BLOCKQUOTE - - %body.content> <!ATTLIST BLOCKQUOTE %attrs; %just; %SDAFORM; "BQ" >
<!-- <BLOCKQUOTE> Quoted passage -->
<!-- <BLOCKQUOTE> Quoted passage -->
<!ELEMENT ADDRESS - - (%text|P)*>
<!ATTLIST ADDRESS
%attrs;
%just;
%SDAFORM; "Lit"
%SDAPREF; "Address:&#RE;"
>
<!ELEMENT ADDRESS - - (%text|P)*> <!ATTLIST ADDRESS %attrs; %just; %SDAFORM; "Lit" %SDAPREF; "Address:&#RE;" >
<!-- <ADDRESS> Address, signature, or byline -->
<!-- <ADDRESS> Address, signature, or byline -->
<!--======= Forms ====================-->
<!--======= Forms ====================-->
<![ %HTML.Forms [
<![ %HTML.Forms [
<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
<!ATTLIST FORM
%attrs;
ACTION CDATA #IMPLIED
METHOD (%HTTP-Method) GET
ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
%SDAPREF; "<Para>Form:</Para>"
%SDASUFF; "<Para>Form End.</Para>"
>
<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)> <!ATTLIST FORM %attrs; ACTION CDATA #IMPLIED 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 -->
<!-- <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 -->
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
Yergeau, et. al. Standards Track [Page 31] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 31] RFC 2070 HTML Internationalization January 1997
RADIO | SUBMIT | RESET |
IMAGE | HIDDEN | FILE )">
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
%attrs;
TYPE %InputType TEXT
NAME CDATA #IMPLIED
VALUE CDATA #IMPLIED
SRC CDATA #IMPLIED
CHECKED (CHECKED) #IMPLIED
SIZE CDATA #IMPLIED
MAXLENGTH NUMBER #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
ACCEPT CDATA #IMPLIED --list of content types --
ACCEPT-CHARSET CDATA #IMPLIED --list of charsets accepted --
%SDAPREF; "Input: "
>
RADIO | SUBMIT | RESET | IMAGE | HIDDEN | FILE )"> <!ELEMENT INPUT - O EMPTY> <!ATTLIST INPUT %attrs; TYPE %InputType TEXT NAME CDATA #IMPLIED VALUE CDATA #IMPLIED SRC CDATA #IMPLIED CHECKED (CHECKED) #IMPLIED SIZE CDATA #IMPLIED MAXLENGTH NUMBER #IMPLIED 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 -->
<!-- <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 -->
<!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST SELECT
%attrs;
NAME CDATA #REQUIRED
SIZE NUMBER #IMPLIED
MULTIPLE (MULTIPLE) #IMPLIED
%SDAFORM; "List"
%SDAPREF;
"<LHead>Select #AttVal(Multiple)</LHead>"
>
<!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)> <!ATTLIST SELECT %attrs; NAME CDATA #REQUIRED SIZE NUMBER #IMPLIED MULTIPLE (MULTIPLE) #IMPLIED %SDAFORM; "List" %SDAPREF; "<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 -->
<!-- <SELECT> Selection of option(s) --> <!-- <SELECT NAME=...> Name of form datum --> <!-- <SELECT SIZE=...> Options displayed at a time --> <!-- <SELECT MULTIPLE> Multiple selections allowed -->
<!ELEMENT OPTION - O (#PCDATA)*> <!ATTLIST OPTION
<!ELEMENT OPTION - O (#PCDATA)*> <!ATTLIST OPTION
Yergeau, et. al. Standards Track [Page 32] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 32] RFC 2070 HTML Internationalization January 1997
%attrs;
SELECTED (SELECTED) #IMPLIED
VALUE CDATA #IMPLIED
%SDAFORM; "LItem"
%SDAPREF;
"Option: #AttVal(Value) #AttVal(Selected)"
>
%attrs; SELECTED (SELECTED) #IMPLIED VALUE CDATA #IMPLIED %SDAFORM; "LItem" %SDAPREF; "Option: #AttVal(Value) #AttVal(Selected)" >
<!-- <OPTION> A selection option --> <!-- <OPTION SELECTED> Initial state --> <!-- <OPTION VALUE="..."> Form datum value for this option-->
<!-- <OPTION> A selection option --> <!-- <OPTION SELECTED> Initial state --> <!-- <OPTION VALUE="..."> Form datum value for this option-->
<!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST TEXTAREA
%attrs;
NAME CDATA #REQUIRED
ROWS NUMBER #REQUIRED
COLS NUMBER #REQUIRED
ACCEPT-CHARSET CDATA #IMPLIED -- list of charsets accepted --
%SDAFORM; "Para"
%SDAPREF; "Input Text -- #AttVal(Name): "
>
<!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)> <!ATTLIST TEXTAREA %attrs; NAME CDATA #REQUIRED ROWS NUMBER #REQUIRED COLS NUMBER #REQUIRED 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 -->
<!-- <TEXTAREA> An area for text input --> <!-- <TEXTAREA NAME=...> Name of form datum --> <!-- <TEXTAREA ROWS=...> Height of area --> <!-- <TEXTAREA COLS=...> Width of area -->
]]>
]]>
<!--======= Document Head ======================-->
<!--======= Document Head ======================-->
<![ %HTML.Recommended [
<!ENTITY % head.extra "">
]]>
<!ENTITY % head.extra "& NEXTID?">
<![ %HTML.Recommended [ <!ENTITY % head.extra ""> ]]> <!ENTITY % head.extra "& NEXTID?">
<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
<!ELEMENT HEAD O O (%head.content) +(META|LINK)>
<!ATTLIST HEAD
%attrs; >
<!ELEMENT HEAD O O (%head.content) +(META|LINK)> <!ATTLIST HEAD %attrs; >
<!-- <HEAD> Document head -->
<!-- <HEAD> Document head -->
<!ELEMENT TITLE - - (#PCDATA)* -(META|LINK)> <!ATTLIST TITLE
<!ELEMENT TITLE - - (#PCDATA)* -(META|LINK)> <!ATTLIST TITLE
Yergeau, et. al. Standards Track [Page 33] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 33] RFC 2070 HTML Internationalization January 1997
%attrs;
%SDAFORM; "Ti" >
%attrs; %SDAFORM; "Ti" >
<!-- <TITLE> Title of document -->
<!-- <TITLE> Title of document -->
<!ELEMENT LINK - O EMPTY>
<!ATTLIST LINK
%attrs;
HREF CDATA #REQUIRED
%linkExtraAttributes;
%SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>" >
<!ELEMENT LINK - O EMPTY> <!ATTLIST LINK %attrs; HREF CDATA #REQUIRED %linkExtraAttributes; %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) -->
<!-- <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) -->
<!ELEMENT ISINDEX - O EMPTY>
<!ATTLIST ISINDEX
%attrs;
%SDAPREF;
"<Para>[Document is indexed/searchable.]</Para>">
<!ELEMENT ISINDEX - O EMPTY> <!ATTLIST ISINDEX %attrs; %SDAPREF; "<Para>[Document is indexed/searchable.]</Para>">
<!-- <ISINDEX> Document is a searchable index -->
<!-- <ISINDEX> Document is a searchable index -->
<!ELEMENT BASE - O EMPTY>
<!ATTLIST BASE
HREF CDATA #REQUIRED >
<!ELEMENT BASE - O EMPTY> <!ATTLIST BASE HREF CDATA #REQUIRED >
<!-- <BASE> Base context document --> <!-- <BASE HREF="..."> Address for this document -->
<!-- <BASE> Base context document --> <!-- <BASE HREF="..."> Address for this document -->
<!ELEMENT NEXTID - O EMPTY>
<!ATTLIST NEXTID
N CDATA #REQUIRED >
<!ELEMENT NEXTID - O EMPTY> <!ATTLIST NEXTID N CDATA #REQUIRED >
<!-- <NEXTID> Next ID to use for link name --> <!-- <NEXTID N=...> Next ID to use for link name -->
<!-- <NEXTID> Next ID to use for link name --> <!-- <NEXTID N=...> Next ID to use for link name -->
<!ELEMENT META - O EMPTY>
<!ATTLIST META
HTTP-EQUIV NAME #IMPLIED
NAME NAME #IMPLIED
CONTENT CDATA #REQUIRED >
<!ELEMENT META - O EMPTY> <!ATTLIST META HTTP-EQUIV NAME #IMPLIED NAME NAME #IMPLIED CONTENT CDATA #REQUIRED >
Yergeau, et. al. Standards Track [Page 34] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 34] RFC 2070 HTML Internationalization January 1997
<!-- <META> Generic Meta-information --> <!-- <META HTTP-EQUIV=...> HTTP response header name --> <!-- <META NAME=...> Meta-information name --> <!-- <META CONTENT="..."> Associated information -->
<!-- <META> Generic Meta-information --> <!-- <META HTTP-EQUIV=...> HTTP response header name --> <!-- <META NAME=...> Meta-information name --> <!-- <META CONTENT="..."> Associated information -->
<!--======= Document Structure =================-->
<!--======= Document Structure =================-->
<![ %HTML.Deprecated [
<!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
]]>
<!ENTITY % html.content "HEAD, BODY">
<![ %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;'">
<!ELEMENT HTML O O (%html.content)> <!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
<!ATTLIST HTML
%attrs;
%version.attr;
%SDAFORM; "Book"
>
<!ATTLIST HTML %attrs; %version.attr; %SDAFORM; "Book" >
<!-- <HTML> HTML Document -->
<!-- <HTML> HTML Document -->
7.2. SGML Declaration for HTML
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).
<!SGML "ISO 8879:1986" -- SGML Declaration for HyperText Markup Language version 2.x (HTML 2.x = HTML 2.0 + i18n).
--
--
CHARSET
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
CHARSET 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
Yergeau, et. al. Standards Track [Page 35] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 35] RFC 2070 HTML Internationalization January 1997
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
document.
--
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 document. --
CAPACITY SGMLREF
TOTALCAP 150000
GRPCAP 150000
ENTCAP 150000
CAPACITY SGMLREF TOTALCAP 150000 GRPCAP 150000 ENTCAP 150000
SCOPE DOCUMENT
SCOPE DOCUMENT
SYNTAX
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
SYNTAX 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
BASESET "ISO 646IRV:1991//CHARSET International Reference Version (IRV)//ESC 2/8 4/2" DESCSET 0 128 0
FUNCTION
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9
FUNCTION RE 13 RS 10 SPACE 32 TAB SEPCHAR 9
NAMING LCNMSTRT ""
UCNMSTRT ""
LCNMCHAR ".-"
UCNMCHAR ".-"
NAMECASE GENERAL YES
ENTITY NO
DELIM GENERAL SGMLREF
SHORTREF SGMLREF
NAMES SGMLREF
QUANTITY SGMLREF
ATTSPLEN 2100
LITLEN 1024
NAMELEN 72 -- somewhat arbitrary; taken from
internet line length conventions --
PILEN 1024
TAGLVL 100
NAMING LCNMSTRT "" UCNMSTRT "" LCNMCHAR ".-" UCNMCHAR ".-" NAMECASE GENERAL YES ENTITY NO DELIM GENERAL SGMLREF SHORTREF SGMLREF NAMES SGMLREF QUANTITY SGMLREF ATTSPLEN 2100 LITLEN 1024 NAMELEN 72 -- somewhat arbitrary; taken from internet line length conventions -- PILEN 1024 TAGLVL 100
Yergeau, et. al. Standards Track [Page 36] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 36] RFC 2070 HTML Internationalization January 1997
TAGLEN 2100
GRPGTCNT 150
GRPCNT 64
TAGLEN 2100 GRPGTCNT 150 GRPCNT 64
FEATURES
MINIMIZE
DATATAG NO
OMITTAG YES
RANK NO
SHORTTAG YES
LINK
SIMPLE NO
IMPLICIT NO
EXPLICIT NO
OTHER
CONCUR NO
SUBDOC NO
FORMAL YES
APPINFO "SDA" -- conforming SGML Document Access application
--
>
FEATURES MINIMIZE DATATAG NO OMITTAG YES RANK NO SHORTTAG YES LINK SIMPLE NO IMPLICIT NO EXPLICIT NO OTHER CONCUR NO SUBDOC NO FORMAL YES APPINFO "SDA" -- conforming SGML Document Access application -- >
7.3. ISO Latin 1 entity set
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.
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.
<!-- (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">
%ISOlat1;
-->
<!ENTITY nbsp CDATA " " -- no-break space -->
<!ENTITY iexcl CDATA "¡" -- inverted exclamation mark -->
<!ENTITY cent CDATA "¢" -- cent sign -->
<!ENTITY pound CDATA "£" -- pound sterling sign -->
<!ENTITY curren CDATA "¤" -- general currency sign -->
<!ENTITY yen CDATA "¥" -- yen sign -->
<!ENTITY brvbar CDATA "¦" -- broken (vertical) bar -->
<!-- (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"> %ISOlat1; --> <!ENTITY nbsp CDATA " " -- no-break space --> <!ENTITY iexcl CDATA "¡" -- inverted exclamation mark --> <!ENTITY cent CDATA "¢" -- cent sign --> <!ENTITY pound CDATA "£" -- pound sterling sign --> <!ENTITY curren CDATA "¤" -- general currency sign --> <!ENTITY yen CDATA "¥" -- yen sign --> <!ENTITY brvbar CDATA "¦" -- broken (vertical) bar -->
Yergeau, et. al. Standards Track [Page 37] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 37] RFC 2070 HTML Internationalization January 1997
<!ENTITY sect CDATA "§" -- section sign -->
<!ENTITY uml CDATA "¨" -- umlaut (dieresis) -->
<!ENTITY copy CDATA "©" -- copyright sign -->
<!ENTITY ordf CDATA "ª" -- ordinal indicator, feminine -->
<!ENTITY laquo CDATA "«" -- angle quotation mark, left -->
<!ENTITY not CDATA "¬" -- not sign -->
<!ENTITY shy CDATA "­" -- soft hyphen -->
<!ENTITY reg CDATA "®" -- registered sign -->
<!ENTITY macr CDATA "¯" -- macron -->
<!ENTITY deg CDATA "°" -- degree sign -->
<!ENTITY plusmn CDATA "±" -- plus-or-minus sign -->
<!ENTITY sup2 CDATA "²" -- superscript two -->
<!ENTITY sup3 CDATA "³" -- superscript three -->
<!ENTITY acute CDATA "´" -- acute accent -->
<!ENTITY micro CDATA "µ" -- micro sign -->
<!ENTITY para CDATA "¶" -- pilcrow (paragraph sign) -->
<!ENTITY middot CDATA "·" -- middle dot -->
<!ENTITY cedil CDATA "¸" -- cedilla -->
<!ENTITY sup1 CDATA "¹" -- superscript one -->
<!ENTITY ordm CDATA "º" -- ordinal indicator, masculine -->
<!ENTITY raquo CDATA "»" -- angle quotation mark, right -->
<!ENTITY frac14 CDATA "¼" -- fraction one-quarter -->
<!ENTITY frac12 CDATA "½" -- fraction one-half -->
<!ENTITY frac34 CDATA "¾" -- fraction three-quarters -->
<!ENTITY iquest CDATA "¿" -- inverted question mark -->
<!ENTITY Agrave CDATA "À" -- capital A, grave accent -->
<!ENTITY Aacute CDATA "Á" -- capital A, acute accent -->
<!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent -->
<!ENTITY Atilde CDATA "Ã" -- capital A, tilde -->
<!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut -->
<!ENTITY Aring CDATA "Å" -- capital A, ring -->
<!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) -->
<!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla -->
<!ENTITY Egrave CDATA "È" -- capital E, grave accent -->
<!ENTITY Eacute CDATA "É" -- capital E, acute accent -->
<!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent -->
<!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut -->
<!ENTITY Igrave CDATA "Ì" -- capital I, grave accent -->
<!ENTITY Iacute CDATA "Í" -- capital I, acute accent -->
<!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent -->
<!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut -->
<!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic -->
<!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde -->
<!ENTITY Ograve CDATA "Ò" -- capital O, grave accent -->
<!ENTITY Oacute CDATA "Ó" -- capital O, acute accent -->
<!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent -->
<!ENTITY Otilde CDATA "Õ" -- capital O, tilde -->
<!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut -->
<!ENTITY sect CDATA "§" -- section sign --> <!ENTITY uml CDATA "¨" -- umlaut (dieresis) --> <!ENTITY copy CDATA "©" -- copyright sign --> <!ENTITY ordf CDATA "ª" -- ordinal indicator, feminine --> <!ENTITY laquo CDATA "«" -- angle quotation mark, left --> <!ENTITY not CDATA "¬" -- not sign --> <!ENTITY shy CDATA "" -- soft hyphen --> <!ENTITY reg CDATA "®" -- registered sign --> <!ENTITY macr CDATA "¯" -- macron --> <!ENTITY deg CDATA "°" -- degree sign --> <!ENTITY plusmn CDATA "±" -- plus-or-minus sign --> <!ENTITY sup2 CDATA "²" -- superscript two --> <!ENTITY sup3 CDATA "³" -- superscript three --> <!ENTITY acute CDATA "´" -- acute accent --> <!ENTITY micro CDATA "µ" -- micro sign --> <!ENTITY para CDATA "¶" -- pilcrow (paragraph sign) --> <!ENTITY middot CDATA "·" -- middle dot --> <!ENTITY cedil CDATA "¸" -- cedilla --> <!ENTITY sup1 CDATA "¹" -- superscript one --> <!ENTITY ordm CDATA "º" -- ordinal indicator, masculine --> <!ENTITY raquo CDATA "»" -- angle quotation mark, right --> <!ENTITY frac14 CDATA "¼" -- fraction one-quarter --> <!ENTITY frac12 CDATA "½" -- fraction one-half --> <!ENTITY frac34 CDATA "¾" -- fraction three-quarters --> <!ENTITY iquest CDATA "¿" -- inverted question mark --> <!ENTITY Agrave CDATA "À" -- capital A, grave accent --> <!ENTITY Aacute CDATA "Á" -- capital A, acute accent --> <!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent --> <!ENTITY Atilde CDATA "Ã" -- capital A, tilde --> <!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut --> <!ENTITY Aring CDATA "Å" -- capital A, ring --> <!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) --> <!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla --> <!ENTITY Egrave CDATA "È" -- capital E, grave accent --> <!ENTITY Eacute CDATA "É" -- capital E, acute accent --> <!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent --> <!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut --> <!ENTITY Igrave CDATA "Ì" -- capital I, grave accent --> <!ENTITY Iacute CDATA "Í" -- capital I, acute accent --> <!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent --> <!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut --> <!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic --> <!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde --> <!ENTITY Ograve CDATA "Ò" -- capital O, grave accent --> <!ENTITY Oacute CDATA "Ó" -- capital O, acute accent --> <!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent --> <!ENTITY Otilde CDATA "Õ" -- capital O, tilde --> <!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut -->
Yergeau, et. al. Standards Track [Page 38] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 38] RFC 2070 HTML Internationalization January 1997
<!ENTITY times CDATA "×" -- multiply sign -->
<!ENTITY Oslash CDATA "Ø" -- capital O, slash -->
<!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent -->
<!ENTITY Uacute CDATA "Ú" -- capital U, acute accent -->
<!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent -->
<!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut -->
<!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent -->
<!ENTITY THORN CDATA "Þ" -- capital Thorn, Icelandic -->
<!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature) -->
<!ENTITY agrave CDATA "à" -- small a, grave accent -->
<!ENTITY aacute CDATA "á" -- small a, acute accent -->
<!ENTITY acirc CDATA "â" -- small a, circumflex accent -->
<!ENTITY atilde CDATA "ã" -- small a, tilde -->
<!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut -->
<!ENTITY aring CDATA "å" -- small a, ring -->
<!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) -->
<!ENTITY ccedil CDATA "ç" -- small c, cedilla -->
<!ENTITY egrave CDATA "è" -- small e, grave accent -->
<!ENTITY eacute CDATA "é" -- small e, acute accent -->
<!ENTITY ecirc CDATA "ê" -- small e, circumflex accent -->
<!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut -->
<!ENTITY igrave CDATA "ì" -- small i, grave accent -->
<!ENTITY iacute CDATA "í" -- small i, acute accent -->
<!ENTITY icirc CDATA "î" -- small i, circumflex accent -->
<!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut -->
<!ENTITY eth CDATA "ð" -- small eth, Icelandic -->
<!ENTITY ntilde CDATA "ñ" -- small n, tilde -->
<!ENTITY ograve CDATA "ò" -- small o, grave accent -->
<!ENTITY oacute CDATA "ó" -- small o, acute accent -->
<!ENTITY ocirc CDATA "ô" -- small o, circumflex accent -->
<!ENTITY otilde CDATA "õ" -- small o, tilde -->
<!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut -->
<!ENTITY divide CDATA "÷" -- divide sign -->
<!ENTITY oslash CDATA "ø" -- small o, slash -->
<!ENTITY ugrave CDATA "ù" -- small u, grave accent -->
<!ENTITY uacute CDATA "ú" -- small u, acute accent -->
<!ENTITY ucirc CDATA "û" -- small u, circumflex accent -->
<!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut -->
<!ENTITY yacute CDATA "ý" -- small y, acute accent -->
<!ENTITY thorn CDATA "þ" -- small thorn, Icelandic -->
<!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut -->
<!ENTITY times CDATA "×" -- multiply sign --> <!ENTITY Oslash CDATA "Ø" -- capital O, slash --> <!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent --> <!ENTITY Uacute CDATA "Ú" -- capital U, acute accent --> <!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent --> <!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut --> <!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent --> <!ENTITY THORN CDATA "Þ" -- capital Thorn, Icelandic --> <!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature) --> <!ENTITY agrave CDATA "à" -- small a, grave accent --> <!ENTITY aacute CDATA "á" -- small a, acute accent --> <!ENTITY acirc CDATA "â" -- small a, circumflex accent --> <!ENTITY atilde CDATA "ã" -- small a, tilde --> <!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut --> <!ENTITY aring CDATA "å" -- small a, ring --> <!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) --> <!ENTITY ccedil CDATA "ç" -- small c, cedilla --> <!ENTITY egrave CDATA "è" -- small e, grave accent --> <!ENTITY eacute CDATA "é" -- small e, acute accent --> <!ENTITY ecirc CDATA "ê" -- small e, circumflex accent --> <!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut --> <!ENTITY igrave CDATA "ì" -- small i, grave accent --> <!ENTITY iacute CDATA "í" -- small i, acute accent --> <!ENTITY icirc CDATA "î" -- small i, circumflex accent --> <!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut --> <!ENTITY eth CDATA "ð" -- small eth, Icelandic --> <!ENTITY ntilde CDATA "ñ" -- small n, tilde --> <!ENTITY ograve CDATA "ò" -- small o, grave accent --> <!ENTITY oacute CDATA "ó" -- small o, acute accent --> <!ENTITY ocirc CDATA "ô" -- small o, circumflex accent --> <!ENTITY otilde CDATA "õ" -- small o, tilde --> <!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut --> <!ENTITY divide CDATA "÷" -- divide sign --> <!ENTITY oslash CDATA "ø" -- small o, slash --> <!ENTITY ugrave CDATA "ù" -- small u, grave accent --> <!ENTITY uacute CDATA "ú" -- small u, acute accent --> <!ENTITY ucirc CDATA "û" -- small u, circumflex accent --> <!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut --> <!ENTITY yacute CDATA "ý" -- small y, acute accent --> <!ENTITY thorn CDATA "þ" -- small thorn, Icelandic --> <!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut -->
Yergeau, et. al. Standards Track [Page 39] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 39] RFC 2070 HTML Internationalization January 1997
8. Security Considerations
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.
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.
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.
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.
Bibliography
Bibliography
[BRYAN88] M. Bryan, "SGML -- An Author's Guide to the Standard
Generalized Markup Language", Addison-Wesley, Reading,
1988.
[BRYAN88] M. Bryan, "SGML -- An Author's Guide to the Standard Generalized Markup Language", Addison-Wesley, Reading, 1988.
[ERCS] Extended Reference Concrete Syntax for SGML.
<http://www.sgmlopen.org/sgml/docs/ercs/ercs-
home.html>
[ERCS] Extended Reference Concrete Syntax for SGML. <http://www.sgmlopen.org/sgml/docs/ercs/ercs- home.html>
[GOLD90] C. F. Goldfarb, "The SGML Handbook", Y. Rubinsky, Ed.,
Oxford University Press, 1990.
[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.
[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-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-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)
Yergeau, et. al. Standards Track [Page 40] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 40] RFC 2070 HTML Internationalization January 1997
[ISO-8879] ISO 8879:1986. International standard -- Information
processing -- Text and office systems -- Standard gen-
eralized markup language (SGML).
[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.
[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,
<http://www.ebt.com/docs/multling.html>
[NICOL] G.T. Nicol, "The Multilingual World Wide Web", Electronic Book Technologies, 1995, <http://www.ebt.com/docs/multling.html>
[NICOL2] G.T. Nicol, "MIME Header Supplemented File Type", Work
in Progress, EBT, October 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.
[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
1993.
[RFC1468] Murai, J., Crispin M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, Keio University, Panda Programming, June 1993.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[RFC1867] Nebel, E., and L. Masinter, "Form-based File Upload in HTML", RFC 1867, Xerox Corporation, November 1995.
Yergeau, et. al. Standards Track [Page 41] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 41] RFC 2070 HTML Internationalization January 1997
[RFC1942] Raggett, D., "HTML Tables", RFC 1942, W3C, May 1996.
[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.
[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.,
1991.
[SQ91] SoftQuad, "The SGML Primer", 3rd ed., SoftQuad Inc., 1991.
[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.
[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>
[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
2.
[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 2.
[UTF-8] ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS Transfor-
mation Format 8 (UTF-8).
[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.
[VANH90] E. van Hervijnen, "Practical SGML", Kluwer Academicq Publishers Group, Norwell and Dordrecht, 1990.
Yergeau, et. al. Standards Track [Page 42] RFC 2070 HTML Internationalization January 1997
Yergeau, et. al. Standards Track [Page 42] RFC 2070 HTML Internationalization January 1997
Authors' Addresses
Authors' Addresses
Frangois Yergeau
Alis Technologies
100, boul. Alexis-Nihon, bureau 600
Montrial QC H4M 2P2
Canada
Frangois Yergeau Alis Technologies 100, boul. Alexis-Nihon, bureau 600 Montrial QC H4M 2P2 Canada
Tel: +1 (514) 747-2547
Fax: +1 (514) 747-2561
EMail: fyergeau@alis.com
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,
Setagaya-ku,
Tokyo
Japan
Gavin Thomas Nicol Electronic Book Technologies, Japan 1-29-9 Tsurumaki, Setagaya-ku, Tokyo Japan
Tel: +81-3-3230-8161
Fax: +81-3-3230-8163
EMail: gtn@ebt.com, gtn@twics.co.jp
Tel: +81-3-3230-8161 Fax: +81-3-3230-8163 EMail: gtn@ebt.com, gtn@twics.co.jp
Glenn Adams
Spyglass
118 Magazine Street
Cambridge, MA 02139
U.S.A.
Glenn Adams Spyglass 118 Magazine Street Cambridge, MA 02139 U.S.A.
Tel: +1 (617) 864-5524
Fax: +1 (617) 864-4965
EMail: glenn@spyglass.com
Tel: +1 (617) 864-5524 Fax: +1 (617) 864-4965 EMail: glenn@spyglass.com
Martin J. Duerst
Multimedia-Laboratory
Department of Computer Science
University of Zurich
Winterthurerstrasse 190
CH-8057 Zurich
Switzerland
Martin J. Duerst Multimedia-Laboratory Department of Computer Science University of Zurich Winterthurerstrasse 190 CH-8057 Zurich Switzerland
Tel: +41 1 257 43 16
Fax: +41 1 363 00 35
EMail: mduerst@ifi.unizh.ch
Tel: +41 1 257 43 16 Fax: +41 1 363 00 35 EMail: mduerst@ifi.unizh.ch
Yergeau, et. al. Standards Track [Page 43]
Yergeau, et. al. Standards Track [Page 43]
一覧
スポンサーリンク
