Network Working Group T.Berners-Lee Request for Comments: 1866 MIT/W3C Category: Standards Track D. Connolly November 1995 日本語訳: 南山大学情報管理学科科における学部3年の後藤の講義の宿題として, 学生に翻訳してもらい, 修正したものです. コピーライトは原典に 準じます. 複数人の作業によるので文体の不一致等は御容赦下さい. Contact: goto@iq.nanzan-u.ac.jp 作成日: 1996年10月4日 (訳注: 本翻訳は参考のため提供されているもので, 英文のものが正式である. 本翻訳の正しさについて, 一切保証しない.) Hypertext Markup Language - 2.0 このメモの意義 このドキュメントは、インターネット社会のためのインターネット標準トラ ックプロトコルについて書かれており、改良のための議論、提案を求めるも のである。このプロトコルの標準化の現状については、”インターネット公 式プロトコル標準”(STD 1) を参照のこと。このメモは、無制限に配布して もよい。 抜粋 ハイパーテキスト・マークアップ言語(HTML)はプラットフォームに依存しな いハイパーテキストを作るのに使われるシンプルなマークアップ言語である。 HTML文書は広範囲の領域からの情報を表すために適した一般的な語義(セマ ンティクス)を持つSGML文書である。HTMLマークアップはハイパーテキスト ニュース、メール、文書そしてハイパーメディア、オプションのメニュー、 データベースの質問結果、インライングラフィックをもつ構造化された文書、 すでに存在する情報の本体をハイパーテキストの形で表現することができる。 HTMLはWorld Wide Web(WWW) global information initiative によって1990 年から使われている。この文書は1994年6月以前に一般に用いられていたHTML の能力とほぼ対応している。HTMLはISO標準 8879:1986 情報処理テキストと オフィスシステムつまり標準汎用マークアップ言語(SGML)のアプリケーショ ンである。 ”text/html”インターネットメディアタイプ(RFC 1590)とMIMEコンテント タイプ(RFC 1521)はこの仕様によって定義されている。 目次 1. はじめに ....................................................2 1.1 適用範囲 ....................................................3 1.2 適合 ........................................................3 2. 用語 ........................................................6 3. SGMLの応用としてのHTML .....................................10 3.1 SGML文書 ...................................................10 3.2 HTML 語句構文 ..............................................12 3.3 HTML公開テキスト識別子 .....................................17 3.4 HTML文書の例 ...............................................17 4. インターネットメディアタイプとしてのHTML ...................18 Berners-Lee & Connolly Standards Track [Page 1] RFC 1866 Hypertext Markup Language - 2.0 November 1995 4.1 text/html メディアタイプ.....................................18 4.2 HTML文書の表現 ..............................................19 5. 文書 構造 ...................................................20 5.1 文書 要素：HTML .............................................21 5.2 ヘッダ：HEAD ................................................21 5.3 本文：BODY ..................................................24 5.4 見出し：H1...H6 .............................................24 5.5 ブロック構造要素 ............................................25 5.6 表の要素 ....................................................28 5.7 句のマークアップ ............................................30 5.8 改行：BR ....................................................34 5.9 水平罫線：HR ................................................34 5.10 イメージ：IMG ..............................................34 6. 文字、単語、段落 ............................................35 6.1 HTML文書文字セット ..........................................36 7. ハイパーリンク ..............................................36 7.1 リソースのアクセス ..........................................37 7.2 ハイパーリンクの活性化 ......................................38 7.3 イメージ リソースの同時の表示 ...............................38 7.4 部分の識別子 ................................................38 7.5 質問と索引 ..................................................39 7.6 イメージマップ ..............................................39 8. フォーム ....................................................40 8.1 フォームの要素 ..............................................40 8.2 フォームの提出(送信) ........................................45 9. HTML公開テキスト ............................................49 9.1 HTML DTD ....................................................49 9.2 厳密なHTML DTD ..............................................61 9.3 レベル1 HTML DTD ...........................................62 9.4 厳密な レベル1 HTML DTD .....................................63 9.5 HTMLのためのSGML宣言 ........................................64 9.6 HTMLのためのSGML公開のエンティティカタログの見本 ............65 9.7 文字エンティティセット ......................................66 10. セキュリティについての考察 ..................................69 11. 参照 ........................................................69 12. 謝辞 ........................................................71 12.1著者のアドレス ..............................................71 13. HTMLコード化された文字セット ................................72 14. 提案されたエンティティ ......................................75 1.はじめに ハイパーテキスト・マークアップ言語(HTML)は1つのプラットフォームから 別のものへと持って行けるハイパーテキスト文書を作成するために使われ るシンプルなデータ形式である。HTML文書は広範囲の領域からの情報を表 すために適した一般的な語義(セマンティクス)を持つSGML文書である。 Berners-Lee & Connolly Standards Track [Page 2] RFC 1866 Hypertext Markup Language -2.0 November 1995 HTMLはSGMLの応用なので、この仕様は[SGML]の実用的な知識があることを前 提としている。 1.1 適用範囲 HTMLはWorld Wide Web(WWW) global information initiative によって、19 90年から使われている。以前は、HTML(規格)に関する非公式文書がインター ネット上の多数の源から入手できた。この本文は1994年6月以前に一般に使 われていたHTMLの能力にほぼ対応している特徴の一式をまとめ、明確にし、 正式にしている。HTMLの多数の新しい特徴はインターネット社会で提案され、 実験されている。 こうして、この文書は（前の非公式の仕様と区別するために）HTML2.0を定 義している。新しい特徴を持つ、HTMLの将来のバージョン（一般的にさらに 矛盾のないもの)は一層高いバーション数で公開されるだろう。 HTMLはISO標準8879:1986、「情報処理テキストとオフィスシステム、つまり 標準汎用マークアップ言語」(SGML)のアプリケーションである。HTMLの文書 型定義(DTD)はSGMLにおけるHTML構文の正式の定義である。 この仕様はまた、インターネットメディアタイプ[IMEDIA]と’text/html'と 呼ばれるMIMEコンテントタイプ[MIME]としてHTMLを定義する。そのようなこ ととして、それはHTMLのセマンティクスとその構文が利用者のエージェント によって解釈されるべきである方法を定義する。 1.2 適合 この仕様はHTMLドキュメントの構文とHTMLユーザエージェントの行為と特徴 を規定する。 1.2.1 文書 文書は次の条件を満たせばHTML文書であると言える。 *それがSGML文書に適合し、HTML DTD(9.1 "HTML DTD"参照)に従う。 注 -- いくつかの古いユーザエージェント(WWWブラウザ)において、 使えないあるいはいいかげんにサポートされている多数の慣用 構文がある。(以後)これらの語法はこの仕様を通じて、このよ うに注として説明される。 *それはこの仕様の中のアプリケーションの慣習に従う。例えば、要素の HREF属性の意味はURI構文に従わなければならない。 Berners-Lee & Connolly Standard Track [Page 3] RFC 1866 Hypertext Markup Language - 2.0 November 1995 *その文書文字セットは[ISO-8859-1]を含み、[ISO-10646]と同意する； つま り、”HTMLコード化された文字セット”を含む、13の中にリストされた 各々 のコードの位置そして文書文字セットの中の各々のコードの位置は[ISO- 106 46] がそのコード位置と対応しているものと同じ文字に位置づけられている。 注 -- この文書文字セットは文書を表現するのに使われる文字符号 化方式と多少独立している。例えば、'ISO-2022-JP'の文字符 号化方式はそのレパートリーが[ISO-10646] のレパートリー のサブセットであるので、HTML文書で使われることができる。 非常に重要な特徴は文書の符号化の方法に関わらず、数による 文字参照が [ISO-10646]と同意することである。 1.2.2 特徴テストエンティティー HTML DTDは特徴テストエンティティーの方法によって、標準HTML文書タイプ といくつかの変形を定義する。特徴テストエンティティーはDTDの一部の包括 または除外をコントロールするHTML DTDの中で宣言されている。 HTML.推奨 いくつかのこの言語の特徴は、すでに広く使われており、互換性のた めに必要となるが、それらは文書の構造の完全性を妥協するかもしれ ない。この特徴テストエンティティーはこのような特徴を除くさらに 長年の使用によって得られた文書型定義を選ぶ。その省略時の値は 'IGNORE'と設定されている。 例えば、文書の構造を保存するために編集するユーザエージェントは HTML文書を推奨サブセットに書き換えるかもしれないし、あるいは、 それは文書が取り込まれるためには、推奨サブセットであることを要 求するかもしれない。 使わないほうがよいHTML この言語のある特徴は仕様の古いバージョンとの互換性を必要とする が、しかし、それらはでたらめに使われ、実現される傾向があり、そ してそれらの使用は非難される。この特徴テストエンティティーはこ のような特徴を許している文書型定義を有効にする。その省略時の値 は'INCLUDE'と設定されている。 Berners-Lee & Connolly Standards Track [Page4] RFC 1866 Hypertext Markup Language - 2.0 November 1995 トランスレーションソフトウェアあるいはソフトウェアを編集するこ とによって生成された文書は非難された慣用句を含むべきではない。 1.2.3.ユーザエージェント HTMLのユーザエージェントは以下の条件を満たせば、この仕様に適合する。 *それはHTML文書の文字を[SGML]に従ってデータ文字とマークアップ に解剖する。 注 -- 頑健性と拡張性のために、不適合文書処理のために広 く用いられている慣例がある。詳細は、4.2.1"宣言さ れていないマークアップエラーの取り扱い"を参照の こと。 *それは 'ISO-8859-1'の文字符号化方式とISO Latin アルファベット NO.1 の中の各々の文字の処理をサポートしている。詳細は6.1 "HTML文書文字セット"で述べる。 注 -- 西洋でない文書システムをサポートするために、HTML ユーザエージェントは'ISO-10646-UCS-2',あるいは 同じような文字符号化方式をサポートするのを支援さ れ、そして[ISO-10646]のレパートリーの多くのもの と同じように実用的である。 *それは 解剖されたトークンの順序が同じである文書のために確かに 作動する。 例えば、タグの中のコメントや空白がトークン化の間に消えてしまう その結果それらはユーザエージェントを適合する行動に影響を与えな い。 *ユーザエージェントはHTML文書の要素からすべてのハイパーリン クを通るのを(あるいは少なくともリソースが許されているなら、通 る試み)許されている。 HTMLユーザエージェントがレベル2のユーザエージェントであるなら次のことを 付け加える： *ユーザエージェントはHTML文書で指定されたフィールドの値からすべ てを表現でき、インフォーメーションサービスへの要求としてのそ の値を提出すること（試み）が許されている。 Berners-Lee & Connolly Standards Track [Page 5] RFC 1866 Hypertext Markup Language - 2.0 November 1995 2.用語 絶対URI 絶対的な書式にあるURI。 アンカー ハイパーリンクの二つの終りのうちの一つ、典型的に、 あるフレーズはエレメントのようにしるされる。 基礎URI もう一つの絶対URIを決定するために相対URIと組合せで 使われたある絶対URI。 文字 情報の細かく分かれたもの。例えば、文または数。 グラフィック文字は、グラフを連想させる。 それにたいしてコントロール文字は、意味論の処理 を連想させる。 文字符号化配列 ある関数である、そしてその範囲は８ビットの順序の集合 でありそして文字のレパートリーから文字の順序 の集合である、ということは、８ビットの順序と、 文字符号化配列は、文字の順序を決定する。 文字レパートリー 文字の有限の集合である。そしてそれは、 符号化文字集合の範囲内である。 コード位置 ある整数である。符号化文字集合とその範囲からの コード位置は、文字を決定する。 符号化文字集合 ある関数である。そしてその範囲は、整数のサブセット であり文字レパートリーである。というのは、整数の いくつかの集合である。（ふつうは、０＋自然数） 符号化文字集合と、あの集合のなかのある整数は、 文字をきめる。逆にいえば文字と符号化文字集合は 文字のコード位置を決める。（または、まれな場合、 少ないコード位置を） HTMLユーザーエイジェントに従うということ インターネットメディアタイプのtext/htmlの中の処理方 の詳述に従うユーザーエイジェント。 Berners-Lee & Connolly Standards Track [Page 6] RFC 1866 Hypertext Markup Language - 2.0 November 1995 データ文字 マークアップ以外の文字、そしてそれはエレメントの 要旨を作り上げる。 文書文字集合 ある符号化文字集合、そしてその範囲は文書のなかで 使われたすべての文字を含む。 すべてのSGML文書は、確かに、一つの文書文字集合 をもつ。数文字参照は、文書文字集合経由で解決 される。 DTD 文書型定義、SGML特定の型の文献のマークアップに、 あてはめるルール、エレメントの集合と実体宣言を 含む。 エレメント 文献型定義により定義された階級的構造のコンポーネント そしてそれは、陳述的なマークアップ、普通はスタート タグとエンドタグにより文書の例と見分けられる。 エンドタグ エレメントの終りを見分ける陳述的なマークアップ。 エンティティー 表記または、解釈を連想させるものを持つデータ、 例えば８ビットはの順序は、インターネット メディアタイプを連想させる。 フレイグメントアイデンティティフィアー HREF特有の値の一部は、次のハイパーリンク の到着地点の表現を修正する文字'#'に従う。 フォームデータ集合 ネームとバリューのペアの順序、そしてネームというのは HTML文書によって与えられている、そしてバリューというのは ユーザーによって与えられている。 HTML文書 この文書型定義に従っているSGML文書。 ハイパーリンク 二つのアンカーの間の関係、そしてそれはヘッドとテイルと 呼ばれる。このつながりは、テイルからヘッドへいくそして、 このヘッドとテイルはまた到着地点と出所としてそれぞれ 知られている。 Berners-Lee & Connolly Standards Track [Page 7] RFC 1866 Hypertext Markup Language - 2.0 November 1995 マークアップ 概括的にその構造を表す文書のデータを加えられた 限りのない文字。 四つの異なったマークアップがある、陳述的マークアップ 、参照マークアップ、宣言、処理命令、である。 may 文献または、ユーザーの境界は、この陳述があてはまる かどうかということに従っている。 メディアタイプ インターネットメディアタイプである。 メッセージエンティティー ヘッドとボディー、ヘッドはネームとバリューの分野の集まり、 そしてボディーは、８ビットの順序。ボディーは満足型と、 満足なボディーの符号化の移動の定義をする。 最小限にHTML利用者に従うこと この陳述に従う利用者は、形態処理を期待する。 それは、レベル１HTML文書を処理するかもしれない。 must 文書またはユーザーエイジェントの作用がこの陳述と不一致するとき 従わない。 数文字参照 文書文字集合のなかのコード位置により文字を参照 するマークアップ。 SGML文書 具体的にエンティティーの集合のように組織された文字の順序 そして抽象的にエレメントの階級組織のなかに組織 された文字の順序、SGML文書はデータ文字とマークアップ からなる。そのマークアップは、情報の構造やその構造 の例を描く。 shall もし文献または、利用者がこの陳述にあわないなら この陳述には、したがわない。 Berners-Lee & Connolly Standards Track [Page 8] RFC 1866 Hypertext Markup Language - 2.0 November 1995 should もし文書または利用者がこの陳述に不一致するなら 望まない結果が、それがこの陳述に従ったとしてさえも 実際には起こるかもしれない。 スタートタグ エレメントのスタートを見分ける、そあいて一般的な 同一性や特性を詳しく述べる論述的マークアップ。 構文参照文字集合 符号文字集合、その範囲は、マークアップのために 使われたすべての文字を含む、そしてそのマークアップ は、e.g.ネーム文字そしてデリミター文字である。 タグ エレメントを制限しないマークアップ。タグは、DTDのなかで エレメント宣言を参照する名前を含む、そして特性を含む かもしれない。 テキストエンティティー 文字の有限の順序。テキストエンティティーは、典型的に文字符号化 配列を連想させる何らかをもつ８ビットの順序ネットワーク上 の移動、ファイルに蓄えられたもの形態をとる。 典型的な 典型的な処理方法は、多くのエレメントのために描かれている。 これは、陳述の主要の部分ではなくデザイナーのための ガイダンスとしてそしてエレメントが何を意図するのか、 説明するのを助けるために与えられたもの。 URI A Uniform Resorse Identifier（URI)は典型的にインターネット では、出所のために同一性として対応する文字列を 配列する。URIは、ハイパーリンクスのアンカーを見分けるために HTMLのなかで使われる。 URIは共通に実際的URLと相対的なURLを含む。 ユーザーエイジェント 境界を表したりユーザーの代わりに要求を処理する 配分システムのコンポーネント例えばWWWブロウザー または、メイルユーザーエイジェントがある。 Berners-Lee & Connolly Standards Track [Page 9] RFC 1866 Hypertext Markup Language - 2.0 November 1995 WWW 世界中で広く使われているWedは、ハイパーテキストベイスド である、そしてそれはスイスのCERNの調査会社によって 出された情報である。 3. SGMLの適用のようなHTML HTMLはISO 8897:1986の適用である。Standard Generalized Markup Language(SGML)。 SGMLは、形作られた文書型とそれらの文書型の例を表現する マークアップ言語を定義するためのシステムである。 公開テキスト、DTDとSGML宣言（HTML文献型定義の） は、9"HTML public textによって与えられている。 HTMLの用語ここで定義された文書型とこの文書型の例 の表現のためのマークアップ言語の両方を参照する。 3.1. SGML文書 HTML文書は、SGML文書 である、というのは体系的に エンティティーの集合中に組織され、論理的にエレメントの階級組織 とみなされる文字の順序である。 SGMLの陳述のなかにSGML構文法の最初の産物は、SGML文献 の三つの部分に分かれる、それはSGML宣言、プロローグ、例 である。この陳述のため、プロローグは、DTDである。このDTD はもう一つの文法を描くその最初の象徴はドクタイプ宣言で与えられる そして最後は、データ文字とタグで与えられる、そしてその産物 は、エレメント宣言によって決められる。その例は、DTDを形成するに ちがいない、というのはこの文法によって言語が定義されなければ ならないからである。 SGMLの宣言は文法の語彙集を決める。それは文書文字集合 を論じるそしてそれはその文書のなかのすべてのテキストエンティティー の中で起こるすべての文字を含む文字レパートリーと それらの文字を連想させるコード位置である。 SGML宣言はまた、文書構文法参照文字集合 とすこしの具体的な構文法へのSGMLの抽象的な構文法 を拘束する他のパラメーターを論じる。この具体的な 構文法は、どのようにプロローグの中の最後の順序 に、文書文字の順序に位置するのか、決める。 Berners-Lee & Connolly Standards Track [Page 10] RFC 1866 Hypertext Markup Language - 2.0 November 1995 例えば次の文章をかんがえよ： Parsing Example

Some text. *wow*

あるHTML使用代理人は、9.5,"SGML Declaration for HTML"に与えられたSGML宣言を 用いるべきである。 その文書文字セットによれば、`*'は星印`*'である。 上の例は、次の一連の端末とみなされる: 1. start-tag: TITLE 2. data characters: "Parsing Example" 3. end-tag: TITLE 4. start-tag: P 5. data characters "Some text." 6. start-tag: EM 7. data characters: "*wow*" 8. end-tag: EM 9. end-tag: P Berners-Lee & Connolly Standards Track [Page 11] RFC 1866 Hypertext Markup Language - 2.0 November 1995 DTD文法の始まりの象徴は、HTMLである。そして、その製品は `-//IE TF//DTD HTML 2.0//EN'によって見分けられる。 公共の本文に与えられて いる。上の端末を次のように解剖する: HTML | \-HEAD | | | \-TITLE | |8 | \- | | | \-"Parsing Example" | | | \- | \-BODY | \-P | \-

| \-"Some text. " | \-EM | | | \- | | | \-"*wow*" | | | \- | \-

その要素のなかには、tagによって、明白に限界を定められるものもある、なのに 他のものに限界は推測される。 要素は、要素や要素を含む。 はstart-やend-tagsによって、明白に限界を定められるを含む。 3.2. HTML Lexical Syntax SGLMは、抽象的なシンタックスや、言及の具体的なシンタックスを明細に述べる。 確かな数や能力(例えば名前の長さ制限)に加えた、全てのHTML文書は、言及の具 体的なシンタックスを用いている。 特に、全ての組指定文字は[ISO-646]のレパ ートリーの中にある。資料文字は、文書文字セット(see 6, "Characters, Words, and Paragraphs")から取られている。 Berners-Lee & Connolly Standards Track [Page 12] RFC 1866 Hypertext Markup Language - 2.0 November 1995 SGMLの解剖の完全な討議、例えばtagsやdataの一連の文字の一連の計画は、SGMLの 基準[SGML]に任せる。 この部分は、ただ１つの要約である。 3.2.1. Data Characters 組指定を制定しない(see 9.6 "Delimiter Recognition" of [SGML])一連の文字は、 直接にデータ文字の組に計画される。 組指定の中にもまた、データ文字の組に計 画するものもある。数の文字言及は文書文字セットによってただ１つの文字の組 に計画する。HTML DTDの中で定義された概略の実体の１つへのそれぞれの言及は、 ただ１つの文字の組に計画する。 例えば abc<def => "abc","<","def" abc<def => "abc","<","def" 実在物もしくは、数の文字言及を終結するセミコロンは、ただ１つ必要なもので ある。 つぎの言及の文字は、他の点では、名前の部分(see 9.4.5 "Reference End" in [SGML])であると認められる。 abc < def => "abc ","<"," def" abc < def => "abc ","<"," def" アンパサンド（＆）は、文字もしくは`#'やアラビア数字をともなうとき、ただ１つ 組指定と認められる。 abc & lt def => "abc & lt def" abc &# 60 def => "abc &# 60 def" 分かりやすい本文をHTMLに訳すために有用な技巧は、それぞれ'<','&',そして'>'を 実在の言及もしくは次のような数の文字言及と取り替えることです。 ENTITY NUMERIC CHARACTER REFERENCE CHAR REF CHARACTER DESCRIPTION --------- ---------- ----------- --------------------- & & & Ampersand < < < Less than > > > Greater than 注意ーSGML機構や内容を宣言されたCDATAやRCDATAがある、それは実在の言及を 利用しないで書き入れられる'<','>'や'&'文字を許す。なぜなら、 これらの技巧は利用されたり、矛盾して実行される傾向がある。 そして、それらは、 Berners-Lee & Connolly Standards Track [Page 13] RFC 1866 Hypertext Markup Language - 2.0 November 1995 輸送するためにHTMLを7 bit ASCIIにするために技巧と矛盾するため、HTMLのこの 説明で軽視される。See 5.5.2.1, "Example and Listing: XMP, LISTING". 3.2.2. Tags Tagsは、見出し、段落、表、文字の連結、そして連結のような要素限界を定める ほとんどのHTMLの要素は、内容に従いend tagに従う要素名や属性を与えるstart- tagのような文書に見分けられる。Start-tagsは、'<'や'>'によって限界を定められ end-tagsは、'</'や'>'によって限界を定められる。１つの例は <H1>This is a Heading</H1> 要素の中には、ただstart-tagをもち、end-tagをもたないものもある。例えば、 境界を破壊することは'<BR>'tagを用いる。その上に段落('</P>')、表の項目(' </L1>')、定義条件('</DT>')、や定義記述('</DD>')要素のような、いくつかの 他の要素のend-tagsは、省略されても良い。要素の内容は、一連のデータ文字の 組々や、安置された要素である。安定装置のような、要素の中には安置出来ない ものもある。安定装置や文字を強調することは、他の組立てたものの中に置かれる。 See the HTML DTD, 9.1, "HTML DTD" for full details. 注意ーSGML宣言は`<EM/.../'; empty start tags, `<>'; and empty end-tags, `</>'のようなtagのための他の妥当なシンタックスがあることを意味する SHORTTAG YESを明細に述べる。これらの熟語の支持が広く展開されるまで、 これらの使用は、強く妨げられた。 3.2.3. Names 名前は、 文字、アラビア数字、ピリオドもしくはハイフンに従う文字から成る。 名前の長さは、HTML, 9.5, "SGML Declaration for HTML"のための、SGML宣言の 中の'NAMELEN'変数によって、72文字に制限されている。要素や属性名は、敏感な 実例ではない、しかし実在物は敏感な実例である。例えば、`<BLOCKQUOTE>', `<BlockQuote>'や`<blockquote>'は等しい、である一方`&'は`&'とは、 異なる。 start-tagの中では、要素名は直ちにtag open delimiter `<'の次に来なければな らない。 Berners-Lee & Connolly Standards Track [Page 14] RFC 1866 Hypertext Markup Language - 2.0 November 1995 3.2.4. Attributes start-tagの中では、白い余白や属性は要素名と限界を定めるものの終結の間に 許される。属性の詳述は、典型的に属性名、等しい印、そして評価から成る、 だけども属性の詳述の中にわ、ただ名前の印であるものもある。白い余白は、 等しい印のまわりに認められる。 属性の評価は、どちらでもいい: *たった１つの引用符もしくわ、２つの引用符によって制限され、そして制限する 文字の発生を含んでいない誤字 注意ー史上存在する実行の中には、'>'文字の発生をtagの終りの合図とみなす ものもある。このような実行を伴う矛盾のために属性の評価の中に'>'が 現れた時、それは数の文字の言及を象徴される。例えば、`<IMG SRC=" eq1.jpg" alt="a>b">'は、`<IMG SRC="eq1.jpg" alt="a>b">'もしく わ `<IMG SRC="eq1.jpg" alt="a>b">'と書かれる。 *（一連の文字、アラビア数字、ピリオド、もしくわ）名前の印。 名前の印は、敏感な実例では、ない。 注意ー史上存在する実行は、名前の印の中に余白や'>' を除いた文字を許すものもある。 この例では、<img> は、要素名であり, srcは、属性名であり、それは`http://host /dir/file.gif'属性評価である。 <img src='http://host/dir/file.gif'> 与えられた文字に対する属性評価を計算するために有用な技巧は、次のような実在 物言及もしくわ数字言及によってそれぞれの引用文や、白い余白を置き換えること である。 ENTITY NUMERIC CHARACTER REFERENCE CHAR REF CHARACTER DESCRIPTION --------- ---------- ----------- --------------------- HT Tab LF Line Feed CR Carriage Return SP Space " " " Quotation mark & & & Ampersand Berners-Lee & Connolly Standards Track [Page 15] RFC 1866 Hypertext Markup Language - 2.0 November 1995 例： <IMG SRC="image.jpq" alt="First "real" example"> SGML宣言（9.5, "HTMLのためのSGML宣言）の中の'NAMELEN'パラメーターは 表号数字の長さを1024字に制限している。 ISMAPやCOMPACTのような表号は最少化されたsyntax（[SGML]の"Omitted Attribute Name"7.9.1.2 を参照）を使って書かれている。 The markup : <UL COMPACT="compact"> 最少化されたsyntaxを用いて書かれると <UL COMPACT> NOTE - いくつかの歴史的実行のみがこの最少化されたsyntaxを理解できる。 3.2.5. Comments （批評） HTML文書の中にコメントを含み、コメント宣言を使います。コメント宣言は '<!'で始まりゼロもしくはより多くのコメントをふくんで'>'で終ります。 それぞれのコメントは'--'で始まりすべてのテキストを含んで次の'--'の 表記で終ります。コメント宣言の中で空欄はそれぞれのコメントの後に与 えられ前には与えられません。全体のコメント宣言は無視されます。 NOTE- いくつかの歴史的HTMLの実行は不正確であり、コメントの最後は'>' であると考えている。 例： <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HEAD> <TITLE>HTML Comment Example

Berners-Lee & Connolly Standards Track [Page 16] RFC 1866 Hypertext Markup Language - 2.0 November 1995 3.3. HTML Public Text identifiers （HTML公開テキストの確認） この仕様書を構成するHTML文書として情報を確認する。それぞれの 文書は文書型宣言に従う１つとして始めなければならない。 この文書型宣言は"HTML DTD" 9.1の中のHTML DTDに言及している。 NOTE- もし'text/html'メッセージエンティティーの実体が文書型宣言 で始まらなかったら、HTMLユーザーエージェントは文書型宣言の 場所を推測すべきである。 この文書型宣言はまた"HTML DTD"9.1に現れるHTML DTDも言及する。 この文書型宣言は"Level 1 HTML DTD"9.3の中のLevel 1 HTML DTDに言 及している。 これら２つの文書型宣言は"Strict HTML DTD"9.2と"Strict Level 1 HTML DTD"9.4のHTML DTDに言及している。それらはHTMLのより厳格で厳しい定義 を述べている。 HTMLユーザーエージェントは他の文書型をサポートする。とくに、他の 公式公開アイデンティファイアーもしくは他の文書型といっしょにサポ ートする。追加エンティティーとして内部宣言の部分集合や要素、他の マークアップ宣言をサポートする。 3.4. Example HTML Document （HTML文書例） 構成例

First Header

これはHTMLファイル例の段落です。 Berners-Lee & Connolly Standards Track [Page 17] RFC 1866 Hypertext Markup Language - 2.0 November 1995 タイトルは文書テキストの中に 現れません。しかしheader（H1によって定義されている）は表示さ れることを覚えておいてください。

  1. リストの初めの文
  2. 2文目
    • リストノート を差し込むことができる。
    • 空欄はHTMLソースを読むための手助けに使うことができる。
  3. 3文目

Warning: これらを読んで確かめる。大まかな構成 4. HTML as an Internet Media Type （インターネットメディア型HTML） HTMLユーザーは、HTML表現を持つリソースをユーザーが相互に影響を与える ことを許している。最小限、ユーザーがHTMLのレベル１文書の内容を検査し たり誘導することを許さなくてはならない。HTMLユーザーエージェントは HTML文書の中の、構成しているすべての相違点を保存し、同時にIMG要素（ いくつかの構成している相違点、もしくはユーザーの要求におけるIMGリソ ースは無視される可能性がある。）によって参照されるリソースを表現すべ きである。レベル２HTMLユーザーエージェントは構成の申請と提出の手助け をすべきである。 4.1. text/html media type （text/htmlメディア型） この仕様書はインターネットメディア型[IMEDIA]（以前はコンテント型とし て参照されていた[MINE]）'text/html'と呼ばれ、定義されている。以下は [IANA]に記載されている。 Media Type name text Media subtype name html 要求されるパラメータ none Berners-Lee & Connolly Standards Track [Page 18] RFC 1866 Hypertext Markup Language - 2.0 November 1995 付属パラメータ level,charset 暗号化する際の考察 いくつかの暗号化は許される。 セキュリティーの考察 "Security Considerations" 10を参照 付属パラメータは以下のように定義される： レベル１ レベルパラメータは文書の中に使われる特徴的な組を詳細に示し ている。レベルはinteger番号であり、いくつかの同じ特徴を持ち より低いレベルが文書の中に表されることもある。レベル１では、

要素が要求するものを除いてすべての特徴はこの仕様書の中 に定義されている。レベル２は過程型を含んでいる。レベル２はデ フォルトである。 Charset Charsetパラメータ（REC 1521[MINE]7.1.1セクションの定義による） はオクテットのシークエンスとしてHTML文書に表現するために使われ る文字暗号化配列を詳細に示すために与えられる。デフォルト数値は この文書の範囲外である。しかし例えばMAIN mailの文脈の中でデフォ ルトは'US-ASCII'でありHTTP[HTTP]の文脈の中では'ISO-8859-1'であ る。 4.2. HTML Document Representation （HTML文書表現） 'text/html'のコンテント型のメッセージエンティティーはHTML文書を表し １つのテキストエンティティーを構成する。'charset'パラメータ（暗黙か そうでないか）は暗号化された文字配列を確認する。テキストエンティティ ーは、メッセージエンティティーの実体のオクテットとこの暗号化された 文字配列によって決定された文字を構成する。 4.2.1. Undeclared Markup Error Handing （非宣言マークアップエラー操作） HTML文書のさまざまなバージョンの実行の間で実験や操作を楽にし、HTMLの 基礎をインストールしたユーザーエージェントはHTML2.0にそれを削減する ことによってHTML2.0言語の特殊な部分をサポートする。包括的なアイデン ティファイアーは宣言されていないが、スタートタグやエンドタグの型の マークアップはトケニゼイションの中では何も記されていない。 宣言されていない特性は同じように扱われる。知られていない特性（その 価値など）の全体的な詳細な特性は無視されるべきである。 Berners-Lee & Connolly Standards Track [Page 19] RFC 1866 Hypertext Markup Language - 2.0 November 1995 他方、宣言の ないエンティティーの参照はデータ記号として扱われる。 例：

foo

...

=>

,"foo",

,

,"..." xxx

yyy => "xxx ",

," yyy Let α & β be finish sets. => "Let α & β be finish sets." ある種のエラーをユーザーに知らせるサポートも充実している。 情報提供者は以下の協定では縛られていないことが警告されている。: 明確ではない行為はマークアップがこの仕様書に一致しないというような 結果を起こす。 4.2.2. conventional Representation of Newlines （ニューラインの形式表現） SGMLは、テキストエンティティーはレコードのシークエンスで、それぞれは レコードのスタート記号で始まり、エンド記号で終ることを詳細に示している。 （コード位置はそれぞれ10と13である。）（[SGML]の"Record Boundaries"の セクション7.6.1） [MIME]は'text/*'型の実体はラインのシークエンスであり、それぞれはCRLF で終り、それはオクテットの13と10である。 実行において、HTML文書は、文書の源の規定に依存している規定線の終りを 使うことによって表現したり、伝えたりする。しばしばその表現はCRだけ、 LFだけ、もしくはCRLFシークエンスを構成する。この理由でオクテットの 暗号を解くかぎは、しばしば誤ったスタート、エンド記号を含んだテキスト エンティティーの中にある。 あいまいさがないことが、HTMLユーザーエージェントがレコードのスタート エンド記号の間違いを推測することを助長している。 HTMLユーザーエージェントはフォーマットされる前のテキストを除いて すべてのテキストに空文字としていろいろなものを最終ラインで扱うべき である。フォーマットされる前のテキストにおいては、HTMLユーザーエー ジェントは、新しい行の始まりとしてエンドオブラインの３つの一般的な 表現をいくつか扱うべきである。 5. Document Structure （文書の構成） HTML文書はheadやbody、headings、paragraphs、listなどを含む要素の系で ある。要素の型は"Forms"8で議論されている。 Berners-Lee & Connolly Standards Track [Page 20] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.1. Document Element(文書の要素): HTML HTML文書の要素は、head(項目)と,body(主文)から成り立っている。また、memoや、 mail massageと、良く似ている。head(項目は)、title(表題)と、任意の要素を、 含んでいる。body(主文)は、段落、表、そして、その他の要素により構成される text(本文)のながれである。 5.2. Head(項目): HEAD HTML文書の head(項目)は、文書についての情報の順序は関係ない情報の集まりです 。 例えば: Introduction to HTML ... 5.2.1. Title(表題): TITLE すべての HTML文書は、の要素を含まなければならない。 title(表題)は,全体の文脈のなかで、文書の目次と同じである。"Introduction " のような短い title(表題)は、たぶん文脈からは、無意味なものでしょう。 "Introduction to HTML Elements" のような title(表題)が、より適当である。 注: title(表題)の長さは、制限されていないが、長い title(表題)は、いくつ かのアプリケーション(Webブラウザなど)では、切り捨て(truncated)られるかも しれない。この可能性を、低くするために、title(表題)は、64文字より少ない べきである。 ユーザーエージェントは、(アクセスの)記録リストや文書を表示する窓のラベ ルに文書のタイトルを表示してよい。これは、典型的に、body(主文)のtext(本文) の流れの中の (5.4, "Headings: H1 ... H6") の項目とは、異なる。 5.2.2. Base Address(基底のアドレス): BASE 文書が、文脈から読みとられる場合の、<BASE>の要素は、相関的な(複数の) URLS を解決するために、ベースアドレスを与える(参照 7, "Hyperlinks")。HREFの特質 の課値は、絶対的な URI にちがいない。 5.2.3. Keyword Index(キーワードの索引): ISINDEX <ISINDEX>の要素は、ユーザーの agent(動因)が、ユーザーに、キーワードを与え ることによって、索引を調べることができることを示す。7.5 をみると、"Queries and Indexes" に、詳細が示されている。 Berners-Lee & Connolly Standards Track [Page 21] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.2.4. Link(リンク): LINK <LINK>の要素は、ハイパーリンクを意味する。(参照 7, "Hyperlinks")どんなに たくさんの LINK の要素でも、HTML文書の HEADの要素で、生じるでしょう。それ は、<A> の要素と同じ特質を持っている。(参照 5.7.3, "Anchor: A") <LINK>の要素は、普通は著書、関連する索引や語彙、古いまたは新しいバージョ ン、文書の階層、style sheetsのような関係するリソースを表すのに使用する。 5.2.5. Associated Meta-information (付随するメタ情報): META <META>の要素は、専門化された文書 meta-information を確認するときに利用 するために、拡張することができる容器である。meta-information には、2つの 主な機能がある。 * セットされたデータが存在することと、どのように、そのデータを手に 入れる、又は、アクセスすることができる方法を見つけるために、手段を 与えること、そして、 * その利用適性表示を含め、内容、質、データセットを記述する文書を、添 付すること。 それぞれの <META>の要素は、1組の名前、有用性を、専門化している。もし多くの META の要素が、同じ名前で与えられるとしたら、くっつけられた内容--コンマで わけられたリストのようにくっつける--は、名前と関係する値である。 注: <META>の要素は、<TITLE>のように、特殊な要素がより適切であるところ では、使われるべきではない。CONTENTの特質の価値としての、URIを有する <META>の要素よりは、<LINK>の要素を使う。 HTTPサーバーは、HTTP-EQUIVの特質のための価値を、定義している。どんな要素 にも相応する header の領域を発生させるために、<HEAD>の文書を読んでも良い。 注: サーバーが、meta-information の文書を引き出すための方法は、専門化 されてなく、また、必須でもない。<META>の要素は、meta-information文書を 、 確認し、深く記憶の留めるための拡張することができる組織のみを、供給する 。 つまり、どうやって使われるかは、個人のサーバーの遂行と、HTMLユーザーの agent(動因)しだいである。 Berners-Lee & Connolly Standards Track [Page 22] RFC 1866 Hypertext Markup Language - 2.0 November 1995 Attributes of the META element(META要素の属性): HTTP-EQUIV これは、HTTP ヘッダフィールドに加える。HTTPサーバーは、文書を処理 するために、その情報を使うかもしれない。特に、この文書に対する要求 への応答の中のヘッダフィールドを含むかもしれない。つまり、ヘッダの 名前は、HTTP-EQUIV の属性値から、ヘッダの値はCONTENT属性の値から取 り出される。HTTPヘッダの名前には、大文字小文字の区別がない。 NAME これは、名前/価値の組の名前を決めている。もし存在しなければ、HTTP -EQUIVによって名前が与えられる。 CONTENT これは、名前/価値の組の値をあらわしている。 例 もし、文書が下記のものを含むのなら <META HTTP-EQUIV="Expires" CONTENT="Tue, 04 Dec 1993 21:29:02 GMT"> <meta http-equiv="Keywords" CONTENT="Fred"> <META HTTP-EQUIV="Reply-to" content="fielding@ics.uci.edu (Roy Fielding)"> <Meta Http-equiv="Keywords" CONTENT="Barney"> サーバーは、次のような header の領域を含むでしょう。 Expires: Tue, 04 Dec 1993 21:29:02 GMT Keywords: Fred, Barney Reply-to: fielding@ics.uci.edu (Roy Fielding) HTTP の一部として、`GET' か `HEAD' の応答は、その文書要求する。 HTTPサーバーは、HTTP-EQUIV の特性が存在しないとき、HTTPの応答の header を形成するために <META> の要素を使ってはいけない。 HTTPサーバーは、HTTPサーバーによって管理されている情報を明記している <META> の要素、例えば、`Server' `Date' そして `Last-modified' を、 無視してもよい。 Berners-Lee & Connolly Standards Track [Page 23] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.2.6. Next Id: NEXTID <NEXTID>の要素は、歴史的な理由のためだけに、含まれる。HTML文書は、<NEXTID> の要素を含むべきではない。 <NEXTID>の要素は、HTML文書を編集するとき、新しい <A> の要素に使用する 名前のためのヒントを与える。それは、<A> 要素について、すべての NAME の 属性値から異なっているべきである。例えば <NEXTID N=Z27> 5.3. Body(主文): BODY <BODY>の要素は、headings(表題), paragraphs(段落), lists(表),などを含んだ 文書の、本文の流れを含む。 例えば、 <BODY> <h1>Important Stuff</h1> <p>Explanation about important stuff... </BODY> 5.4. Headings(表題): H1 ... H6 6つの heading の要素 <H1> から <H6> は、節の headings の名前である。 headings の指示や発生は、HTML DTD によって強制されないけれど、そのような 文書を他の表現に変えることは、しばしば問題になるように、文書は、段階 (例えば、 H1 から H3 )を飛ばすべきではない。 使用例: <H1>This is a heading</H1> Here is some text <H2>Second level heading</H2> Here is some more text. 典型的な表現は、 H1 線が太く、とても大きい活字で、中心に位置する。1行か2行、上か下 に、空いている。 H2 線が太く、大きい活字で、左によっている。1行か2行、上か下に、 空いている。 Berners-Lee & Connolly Standards Track [Page 24] RFC 1866 Hypertext Markup Language - 2.0 November 1995 H3 イタリック体で、大きい活字で、左縁から、少しギザギザに 書かれている。 H4 線が太く、普通の大きさの活字で、H3 よりギザギザに書かれている。 1行か2行、上か下に、空いている。 H5 イタリック体で、普通の大きさの活字で、H4 のようにギザギザに 書かれている。1行上に、空いている。 H6 線が太く、ギザギザに書かれているが、H5 よりも、普通の本文と 同じぐらいである。1行上に、空いている。 5.5. Block Structuring Elements(ブロック構造の要素） Block structuring elements(ブロック構造の要素)は、paragraphs(段落)、 lists(表)、そして block quotes(固まりの引用句)、を含む。それらは、 heading の要素を含まない。しかし、makeup 語句は含むでしょう。また いくつかの場合、それらは、組み合わせられる。 5.5.1. Paragraph(段落): P <P>の要素は、段落を示します。読むための空欄などの段落の正確な意味は、明確 にされていない。けれど、他の付属物、style sheets などの機能かもしれない。 典型的に、段落は、縦一行か半行の空白によって囲まれている。段落の第一行めは、 よくギザギザに書かれる。 使用例: <H1>This Heading Precedes the Paragraph</H1> <P>This is the text of the first paragraph. <P>This is the text of the second paragraph. Although you do not need to start paragraphs on new lines, maintaining this convention facilitates document maintenance.</P> <P>This is the text of a third paragraph.</P> 5.5.2. Preformatted Text(前もって形作られた本文): PRE <PRE>の要素(element)は、、文章の文字細胞ブロックを表現し、等幅 (monospace)フォント用に、書式化されている文章に適する。 <PRE>タグはオプションのWIDTH属性とともに用いて良い。 WIDTH属性は一行の最大文字数を、明確にしている。 Berners-Lee & Connolly Standards Track [Page 25] RFC 1866 Hypertext Markup Language - 2.0 November 1995 プレフォーマテッドテキストの中で ＊ テキストの中でラインブレイクは次の行の始まりへの移動として訳 される。 注 - ”新しい行の始まりへ”の参照は、翻訳するものがプレフォ ーマテッドテキストの翻訳として常に左の字下げの使用を禁止する ことを必要としない。左の字下げは幅を必要とするまで強制される かもしれない。 ＊ アンカー要素と句のマークアップは使われるかもしれない。 注 ー <PRE>の内容の処理上での強制はHTMLのユーザエージェントが 句のマークアップを正確に訳すための能力を制限したり、妨害した りする。 ＊ 段落の書式を定義すると言う要素は（headingsやaddressなどだが） 使われてはいけない。 注 ー いくつかの歴史的な文書は<PRE>要素の中に<P>タグを含む ユーザエージェントは改行としてこれを取り扱うことを奨励する。 <P>タグの後に続く新しい行の文字は改行を一回行なうだけであっ て、改行に空行を一つ加えるのではない。 ＊ 水平タブ文字はそこまでの行の文字数が８の倍数となる、もっとも 小さい正の整数の個数のスペースと解釈されなければならない。文書は 矛盾なく支持されないので、タブ文字を含むべきでない。 使用例： <PRE> Line 1. Line 2 is to the right of line 1. <a href="abc">abc</a> Line 3 aligns with line 2. <a href="def">def</a> </PRE> Berners-Lee & Connolly Standards Track [Page 26] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.5.2.1. 例と表にすること: XMP, LISTING <xmp>と<LISTING>要素は<PRE>要素に似ている。しかし、それらの要素に は異なる構文法がある。それらの内容はCDATAとして宣言される。end-tag open,delimiter-in-context（[SGML]の9.6"Delimiter Recognition"を見 よ)以外のマークアップは認識されない。 注 ー HTML説明書の前の下書きでは、<XMP>と<LISTING>要素の構文法 は、タグネームがそれぞれ<XMP>や<LISTING>でない限りクロージング タグをデータ文字として扱うことを許した。 CDATA宣言された内容は、処理技術においてかなりの不首尾な相互作用があ ったり、無節操に使われたり実行されたりするから、HTML文書は<XMP>も <LISTING>要素も含むべきでない。ーー<PRE>タグはより表現力に富みより 矛盾がない支えとなっている。 <LISTING>要素は少なくとも１行に１３２文字を適合させるために翻訳さ れるべきである。<XMP>要素は少なくとも１行に８０文字を適合させるた めに翻訳されるべきであるが、その他の点では<LISTING>要素と同じであ る。 注 ー 前の下書きでは、HTMLはクロージングタグがないことを除い て<LISTILG>要素と似ている<PLAINTEXT>要素を含んでいた。<PLAINTE XT>start-tagの後のすべての文字はデータである。 5.5.3. Address: ADDRESS <ADDRESS>要素は住所、署名、原作者をしばしば文書の本文の最初と最後 に情報として含む。 一般的に、<ADRRESS>要素はイタリック体で翻訳され、字下げして書く。 使用例： <ADDRESS> Newsletter editor<BR> J.R. Brown<BR> JimquickPost News, Jimquick, CT 01234<BR> Tel (123) 456 7890 </ADDRESS> Berners-Lee & Connolly Standards Track [Page 27] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.5.4. ブロック引用： BLOCKQUOTE <BLOCKQUOTE>要素は他の情報源から引用されたテキストを含む。 一般的な翻訳には右と左にわずかな余白があるかもしれない、イタリッ クフォントで。<BLOCKQUOTE>は一般的に引用の上下に空白を備える。 Single-fontの翻訳はより大きいという（＞）のような縦の行の絵文字を 左の余白に押し込むことによって、インターネットのメイル引用スタイル に似るかもしれない。 使用例： I think the play ends ＜BLOCKQUOTE＞ <P>Soft you now, the fair Ophelia. Nymph, in thy orisons, be all my sins remembered. </BLOCKQUOTE> but I am not sure. 5.6. 表の要素 HTMLはかなりの表の要素を含む。それらは連結で使われるかもしれない； 例えば、<OL>は<UL>の<LI>要素に入れ子にされるかもしれない。 COMPACT属性は簡単な翻訳に使われることを暗示する。 5.6.1. 順序のない箇条書：UL,LI <UL>は項目の箇条書を表す。ーー一般的に黒丸として翻訳した。 <UL>要素の内容は一連の<LI>要素である。 例： <UL> <LI>First list item <LI>Second list item <P>second paragraph of second item <LI>Third list item </UL> 5.6.2. 順序のある箇条書：OL <OL>要素は続いているものや重要な順によって並べられた順序のある項 目の箇条書を表す。一般的に番号付けられた箇条書として翻訳された。 Berners-Lee & Connolly Standards Track [Page 28] RFC 1866 Hypertext Markup Language - 2.0 November 1995 <OL>要素の内容は一連の<LI>要素である。例： <OL> <LI>URIウィンドウをオープンするためにウェブのボタンをクリックしな さい。 <LI>オープンURIウィンドウのテキストフィールドの中にURIのナンバーを いれなさい。あなたの指定したウェブの文書が表示される。 <ol> <li>substep 1 <li>substep 2 </ol> <LI>あるリンクから他のリンクへ移動するためにハイライトされたテキ ストをクリックしなさい。 </OL> 5.6.3. ディレクトリー表：DIR <DIR>要素は<UL>要素に似ている。それは一般的にそれぞれ２０文字まで の短い項目の表を表す。ディレクトリー表の中の項目は一般的に２４文字 幅のコラムの中からまとめられる。 <DIR>要素の内容は一連の<LI>要素である。入れ子の要素は<DIR>要素の 内容の中で許されない。例： <DIR> <LI>A-H<LI>I-M <LI>M-R<LI>S-Z </DIR> 5.6.4. メニュー表： MENU <MENU>要素は一般的に項目ごとに１行をもっている項目表である。メニュ ー表のスタイルは一般的に順序のない箇条書のスタイルよりも簡潔である。 <MENU>要素の内容は一連の<LI>要素である。入れ子の要素は<MENU>要素の 内容の中で許されない。例： <MENU> <LI>First item in the list. <LI>Second item in the list. <LI>Third item in the list. </MENU> Berners-Lee & Connolly Standards Track [Page 29] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.6.5. 定義表：DL,DT,DD 定義表は用語とその用語の定義の表である。定義表は、一般的に用語の 左寄せと段落のスタイルの書式、用語の後の字下げなどの定義によって 書式化される。 <DL>要素の内容は一連の<DT>要素と<DD>要素（通常はペアで）である。 複雑な<DT>は個個の<DD>要素をもってペアにされるかもしれない。文書 は複雑で連続的な<DD>要素を含まないべきである。 使用例： <DL> <DT>Term<DD>This is the definition of the first term. <DT>Term<DD>This is the definition of the second term. </DL> もしDTの用語がDTコラムに適合しないなら（一般的にディスプレイエリ アの３分の１）DDの部門を次の行に移動することでページを拡大するか 行の続きを左手のコラムの上に重ねるかもしれない。 任意のCOMPACT属性は簡単な翻訳に使われるということを暗示する。なぜ なら、その表の項目は小さく（が小さいか）全体の表は（が）大きいから。 もしCOMPACT属性が提示されてないならHTMLのユーザエージェントは連続 したDT、DDペアの間に空白をおくかもしれない。COMPACTの性質はまた、 左手の（DT）コラムの幅を少なくするかもしれない。 <DL COMPACT> <DT>Term<DD>This is the first definition in compact format. <DT>Term<DD>This is the second definition in compact format. </DL> 5.7. 句のマークアップ 句は慣用的な語法や、印刷上の外観、またはハイパーリンクアンカー として使うためにマークアップされる。 ユーザエージェントは無地のテキストからはっきりと強調された句を訳さ なければならない。そのうえに、<EM>の内容は<STRONG>の内容からはっき りと訳されなければならなく、<B>の内容は<I>の内容からはっきりと訳さ なければならない。 句の要素は他の句の要素の内容の中に入れ子にされるかもしれないが、 HTMLのユーザエージェントは入れ子にされた句の要素を入れ子になってい ない句の要素と区別なく翻訳するかもしれない。 Berners-Lee & Connolly Standards Track [Page 30] RFC 1866 Hypertext Markup Language - 2.0 November 1995 しかし、HTMLユーザエージェントは入れ子になった段落要素を 入れ子になっていない要素と区別なく翻訳するかもしれない。： plain <B>bold <I>italic</I></B>は、plain <B>bold </B><I>italic</I> と同じように翻訳されることがある。 5.7.1. 慣用的な要素 成句は確かな慣用句を示すために記号をつけられることがある。 注 − ユーザエージェントはある程度使われてきたので、この詳述 に含まれていない<DFN> 要素を支持するかもしれない。それは、定義 される用語の例を示すのに使われており、一般的にイタリック体また は太字のイタリック体で翻訳される。 5.7.1.1. 引用： CITE <CITE>要素は本のタイトルあるいは他の引用文を示すのに使われる。 一般的にイタリック体で翻訳される。例： He just couldn't get enough of <cite>The Grapes of Wrath</cite>. 5.7.1.2. コード： CODE <CODE>要素はプログラムの例を示すのに使われ、一般的に等幅フォン トで翻訳される。<CODE>要素は短い単語やプログラムの成句のための ものである。； ブロック構造の<PRE>要素（5.5.2「あらかじめ整形さ れたテキスト： PRE」）は複合列からなる表を表わすとき、より適し ている。例： The expression <code>x += 1</code> is short for <code>x = x + 1</code>. 5.7.1.3. 強調： EM <EM>要素は、強調された成句を示し、一般的にイタリック体として翻訳 される。例： A singular subject <em>always</em> takes a singular verb. 5.7.1.4. キーボード： KBD <KBD>要素はユーザによりタイプされるテキストを示し、一般的に等幅 フォントで翻訳される。これは普通は、使用説明書に使われる。例： Enter <kbd>FIND IT</kbd> to search the database. Berners-Lee & Connolly Standards Track [Page 31] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.7.1.5. 例： SAMP <SAMP>要素は文字通りの一連の文字の順序を示し、一般的に等幅 フォントで翻訳される。例： The only word containing the letters <samp>mt</samp> is dreamt. 5.7.1.6. 強い強調： STRONG <STRONG>要素は強い強調を示し、一般的に太字で翻訳される。例： <strong>STOP</strong>, or I'll say "<strong>STOP</strong>" again! 5.7.1.7. 変数： VAR <VAR>要素は代入すべき変数を示し、一般的にイタリック体で翻訳 される。例： Type <SAMP>html-check <VAR>file</VAR> | more</SAMP> to check <VAR>file</VAR> for markup errors. 5.7.2. 印刷上の要素 印刷上の要素はマークされたテキストの書式を決めるのに使われる。 慣用的な要素のような一般的な翻訳はユーザエージェントの間で違う かもしれない。もし特定の翻訳が必要ならば、--例えば、“イタリック 体の部分が必須のことである。”といったような特定のテキスト属性を 参照するとき--印刷上の要素が、故意な印刷術ができる限りのところで 使われることを保証するのに使われることがある。 注 −ユーザエージェントは印刷上の要素がある程度使われてきたので、 この詳述に含まれていない印刷上の要素を支持するかもしれない。 <STRIKE>要素は文字の初めから終わりまで、横線を示し、<U> 要素は下 線を示す。 5.7.2.1. 太字： B <B> 要素は太字テキストを示す。太字の印刷術が利用できない場合に、い ずれか一方の表現が使われることがある。 5.7.2.2. イタリック体： I <I>要素はイタリック体のテキストを示す。イタリック体の印刷術が利用で きない場合に、いずれか一方の表現が使われることがある。 Berners-Lee & Connolly Standards Track [Page 32] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.7.2.3. テレタイプ： TT <TT> 要素はテレタイプ（等幅）テキストを示す。 テレタイプフォントの 印刷術が利用できない場合に、いずれか一方の表現が使われることがある。 5.7.3. アンカー： A <A>要素はハイパーリンクアンカー（７「ハイパーリンク」参照）を示す。 少なくともNAME属性とHREF属性の１つが存在するべきである。 <A>要素の属性： HREF ハイパーリンクのヘッドアンカーのURIを与える。 NAME アンカーの名前を与え、それをハイパーリンクの先頭として利用で きるようにする。 TITLE 目的地リソースのタイトルを提案する。--勧告にすぎない。 TITLE属性は次のように使われる場合がある。 *目的地リソースをアクセスする前のディスプレイのために使 われる。例えばマウスがアンカーの上にある間、また文書が つめこまれている間、余白のメモとしてや小さな箱の上にお いて使われる。 *タイトルを含まないリソースのために、例えばグラフィック やプレーンテキストやGopherメニュー、ウインドウタイトル としての使用のために使われる。 REL REL属性はハイパーリンクによって述べられた関係を与える。 その値は空白でわけられた関係名のリストである。 リンク関係の意味論はこの文書で決められていない。 REV REL属性と同様であるが関係の意味論が逆の方向にある。 REL="X"で示すAからBへのリンクは，REV="X"で示す BからAへのリンクと同じ関係で表現される。 アンカーはRELとREVの両方の属性を持つことがある。 URN ハイパーリンクのヘッドアンカーにとって優位の、より持続する 識別子を指定する。 URN属性の構文法と意味論はまだ決められて いない。 Berners-Lee & Connolly Standards Track [Page 33] RFC 1866 Hypertext Markup Language - 2.0 November 1995 METHOD 空白で分けられた名前のリストとして目的地をアクセスすること に使われるための方法を指定する。一組の有効な名前は、 HREF 属性における URIの仕組みの関数である。 TITLE属性にとって同 様な理由でリンクにおいて、前もってその情報を含むことは有用 な場合がある。例えば、HTMLユーザエージェントが許された方法 の関数として異なった表現を選ぶことがある。；例えば、検索可 能なものが異なったアイコンを得ることがある。 5.8. 改行： BR <BR>要素は、単語の間で改行を指定する。（６「文字、単語、段落」を参 照）例： <P> Pease porridge hot<BR> Pease porridge cold<BR> Pease porridge in the pot<BR> Nine days old. 5.9. 横線： HR <HR>要素は、テキストのセクションとセクションとの間を分割するものであ る。；一般的に幅いっぱいの横線あるいは同等のグラフィックなもの。例： <HR> <ADDRESS>February 8, 1995, CERN</ADDRESS> </BODY> 5.10. イメージ： IMG <IMG>要素はイメージあるいはハイパーリンクを通じたアイコンを参照する （7.3「イメージリソースの同時に起きる提示」参照）。 HTMLユーザエージェントは、SRC属性によって示されたイメージリソ ースを処理する代わりの手段としてATL属性の値を処理することがある。 注− いくつかのHTMLユーザエージェントはアンカーを通じてつなげら れたグラフィックを処理することはできるが、<IMG> グラフィックは処 理できない。もしあるグラフィックが欠くことのできないものならば、 <IMG>要素よりもやや <A>要素から参照されるべきである。もしそのグ ラフィックが必要でないならばそれなら<IMG>要素が適している。 要素の属性： Berners-Lee & Connolly Standards Track [Page 34] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ALIGN テキストの基準線への関係を持つイメージの整列 *`TOP'はイメージの最上部がそのイメージを含んでいるラ イン上の最も高い項目に提携することを指定する。 * `MIDDLE'はイメージの中央部がイメージを含むラインの 基準線と提携することを指定する。 * `BOTTOM'はイメージの最下部がイメージを含むラインの 基準線と提携することを指定する。 ALT 参照されたイメージリソースの場所で使うためのテキストで、 例えば、強制あるいはユーザの好みで処理させる。 ISMAP イメージマップ（7.6「イメージマップ」参照） SRC イメージリソースのURIを指定する。 注−実際には、イメージリソースのメディアタイプは少数 のラスタグラフィック書式に限られている。：一般的に `image/gif', `image/jpeg'である。特に`text/html'リソ ースは、イメージリソースとして使われる傾向はない。 使用例： <IMG SRC="triangle.xbm" ALT="Warning:"> Be sure to read these instructions. <a href="http://machine/htbin/imagemap/sample"> <IMG SRC="sample.xbm" ISMAP> </a> 6. 文字、単語、段落 HTMLユーザエージェントは、活字に組まれた段落とあらかじめ整形されたテキ ストの収集として、HTML文書の本文を表現すべきである。あらかじめ整形され た要素 ( <PRE>, <XMP>, <LISTING>, <TEXTAREA> )を除いて、それぞれのブロ ック構造の要素はその内容やその子孫の要素の内容においてデータ文字を置く ことによって段落として表わされ、それらを鎖状につなぎ、その結果を単語で わけていき、空白やタブで区切る、あるいは終了文字（とおそらくハイフン文 字）を表示する。 Berners-Lee & Connolly Standards Track [Page 35] RFC 1866 Hypertext Markup Language - 2.0 November 1995 6.1. HTMLドキュメント文字セット ドキュメント文字セットは9.5のなかに指定されている。"HTMLのためのSGML宣言" はHTMLのユーザーエージェントによってサポートされなければならない。それは ラテンアルファベット<No.1>や単に<Latin-1>というものを含んでいる。 <Latin-1>はほとんどのwesternアルファベットをいれて191個のグラフィックキャ ラクターがある。 注ー切れ目のないスペースやソフトハイフン指示文字を使用することは良くない。 なぜなら、それらのサポートは広く使用されていないからである。 注ーwesternではないドキュメントをサポートするためには、より多くの文字数が 将来のHTMLに指定されるだろう。ドキュメント文字セットは(ISO-10646),ある いは(ISO-10646)に合うサブセットになるだろう。特に全ての数字は(ISO-10646) によって割り当てられたコードを使用しなければならない。 SGMLのアプリケーションでは、制御文字の使用は限られている。というのは異種の ネットワークを越えてやオペレーティングシステムの交換を成功させる可能性を最 大限にするためにである。 HTMLキャラクター文字セットのなかではたった３個の制御文字が許されている。 その３個は、Horizonal Tab, Carriage return, Line Feed(コード9,13,10)である。 HTML DTDはadded Latin-1というもののセットを参照している。広く支援されている ASCIIキャラクターレパートリーを使うことで、Latin-1キャラクターの選ばれた記 憶を助ける。例えば、Kurt G & ouml;delは有名な論理学者であり数学学者である。 9.7.2.を見て下さい。(Added Latin1)の一覧表の(ISOLatin 1 Character Entry Set) は存在する。(ISO 8859-11)のコードの一覧表の(The HTML Corded Character Set) と、HTMLドキュメント文字セットの制御文字。 7. ハイパーリンク HTMLドキュメントは、パラグラフやリストのような一般的な目的要素に加えてハイパ ーリンクを使える。ユーザーはHTMLのユーザーエージェント上ではこれらのハイパー リンクを操縦できる。 Berners-Lee & Connolly Standards Track [Page 36] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ハイパーリンクというのはヘッドとテールと呼ばれるハイパーリンク(DEXTER)の２ つのアンカーに書かれたものの関係のことである。アンカーはアンカーアドレスと 同意義とみなされる。そのアドレスは見完成の識別しと呼ばれる文字の連続と”＃” によって続く完全な同一手段絶対URIである。 例えば、http://www. w3. org/hypertext/www/TheProject. html http://www. w3. org/hypertext/www/TheProject. html#z31 １つのアンカーアドレスについてはURIは１つのリソースを参照する。それはリソー スを表しているじっさいにあるものを得るために情報をとりにいくプロトコルのそ れぞれのものの中で使われる。見完成の識別しは表すならば、見方リソースの一部 を参照する。次に表すマークアップコントラクトの各々はハイパーリンクのテール アンカーやハイパーリンクのセットを表している。 HREF表現の<A>エレメント <LINK>エレメント <IMG>エレメント SRC属性表現の <INPUT>エレメント <ISINDEX>エレメント "METHD=GET"の<FORM>エレメント これらのマークアップコントラクトはURIによってヘッドアンカーを参照する。 絶対URIか相対か見完成の識別し、または両方によるヘッドアンカーのことである。 相対URIの場合、ヘッドアンカーのアドレスのなかの絶対URIは相対URIと<RELURL>の なかでとして基本的な絶対URIを統合する結果になる。ベーシックドキュメントは、 ドキュメントの<BASE>エレメントからできている。表すならばその他に<RELURL>の 中でとして決定される。 7.1. リソースのアクセス ヘッドアンカーのアドレスはかつて決まっているユーザーはリソースの表現をえる ことができる。 例えば、基本的なURIが'http://host/x/y. html'であり、ドキュメントが含んでい れば<IMG src="../icons/abc. gif">になる。 そうすればユーザーはリソースにアクセスするために、 URI'http://host/icons/abc.gif'を使う。 Berners-Lee & Connolly Standards Track [Page 37] RFC 1866 Hypertext Markup Language - 2.0 November 1995 7.2. ハイパーリンクの活性化 HTMLユーザーはドキュメントの内容を導くために、ユーザーエージェントに<A>エレ メントにより示されたハイパーリンクの活性化を｀要求できる。HTMLのユーザー エージェントはまた<LINK>エレメントのハイパーリンクを許すべきである。 リンクを活性化するためにはヘッドアンカーのアドレスに示されたリソースの表現 を得る。その表現が他のHTMLドキュメントであるならば、導くことは再びこの新し いドキュメントとともに始まることが出来る。 7.3. イメージリソースの同時提示 HTMLユーザーエージェントはドキュメントを処理中<IMG><INPUT>によって示された 場合ハイパーリンクを活性化できる。それは、イメージのハイパーリンクはユーザ ーによる明白な要求なしで処理され得る。イメージのリソースはテールアンカーの 場所の所に表示される。それは<IMG><INPUT>である。 <LINK>ハイパーリンクもまた明白なユーザーの要求なしで処理することができる。 例えば、スタイルシートリソースはドキュメントの処理前か処理中に処理される。 7.4. 未完の部分の識別し ハイパーテキストアドレスの”＃”の後のどんな文字も未完の部分の識別しを構成 する。特に'# fragment'を作るアドレスは同じドキュメントのことをいっている。 未完の部分の識別しの意味はアンカーが示すリソースの表現のメディアタイプに依 存する。'text/HTML'表現においては、未完成の識別しと同じ値のNAMEという属性 の<A>といっています。マッチングは敏感なばあいである。ドキュメントには正確 にそのような要素の１つがある。 例えば、基本URIが'http://host/x/y.html'であり、ユーザーが次のマークアップ により示されたリンクを活性化すれば、 ユーザーエージェントは 'http://host/x/app1.html'により、確認されるリソースにアクセスする。 <P> See: <a href="app1.html#bananas">appendix 1</a> for more detail on bananas. リソースが、'text/html'メディアタイプを使うことを表現されるとすれば、ユーザ ーエージェントはNAMEの属性が「banana」という<A>エレメントを書かなければなら ない。そしてそこで導き始める。 Berners-Lee & Connolly Standards Track [Page 38] RFC 1866 Hypertext Markup Language - 2.0 November 1995 7.5 .質問と索引 <ISINDEX>はハイパーリンクスの集合を表す． 　そのユーザーは，ユーザーへのキーワードを与えることによって集合からえらぶこと ができる． 　そのユーザーは’？’とベースURIへのキーワードを付け加えることによってヘッド URIを処理する． 　キーワードは[URI]に従ってエスケープされ，’＋’によって加えられる． 　たとえば文書が含むならば， 　　<BASE HREF="http://host/index"> <ISINDEXOA> そしてユーザーは'apple'と'berry'というキーワードを与えるならばユーザーは 'http://host/index?apple+berry'というリソースにアクセスしなければならない． 　'METHOD=GET'を伴っている<ＦＯＲＭ>もハイパーリンクの集合を表す． 　8．2．2参照”Query Forms: METHOD=GET" 7．6　　　　　　　　　イメージマップ 　ISMAPが<IMG>の表現上のものであるならば<IMG>はHRFFを伴っている<A>の中に含ま れていなければならない． 　この構造はハイパーリンクスの集合を表している． 　ユーザーはイメージのピクセルを選ぶことによってその集合から選ぶことができる． 　ユーザーエージェントは’？’と<Ａ>という要素の中で与えられるURIへのピクセル のｘとｙ座標を加えることによってヘッドURIを 　処理する． 　例えば文書が <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2．0//EN"> <head><title>ImageMap Example</head> <body> <p>これらのどれかアイコンを選びなさい：<BR> <a href="/cgi-bin/imagemap"><IMG ISMAP src="icons．gif"></a> を含み，ユーザーが左上のピクセルを選ぶならばURI 'http://host/cgi-bin/imagemap?0，0'を伴う1つである． Berners-Lee & Connolly Standards Track [Page 39] RFC 1866 Hypertext Markup Language - 2.0 November 1995 8. Form 形はフォームデータ集合と，関連されるmethod URIとaction URIの形である． 　フォームデータの集合は，名前と値の一対の組み合わせの連続である． 　その名前は，フォームインプットエレメントというNAMEの属性に特徴づけら れる． 　そしてその値はマークアップといういろいろなフォームによってイニシャル バリューが与えられ，ユーザーによって編集される． 　結果として得られた形のデータの集合はアクションとメソッドの関数として 情報サービスにアクセスするために使われる． 　フォームエレメントは要素を構造する文書に混合されることができる． 　例えば<PRE>エレメントは<FORM>エレメントを含みあるいは<FORM>エレメントは <INPUT>エレメントを含むリストを含むことができる． 　このことは形の輪郭をデザインするのにかなりのしなやかさを与えている． 　フォームプロセッシングはレベル2の要点である． 8.1. フォームの要素 　8．1．1　　　　　　Form:FORM 　　　 　<FORM>エレメントはインプットエレメントの列を含む，それは要素を構造する文 書とともに沿って．．． 　その属性は， 　　　　ACTION:形を作るためのアクションURIを特徴づける． 　　　　　　　形のアクションURIは文書のベースURIを怠る． 　　　　　　　　（7，ハイパーリンクス参照） 　　　　METHOD:アクションURIにアクセスする手段を選ぶ． 　　　　　　　　応用的な手段の集合は形のアクションURIのスキームの関数である． 　　　　　　　　　8．2．2"Query Forms:METHOD=GET"と， 　　　　　　　　　8．2．3"Form with Side-Effects:METHOD=POST"参照． 　　　　ENCTYPE:規約はそれ自身初期化を義務づけない場合，送るために名前と 　　　　　　　　値の組を符号化するのに使われる媒体型を特徴づける． 　　　　　　　　　8．2．1"The form-urlencorded Media Type"参照． 　 　8．1．2　　　　　　　INPUT Field:INPUT 　<INPUT>エレメントはユーザー入力のための領域を表す． 　TYPEの属性はいくつかの領域のバリエーションの間を区別する． Berners-Lee & Connolly Standards Track [Page 40] RFC 1866 Hypertext Markup Language - 2.0 November 1995 <INPUT>要素は多くの属性があります。応用できる属性はすべてTYPE 属性の値に依存しています。 8.1.2.1. Text Field: INPUT TYPE=TEXT TYPEのデフォルト値は'TEXT'で、一行の入力フィールドを示します。 （複数行のフィールドには<TEXTAREA>を使います） 属性： NAME この要素に対応するフィールドの名前 オプションの属性： MAXLENGTH 入力フィールドに入力できる文字の数を制限します。もしMAXLENGTH の値がSIZE属性の値以上ならば、フィールドは適切にスクロールしま す。デフォルトの文字の数には制限がありません。 SIZE その型に応じてこの入力フィールドを割り当てられたディスプレイの 総数を設定します。デフォルトは利用者に依存しています。 VALUE フィールドの最初の値 例： <p>Street Address: <input name=street><br> Postal City code: <input name=city size=16 maxlength=16><br> Zip Code: <input name=zip size=10 maxlength=10 value="99999-9999"><br> 8.1.2.2. Password Field: INPUT TYPE=PASSWORD <INPUT>の要素の'YTPE=PASSWORD'は、値が隠れていること以外は、前述 のようなテキストフィールドです。 （参照 ： 10,"Security Considerations"） 例： <p>Name: <input name=login> Password: <input type=password name=passwd Berners-Lee & Connolly Standards Track [Page 41] RFC 1866 Hypertext Markup Language - 2.0 November 1995 8.1.2.3. Check Box: INPUT TYPE=CHECKBOX <INPUT>の要素である`TYPE=CHECKBOX'は論理型の選択を設定します。 同じ名前の一組の要素は、多数からnを選択するフィールドを表現します。 属性： NAME この要素か要素のグループに対応するフォームフィールドのシンボリック名 VALUE この要素によって決まるフィールドの値の部分 オプションの属性： CHECKED 初めから選択された状態であることを示します。 例： <p>What flavors do you like? <input type=checkbox name=flavor value=vanilla>Vanilla<br> <input type=checkbox name=flavor value=strawberry>Strawberry<br> <input type=checkbox name=flavor value=chocolate checked Chocolate<br> 8.1.2.4. Radio Button: INPUT TYPE=RADIO <INPUT>の要素である`TYPE=RADIO'は論理型の選択を設定します。同じ名 前の一組の要素は 、多数から1つを選択するフィールドを表現しますNAME とVALUEの属性はCHECKBOX間と同じように命令します。 オプションの属性： CHECKED 初めから選択された状態であることを示します。 常にひとつだけのボタンがチェックされます。 もしRADIOボタンの<INPUT>の要素に`CHECKED'を明示していなかったら、 利用者は、最初のRADIOボタンをチェックしなければいけません。 例： <p>Which is your favorite? <input type=radio name=flavor value=vanilla>Vanilla<br> <input type=radio name=flavor value=strawberry>Strawberry<br> <input type=radio name=flavor value=chocolate>Chocolate<br> Berners-Lee & Connolly Standards Track [Page 42] RFC 1866 Hypertext Markup Language - 2.0 November 1995 8.1.2.5. Image Pixel: INPUT TYPE=IMAGE `TYPE=IMAGE'の<INPUT>要素は、表示するイメージの元を決め、二つのフォ ームフィールドへの入力を許します。それは、そのイメージから選ぶピクセ ル(画素)のxとyの座標。フィールドの名前には、`.x'と`.y'が付け加えられ る。 `TYPE=IMAGE'には`TYPE=SUBMIT'の役割も含まれています。すなわち、ピクセ ルが選択される時、全体としてフォームは送られます。 NAMEの属性は他の入力フィールドと同様に命令します。<IMG>の要素(参照 5. 10,"Image: IMG")について述べると、SRCは必要で、ALIGNはオプションです。 例： <p>Choose a point on the map: <input type=image name=point src="map.gif"> 8.1.2.6. Hidden Field: INPUT TYPE=HIDDEN <INPUT>の要素である`TYPE=HIDDEN'では、隠れているフィールドを設定します。 useにはこのフィールドは表示されません。代わりにVALUEはフィールドの値を 明示します。NAMEとVALUEは、フィールドの値を明示します。NAMEとVALUEは必 要です。 例： <input type=hidden name=context value="l2k3j4l2k3j4l2k3j4lk23"> 8.1.2.7. Submit Button: INPUT TYPE=SUBMIT <INPUT>の要素である`TYPE=SUBMIT'は入力ボタンを設定する典型的なボタンで、 フォームを送るために利用者は命令します。 オプションの特性： NAME この要素は値がVALUEの属性によって与えられるフィールドを与えます。 もしNAMEの属性がなければ、この要素はフィールドでは役に立ちません。 VALUE 入力（ボタン）に表示されるラベルを示します。 内部にこの要求を送る。 <input type=submit name=recipient value=internal><br> あるいは外部の世界へ。 <input type=submit name=recipient value=world> Berners-Lee & Connolly Standards Track [Page 43] RFC 1866 Hypertext Markup Language - 2.0 November 1995 8.1.2.8. Reset Button: INPUT TYPE=RESET <INPUT>の要素である`TYPE=RESET'は入力ボタンを表現するボタンで 最初の状態にフィールドをリセットするために利用者に命令します。 VALUEの属性がもしあるならば入力（ボタン）にラベルを表示します。 入力を終えたとき、この要求を送ります。 <input type=submit><br> フォームをきれいにして、いつでも繰り返して始められます。 <input type=reset> 8.1.3. Selection: SELECT <SELECT>要素は、フォームフィールドを列挙リストの範囲に限定する。 値は<OPTION>で与えられます。 特性： MULTIPLE 値の中に、１以上のオプションが含まれていることを示します。 NAME フィールドの名前を明示します。 SIZE 目に見える項目数を設定します。１つ以上のリストの選択に対して、 典型的なプルダウン形式のメニューで選択をします。 例： <SELECT NAME="flavor"> <OPTION>Vanilla <OPTION>Strawberry <OPTION value="RumRasin">Rum and Raisin <OPTION selected>Peach and Orange </SELECT> SELECTED属性が<OPTION>要素のどこにもなければ、最初の状態は、オプ ション要素のはじめに選択されているものになります。 8.1.3.1. Option: OPTION オプションはSelectの中でしか使えません。１つの選択を表現し、次のよう な属性があります。 SELECTED このオプションは、はじめに選択されることを示します。 Berners-Lee & Connolly Standards Track [Page 44] RFC 1866 Hypertext Markup Language - 2.0 November 1995 VALUE このオプションが選択されると、返される値を示します。フィールドの値 はオプション要素の内容に関係ありません。 オプション要素の内容はオプションを設定するために、ユーザーに与えられ ます。もし、VALUEの属性がなければ、返される値を使います。 8.1.4. Text Area: TEXTAREA <TEXTAREA>では、複数行のテキストフィールドを設定します。 特性： COLS 文字でテキストにディスプレイを表示させるための列の数。 NAME フィールドの名前を定義します。 ROWS 文字でテキストにディスプレイを表示させるための行の数。 例： <TEXTAREA NAME="address" ROWS=6 COLS=64> HaL Computer Systems 1315 Dell Avenue Campbell, California 95008 </TEXTAREA> <TEXTAREA>要素の内容は、フィールドの初めの値です。 典型的に行と列は文字で書かれたフィールドの範囲で決定します。フィール ドでは、決められているフォントで（値を）返します。HTMLユーザは、必要 なスクロール分以上にテキストの範囲を設定するべきです。 8.2. Form submission（フォームの送信） HTMLユーザは初めの状態でフィールド上でドキュメントを存在させることで フォームを処理し始めます。ユーザはフィールドの変更ができますし、 フィールドのタイプを抑えることなどもできます。ユーザはフォームが 送られること（submittedボタン、あるいはimage入力を使うこと）を示すとき フォームのデータはその方法、URI、エンコードタイプに従って処理されます。 Berners-Lee & Connolly Standards Track [Page 45] RFC 1866 Hypertext Markup Language - 2.0 November 1995 フォームで、フィールドをインプットした一行のテキストがある時、ユー ザーは、フォームを送信することを要請することとして、そのフィールド をEnterに受け入れる。 8.2.1.The form-urlencoded Media Type すべてのフォームを記号化するデフォルトは'application/x-www-form-ur lencoded'であり、フォームのデータは、次のように、このメディアで表 せれる。 1.フォームフィルドの名前や値は、エスケープされる。：スペース文字は '+'で入れ換わる。そしてリザーブされた文字は、[URL}として、エスケー プされる。１つのパーセント記号や２の１６進法で表せる、文字のASCII コードなどの文字や数字以外のものは、'%HH'によって入れ換える。マルチ ラインのテキストフィールドの値として、ラインをおることはCRやLF、i.e .'%0D%0A'で表される。 2.フィールドは文書の中で、名前は'='によって値と離れて、そのペアは '&'によってお互い離れて、順序良くリストされる。空の値のフィールド は省略される。特に無作為にセレクトされたラジオボタンやチェックボッ クスは、記号化されたデータの中ででないようにする。しかし、VALUEと 隠されたフィールドはあるものとする。 注ー疑問フォームの送信からのURIは、ノーマルアンカースタイルの ハイパーリンクで使える。不運にも、SGMLを使って、互いに影響し あうフォームフィールドを分けるために'&'文字を使う時は、実体 リファレンス区切り文字のような値に属する。例えば、the URI `h ttp://host/?x=1&y=2' must be written `<a href="http://host/?x =1&y=2"'or `<a href="http://host/?x=1&y=2">'. HTTP実行サーバー、そして特にCGI実行はユーザーが’＆’文字を エスケープして衝突を防ぐために、’；’の代わりに’＆’を使い 助長される。 8.2.2. Query Forms: METHOD=GET フォームの過程がアイデムポイント（i.e.全然、永久に観察する効果を もたない。）なら、フォームの方式は'GET'である。たくさんのデータ ベースのサーチは目にみえる副作用をもたないし、疑問フォームの申し 分のない適用をつくる。 Berners-Lee & Connolly Standards Track [Page 46] RFC 1866 Hypertext Markup Language - 2.0 November 1995 URL活動のフォームを処理する仕方はHTTP URLで、方法の処理の仕方は ’GET'であり、ユーザーはURI活動と'&'とフォームデータを追加し、 始めたりすることであり、次のように’application/x-www-form-urlenc oded’とフォーマットする。その時、ユーザーはちょうど、もしanchor だったら、このURIを連結するか検討する。（7.2の”活性化の適度連 結をみる） 注ー記号化されたURLはとても長いURIs、いくつか前のHTTPのサーバー の欠点の行為を説明するための結果になるかもしれない。結果として いくつかのHTMLフォームは、たとえフォームの送信が、結果の面を全 く持たなかったにしても’METHOD＝POST’として使われ、かかれる。 8.2.3 Forms with Side-Effects: METHOD=POST サービスの結果の面を持つ形状の過程と結び付けて考えてみる。（例えば、 基礎ベースやサービスの出資）その方法は’POST’である。 URI活動のフ ォームを処理することはHTTP URLであり、その方法はPOSTであり、そのユ ーザーはURI活動を使うHTTP POST処理に導き、そして’application/x-ww w-form-urlencoded’の型のメッセージボディを、上記のようにフォーマッ トする。ユーザーは、ちょうどHTTP GETのフォームの応答を表示するよう に、HTTP POSTの相互作用のフォームの応答を表示すべきだ。 8.2.4.Example Form Submission: Questionnaire Form Consider the following document: <!DOTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <title> HTMLフォームの送信の見本

アンケート見本

どうかこのアンケートにお答え下さい：

あなたの名前：

男

女

家族番号：

あなたの保持する住所の都市：

あだ名：

このアンケートに応答してくれてありがとう

Berners-Lee & Connolly Standards Track [Page 47] RFC 1866 Hypertext Markup Language - 2.0 November 1995 フォームデータの最初の状態は 名前 "" 性 "男" 家族 "" 他 "" あだ名 "" CHECKBOXになにもない間、ラジオ入力された文書は、最初の値をもつ。 ユーザーは、提案されたフォームと、送信されたフォームのリクエストを 編集する。 名前 "ジョン ドウ" 性 "男" 家族 "５" 都市 "ケント" 都市 "マイアミ" 他 "abc\ndefk" あだ名 "J＆D" その時、ユーザーはURIの'http:/www w3.org/sampleを使う、HTTP CHECKBOX処理を導く。そのMessage bodyを（おられた線を無視す る。）： Berners-Lee & Connolly Standards Track [Page 48] RFC 1866 Hypertext Markup Language - 2.0 November 1995 名前＝ジョン＋ドウ＆性＝男＆家族＝５＆都市＝ケント＆都市＝マイアミ＆ 他＝abc%0D%0Adef＆あだ名=J%26D 9. HTML Public Text 9.1. HTML DTD これはレベル２のHyperText Markupのために、明確に定義した文書で ある。 ... -- > Berners-Lee & Connolly Standards Track [Page 49] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ]]> %ISOlat1; Berners-Lee & Connolly Standards Track [Page 50] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ]]> Heading

はという書き方は

Heading

より望ましい。 --> ]]> " > #AttVal(Alt)" > Berners-Lee & Connolly Standards Track [Page 53] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ]]> Berners-Lee & Connolly Standards Track [Page 54] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ]]> ]]> Directory" > Berners-Lee & Connolly Standards Track [Page 56] RFC 1866 Hypertext Markup Language - 2.0 November 1995 Menu" > Heading

Text ... is preferred to

Heading

Text ... --> ]]> Form:" %SDASUFF; "Form End." > Berners-Lee & Connolly Standards Track [Page 58] RFC 1866 Hypertext Markup Language - 2.0 November 1995 Select #AttVal(Multiple)" > ]]> ]]> " > [Document is indexed/searchable.]"> Berners-Lee & Connolly Standards Track [Page 60] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ]]> 9.2. Strict HTML DTD この文書形式の宣言文は、IGNOREというよりもむしろ本質的にINCLUDEに定義され る HTML.RecomendedのHTML DTDである。 つまりそれは構造上より厳格なHTMLの定義である。 Berners-Lee & Connolly Standards Track [Page 61] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ... -- > %html; 9.3. Level 1 HTML DTD この文書形式の宣言文はINCLUDEというよりはむしろ本質的にIGNOREに定義される HTML.FormsのHTML DTDである。 FORMの要素を含む文書はこのDTDに順応しなければならない。 ... Berners-Lee & Connolly Standards Track [Page 62] RFC 1866 Hypertext Markup Language - 2.0 November 1995 -- > %html; 9.4. Strict Level 1 HTML DTD この文書形式の宣言文はIGNOREというよりはむしろINCLUDEに定義される HTML.Recommendedのlevel 1 HTML DTDである。 つまりそれは構造上より厳格なHTMLの定義である。 ... -- > %html-1; Berners-Lee & Connolly Standards Track [Page 63] RFC 1866 Hypertext Markup Language - 2.0 November 1995 9.5. SGML Declaration for HTML これはHTMLのためのSGMLの宣言文です。 9.6. Sample SGML Open Entity Catalog for HTML SGML基準は実際の保管モデル（例：ファイルシステム）の中のSGMLシステムの 一部分や構成要素として”本質的な支配人”である。 Berners-Lee & Connolly Standards Track [Page 65] RFC 1866 Hypertext Markup Language - 2.0 November 1995 それ自身の基準は特に方法論や表記法では定義されていない。 さまざまなSGMLの手段や方法間の解釈に役立つことは、SGML Openの固まりはファイ ルネームへのエンティティーと外部の判断を構成する独立したアプリケーション のエンティティー一覧のために形づけられ定義した技術的な解決方法をやりとり する。 一覧のそれぞれの項目ではSGML中で示された外的エンティティーについての情報 を伴った（ファイルネームのような）物や見解の記憶に関連づける。関連づけた 公共見解の項目に加えて、一覧の見解は物や見解の記憶を伴ったエンティティー ネームに関連づけることができる。例えば、次に一覧項目を示す。 -- catalog: SGML Open style entity catalog for HTML -- -- $Id: catalog,v 1.3 1995/09/21 23:30:23 connolly Exp $ -- -- Ways to refer to Level 2: most general to most specific -- PUBLIC "-//IETF//DTD HTML//EN" html.dtd PUBLIC "-//IETF//DTD HTML 2.0//EN" html.dtd PUBLIC "-//IETF//DTD HTML Level 2//EN" html.dtd PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN" html.dtd -- Ways to refer to Level 1: most general to most specific -- PUBLIC "-//IETF//DTD HTML Level 1//EN" html-1.dtd PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN" html-1.dtd -- Ways to refer to Strict Level 2: most general to most specific -- PUBLIC "-//IETF//DTD HTML Strict//EN" html-s.dtd PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN" html-s.dtd PUBLIC "-//IETF//DTD HTML Strict Level 2//EN" html-s.dtd PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 2//EN" html-s.dtd -- Ways to refer to Strict Level 1: most general to most specific -- PUBLIC "-//IETF//DTD HTML Strict Level 1//EN" html-1s.dtd PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 1//EN" html-1s.dtd -- ISO latin 1 entity set for HTML -- PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML" ISOlat1\ sgml 9.7. Character Entity Sets HTML DTDは次のエンティティーにより定義する。それらは、マークアップの所に 特に意味づけられたものを持つ特別な絵文字を意味するか、そうでなければ書き手 が利用できる文字指定の一部分ではないかもしれない。 Berners-Lee & Connolly Standards Track [Page 66] RFC 1866 Hypertext Markup Language - 2.0 November 1995 the writer. 9.7.1. Numeric and Special Graphic Entity Set 以下における各々の文字の一覧表や、加えてその名前や、使用を目的とした 系統的配列、描写等は数式に関する特殊文字のエンテイテイー指定からのも のである。この表は'ISO Standard 8879:1986//ENTITIES Numeric and Spec- ial Graphic//EN'からの引用である。しかしながら、HTMLは全部のエンテイ テイー指定を含んでいるというわけではなく、以下に表として書かれたエン テイテイーだけを含んでいる。 GLYPH NAME SYNTAX DESCRIPTION < lt < Less than sign > gt > Greater than signn & amp & Ampersand " quot " Double quote sign 9.7.2. ISO Latin 1 Character Entity Set 以下における各々の文字の著名な文や、加えてその名前、使用を目的とした 系統的配列、描写等は the Added Latin 1 entity set の中で具体的に挙げ られている。この表は'ISO Standard 8879:1986//ENTITIES Added Latin 1 //EN'からの引用である。ここでは、HTML は全部のエンテイテイーを含んでいる。 Berners-Lee & Connolly Standards Track [Page 67] RFC 1866 Hypertext Markup Language - 2.0 November 1995 Berners-Lee & Connolly Standards Track [Page 68] RFC 1866 Hypertext Markup Language - 2.0 November 1995 10. Security Considerations 支えや深くとどまっているイメージや要因としてURIsを含んでいるその他 全ての要素は、使用者の入力への反応の中において、URIがそれに言及しな いようにさせる原因になるかもしれない。この場合、[URL]の安全への考慮 があてはまる。 広く展開された、型の要求を従わせる方法 -- HTTP and SMTP -- は秘密性 の保証をほとんどしない。型 --特に'PASSWORD'を入力するような分野を通 しての場合(8.1.2. "Input Field:INPUT"参照)-- を通して、取り扱いに慎 重を要する情報を要求する情報供給者は、秘密性の欠落に気をつけるべきで あり、又利用者も同様に気をつけるべきである。 11. References [URI] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World- Wide Web", RFC 1630, CERN, June 1994. [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen, "Hypertext Transfer Protocol - HTTP/1.0", Work in Progress, MIT, UC Irvine, CERN, March 1995. [MIME] Borenstein, N., and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. [RELURL] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995 Berners-Lee & Connolly Standards Track [Page 69] RFC 1866 Hypertext Markup Language - 2.0 November 1995 [GOLD90] Goldfarb, C., "The SGML Handbook", Y. Rubinsky, Ed., Oxford University Press, 1990. [DEXTER] Frank Halasz and Mayer Schwartz, "The Dexter Hypertext Reference Model", Communications of the ACM, pp. 30-39, vol. 37 no. 2, Feb 1994. [IMEDIA] Postel, J., "Media Type Registration Procedure", RFC 1590, USC/Information Sciences Institute, March 1994. [IANA] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciecnes Institute, October 1994. [SQ91] SoftQuad. "The SGML Primer", 3rd ed., SoftQuad Inc., 1991. [ISO-646] ISO/IEC 646:1991 Information technology -- ISO 7-bit coded character set for information interchange [ISO-10646] ISO/IEC 10646-1:1993 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane [ISO-8859-1] ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. [SGML] ISO 8879. Information Processing -- Text and Office Systems - Standard Generalized Markup Language (SGML), 1986. Berners-Lee & Connolly Standards Track [Page 70] RFC 1866 Hypertext Markup Language - 2.0 November 1995 12. Acknowledgments(謝辞) HTML文書型は、1990年 World Wide Web計画の一部分としてCERNで Tim Berners-Leeによって作られた。1992年に、Dan Connolly はHTML 文書型(DTD)と簡潔なHTMLの詳述を記した。 1993年以後、インターネットの関係者の幅広い多様性が、WWWのための NCSA Mosaicソフトウエアによって導入されたインラインイメージの 追加を含む、HTMLの発展に貢献した。Dave Raggettは、HTML+の詳述から (もともとのHTMLになかった記入書式)型の機能の抜粋をするという、重要 な役をつとめた。 Dan ConnollyとKaren Olson Muldrowは、1994年にHTMLの詳述を書き改 めた。その文書はそのときに総括してHTMLワーキンググループによって 編集され、Spyglass社でEric Schieler、Mike Knezovich、そして Eric W. Sinkによって更新された。最終的に、Roy Fieldingがその全体の 下書きを再考察し、現在の型にした。 HTMLワーキンググループのたくさんの活発な関係者に感謝の意を表すが、 大勢すぎて個々に挙げることができないが、彼らなしには標準化プロセスも 標準もあり得なかった。この文書は、現在の試用化とSGMLとのHTMLの関係の 形式化の叙述を上手にまとめる、という目的に達成するというものであり、 これは彼らの努力のたまものである。 12.1.Authors' Addresses(作者の住所) Tim Berners-Lee Director, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. 電話: +1 (617) 253 9670 ファックス: +1 (617) 258 8682 EMail: timbl@w3.org Daniel W. Connolly Research Technical Staff, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. 電話: +1 (617) 258 8682 EMail: connolly@w3.org URI: http://www.w3.org/hypertext/WWW/People/Connolly/ Berners-Lee & Connolly Standards Track [Page 71] RFC 1866 Hypertext Markup Language - 2.0 November 1995 13. The HTML Coded Character Set (HTMLのコード化された文字指定) このリストは、9.5で詳しく述べられている、"SGML Declaration for HTML (HTMLのためのSGML宣言)"という、コードの位置とHTMLの文書の 文字指定の文字を詳しく述べている。このコード化された文字指定は [ISO-8859-1]に基づいている。 参照場所 説明(注:かっこ内は画面に表示される記号) --------------- ----------------------------------------- � -  未使用 水平タブ 行送り - 未使用 改行  -  未使用 スペース ! 感嘆符(!) " 引用符(") # 番号記号(#) $ ドル記号($) % パーセント記号(%) & アンパサンド(&) ' アポストロフィー(') ( 丸かっこ(() ) 丸かっことじる()) * 星印(*) + 加算記号(+) , コンマ(,) - ハイフン(-) . ピリオド(.) / スラッシュ(/) 0 - 9 数字(0〜9) : コロン(:) ; セミコロン(;) < 〜より小さい(<) = 等号(=) > 〜より大きい(>) ? クエスチョンマーク(?) @ アットマーク(@) A - Z 大文字(A〜Z) [ 角かっこ([) \ バックスラッシュ(\) ] 角かっことじる(]) ^ ハット記号(^) _ 下線(_) ` 強いアクセント記号(｀) a - z 小文字(a〜z) { 大かっこ({) | 垂直の棒線(|) Berners-Lee & Connolly Standards Track [Page 72] RFC 1866 Hypertext Markup Language - 2.0 November 1995 } 大かっことじる(}) ~ から(〜)  - Ÿ 未使用   スペースと見なされないスペース ¡ さかさまの感嘆符 ¢ セント記号(¢) £ 英貨ポンド(£) ¤ 一般通貨記号(〇と×が合体したような記号) ¥ 円記号(￥) ¦ 切れ目のある垂直な棒線 § 節記号(§) ¨ ドットが水平に2つ(¨) © 著作権記号(丸の中にc) ª 女性形をあらわす記号(小さめのa) « 左向きの引用符(《のようなやつ) ¬ 〜でないを表す論理記号(¬) ­ 短いハイフン(‐) ® 登録商標(丸の中にR) ¯ 長音記号(￣) ° 度記号(°) ± プラスマイナス(±) ² 2乗(小さめの2) ³ 3乗(小さめの3) ´ 強いアクセント(´) µ ミクロ記号(μみたいなやつ) ¶ 段落記号(¶) · 点(・) ¸ コンマ(,)のような記号 ¹ 1乗(小さめの1) º 男性形をあらわす記号(小さめのo) » 右向きの引用符(》のようなやつ) ¼ 分数(1/4) ½ 分数(1/2) ¾ 分数(3/4) ¿ さかさまのクエスチョンマーク À 大文字のAの上にアクセント記号(｀)がついた文字 Á 大文字のAの上にアクセント記号(´)がついた文字 Â 大文字のAの上にアクセント記号(^)がついた文字 Ã 大文字のAの上に記号(~)がついた文字 Ä 大文字のAの上に記号(¨)がついた文字 Å 大文字のAの上に輪がついた文字 Æ 大文字のAとEがひっついた文字 Ç 大文字のCの下に記号(,)がついた文字 È 大文字のEの上にアクセント記号(｀)がついた文字 É 大文字のEの上にアクセント記号(´)がついた文字 Ê 大文字のEの上にアクセント記号(^)がついた文字 Ë 大文字のEの上に記号(¨)がついた文字 Ì 大文字のIの上にアクセント記号(｀)がついた文字 Berners-Lee & Connolly Standards Track [Page 73] RFC 1866 Hypertext Markup Language - 2.0 November 1995 Í 大文字のIの上にアクセント記号(´)がついた文字 Î 大文字のIの上にアクセント記号(^)がついた文字 Ï 大文字のIの上に記号(¨)がついた文字 Ð 大文字のEthのアイスランド体(Dに-をくっつけたようなやつ) Ñ 大文字のNの上に記号(~)がついた文字 Ò 大文字のOの上にアクセント記号(｀)がついた文字 Ó 大文字のOの上にアクセント記号(´)がついた文字 Ô 大文字のOの上にアクセント記号(^)がついた文字 Õ 大文字のOの上に記号(~)がついた文字 Ö 大文字のOの上に記号(¨)がついた文字 × 乗算記号(×) Ø 大文字のOにスラッシュ(/)をくっつけたもの Ù 大文字のUの上にアクセント記号(｀)がついた文字 Ú 大文字のUの上にアクセント記号(´)がついた文字 Û 大文字のUの上にアクセント記号(^)がついた文字 Ü 大文字のUの上に記号(¨)がついた文字 Ý 大文字のYの上にアクセント記号(´)がついた文字 Þ 大文字のTHORNのアイスランド体(pみたいなやつ) ß 小文字のシャープのドイツ体(βみたいなやつ) à 小文字のaの上にアクセント記号(｀)がついた文字 á 小文字のaの上にアクセント記号(´)がついた文字 â 小文字のaの上にアクセント記号(^)がついた文字 ã 小文字のaの上に記号(~)がついた文字 ä 小文字のaの上に記号(¨)がついた文字 å 小文字のaの上に輪がついた文字 æ 小文字のaとeがひっついた文字 ç 小文字のcの下に(,)がついた文字 è 小文字のeの上にアクセント記号(｀)がついた文字 é 小文字のeの上にアクセント記号(´)がついた文字 ê 小文字のeの上にアクセント記号(^)がついた文字 ë 小文字のeの上に記号(¨)がついた文字 ì 小文字のiの上にアクセント記号(｀)がついた文字 í 小文字のiの上にアクセント記号(´)がついた文字 î 小文字のiの上にアクセント記号(^)がついた文字 ï 小文字のiの上に記号(¨)がついた文字 ð 小文字のethのアイスランド体(6が裏がえったような文字) ñ 小文字のnの上に記号(~)がついた文字 ò 小文字のoの上にアクセント記号(｀)がついた文字 ó 小文字のoの上にアクセント記号(´)がついた文字 ô 小文字のoの上にアクセント記号(^)がついた文字 õ 小文字のoの上に記号(~)がついた文字 ö 小文字のoの上に記号(¨)がついた文字 ÷ 除算記号(÷) ø 小文字のoにスラッシュ(/)をつけた文字 ù 小文字のuの上にアクセント記号(｀)がついた文字 ú 小文字のuの上にアクセント記号(´)がついた文字 û 小文字のuの上にアクセント記号(^)がついた文字 ü 小文字のuの上に記号(¨)がついた文字 Berners-Lee & Connolly Standards Track [Page 74] RFC 1866 Hypertext Markup Language - 2.0 November 1995 ý 小文字のyの上にアクセント記号(´)がついた文字 þ 小文字のthornのアイスランド体(Pみたいなやつ) ÿ 小文字のyの上に記号(¨)がついた文字 14. Proposed Entities (予約文字) HTML DTDは、[ISO-8859-1]にあってアスキーコードにない文字、すなわち特殊文字 の設定のための名称づけられた文字記号しか補われていない"Added Latin 1"という 文字記号指定を示している。次の文字記号は、すべてのISO8859-1の文字が省略文字 だけで参照できるように設定されている。それらの文字記号に対応する名称は [SGML]の付録から引用されている。 Berners-Lee & Connolly Standards Track [Page 75] RFC 1866 Hypertext Markup Language - 2.0 November 1995 Berners-Lee & Connolly Standards Track [Page 76] RFC 1866 Hypertext Markup Language - 2.0 Nobenber 1995 Berners-Lee & Connolly Standards [Page 77]