原典 RFC2070 ftp://ds.internic.net/rfc/rfc2070.txt
98.1.12 翻訳開始
98.4.12 第7項 HTML Public Textを除き翻訳終了
98.8.29 一部修正
http://www.bekkoame.or.jp/‾poetlabo/WWW/rfc2070J.html
Network Working Group
Request for Comments: 2070
Category: Standards Track
F. Yergeau
Alis Technologies
G. Nicol
Electronic Book Technologies
G. Adams
Spyglass
M. Duerst
University of Zurich
January 1997
この文書は、インターネット社会のためのインターネット標準過程となる作法を決めるもので、改良のための議論や提案を求めます。標準化の状況とこの作法の位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1) を参照してください。この書き付けの配布は無制限です。
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.
超越書類表記法(HTML)は、特定の使用機器に依存しない超越書類文書の作成に使われる表記法です。当初は、『世界中蜘蛛の巣通信網』W.W.W.におけるHTMLの応用は、ごく限定されたものでした。西欧の言語のみにふさわしいISO-8859-1方式の文字セットを拠り所としていたからです。この制約にもかかわらず、 HTML は他の言語をもって広く使用されつつあります。しかし、その際に他の方式による文字セットあるいは文字符号化方式を使うため、互換性を失っています。
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の仕様を拡張し適切に国際化を扱うための追加勧告を与えることにより、HTML の国際化版（i の後に18字、最後に n ということで、以下これを i18n と呼ぶ）について解説することを意図しています。主要な考慮すべきことは、世界中の全ての言語での使用へ対応できるようにした上で、なおもHTML が SGMLを正しく応用していることを確かめることです。
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)は、特定の使用機器に依存しない超越書類文書の作成に使われる表記法です。当初は、W.W.W.におけるHTMLの応用は、ごく限定されたものでした。西欧の言語のみにふさわしいISO-8859-1方式の文字セットを拠り所としていたからです。この制約にもかかわらず、 HTML は他の言語をもって広く使用されつつあります。これは、さまざまの特別な言語拡張子 [TAKADA] を通して、他の方式による文字セットあるいは文字符号化方式を使うことによるものです。
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の仕様を拡張し適切に国際化を扱うための追加勧告を与えることにより、HTML の国際化版について解説することを意図しています。これはWWWにおける多言語環境に関する著者の１人が書いた論文 [NICOL] に基づくものの良い見本です。主要な考慮すべきことは、世界中の全ての言語での使用へ対応できるようにした上で、なおもHTML が SGMLを正当に応用していることを確かめることです。
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 に使用される SGML 文書文字セット、"text/html"内容種別と結び付いている charset 変数の適切な処理と、追加要素および実体の仕様です。
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は1990年以来、専ら『世界中蜘蛛の巣通信網』(WWW)で地球規模の情報発信に使われてきました。この仕様書は、主にISO-8859-1方式文字セット [ISO-8859] への制約を取り除くことにより、HTML 2.0 (RFC 1866)の能力を拡張するものです。
HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. This specification extends the capabilities of HTML 2.0 (RFC 1866), primarily by removing the restriction to the ISO-8859-1 coded character set [ISO-8859] .
HTMLは、ISO 標準 8879:1986,情報処理書類および機構（SGML, 標準汎用表記法） [ISO-8879] の応用です。HTML文書種別定義（ DTD ）は SGML の観点からの HTML 構文の形式的な定義です。
この仕様書は、 SGML に従いつつ、ISO-8859-1のものよりずっと大規模な文字レパートリーを包含している文書に適用できるようにするために、 HTML 2.0 の DTD を修正するものです。
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 の発展は、形式的にも実際にも、非常に速く進んでいます。
この文書で描写された機能は、できるだけ（そしてなるべく）RFC 1866 で描写されたものに近い形のHTMLとして追加できるように設計されています。
ここで紹介された属性が示された所では、それは適切な要素に拡張されるべきです。
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 利用者手先の準拠条件を変更します。
This specification changes slightly the conformance requirements of HTML documents and HTML user agents.
HTML 2.0 準拠の文書は全て、この仕様書に準拠しています。
しかしながらここで紹介された拡張子により、 特にISO 8859-1に含まれない文字か文字参照が入っているものや、ここに紹介された表記が入っているものなど、HTML 2.0 に準拠しない文書が正当なものとなることがあります。
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.
RFC 1866での必要条件に加え、以下の必要条件がHTML利用者手先に課されます。
In addition to the requirements of RFC 1866, the following requirements are placed on HTML user agents.
この概説では、 HTML で使われる参照処理模型、特に文書文字セットに関するSGML 概念を説明します。
実際の実装は、その内部の働きにおいて下記のモデルと大幅に異なっていてかまいませんが、外部の観察者に対しては、描写されたとおりにふるまうべきです。
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.
文章の符号化については、大幅に異なるさまざまな方式があります。このため、抽象的な感覚でSGML 文書を構成する文字の連続が、コンピュータファイルのような具体的な文書の認識において、どのように8ビットの集まり（またはしばしば8でない長さのビットグループ）として符号化されるかについては、SGML は直接には言及しません。この符号化方式は、具体的 SGML 文書の外部文字符号化方式と呼ばれます。これは抽象的な HTML 文書の文書文字セットから慎重に区別されるべきです。SGML は文字を、（『文字レパートリー』と呼ばれる）１個のセット、またはそのレパートリーにある各々の文字に整数の番号（『文字ナンバー』として知られているもの）を割り振った『コードセット』と見なします。
各々の文字番号が何を表わすかについては、文書文字セット宣言で定めます [GOLD90, p. 451]。
ほとんどの場合、 SGML DTD とそれを参照する全ての文書は、１個の文書文字セットを持ち、全てのマークアップとデータ文字はこのセットの一部となります。
Because there are various widely differing encodings of text, SGML does not directly address how the sequence of characters that constitutes an SGML document in the abstract sense are encoded by means of a sequence of octets (or occasionally bit groups of another length than 8) in a concrete realization of the document such as a computer file. This encoding is called the external character encoding of the concrete SGML document, and it should be carefully distinguished from the document character set of the abstract HTML document. SGML views the characters as a single set (called a "character repertoire"), and a "code set" that assigns an integer number (known as "character number") to each character in the repertoire. The document character set declaration defines what each of the character numbers represents [GOLD90, p. 451]. In most cases, an SGML DTD and all documents that refer to it have a single document character set, and all markup and data characters are part of this set.
SGML の応用である HTML が、外部の文字符号化方式の問題を直接に言及することはありません。
MIMEがHTTP 作法や電子メールで使用されるのと同様に、これは HTML 以外の機構に委ねられます。
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.
HTTP 作法 [RFC2068] のために、HTTP 応答ヘッダの"Content-Type"フィールドの"charset"変数によって、外部の文字符号化方式が 示されます。
例えば、送られた文書が日本の"JUNET"符号化方式 [RFC1468] を用いているということを示すためには、ヘッダに次の1行を入れます：
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:
Content-Type: text/html; charset=ISO-2022-JP
MIME の用語"charset"はどちらかというと、単に符号化された文字セットを示唆するだけの用語というより、文字符号化方式を指定するものとして使用されます。
文字符号化は、 １つ以上の文字レパートリーから取られた文字集合から、対応する（多対一も可）8ビット集合への写像です。
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.
HTTP 作法はまた、利用者側が受け入れられる文字符号化方式を指定するための機構をも定義しています。
受け手と送り手は、どんな文書についても正しい伝達と解釈を保証するために、これらの機構を用いることが強く求められます。
送り手や受け手がまだこれらの機構を用いない場合でも、正しい解釈を助けるために取ることができる措置については、6項で述べます。
The HTTP protocol also defines a mechanism for the client to specify
the character encodings it can accept. Clients and servers are
strongly requested to use these mechanisms to assure correct
transmission and interpretation of any document. Provisions that can
be taken to help correct interpretation, even in cases where a server
or client do not yet use these mechanisms, are described in section
6.
同様に、 HTML 文書が電子郵便によって転送されるならば、外部の文字符号化方式は、"Content-Type" MIMEヘッダフィールド [RFC2045] の"charset"変数によって指定され、これを欠くものはUS-ASCIIと見なされます。
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.
FTPか配布されたファイルシステムでの呼び出しによって転送されたHTML文書の外部の文字符号化方式を示すための標準化された機構は、今のところ在りません。
No mechanisms are currently standardized for indicating the external
character encoding of HTML documents transferred by FTP or accessed
in distributed file systems.
HTML文書を転送し保管する他の手段が定義されるか一般的になる場合においては、用いられた文字符号化方式をはっきりと確認し、さらに（あるいは、その代わりに）国際的な文脈で使用される文字の最も広範な表現能力がある１個あるいは所定の符号化方式を用いるための、類似した規定を作ることが薦められます。
In the case any other way of transferring and storing HTML documents
are defined or become popular, it is advised that similar provisions
be made to clearly identify the character encoding used and/or to use
a single/default encoding capable of representing the widest range of
characters used in an international context.
外部の文字符号化方式が何であろうと、参照処理モデルはそれを、 SGML/HTML 特有の加工をする前に、 2.2 項で指定された文書文字セットへ翻訳します。
参照処理モデルは、以下のように描くことができます：
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:
[resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display]
[manager] [parser]
^ |
| |
+----------+
ここでデコーダは、素材の外部表現を文書文字セットへ変換するためのものです。
実体操作部と解析部とアプリケーションは、文書文字セットの文字だけを扱います。
アプリケーションか表示装置の表示指向部分が、文書文字セットで表わす文字をさらに、その目的によりふさわしい他の表現に再変換することはかまいません。
いずれにせよ実体操作部と解析部とアプリケーションは、文字意味論に関する限り、 HTML 文書文字セットだけを用います。
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.
実際の処理では、文書を、上に描写したような文書文字セットの符号化方式へ翻訳するようにしてもしなくてもかまいません。この参照処理モデルによって描写された振る舞いは、他の方法でも実現することができるでしょう。
しかしながらこの話は、この仕様書の範囲から外れます。詳細については、 SGML 標準の [ISO-8879] か SGML ハンドブック [BRYAN88]
[GOLD90] [VANH90] [SQ91] に意見を求めるように勧めます。
An actual implementation may choose, or not, to translate the
document into some encoding of the document character set as
described above; the behaviour described by this reference processing
model can be achieved otherwise. This subject is well out of the
scope of this specification, however, and the reader is invited to
consult the SGML standard [ISO-8879] or an SGML handbook [BRYAN88]
[GOLD90] [VANH90] [SQ91] for further information.
この参照処理モデルの最も重要な結果は、実際に用いられた外部符号化方式が何であろうと、数字参照が常に固定的な文書文字セットに関連しており、したがって同じ文字として決められることです。
例としては2.2 項を見てください。
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.
文書文字セットとは、SGML の感覚では、国際標準化機構 10646:1993 [ISO-10646] にいう Universal Character Set （ UCS ）の改訂版です。
現在、これは code-by-code で Unicode 標準第1.1 版 [UNICODE] と全く同一のものとなっています。
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] .
この文書文字セットの採用は、 HTML 2.0 仕様書（ 9.5 項の [RFC1866] ）で指定されたSGML 宣言の変更を示唆します。
変更点としては、最初の BASESET 仕様書とそれに伴う DESCSET 宣言を取り除き、以下の宣言に置き換えることになります：
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:
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
文書文字セットを UCS にすれば、 HTML 2.0 に準拠する構造物や文書のどんな表現も、 non- conformance を引き起こすことはありません。
これは HTML 2.0 で許されない構造物を準拠するものとすることになります。
１つの結果として、データ文字は ISO-8859-1 のレパートリーに入らなくても、 UCS-4 の範囲内なら有効な SGML 文字になります。
別の結果としては、数字参照の範囲の上限が、 255 から 2147483645 へ拡張されます。従ってИ は、『キリル語大文字I』への有効な参照となります。
[ERCS] は、その範囲と技術的な内容がこの仕様書と大いに異なってはいますが、 Unicode と SGML に関する良い情報源です。
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.
HTML 2.0 SGML 宣言が著者の真意を反映しなかった点を反省して、これに加えられた変化がもう一つあります。
シンタックス文字セット宣言は、ISO 646.IRV:1983から、より新しいISO 646.IRV:1991に変更されました。後者は、以前のものとは違い、US-ASCIIと全く同一です。
基本的に、これは HTML 2.0 に非互換性をもたらすことになりますが、 実際には
i) SGML 宣言に皆が何を考えているか言ってもらう、
ii) シンタックス文字セットを文書文字セットの適当なサブセットとする。
ことによって 相互干渉性を増すでしょう。
ISO 646.IRV の2つの版の間で異なる文字は実際には、 HTML シンタックスを表すのには使用されていません。
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.
国際標準化機構 10646-1:1993 は、現存する文字セットの最大の包みです。HTML の文書文字セットとしてこれに取って代わる他の文字セットはありません。それでもなお、この標準に入らない文字を使う必要がある特定のアプリケーションがある場合には、例えばUCS-4 coding space [ISO-10646 section 11]の独自領域にこれらの文字をあてがうなどして、これがISO 10646の現在および将来の版と衝突することを避けるようにすべきです。また、そのような使用が極めて互換性を欠くことを銘記すべきです。多くのケースでは、埋込み画像を用いたほうがより適切でしょう。
ISO 10646-1:1993 is the most encompassing character set currently
existing, and there is no other character set that could take its
place as the document character set for HTML. If nevertheless for a
specific application there is a need to use characters outside this
standard, this should be done by avoiding any conflicts with present
or future versions of ISO 10646, i.e. by assigning these characters
to a private zone of the UCS-4 coding space [ISO-10646 section 11].
Also, it should be borne in mind that such a use will be highly
unportable; in many cases, it may be better to use inline bitmaps.
国際標準化機構 10646 の全ての文書文字セットをもってしても、適切な素材（活字）が足りない為に表示できない文字があるという可能性を避けることはできません。
そのようなケースとしては実にさまざまなものがありえますので、この文書は具体的なふるまいについては、いっさい規定しません。
これは実際の処理のしかたに左右されるため、アプリケーション自体ではなく、それが管理している表示装置によって扱われるようにしてかまいません。
しかしながら理解を助けるために、以下に目安を示します。
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:
言語タグは、さまざまなやり方でマークアップした文書のコントロール表現に使用することができます：
具体的な字体にするのに文字符号化方式が十分でないケースでの字体disambiguation、引用符、ハイフンによる連結、合字、空白、合成音声など。
表現の問題とは別に、言語マークアップは内容マークアップとして分類と検索のような目的に役立ちます。
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.
どんな文章にも論理的に言語を割り当てられる以上、ほとんど全ての HTML 要素には、 LANG 属性が入ります。
DTD はこれを反映しており、 HTML のこの版において LANG 属性のない要素は、 BR と HR と BASE と NEXTID と META に限られます。
HTML のより新しい版でもたらされたどんな新しい要素も、そうしないもっともな理由があるのでない限り、 LANG 属性を認めることが予定されてもいます。
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.
言語属性（ LANG ）はその値として、話されたり書かれたりしている自然言語あるいは人から人へ情報を伝達するための別の方法を明示する言語タグをとります。
コンピュータ言語は明白に除外されます。
HTML 言語タグの語法と記載は、 RFC 1766 [RFC1766] によって定められたものと同一です。
かいつまんで言うと、言語タグは１つ以上の部分から成り立ちます：
つまり、第1言語タグとあるいは空かもしれない副タグの直列配置となります。
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.
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:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
タグの範囲内での空白は許されません。また、全てのタグは大文字・小文字を区別しません。 言語タグの namespace は、 IANA によって管理されます。 タグの例としては次のようなものがあります。 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:
en, en-US, en-cockney, i-cherokee, x-pig-latin
HTML の文脈で言語タグは、 RFC 1766 にある単一のトークンとしてではなくピラミッド型階層構造として解釈されます。例えば、言語によって表現を調整するユーザエージェントは、スタイルシートに記載された言語タグが要素の言語タグの初めの部分と一致するとき、それらを組み合わせて考えるべきです。正確な組み合わせが優先されるべきでしょう。この解釈に従えば、マークアップされた要素について例えば "en-US" は、US-English ("en-US") 、'plain'、'international' English ("en") の優先順序で、対応するスタイルを引き出すことが可能です。
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").
要素の表現は、 LANG 属性によって影響を受けるかもしれません。
どんな要素でも、 LANG 属性の値が、取り囲まれた要素の LANG 属性によって指定された値や（どのようなものでも）HTTP Content-Language ヘッダの値を上書きします。
これらのどれも設定されていなければ、おそらく利用者の指定か、自動的な文脈分析か、或いは利用者の現場において管理されている適当な既定の値が、コントロール表現に使用されているべきです。
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.
[RFC1866] の第14項の提案に従えば、Latin-1実体のセットは、すでに一般に用いられている ・©・®を含む ISO- 8859-1 （高い番号のビットセットをもつ全てのコード位置）の全部を確保するために拡張されます。
実体の名前は、 SGML [ISO-8879] の付録から取られています。
一覧表が、この仕様書の第7.3項にあります。
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.
特定の言語による文章を（フォーマットの問題とは別に）正しく提示するために、書式において追加される実体と要素を取り扱うことが必要とされます。
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:
上記の機能については、追加的な取り扱いがほとんど必要ないものもあり、大いに必要なものもあります。 追加機能は、短い注釈のみをつけて以下に紹介されます。 その後に、筆記体が加わる際の動作と双方向性の文章についての説明が続きます。 筆記体が加わる際の動作と双方向性の文章について、 この文書は次の点で [ UNICODE ] に基づいています：
まず、他に適切な要素がない場合、一般的な包含要素が LANG と DIR （下記参照）属性を担う必要があり、そのためのSPAN 要素が紹介されます。
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.
双方向性の表現と筆記体を加える際の制御に使用するための名前つき文字実体セットが追加されます：
A set of named character entities is added for use with bidirectional
rendering and cursive joining control:
<!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-->
これらの実体は、対応している設定された文字の代わりに、たとえば、キーボード入力を省いたり、設定された文字がその文書の文字符号化方式では利用できないときなど、いつでも使用することができます。
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.
次に、DIRと呼ばれる属性を紹介しましょう。その値はLTR（左から右）とRTL（右から左）の2つに限られており、双方向性の文章の文脈における方向性（詳細は 4.2.4 以下を参照のこと）を指示します。
どのような文章も、多くの他の要素（表組など）も論理的に方向性を与えることができるので、BR,
HR, BASE, NEXTID, METAを除く全ての要素は、この属性を受け入れます。DTDにはこれが反映されます。
HTMLのこの後の版におけるどの新しい要素についても、もっともな理由があるのでない限り、DIR属性が受け入れられるはずです。
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.
BDO (BIDI Override)と呼ばれる新しい語句単位の要素を紹介しましょう。これは、上書きが左から右になるか右から左になるかを指定するDIR属性を必要とします。
この要素は、双方向性文章の管理のために必要とされます。詳細については、 4.2.4 項を見てください。
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.
言語と使用機材の能力によって変化する短い引用句の言語特有の表現による表示を可能にするための、語句単位の要素Qを紹介しましょう。以下の例に見られるように（インターネット仕様書の文字セット節約のため、いささか貧弱ではありますが）、引用部分を取り囲む引用符には特に効果的です。
"英語での引用", `別の例', ,,ドイツ語での引用'', <<フランス語での引用 >>.
Q要素の内容には引用符は入りません。引用符は表示過程において加えられなければなりません。
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.
多くの言語は適切な表示のために上つき文字による文章を必要とします。例としては、フランス語の"Mlle Dupont"には、上つき文字による"lle"があって然るべきです。
そのような文章を適切にマークアップできるようにするためのSUP要素と、これを逆にした下つき文字による文章のためのSUBを紹介しましょう。SUPとSUBの内容は、入れ子の問題を避けるため、PCDATAに限られます。
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.
最後に、多くの言語において文章の行揃えは、西欧の言語におけるよりもずっと重要であり、マークアップを正当なものとします。LEFT・RIGHT・CENTER・JUSTIFYといった値を受け入れるALIGN属性が、それが意味を成すような要素（まとめ的な要素 P・HR・H1からH6まで・OL・UL・DIR・MENU・LI・BLOCKQUOTE・ADDRESS）の選択項目に加えられます。利用者手先が、左から右へ向かう部分の既定値としてLEFTを選ぶなら、右から左へ向かう部分にはRIGHTを使用するべきです。
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.
DTD では、 LANG と DIR 属性は attrs と呼ばれる変数実体で一つにまとめられています。
RFC 1942 に対応して、 attrs には ID と CLASS 属性も含められます。
ID と CLASS 属性はスタイルシートでの使用のために必要とされており、 RFC 1942 はこれを以下のとおりに定義しています。
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:
普通は出てこないような文脈で筆記体を加えるという動作を強いるか、普通は出てくるようなところでそれをさえぎるなどのケースでは、マークアップが必要とされます。
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.
幅なし接続子と非接続子 (‍ and ‌) は、筆記体文字を加える動作を制御するのに使用されます。
例えば、 ARABIC LETTER HEH は"Hijri"（イスラムの暦法）を短縮するために切りはなして使用されますけれども、アラビア文字を読み慣れた者には HEH の切り離された形が数字の5のように見えますので、文字の当初の形が望まれるところです。
これは（ただ文脈を与えるだけの効果をもつ）幅なし接続子の後に HEH を続けることによって得られます。
ペルシャの文章では、通常はその後に文字が続く文字に、筆記体では接続しないケースがあります。
ここでは幅なし非接続子が使用されます。
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.
多くの言語は、左から右へ横書きにされていますが、右から左へと書かれるものもあります。
筆記方向が両方あるようなときは、双方向性の文章（略して BIDI ）としましょう。
BIDI 文章は、文字がどちらを向いているかわからなくなるような特別の状況でマークアップを必要とします。
このマークアップは、 BIDI 文章を意味論的に読みやすい様式で表示する能力へ働きかけます。
つまり、この特別の BIDI マークアップなしでは、何がなし文章の基本的な意味を反映して表示するのに障害が発生する場合があります。
普通の文章に、特殊用途形式文字の形で BIDI マークアップを入れてかまいません。
Many languages are written in horizontal lines from left to right,
while others are written from right to left. When both writing
directions are present, one talks of bidirectional text (BIDI for
short). BIDI text requires markup in special circumstances where
ambiguities as to the directionality of some characters have to be
resolved. This markup affects the ability to render BIDI text in a
semantically legible fashion. That is, without this special BIDI
markup, cases arise which would prevent *any* rendering whatsoever
that reflected the basic meaning of the text. Plain text may contain
BIDI markup in the form of special-purpose formatting characters.
これは国際標準化機構 10646 の5つの BIDI 関連形式化文字（ 202A - 202E ）を含む HTML でも可能です。
代替手段としては、 HTML は同等の SGML マークアップを提供します。
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.
BIDI は複雑な問題です。論理的な文章シークエンスから表示シークエンスへの変換は、 [UNICODE] で指定されたアルゴリズムと文字特性に従ってなされなければなりません。
ここでは、紹介された機能の必要性を理解し、その正確な意味論を定めるのに必要なだけの説明が与えられます。
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.
Unicode BIDI アルゴリズムは論理的な順序、通常入力されたり、通常の会話に対応している音声の順序で構成された文書の類の individual characters に基づいています。
論理的な文章順序を可能な限り表現するために、アルゴリズムは各々の文字に方向性特性を認めます。例えばラテン文字は左から右へ書くものとし、アラビアとヘブライの文字については右から左へ書くものとするなど。
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.
left-to-right と right-to-left マーク(‎ と ‏)は、はっきりしない文字の方向性を特定するために使用されます。
たとえば二重引用文がアラビア文字とラテン文字の間に入るときは、その方向が曖昧です。単一方向性の文字で囲まれた引用符のような方向の印を片方に付ければ、曖昧さは解消されます。
これらの文字は、方向性を持つ幅なし空白文字と同様のものです。ただし、単語や文の切れ目にはなりません。
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).
入れ子にされた引用あるいは１つの BIDI 文脈から抜き出した文章を他のところへ張り付けるときのために、対称方向性を持つ文章を入れ子にして流し込むような場合には、やはり文字の方向性は自明ではなくなり、マークアップが必要となります。
また文章のブロックの基本的な方向性を指定することが大いに望まれます。
このような目的のために、 DIR 属性が使用されます。
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.
ブロック-タイプ要素では、 DIR 属性がそのブロックの文章の基本方向性を示します。これが省略されたときには、親要素から引き継がれます。
HTML 文書全体の既定方向性は、 left-to-right です。
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.
inline 要素では、その要素が（以下で説明されるように）新しい埋め込みレベルを始めるようにします。これが省略されたときには、 inline 要素は、新しい埋め込みレベルを始めません。
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.
以下は埋め込みが必要なケースの例で、その効果を示すものです。
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:
<SPAN DIR=LTR> AB <SPAN DIR=RTL> xy <SPAN DIR=LTR> CD </SPAN> zw
</SPAN> EF </SPAN>
以下の表示が得られます（ [] で方向の変化を記します）
One gets the following rendering (with [] showing the directional
transitions):
[ AB [ wz [ CD ] yx ] EF ]
その一方で、このマークアップがなくて基本方向がLTRなら、以下の表示が得られます
On the other hand, without this markup and with a base direction
of LTR one gets the following rendering:
[ AB [ yx ] CD [ wz ] EF ]
埋め込みレベルが使用された上記のケースと違って、yx が左に、wz が右にあることに注意してください。
埋め込みマークアップなしでは、2つまでのレベルがあります。
基本となる方向のレベルと単一の逆行方向のレベルです。
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.
inline 要素の DIR 属性は、国際標準化機構 10646 のLEFT-TO-RIGHT EMBEDDING （ 202A ）と RIGHT-TO-LEFT EMBEDDING （ 202B ）の様式化文字と同等です。
要素の終了タグは、 POP DIRECTIONAL FORMATTING （ 202C ）文字と同等です。
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.
方向の更改は、BDO 要素によって与えられますが、明瞭な様式の文脈から方向性を判断できないような、普通でない短い文章の断片を扱う必要があります。
例えば、これを使って、ラテン文字とアラビア数字とヘブライ文字で構成された部分番号に左から右（または右から左）の表示を強いることができます。
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 の効果は、固有の方向特性にかかわりなく、範囲内の全ての文字の方向性を DIR の値のそれへ強制することです。
これは国際標準化機構 10646 の LEFT-TO-RIGHT OVERRIDE （ 202D ）か RIGHT-TO-LEFT OVERRIDE （ 202E ）文字を用いるのと同等であり、終了タグはまたしても、 POP DIRECTIONAL FORMATTING （ 202C ）文字と同等です。
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.
書式がユーザ入力を得る唯一の方法である以上、どんな言語でも書式へ入力できるようにしたいというのは、当然の要求でしょう。
これは主に UI 問題である一方、動作を助け互換性を増すためのHTML レベルで指定すべき事項があります。
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.
完全な互換性を保証するためには、利用者手先（そして利用者）に、書式を提供しているサーバが、書き込まれた書式を送信するときに扱うことができる文字符号化方式の指示を与える必要があります。
そのような指示は INPUT と TEXTAREA 要素の ACCEPT-CHARSET 属性によって与えられ、スペースかコンマ、またはその両方で区切られた、サーバに受け入れられる文字セットの一覧を含む HTTP Accept-Charset ヘッダ（ [HTTP-1.1] を見よ）を形作ります。
利用者手先は、この属性の内容を利用者に知らせるか、一覧に挙げられた文字セットのレパートリーにない文字を入力できないようにしたければ、そのようにしてかまいません。
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.
"application/x-www-form-urlencoded"メディアタイプに基づく HTML 2.0 書式送信機構は、国際化に対応していません。
実際のところは、 URLs がアスキー文字に限られているため、この機構は ISO-8859-1 テキストにとっても具合が悪いのです。
[RFC1738] の2.2項では、"%HH"表記法を用いて、オクテットを符号化してもよいとしています。しかし、書式から送信されたテキストは、オクテットではなく文字から成り立ちます。
文字符号化方式スキームの仕様書がないため、"%HH"表記法には明確な意味がありません。
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 awkward 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.
最も良い解決案は、 [RFC1867] で描写された"multipart/form-data"メディアタイプを書式送信の POST 方法で用いることです。
この機構は、 HTTP エンティティとして送られた multipart MIME 本文の本文部分にある各々の名前/値の組み合わせの値の部分を取り入れます。各々の本文部分は、もし文字符号化方式スキームを指定するcharset 変数が必要ならば、それを含む適切な Content-Type で分類できます。
書式送信のこの方法を扱うために必要な DTD の変更は、この仕様書に付属している DTD に組み入れられています。
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.
[RFC1738] の URL 符号化方式が、一種の絶対的な内容転送符号化方式として、指定された文字符号化方式の上に適用されたと考えて、POST 方法書式送信をもって送られた"application/x-www-form-urlencoded"メディアタイプ識別子に MIME charset 変数を加える解決案もありますが、上記のものに劣ります。
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.
上述した両方の解決案にまつわる問題の１つは、現行のブラウザの大半で、ブックマークが POST 方式を指定できるようになっていないことで、これは改善されるべきです。
逆に、 GET 方式を、書式データを URL ではなくbodyで送るのに使用できることになります。
これを阻むようなものは、プロトコルには見当たりませんが、今のところ製品としては存在していないようです。
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.
ユーザが入力したテキストの符号化方式を、ユーザエージェントがどのように決定するかは、この仕様書の範囲を外れます。
How the user agent determines the encoding of the text entered by the
user is outside the scope of this specification.
文書を正しく解釈するために、文字符号化スキームを知る必要があります。
しかしながら現行の HTTP サーバは、一般に Content- Type ヘッダのある適切な charset 変数を含む訳ではありません。
これは、 charset 変数を受信していても、認められていないメディアタイプを宣言するブラウザが存在し続けたために助長された、悪いふるまいです。
ユーザエージェントの設計者には、たとえこの変数を利用できなくても、ソフトウェアをこれに対して寛大にするように強く奨励します。
適切な分類が強く望まれるところですが、その欠落による有害な影響を最小限にするために取りうる予防策を以下に挙げておきます。
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:
文書が元の HTML 文書の超連鎖から呼び出された場合、 CHARSET 属性は、 linkExtraAttributes 実体にそれを加えることによって、リンクを意味する（ A と LINK ）要素の属性一覧に加えられます。
その属性の値は、超連鎖によって示された素材に使用された文字符号化方式スキームに関するユーザエージェントへのヒントだと見なされます。；それはその素材のMIME charset 変数の適切な値であるべきです。
In the case where a document is accessed from a hyperlink in an
origin HTML document, a CHARSET attribute is added to the attribute
list of elements with link semantics (A and LINK), specifically by
adding it to the linkExtraAttributes entity. The value of that
attribute is to be considered a hint to the User Agent as to the
character encoding scheme used by the resource pointed to by the
hyperlink; it should be the appropriate value of the MIME charset
parameter for that resource.
どんな文書にも、文書の HEAD の範囲内のできるだけ初めの方に、以下のような符号化方式スキームの指示を入れることができます：
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:
<META HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-2022-JP">
これは万全の事故防止策ではありません。しかし、その符号化方式スキームが、少なくともMETA 要素が解析されるまではそれ自体を表わしているアスキー文字のようにASCII-valuedなオクテットに限っては、うまくいきます。
以上のあてにならない META の代わりに、サーバのための文字符号化方式情報を得るより良い方法があることに注意してください。詳細と提案については [NICOL2] を見てください。定義づけると、文書の原本から受信された"charset"変数がもっとも権威があるものと考えられるべきであり、続いて優先順に、上記のような META 要素の内容、そして最後に（どのようなものでも）錨の CHARSET 変数、となります。
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.
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).
HTML 形式の文章が直接 UCS-2 か UCS-4 形式で送られるときには、バイト順序の問題が起こります。各々の multi-byte 文字の優先バイトが来るのは、最初でしょうか、最後でしょうか？
definiteness のために、この仕様書では、 UCS-2 と UCS-4 が big- endian なバイト順序（優先バイトが最初）、つまり、2,4バイトquantitiesのための確立したネットワークバイト順序──これは連続した文字情報のための国際標準化機構 10646 必要条件と Unicode 推薦条件、そして RFC 1641 に対応する──に対応する形で送られるように勧めます。
さらに、できるだけ正しく解釈できるようにするために、 UCS-2 か UCS-4 として送られる文書は常に、 ZERO-WIDTH NON-BREAKING SPACE 文字（16進法でいう FEFF か 0000FEFF）で始めることを勧めます。この文字は、その反転バイトが、決して割り当てられないことを保証された文字であるナンバー FFFE か FFFE0000 になります。
従って、ユーザ-エージェントがテキストの最初のオクテットとして FFFE を受信すると、文章の残りの部分のためにバイトを反転しなければならないことがわかるわけです。
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.
UCS-2 と UCS-4 に加えて、UCS データを送るために使用できるいわゆる UCS 転送形式というものもあります。
UTF-7 [RFC1642] と UTF-8 [UTF-8] には、考慮に値する、特に多言語テキストの伝達のために都合のいい性質（アスキー適合性が異なりバイト順序の問題がない）があります。
他の符号化方式スキームとしては、 MNEM [RFC1345] も興味深い性質と完全な UCS を送る能力があります。
国際標準化機構 10646:1993 のUTF-1 転送形式（ ISO- 10646-UTF-1 として IANA に登録済）は、国際標準化機構 10646 とは修正４から異なっており、使用すべきでないでしょう。
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.
この項には、RFC 1866のHTML 2.0 DTDに基くHTMLのDTDに、RFC 1867で指定されたファイルアップロードについての変更と、この文書に由来する変更を組み込んだものを収めます。
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.
<!-- html.dtd
Document Type Definition for the HyperText Markup Language,
extended for internationalisation (HTML DTD)
Last revised: 96/08/07
Authors: Daniel W. Connolly <connolly@w3.org>
Francois Yergeau <yergeau@alis.com>
See Also:
http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
<!ENTITY % HTML.Version
"-//IETF//DTD HTML i18n//EN"
-- Typical usage:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">
<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.Deprecated "IGNORE">
]]>
<!ENTITY % HTML.Deprecated "INCLUDE"
-- Certain features of the language are necessary for
compatibility with earlier versions of the specification,
but they tend to be used and implemented inconsistently,
and their use is deprecated. This feature test entity
enables a document type definition that eliminates
these features.
-->
<!ENTITY % HTML.Highlighting "INCLUDE"
-- Use this feature test entity to validate that a
document uses no highlighting tags, which may be
ignored on minimal implementations.
-->
<!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 ==============================-->
<!ENTITY % Content-Type "CDATA"
-- meaning an internet media type
(aka MIME content type, as per RFC2045)
-->
<!ENTITY % HTTP-Method "GET | POST"
-- as per HTTP specification, RFC2068
-->
<!--========= DTD "Macros" =====================-->
<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
<!ENTITY % list " UL | OL | DIR | MENU " >
<!ENTITY % attrs -- common attributes for elements --
"LANG NAME #IMPLIED -- RFC 1766 language tag --
DIR (ltr|rtl) #IMPLIED -- text directionnality --
ID ID #IMPLIED -- element identifier
(from RFC1942) --
CLASS NAMES #IMPLIED -- for subclassing elements
(from RFC1942) --">
<!ENTITY % just -- an attribute for text justification --
"ALIGN (left|right|center|justify) #IMPLIED"
-- default is left for ltr paragraphs, right for rtl -- >
<!--======= Character mnemonic entities =================-->
<!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 -->
<!--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 =====-->
<!-- 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"
-- suspend transform process -->
<!--========== Text Markup =====================-->
<![ %HTML.Highlighting [
<!ENTITY % font " TT | B | I ">
<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
<!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">
<!ELEMENT (%font;|%phrase) - - (%text)*>
<!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
%attrs;
%SDAFORM; "Lit"
>
<!ATTLIST ( B | STRONG )
%attrs;
%SDAFORM; "B"
>
<!ATTLIST ( I | EM | CITE )
%attrs;
%SDAFORM; "It"
>
<!-- <TT> Typewriter text -->
<!-- <B> Bold text -->
<!-- <I> Italic text -->
<!-- <EM> Emphasized phrase -->
<!-- <STRONG> Strong emphasis -->
<!-- <CODE> Source code phrase -->
<!-- <SAMP> Sample text or characters -->
<!-- <KBD> Keyboard phrase, e.g. user input -->
<!-- <VAR> Variable phrase or substitutable -->
<!-- <CITE> Name or title of cited work -->
<!ENTITY % pre.content "#PCDATA|A|HR|BR|%font|%phrase|SPAN|BDO">
]]>
<!ENTITY % text "#PCDATA|A|IMG|BR|SPAN|Q|BDO|SUP|SUB">
<!ELEMENT BR - O EMPTY>
<!ATTLIST BR
%SDAPREF; "&#RE;"
>
<!-- <BR> Line break -->
<!ELEMENT SPAN - - (%text)*>
<!ATTLIST SPAN
%attrs;
%SDAFORM; "other #Attlist"
>
<!-- <SPAN> Generic inline container -->
<!-- <SPAN DIR=...> New counterflow embedding -->
<!-- <SPAN LANG="..."> Language of contents -->
<!ELEMENT Q - - (%text)*>
<!ATTLIST Q
%attrs;
%SDAPREF; '"'
%SDASUFF; '"'
>
<!-- <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"
>
<!-- <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)"
>
<!-- <SUP> Superscript -->
<!-- <SUB> Subscript -->
<!--========= Link Markup ======================-->
<!ENTITY % linkType "NAMES">
<!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)*"
-- <H1><a name="xxx">Heading</a></H1>
is preferred to
<a name="xxx"><H1>Heading</H1></a>
-->
]]>
<!ENTITY % A.content "(%heading|%text)*">
<!ELEMENT A - - %A.content -(A)>
<!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 ==========================-->
<!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 -->
<!--========== Paragraphs=======================-->
<!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) -->
<!--========== Headings, Titles, Sections ===============-->
<!ELEMENT HR - O EMPTY>
<!ATTLIST HR
%just;
%SDAPREF; "&#RE;&#RE;"
>
<!-- <HR> Horizontal rule -->
<!ELEMENT ( %heading ) - - (%text;)*>
<!ATTLIST H1
%attrs;
%just;
%SDAFORM; "H1"
>
<!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 -->
<!--========== Text Flows ======================-->
<![ %HTML.Forms [
<!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
]]>
<!ENTITY % block.forms "BLOCKQUOTE">
<![ %HTML.Deprecated [
<!ENTITY % preformatted "PRE | XMP | LISTING">
]]>
<!ENTITY % preformatted "PRE">
<!ENTITY % block "P | %list | DL
| %preformatted
| %block.forms">
<!ENTITY % flow "(%text|%block)*">
<!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO">
<!ELEMENT PRE - - (%pre.content)*>
<!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 -->
<![ %HTML.Deprecated [
<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the end tag
in full
-->
<!ELEMENT (XMP|LISTING) - - %literal>
<!ATTLIST XMP
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Example:&#RE;"
>
<!ATTLIST LISTING
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Listing:&#RE;"
>
<!-- <XMP> Example section -->
<!-- <LISTING> Computer listing -->
<!ELEMENT PLAINTEXT - O %literal>
<!-- <PLAINTEXT> Plain text passage -->
<!ATTLIST PLAINTEXT
%attrs;
%SDAFORM; "Lit"
>
]]>
<!--========== Lists ==================-->
<!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 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 -->
<!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 (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 -->
<!ELEMENT LI - O %flow>
<!ATTLIST LI
%attrs;
%just;
%SDAFORM; "LItem"
>
<!-- <LI> List item -->
<!--========== Document Body ===================-->
<![ %HTML.Recommended [
<!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
-- <h1>Heading</h1>
<p>Text ...
is preferred to
<h1>Heading</h1>
Text ...
-->
]]>
<!ENTITY % body.content "(%heading | %text | %block |
HR | ADDRESS)*">
<!ELEMENT BODY O O %body.content>
<!ATTLIST BODY
%attrs;
>
<!-- <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"
>
<!-- <BLOCKQUOTE> Quoted passage -->
<!ELEMENT ADDRESS - - (%text|P)*>
<!ATTLIST ADDRESS
%attrs;
%just;
%SDAFORM; "Lit"
%SDAPREF; "Address:&#RE;"
>
<!-- <ADDRESS> Address, signature, or byline -->
<!--======= 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>"
>
<!-- <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 |
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 -->
<!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 -->
<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
%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-->
<!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 -->
]]>
<!--======= Document Head ======================-->
<![ %HTML.Recommended [
<!ENTITY % head.extra "">
]]>
<!ENTITY % head.extra "& NEXTID?">
<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
<!ELEMENT HEAD O O (%head.content) +(META|LINK)>
<!ATTLIST HEAD
%attrs; >
<!-- <HEAD> Document head -->
<!ELEMENT TITLE - - (#PCDATA)* -(META|LINK)>
<!ATTLIST TITLE
%attrs;
%SDAFORM; "Ti" >
<!-- <TITLE> Title of document -->
<!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) -->
<!ELEMENT ISINDEX - O EMPTY>
<!ATTLIST ISINDEX
%attrs;
%SDAPREF;
"<Para>[Document is indexed/searchable.]</Para>">
<!-- <ISINDEX> Document is a searchable index -->
<!ELEMENT BASE - O EMPTY>
<!ATTLIST BASE
HREF CDATA #REQUIRED >
<!-- <BASE> Base context document -->
<!-- <BASE HREF="..."> Address for this document -->
<!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 -->
<!ELEMENT META - O EMPTY>
<!ATTLIST META
HTTP-EQUIV NAME #IMPLIED
NAME NAME #IMPLIED
CONTENT CDATA #REQUIRED >
<!-- <META> Generic Meta-information -->
<!-- <META HTTP-EQUIV=...> HTTP response header name -->
<!-- <META NAME=...> Meta-information name -->
<!-- <META CONTENT="..."> Associated information -->
<!--======= Document Structure =================-->
<![ %HTML.Deprecated [
<!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
]]>
<!ENTITY % html.content "HEAD, BODY">
<!ELEMENT HTML O O (%html.content)>
<!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
<!ATTLIST HTML
%attrs;
%version.attr;
%SDAFORM; "Book"
>
<!-- <HTML> HTML Document -->
<!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
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
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
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
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
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
--
>
以下の公文は、拡張ラテン１実体セットで指定された文字の各々を、その名前、使用法、説明と共に一覧表にしたものです。
この一覧表は、国際標準化機構標準 8879:1986//ENTITIES Added Latin 1//ENに由来しています。
HTML はこの実体セットの全体を採り入れ、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 -->
<!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 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 -->
錨、埋め込み画像、および全ての他の要素で、パラメーターとしてURIs を含むものでは、利用者入力に応じてその URI を書き換えられるようにしてかまいません。
このケースでは、 [RFC1738] にある安全性への配慮があてはまります。
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.
書式リクエストを提出するための普及した方法（ HTTP と SMTP ）では、秘匿性についてほとんど保証されません。
書式、特に「パスワード」打ち込み入力フィールド（ [RFC1866] のセクション 8.1.2 を見よ）によって、取り扱いに慎重を要する情報を要請する情報供給者は、その秘匿性の不足に警戒し、またそのことについて利用者に警告するようにすべきです。
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.
以上は、RFC2070の全訳です。なお、原典はテキストファイルであり、この文書のHTMLは訳者において表記したものです。
訳文についてのご意見などは、訳者までお送りください。翻訳にあたって原著者の了解など一々取ってはいません。訳文のことで原著者に迷惑を掛けたりしないでください。
また、正式なRFCは英語で書かれた原典のみです。この翻訳を見ただけで原著者を批判したりしないでください。
この翻訳の利用については、RFCに準じます。RFC2026を参照してください。このうち、copyrightに関する部分は、rfc-jpにて試訳したものがありますので、併せて参考にしてください。
また、これとは別にRFCの編者がcopyrightに関して述べたものの南山大学による日本語訳もあります。