ホーム・ 翻訳について・ SGML入門・ HTML 2.0・ HTML 2.x text版原著 ------------------------------------------------------------------------ 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) の 最新版を参照して下さい。このメモの配布には制限はありません。 要約 ハイパーテキスト・マークアップ言語（HTML）は、プラットフォームに依存しない ハイパーテキストを作成するのに使います。初期において、世界的通信網（www）上 でHTMLアプリケーションはISO-8859-1コード文字セットに頼って深刻な制限を受けて いて、西欧言語にだけしか適用されていませんでした。この制限にも関わらず、HTML は他のコード文字セット乃至は文字コード化で、互換性を犠牲にして、広く使われる ようになりました。 この文書はHTMLの国際化問題internationalization（i18n、iに続いて18アルファ ベットが来てその後にnとなります）を呼びかけることを意味し、HTML仕様書を拡大 し、適切な国際化を支持する勧告を追加しようということです。真っ先に考えて置く べきことは、HTMLは正しく SGMLアプリケーションであり世界の全ての言語で使うこ とができるということを再確認しておくことです。 ------------------------------------------------------------------------ 目次 1. はじめに 1. 目的 2. 適合性 2. 文書文字セット 1. 参照処理モデル 2. 文書文字セット 3. 表示できない文字 3. LANG属性 4. 追加された実体・属性と要素 1. 全ラテン1実体セット 2. 言語特有の体裁用マーク付け 5. フォーム（書式） 1. 追加DTD 2. フォーム提出 6. 外部文字コード化の問題 7. HTML公開テキスト 1. HTML DTD 2. HTMLのSGML宣言 3. ISOラテン1文字実体セット 8. 案全問題 * 文献 * 原著者連絡 ------------------------------------------------------------------------ 1.はじめに ハイパーテキスト・マークアップ言語（HTML）は、プラットフォームに依存しない ハイパーテキストを作成するのに使われるマーク付け言語です。初期の頃は世界的な 通信網（WWW）上でHTMLアプリケーションは深刻な制限があり、ISO-8859-1コード化 文字セットに依存し、西欧言語だけが適応していました。この制約にも関わらず、 HTMLは他の言語でも、言語にに色々なその場しのぎの拡張を加えて、広く使われるよ うになりました[TAKADA]。 この文書はHTML仕様書を拡張し適切な国際化サポートの追加勧告を加えて、HTMLの 国際化問題を呼びかけることを意味しています。それは、著者の一人によってなされ たWWW上での多言語に関するペーパーに基づいたいい部分にあります[NICOL]。最初に 考えておくことは、HTMLはSGMLの正しいアプリケーションでありつづけ、世界の全て の言語で使うことができるということです。 この呼びかけられた問題は、HTMLに使われるためのSGML文書文字セットで、 "text/html"内容タイプと協調する文字パラメータや幾つかの追加された要素や実体 の適切な処理です。 1.1目的 HTMLは、1990年以来世界的な通信網でグロバルな情報によって率先して使われてき ました。この仕様書は、 HTML 2.0 (RFC 1866)の能力を、主にISO-8859-1コード化文 字セットの制限を取り除いて、拡張発展します[ISO-8859]。 Standard 8879:1986, Information Processing Text and Office Systems -- Standard Generalized Markup Language (SGML) [ISO-8879]。HTML文書型定義 （DTD）は、SGMLの用語でなされたHTML構文の正式な定義です。この仕様書は、HTML 2.0のDTDを正式な手続きで改訂し、ISO-8859-1より多くの文字目録（レパートリー） を文書に取り込み、なお且つSGMLに適合するようにします。 HTMLの正式且つ実用的な発展が、非常に速いスピードで進んでいます。この仕様書 で説明されている特質（機能）は、RFC 1866で記載されたもの以外に別のHTMLフォー ムを追加でき（追加されるべき）ます。ここに導入された属性は、適切な要素にも広 げられるべきです。 1.2適合性 この仕様書は、HTML文書やHTML表示代行手段の適合要求を多少変更します。 1.2.1文書 HTML 2.0に適合する文書は全て、この仕様書とも適合します。しかしここで導入 された拡張は、特にISO 8859-1目録以外の文字や文字参照を含みここの中に導入され たマークづけを含むと、HTML 2.0に適合しない文書でも正しいとします。 1.2.2.表示代行手段（ユーザー・エージェント） RFC1866の要件以外に以下の要件がHTML表示代行手段に委ねられます。 ISO-8859-1以上の文字コード化体系がある場合互換性と少なくともISO-8859-1の適 切なサポートを確保するために、表示代行手段はネットワークから受け取った文書に 伴う文字パラメータを正しく解釈しなければなりません。 更に、適合表示代行手段は少なくともISO 10646-1範囲の数値文字参照を全て正し く解釈しなければなりません[ISO-10646]。 適合表示代行手段は、右から左文字を表示するなら、BIDI描写アルゴリズムを適用 するよう要求されます。表示できない右左文字が文書にないなら、BIDI処理を摘要す る必要はありません。 ［目次］ ------------------------------------------------------------------------ 2.文書文字セット 2.1.参照処理モデル この概要で、HTMLで使われる参照処理モデル、とくに文書文字セットのSGMLの概念 を説明します。実際の装備はインターネット上での作業では以下に述べるモデルと隔 たりがありますが、部外観察者への説明として振る舞うべきです。 テキストの色々異なったコード化がありますので、理論上SGML文書を構成する一連 の文字は、コンピュータ・ファイルと言った文書の強固な実現で、一連のオクテック （または場合によっては、8以外の長さのビット・グループ）でどのようにコード化 されるかを直接呼びかけていません。このコード化はSGML文書の固定化された外部文 字コード化と言われ、理論的なHTML文書の文書文字セットと注意深く区別すべきで す。 SGMLは文字を一つのセット（「文字目録（レパートリー）」）としてみ、整数 値（「文字数値」として知られている）を目録の各文字に割り当てます。文書文字セ ット宣言は、文字数値の一つ一つが何を表現しているのかを定義します[GOLD90, p. 451]。おおくの場合それを参照するSGML DTDと文書は、一つの文書文字セットを持 ち、マーク付けやデータ文字はすべてこのセットの一部です。 注： "Character Set" Considered Harmful からの引用 オクテット（8個一組のもの）：octet an element of the set {0, 1, 2, ..., 255} {0, 1, 2, ..., 255}組の一つ 文字コード化体系：character encoding scheme a function whose domain is the set of sequences of octets, and whose range is the set of sequences of characters over some character repertoire. ドメインが一連のオクテットのセットで、その範囲は文字目録（レ パートリー）をカバーする機能 HTMLは、SGMLアプリケーションとして、外部文字コード化を直接割り当てません。 これは、HTTPプロトコールや電子メールによって使われるMIMEといったHTMLの外部の 機序に据え置かれます。 HTTPプロトコール[RFC2068]にとって外部文字コード化は、HTTP応答ヘッダーの "Content-Type"欄の"charset"パラメータによって指定されます。例えば、転送され た文書が日本語の"JUNET"コード[RFC1468]でコード化されていると指定されている と、ヘッダーは以下のような行に内容を持ちます： Content-Type: text/html; charset=ISO-2022-JP MIMEでの"charset"と言う用語は、用語が示すような単なるコード化された文字以 上に文字のコード化を設計するのに使われます。文字コード化は、一連のオクテット を一つ以上の文字目録取ってきた一連の文字にマッピング（多対一も可能）します。 HTTPプロトコールはまた受け入れる文字コードをクライアントが特定できる機序を も定義します。クライアントとサーバーは、文書の正しい転送や解釈を確実にするた めにこの機序を使うことを要求されます。サーバーやクライアントがいまだこの機序 を使用していない場合であっても、正しい解釈を助けるために取られる規定について はセクション6で言及されています。 同様にHTML文書が電子メールによって転送なら、外部文字コード化は "Content-Type" MIMEヘッダー欄[RFC2045]の"charset"パラメーターによって定義さ れ、それがない場合US-ASCIIに初期化します。 現在、FTPで転送されるHTML文書や分布されているファイル・システムで利用され るHTML文書の外部文字コード化用に標準化されている機序はありません。 HTML文書の転送や保存で他の方法が定義され行き渡っている場合、同じ規定で使わ れて文字コード化を明確に識別するよう、またインターネット文脈で使われる文字の 広い範囲を表示できる能力のある単一／初期コード化を使うように薦められていま す。 外部文字コード化がなんであれ、参照処理モデルでは、SGML/HTMLに特有な処理の 前にセクション2.2で特定された文書文字セットに翻訳されます。この参照処理モデ ルは以下の様に描けます： [resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display] [manager] [parser] ^ | | | +----------+ デコーダー（解読者）は、資源の外面的な体裁を体裁文書文字セットに解読する責 任を持っています。実体処理（entity manager）・解析（parser）そしてアプリケー ションは、ただ文書文字セットの文字を取り扱うだけです。アプリケーヨンの画面表 示指向の部分や画面表示機構自体は、文書文字セットで表現できる文字を別のより目 的に合った表現に再度変換するだけかもしれません。如何なる場合でも実体処理・解 析そしてアプリケーションは、文字の意味に関わる限り、HTML文書文字セットだけを 使うことです。 実際の装備が、文書を上で述べた文書文字セットのコーディング化に文書を翻訳す ることを選ぶかもしれませんし、そうしないかもしれません；この参照処理モデルに よって説明した振る舞いは別のやり方でもできます。この問題はこの仕様書の目的を 超えていますが、読者はより詳しい情報は標準SGML [ISO-8879]やSGMLハンドブック [BRYAN88] [GOLD90] [VANH90] [SQ91]から得られます。 この参照処理モデルの最も重要な結果は、数値文字参照は必ず固定された文書文字 セットにそい、かくて、外部コード化が実際に使われていればなんでも、同じ文字に そって解決されることです。例えば、セクション2.2を参照して下さい。 2.2.文書文字セット 文書文字セットはSGMLの意味において、修正されISO 10646:1993 [ISO-10646]のユ ニバーサル文字セット(UCS) です。現在これはUnicode standard,version 1.1 [UNICODE]とコート対コードで 注意−−装備はISO 1064は時々修正されることを知っておかなければな りません；はじめての1993年出版以来4修正が採用されて、これはこの仕 様書に本質的な影響を与えていません。五番目の修正が現在考慮中ですが、 非互換性の変更をこの標準に導入しています：コード位置3400と4DFF（十 六進法）に割り振られている6556 韓国ハングル音節は新しい位置に移動 させられ（そして4516新しい音節が追加されます）、旧位置への参照は間 違いにさせられます。ユニコード協会は既に次のユニコード2.0に含むよ うに修正を採用し、DAM5の採用は同じ様になると考えられ、装備制作者は おそらく旧コード位置を既に不正なものと考えるべきです。この一回りの 変更がありましたが、当面の問題に関係のある標準体部は割り振られた全 てのコードを将来変更しないと書き留められています。この変更にも関わ らない韓国ハングルをコード化するには、1110-11F9の範囲でHangul Jamo を連結して使うことができます。 この文書文字セットの採用はHTML 2.0仕様書で特定されたSGML宣言に変更を伴いま す（[RFC1866]のセクション9.5)。この変更は最初のBASESET使用やそれに伴う DESCSET宣言を取り除き、以下の宣言に置き代えます： BASESET "ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3 //ESC 2/5 2/15 4/6" DESCSET 0 9 UNUSED 9 2 9 11 2 UNUSED 13 1 13 14 18 UNUSED 32 95 32 127 1 UNUSED 128 32 UNUSED 160 2147483486 160 CUSで、文書文字セットでHTML 2.0に適合する表現・構造や文書は非適合になりま せん。HTML 2.0で受け入れられる或る種の構造を適合なものにします。その結果、 ISO-8859-1目録以外だがUCS-4の範囲内のデータ文字が正しいSGML文字となります。 更に、数値文字参照の上限が255から2147483645に拡張されます；かくて Иは "CYRILLICの大文字 I"の正しい参照になります。 [ERCS]は、UnicodeやSGMLの情報 のいい資源です。その目的や技術的な内容はこの仕様書と非常に異なりはしますが。 注意−−HTML 2.0と同じで上記のSGML宣言は数値文字128から159（80か ら9F 十六進法)をUNUSEDと特定しています。この範囲の数値文字参照 （例、’）はHTMLでは正しくないという意味です。ISO 8859-1 もISO 10646もどちらもこの範囲の文字を含んでいますが、これは制御文 字として予約されています。 後者はその著者の真の意図を表わしていないという考えで、別の変更がHTML 2.0 SGML宣言からなされました。構文文字セット宣言がISO 646.IRV:1983から新しいISO 646.IRV:1991に変更され、前のではなくでなく最新のものははUS-ASCIIと一致しま す。原理的にこれはHTML 2.0との非互換性をもたらしますが、実際的には(i)SGML宣 言に皆が考えていることをいわせ、(ii)構文文字セットに文書文字セットのサブセッ ト作ることによって互換性を増すにちがいありません。ISO 646.IRVの二つのバージ ョンでことなる文字は、実際上HTML構文を表わすために使われません。 ISO 10646-1:1993は現存する、最も文字を取り込んでいるもので、HTML用の文書文 字セットとしてその位置を凌駕する文字セットはありません。それにもかかわらず特 別なアプリレーションのためにこの標準範囲外の文字を使う必要が出てきたら、現在 のまた将来のISO 10646バージョンとの衝突を避けなければならなく、例えばこれら の文字をUCS-4コード化空間の私的なゾーン[ISO-10646セクション11]にあてがいま す。また、この様な使い方は、互換性にかけることを心に留めておかなければなりま せん；多くの場合インライン画像を使うほうがよりいいかもしれません。 2.3.表示できない文字 適当な資源（文字）がないので、文字が描写できない可能性は全ISO 10646装備で も回避できません。その様なケースとして、様々なものがありますので、この文書特 別な何らかの振る舞いについて言及していません。装備に依存するので、これもアプ リケーション自体でなく基礎となる表示システムによって処理される問題です。しか し以下述べることは手助けになるかもしれません： − はっきり見えるのでなく控えめな振る舞いがいいでしょう。或る文書に 表示することが出来ない多くの文字があり、それぞれに代替で示すこと は正しいやり方ではありません。 − 間違った文字の数値参照が与えられるケースでは、その十六進法（十進 法でなく）形式が好まれまれ、この形式が文字セットの標準[ERCS]で使われて いるからです。 ［目次］ ------------------------------------------------------------------------ 3.言語属性（LAG属性） 言語タグは色々なやり方でマーク付けされた文書の表示を制御するのに使えます： 文字コード化が特別な象形文字を特のに十分でないケースでの象形文字の一義性；引 用マーク；ハイフォネーション；合字（fi, ffl, ）や連結線（^）；スペーシング； 音声合成；など。表示問題とは別に、言語マーク付けは分類や検索といった目的の内 容マーク付けとしても有効です。 以下なるテキストも論理的に言語を割り当てることができるので、殆ど全てのHTML 要素はLANG属性（言語属性）を許しています。DTDはこれを反映しています；言語属 性のないこのHTMLバージョンでの要素はBR・HR・BASE・NEXTIDそしてMETAで、属性を 取らない十分な理由があります。 言語属性、LANG、は値として普通に話され・書かれ・他の人との情報交換のために 人が伝達する言語を識別する言語タグをとります。コンピューター言語ははっきりと 除外されます。 HTML言語タグはRFC 1766 [RFC1766]によって定義されているものと同じです。要約 すると、言語タグは一つ以上の部分から構成されています：基本言語（プライマリー 言語）とサブタグとがくる空白部分で： language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA 空白文字はこのタグ内では許されていませんし、大文字小文字は区別しません（ケ ース非感受性性）。言語タグの名称はIANAによって管理されています。見本タグとし て： en, en-US, en-cockney, i-cherokee, x-pig-latin HTMLの文脈で、言語タグはRFC 1766にそって単一字句（トークン）としてではなく 階層構造として解釈されます。例えば、言語に従って表示を調整する表現代行手段 は、スタイル・シート登録言語タグが要素の言語タグの最初の部分と一致した場合そ れは一致したと考えなければならない。正確な一致が好ましいとされるべきです。こ の解釈では、要素が例えば"en-US"としてマーク付けし、優先順位としてUS-English ("en-US") か'plain'乃至'international' English ("en")に対応するスタイルを引 き出すことを可能にします。 注意−−階層構造として言語タグを使うことは、共通の接頭語をもった 全ての言語がそれらの一つ以上の言語でその変数によって理解されると いっるのではありません；それは単にユーザーがユーザーにとって正し いときこの共通性を要求できるだけです。 要素の表示は言語属性によって影響されます。如何なる要素でも言語属性の値は閉 じられた要素の言語属性と、もしあるならHTTP Content-Languageヘッダーの値によ って特定された値を上書きします。これらが設定されていないなら、恐らくユーザー の好みによって制御されている最適な初期値が、自動的な文脈分析乃至はユーザーの 地域によって表示を制御するのに使われるべきです。 ［目次］ ------------------------------------------------------------------------ 4. 追加された実体・属性・要素 4.1. Full Latin-1 entity set [RFC1866]のセクション14の示唆に従ってLatin-1実体はISO-8859-1（高順位ビッ ト・セットの全てのコード位置）の全ての右部分をカバーするように拡張され、既に よく使われている , ©や ®を含んでいます。実体の名前はSGML [ISO-8879]の付録にあります。 4.2.言語特有の体裁用マーク付け 4.2.1.概要 ある種の言語でのテキストの正しい描写のために（フォーマット問題に関わりな く）、追加実体や要素の形式上での幾つかのサポートが必要になります。 特に、以下の特徴が関連させられます： − 双方向性のテキスト、例左右と右左叙述が混在していつテキスト − 初期振る舞いが適当でない文脈上で、草書体振る舞いの制御 − 短い（インライン）引用の言語依存表示 − 必要な所での言語のよりよい調整制御 − 一般的なテキストの一部として表われる言語の上付きと下付き 上記の特徴の追加サポートは余り必要でないものもあります：別のものはより必要 なものもあります。追加された特徴は短いコメント付きで以下に紹介されています。 筆記体合併振る舞いや双方向性テキストについての説明は後につづいています。筆記 体合併振る舞いや双方向性テキストのために、この文書は[UNICODE]に従い：i)適応 されるなら文字構文は[UNICODE]と同じで、ii)機能性が高いレベルのプロトコールと してHTMLに移る所で、これは[UNICODE]で定義された低いレベルに直接変換できま す。 4.2.2.実体・要素そして属性のリスト まず、一般的なコンテーナ（容器）が、他に適切な要素がない所で言語（LAG） や方向（ DIR）属性を実行するために必要です； SPAN要素はこの目的のために導入 されています。 指定された文字実体のセットが双方向性表示や中世ラ書体との連合制御で使うのに 追加されています： これらの実体は、対応するフォーマットされた文字の場所でキーボード入力を容易 にするなどの便宜性の場合や文書の文字コード化が得られない場合に使うことができ ます。 次に、DIRという属性が導入され、 LTR（左右）と RTL（右左）の値だけで、双方 向性のテキストの文脈上方向性を指すためのものです（詳しくは以下のセクション 4.2.4 ）。如何なるテキストやその他の多くの要素も論理的には方向性が割り当てら れます（例えば、テーブル）ので、BR・HR・BASE・NEXTIDそしてMETAを除く全ての要 素はこの属性を受け入れます。DTDもこれを反映しています。HTMLの将来のバージョ ンで導入される如何なる新要素もDIR属性を、そうしない理由がない限り、受け入れ ます。 BDO（BIDI上書き）という語句−レベル要素が導入され、上書きが左右か右左かを 特定するかをDIR属性に要求します。この要素は双方向性テキストの制御に必要で す；より詳しくはセクション4.2.4を参照して下さい。 語句−レベルの要素Qで、言語やプラットフォームに依存する短い引用を言語から 独立して表示できます。次の例が（インターネット仕様書での文字セットの制限があ るので、やや貧弱ですが）示すように、引用を囲む引用マークは特に影響されます： "英語の引用符号"・'別の、少しいいもの'・,,ドイツ語の引用符号''・<<フランス語 での引用符号>>。Q要素の内容は引用符号を含まないで、表示処理過程で加えなけれ ばなりません。 注意−−Q要素は入れ子出来ます。おおくの言語は外側と内側の引用で異 なったスタイルの引用符号を使い、これはこの要素を装備している表示 代行手段によって守られるべきです。 注意−−Q要素の最小サポートは、ASCIIの二重引用符号の様に、ある種 の引用符号で内容を囲むことです。 これは備えることは容易で視覚的 な引用がないとテキストの意味を理解するすることに影響するので、表 示代行手段制作者は少なくともこの最低レベルのサポートを提供するよ うに強く要求されています。 適切な表示のために上書きテキストが必要な言語がありまう：例として、フランス 語"Mlle Dupont"は上書きの"lle"があります。このSUP要素と双子である下書きテキ スト用のSUBが導入され、この様なテキストの適切なマーク付けができます。SUPと SUBの内容は入れ子問題を避けるためにPCDATAに制限されています。 最後に多くの言語ではテキストの調整が西欧語よりも非常に重要で、マーク付けを 調整します。 ALIGN属性は LEFT・RIGHT・CENTER・JUSTIFYの値を取り、それが必要 な所（ P・HR・Hから H6・OL・ UL・DIR・ MENU・LI・BLOCKQUOTEそしてADDRESSとい ったブロック様のもの）の要素の選択に加えられます。表示代行手段が初期値として 左から右方向性を選んでいたら、右から左方向性のブロックにはRIGHTを使うべきで す。 注意−−RFC1866セクション4.2.2で、HTML表示代行手段は行末を一語のス ペースとして、整形文は例外ですが、処理すべきだと特定しています。こ れは処理されるスクリプトの文脈で解釈されるべきです。或るスクリプト （例、ラテン）では一語スペースは一つのスペースですが、他のスクリプ ト（例、タイ）では空白のない言語区切りで、それに対してまた別のスク リプト（例、日本語）ではそもそも空白がなく言い代えると全く無視され ます。注：HTML文書中の改行文字について 注意−−ソフト・ハオフェン文字（U+00AD）は、表示代行手段制作者から 特別な注意を必要とします。これは多くに文字セット（全ISO 8859 シリー ズや勿論ISO 10646もふくめて）にあり、必ず­参照です。この構 文的は、普通のハイフェンとはことなっています：これは改行ができる言 葉のポイントを指しています。行が実際にここで改行されるとハイフェン は最初の行の終わりで表示されなければなりません。改行がないなら、こ の文字は全く表示されません。検索や並び代えなどの操作でこれは必ず無 視されなければなりません。 DTDでLANGとDIR属性はattrsと銘々されたパラメーター内に一つに纏められていま す。RFC 1942 [RFC1942]と同じ様に、IDとCLASS属性もattrsに含まれます。IDと CLASS属性はスタイル・シートで使うよう要求されて、RFC 1942はこれらを以下のよ うに定義しています： ID 文書範囲識別子を定義するのに使います。これはハイパーテキスト・ リンクの行き先として文書内で指定位置のために使われることもできま す。またユニークなスタイルで要素を表示するためのスタイル・シート によっても使われるかもしれません。ID属性値はSGMLの名前字句（NAME token）です。名前字句はアルファベット文字に始まり続いて、文字・ 数字・"-"そして"."文字がきます。文字は A-Zとa-zに限定されています。 CLASS SGML名前字句のスペース区切りのリスト。CLASS名はその要素が対応する 名付けられたクラスにぞくしていることを特定します。同じタグによって 演じられる異なった役割を区別することができます。このクラスはスタイ ル・シートによって使われ、役目によって異なった表示を提供します。 4.2.3.中世ラ書体結合作用 或る例でマーク付けは、普通では起こらないかもしれないし、普通に起こったらそ れを阻止する文脈で、中世ラ書体結合作用をするよう要求されることもあります。 ゼロ幅結合と非結合（‍と‌）は、中世ラ書体結合作用を制御するのに使 われます。例えばアラビア文字"HEH"は、単独で"Hijri"を短縮するのに使われます （イスラム暦システム）；しかしその文字のはじめに形式が必要で、というのもHEH の単独型はアラビア・スクリプトで採用されている数字五の様にみえるからです。効 果は唯文脈を提供するだけのゼロ幅結合（zero-width joiner）を、HEHの後に続ける ことで達成されます。ペルシャ語テキストで、普通では続く文字に連合する文字が中 世ラ書体結合でないケースがあります。ここでは、セロ幅非結合（zero-width non- joiner）が使われます。 4.2.4. 双方向性テキスト 多くの言語は水平方向で左から右に書かれますが、みぎから左に書かれるものもあ ります。両方の書き方でするものもあり、双方向性テキスト（BIDIrectional;短縮し てBIDI）について述べます。ビアイディアイ・テキストは、特別な場合でマーク付け が必要で、或る文字の方向性にとって多義性が解決されなければなりません。このマ ーク付けは構文的に正しい形式でビアイディアイ・テキストを表示する能力に関与し ます。言い替えるとこの特別なビアイディアイマーク付けなしては、テキストの基本 的な意味を反映したものを表示するものがなんであれ妨げるケースが起こります。テ キストは、特別な目的のフォーマット文字の形式でビアイディアイマーク付けを含む かもしれません。 これはHTMLでも可能で、ISO 10646の五つのビアイディアイ関連フォーマット文字 （202A - 202E）を含んでいます。代替として、HTMLは等価のSGMLマーク付けを提供 しています。 BIDIは複雑な問題で、一連の論知的なテキストを一連の表示に切り替えるのはアル ゴリスムと[UNICODE]で特定されている文字特性に従ってなさなければなりません。 ここでは、導入された特徴の必要性を理解し正確な構文を定義する範囲だけの説明を します。 ユニコード・ビアイディアイは論理的な順序に貯えられているテキストの個々の文 字に基盤を置いて、普通に入力された順番であり、対応する音が普通に話されるもの です。論理的な順序テキストの表示を可能にするために、アルゴリズムは方向特性を 各文字に割り当て、例えばラテン文字は左右方向にアラビアやヘブライ文字は右左方 向に特定します。 左右と右左マーク（‎と‏）が中立文字の方向性を定めるのに使われます。 例えばアラビア文字とラテン文字の間に二重引用符があると、方向性は曖昧になりま す；方向性マークが一方に加えら引用符が一つの方向性のみの文字で囲われると、曖 昧さは取り除かれます。これらの文字は方向特性を持ったゼロ幅空間（しかし言葉／ 行の改行特性はない）のようになります。 入れ子で組み込まれた反対の方向性のテキストは入れ子された引用やビアイディア イ文脈から別のものへのテキストのペースに従い、文字の明確な方向性が十分でなく マーク付けを必要とするケースです。また、テキストのブロックの基本方向と特定す ることが望まれ、方向属性（DIR属性）が使われます。 ブロック−タイプ要素で方向属性はブロック内のテキストの基本的な方向性を差し ます；省略されていた場合親要素から継承されます。HTML全域の初期方向性は左右で す。 オンライン要素では要素を組み込まれたレベルで始めます（後で説明しますが）； 省略されていた場合インライン要素は組み込まれたレベルではじめません。 注意−−PRE・XMPそしてLISTING要素は方向属性を受け付けません。その 内容は双方向性のレイアウトで整形されたと考えるべきではありません が、ビアイディアイ・アルゴリズッムは各テキスト行に適応されるべき です。 以下は組み込みが必要なケースの例で、その効果をみせています： 次のラテン文字（大文字）とアラビア文字（小文字）を特定された組み込みで AB xy CD zw EF 以下の表示が得られます（[] は方向の移行を指しています）： [ AB [ wz [ CD ] yx ] EF ] 一方このマーク付けがなく基本方向が LTRの場合は以下のように表示します： [ AB [ yx ] CD [ wz ] EF ] 組み込みレベルが使われているのと違って、yxは左にそしてwzは右にあることに注 意して下さい。組み込みマーク付けがない場合多くても二つのレベルを持てます：基 本的な方向レベルと単一の反対方向のレベルです。 インライン要素での方向属性はISO 10646の形式文字LEFT-TO-RIGHT EMBEDDING (202A) やRIGHT-TO-LEFT EMBEDDING (202B)と同じです。この要素の閉じタグはPOP DIRECTIONAL FORMATTING（202C）文字と同じです。 方向性の上書きは、BDO要素によって提供され、方向性が安定した形での文脈から は解決できないテキストの普通でない短い部分を取り扱うために必要です。例えば、 ラテン文字・数字とヘブライ文字から構成されている部分の左右（また、右左）表示 を強制するのに使うことが出来ます。 BDOの効果はその中の全ての文字の方向性をDIRの値、それぞれの内部方向性特性、 に強制することです。ISO 10646のLEFT-TO-RIGHT OVERRIDE (202D) かRIGHT-TO-LEFT OVERRIDE (202E)文字を使うのと同じで、閉じタグは POP DIRECTIONAL FORMATTING (202C)文字と同じです。 注意−−著者や閲覧ソフト制作者は、方向属性がインライン要素（BDOも 含めて）でそれに対応するISO 10646形式文字の使用と伴に使われていり と衝突が起こりえ得ることを知っていなくてはなりません。 どれは一つを使うのが好ましく：テキスト・エディターで双方向性のHTMLテキスト を編集際文書構造の統一性を保証し、問題を軽減することができるマーク付け方法が ベターです。両方の方法を使うなら、マオク付けの適切な入れ子・方向組み込み・上 書きを確認する充分な注意を発揮しなければなりません；そうしないならば、表示結 果ははっきりしません。 ［目次］ ------------------------------------------------------------------------ 5.フォーム（書式） 5.1.追加DTD フォームがユーザー入力を得る唯一の方法を提供しているので、フォームで如何な る言語でも入力できるのを期待するのは当然のことです。これは原理的にはUIの問題 ですが、振る舞い方を案内し相互運用可能性を促進するためにHTMLレベルで特定され るべきことも幾つかあります。 全面的な相互運用可能性を確実なもにするには、表示代行手段（とユーザー）がフ ォームを提供するサーバーが書き込まれたフォームの転送を処理できる文字コード化 の指示をもつ必要があります。この様な指示はINPUTやTEXTAREA要素の ACCEPT-CHARSET属性によって提供され、HTTP Accept-Charsetヘッダー（ [HTTP-1.1] ）上に模擬化され、サーバーで受け付ける文字セットのスペースやコンマで区切られ たリストになっています。表示代行手段はユーザーにこの属性をもった内容を忠告す るかリスト化された文字セットの目録以外の文字の入力できるのを制限するように求 めます。 注意−−文字セットのリストは、排他的論理和リストとして解釈すべ きです；多元実体の各部分のための文字コード化体系の如何なるもの をも受け入れる容易があるとサーバーは言ってます。クライアント は、必要ならサーバーを満足させるために文字コード化翻訳を実行す るかもしれません。 注意−−INPUT or TEXTAREA要素のACCEPT-CHARSET属性の初期値は "UNKNOWN"と予約値です。表示代行手段は、要素を含む文書を転送する のに使われた文字コード化体系としてその値を解釈するかもしれませ ん。 5.2.フォーム提出 HTML 2.0のフォーム提出機序は"application/x-www-form-urlencoded"メディア・ タイプに基礎をおいていて、国際化の点では充分に装備されていません。事実URLsは ASCIIに限定されていますし、機序はISO-8859-1テキストにとってもさえも未熟なの です。[RFC1738]のセクション2.2ではオクテット（8ビット） "%HH"表記法を使って コード化されるかもしれないと特定していますが、フォームから提出されたテキスト は文字から構成されていてオクテックからではありません。文字コード化体系の仕様 に欠けていて、"%HH"表記法は充分に定義された意味を持っていません。 最善の解決は、フォーム提出のPOSメソッドで、 [RFC1867]に記載されている "multipart/form-data"メディア・タイプを使うことです。この機序は、HTTP本質と して送られる多元マイム体部のボディ部分で各name-value組の値部分を包み込みま す；各ボディ部分を、必要なら文字コード化体系を特定した文字パラメーターを含む 適切なContent-Typeでラベルすることができます。フォーム提出のこの方法をサポー トするのに必要なDTDへ変更は、この仕様書に含まれているDTDに組み込まれていま す。 多少不満足な解決としては、POSTメソッドフォーム提出にそって送られた "application/x-www-form-urlencoded"メディア・タイプ識別子にMIME charsetパラ メーターを加えることで、 一種の明示的な内容転送コード化として[RFC1738]のURL コード化が特定された文字コード化のトップに適用されます。 上記の二つの解決策の問題は、現在のブラウザは一般的にブックマーックで ポス ト・メソッドを特定することが許されていないことです；これは改善されるべきで す。反対にゲット・メソッドは、URL内でなくボディ内で転送されるフォーム提で使 うことができます。プロトコール上それを妨げるものは何もありませんが、装備が現 在は存在していないようです。 表示代行手段はユーザーによって登録されたテキストのコード化をどのようにして 決定しているのかということは、この仕様書の目的外です。 注意−−フォームやその処理スクリプトの設計者は重要な警告を意識 しておかねばなりません：欄（値属性）の初期値はフォーム提出に 戻って（例、ユーザーはこの値を変更しません）くる時、一連のオク テックが資源文書のそれと一致したものとして転送されると保証され ていません−−ただ、異なる可能性がるが一連の同じテキスト要素の 正しいコード化として。フォームと転送に使われたものを含む文書の コード化が同じ場合でも、これはおこるかもしれません。 一連の文字が色々なオクテックの繋がりによって表現される時や、一連の構成（基 本文字プラス一つ以上の結合区分表示符）が異なるかまたは同じ一連の構成によっ て、または前もって充分に作られている文字によって表現される時、違いが起こりま す。例えば等価の一連の構造要素に形を変える様に、UCS-2列00EA+0323（ラテンの小 文字で屈折アクセントのあるE＋下にドットがついている）は、1EC7（ラテンの小文 字で屈折アクセントと下にドット）・0065+0302+0323（ラテンの小文字E＋屈折アク セント＋下にドットがついている）に形を変えるかもしれません。 ［目次］ ------------------------------------------------------------------------ 6.外部文字コード化の問題 テキスト文書の適切な解釈には文字コード化体系が分かっていなければなりませ ん。しかし、現在のHTTPサーバーは Content-Typeヘッダーと適切なcharsetパラメー ターを含んでいません。charsetパラメーターを受け取った時、認知されないメディ ア・タイプを宣言するブラウザが存続しつづけることでその気にさせられないとして も、これは悪い振る舞いです。表示代行手段の装備制作者は、利点がないとしても、 ソフトウェアーをこのパラメーターに寛容にするように強く薦めます。適切なラベル は非常に望ましいのですが、それが無い場合の決定的な影響を最小にするために幾つ かの予防的な尺度があります： 文書が元のHTML文書にあるリンクからアクセスされた場合、リンクの意味（Aや LINK）のある要素の属性リストに、特にlinkExtraAttributes実体に、CHARSET属性を 加えます。その属性の値は、ハイパーリンクによって指し示されている資源によって 使われている文字コード化体系の表示代行手段へのヒントになるものでなけらばなり ません；それは資源のMIME charsetパラメーターの適切な値でなければなりません。 どの文書に於いても、コード化体系の示唆を以下の様に文書頭部（ヘッダー）ので きるだけはじめに含むことは可能です： これは絶対安心といえるものではありませんが、メタ要素が解析される迄は少なく ともただASCII文字のようにASCII値オクテットがあるだけ、といったコード化体系の 場合はうまく働くでしょう。上記の様に信頼がおけないメタの代わりに、サーバーが 文字コード化情報を得るのがよりいい方法であることに注意して下さい；より詳しい ことや提案については[NICOL2]を参照下さい。 定義にとって、文書資源から受け取る"charset"パラメーターが最も権威あるもの で、次いで上で述べたようなメタ要素の内容による優先順位に続き、在るなら最後に アンカー（固定点）のCHARSETパラメーターです。 HTMLテキストはUCS-2かUCS-4書式で運ばれる際バイト順位の問題がおこります： 各々の多次元バイト文字の高順位バイトは最初にくるのか最後にくるのか？ UCS-2と UCS-4はbig-endianバイト順位で運ばれるよう、この仕様書ははっきりと推奨し（高 順位バイトが最初に）、二と四バイト質で確立しているネットワーク・バイト順に対 応し、連続したテキスト・データ用のISO 10646要請とユニコード推奨に対応し、RFC 1641に対応しています。更に適切な解釈の機会を最大にするために、文書は必ず ZERO-WIDTH NON-BREAKING SPACE文字（十六進法のFEFFか0000FEFF）ではじまるUCS-2 かUCS-4として運ばれることを推奨していて、逆転されたバイトがFFFEかFFFE0000に なる場合文字は決して振り当てられないと保証されています。かくて、FFFEをテキス トの最初のオクテットとして受け取った表示代行手段は、バイトがテキストの残りの 為に逆転させられなくてはならないと分かります。 UCS-2やUCS-4以外に、UCSデーターを運ぶのに使える所謂UCS変換書式があります。 UTF-7 [RFC1642]とUTF-8 [UTF-8]は有利な特性があり（バイト順問題がなく、アスキ ーIIとの互換性という別の特色）、特に多言語テキストを運ぶ場合に考慮に値しま す。別のコード化体系、MNEM [RFC1345]、も全UCSを運ぶ興味深い特性と能力を持っ ています。ISO 10646:1993 のUTF-1変換形式（ISO-10646-UTF-1としてIANAによって 登録されている）は、修正4でISO 10646から除かれ、使用すべきではありません。 ［目次］ ------------------------------------------------------------------------ 7.HTML公開テキスト 7.1. HTML DTD このセクションは、RFC 1866のHTML 2.0 DTDに基づいたHTMLのDTDで、RFC 1867で 特定され登録されたファイルの変更やこの文書から始動する変更を組み入れたもので す。 ... -- > ]]> %ISOlat1; " --> ]]> Heading is preferred to

Heading

 --> ]]> " > #AttVal(Alt)" > ]]> ]]> ]]> Directory" > Menu" > Heading

Text ... is preferred to

Heading

Text ... --> ]]> ================================================================== 訳者注：マーク区間と実体宣言での解釈 %HTML.Recommendedを厳密に（Strictに）認める（INCLUDE）場合は、 % body.contentとは、 "(%heading|%block|HR|ADDRESS|IMG)*"なので、

Heading

Text ... でなくて、

Heading

Text ... と、ボディ内には%textはきません。 %HTML.Recommendedを厳密に（Strictに）でない（IGNORE）場合は、 % body.content "(%heading | %text | %block | HR | ADDRESS)*"> と %textがボディ内にきてもよく、

Heading

Text ... も認められます。 ==================================================================== Form:" %SDASUFF; "Form End." > Select #AttVal(Multiple)" > ]]> ]]> " > [Document is indexed/searchable.]"> ]]> 7.2. SGML Declaration for HTML 7.3. ISOラテン1 実体セット 以下の公開テキストは追加されたラテン1実体セットで特定された各文字を名前・ 使い方・説明でリストしています。このリストはISO Standard 8879:1986//ENTITIES Added Latin 1//ENから始動されます。HTMLは全実体セットを含み、ISO-8859-1の右 部分の全ての欠落した文字の実体を加えています。 ［目次］ ------------------------------------------------------------------------ 8.案全問題 アンカー・組み込み画像そしてパラメーターとしてURIsを持つその他のあらゆる要 素は、URLsがユーザー入力応答で逆参照される原因になります。この場合 [RFC1738]の安全問題が当てはまります。 広く採用されている要求（請求）フォームの転送方法−HTTPとSMTP−は機密の確実 性を殆ど提供していません。微妙な情報をフォーム--特に `PASSWORD'型入力欄によ る（セクション8.1.2参照）--を経て要求する情報提供者は機密性の欠陥があること を意識し、ユーザーにもこれを意識させるようにしなければなりません。 ［目次］ ------------------------------------------------------------------------ 文献 [BRYAN88] M. Bryan, "SGML -- An Author's Guide to the Standard Generalized Markup Language", Addison-Wesley, Reading, 1988. [ERCS] Extended Reference Concrete Syntax for SGML. [GOLD90] C. F. Goldfarb, "The SGML Handbook", Y. Rubinsky, Ed., Oxford University Press, 1990. [HTTP-1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [ISO-639] ISO 639:1988. International standard -- Code for the representation of the names of languages. Technical content in [ISO-8859] ISO 8859. International standard -- Information pro- cessing -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1 (1987) -- Part 2: Latin alphabet No. 2 (1987) -- Part 3: Latin alphabet No. 3 (1988) -- Part 4: Latin alphabet No. 4 (1988) -- Part 5: Latin/Cyrillic alphabet (1988) -- Part 6: Latin/Arabic alphabet (1987) -- Part : Latin/Greek alphabet (1987) -- Part 8: Latin/Hebrew alphabet (1988) -- Part 9: Latin alphabet No. 5 (1989) -- Part 10: Latin alphabet No. 6 (1992) [ISO-8879] ISO 8879:1986. International standard -- Information processing -- Text and office systems -- Standard gen- eralized markup language (SGML). [ISO-10646] ISO/IEC 10646-1:1993. International standard -- Infor- mation technology -- Universal multiple-octet coded character Sset (UCS) -- Part 1: Architecture and basic multilingual plane. [NICOL] G.T. Nicol, "The Multilingual World Wide Web", Electronic Book Technologies, 1995, [NICOL2] G.T. Nicol, "MIME Header Supplemented File Type", Work in Progress, EBT, October 1995. [RFC1345] Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345, Rationel Almen Planlaegning, June 1992. [RFC1468] Murai, J., Crispin M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, Keio University, Panda Programming, June 1993. [RFC2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. [RFC1641] Goldsmith, D., and M.Davis, "Using Unicode with MIME", RFC 1641, Taligent inc., July 1994. [RFC1642] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe Transformation Format of Unicode", RFC 1642, Taligent, Inc., July 1994. [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, October 1994. [RFC1766] Alverstrand, H., "Tags for the Identification of Languages", RFC 1766, UNINETT, March 1995. [RFC1866] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, MIT/W3C, November 1995. [RFC1867] Nebel, E., and L. Masinter, "Form-based File Upload in HTML", RFC 1867, Xerox Corporation, November 1995. [RFC1942] Raggett, D., "HTML Tables", RFC 1942, W3C, May 1996. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [SQ91] SoftQuad, "The SGML Primer", 3rd ed., SoftQuad Inc.,1991. [TAKADA] Toshihiro Takada, "Multilingual Information Exchange through the World-Wide Web", Computer Networks and ISDN Systems, Vol. 27, No. 2, Nov. 1994 , p. 235-241. [TEI] TEI Guidelines for Electronic Text Encoding and Inter- change. [UNICODE] The Unicode Consortium, "The Unicode Standard -- Worldwide Character Encoding -- Version 1.0", Addison- Wesley, Volume 1, 1991, Volume 2, 1992, and Technical Report #4, 1993. The BIDI algorithm is in appendix A of volume 1, with corrections in appendix D of volume 2. [UTF-8] ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS Transfor- mation Format 8 (UTF-8). [VANH90] E. van Hervijnen, "Practical SGML", Kluwer Academicq Publishers Group, Norwell and Dordrecht, 1990. ［目次］ ------------------------------------------------------------------------ Authors' Addresses Frangois Yergeau Alis Technologies 100, boul. Alexis-Nihon, bureau 600 Montrial QC H4M 2P2 Canada Tel: +1 (514) 747-2547 Fax: +1 (514) 747-2561 EMail: fyergeau@alis.com Gavin Thomas Nicol Electronic Book Technologies, Japan 1-29-9 Tsurumaki, Setagaya-ku, Tokyo Japan Tel: +81-3-3230-8161 Fax: +81-3-3230-8163 EMail: gtn@ebt.com, gtn@twics.co.jp Glenn Adams Spyglass 118 Magazine Street Cambridge, MA 02139 U.S.A. Tel: +1 (617) 864-5524 Fax: +1 (617) 864-4965 EMail: glenn@spyglass.com Martin J. Duerst Multimedia-Laboratory Department of Computer Science University of Zurich Winterthurerstrasse 190 CH-8057 Zurich Switzerland Tel: +41 1 257 43 16 Fax: +41 1 363 00 35 EMail: mduerst@ifi.unizh.ch ［目次］ ------------------------------------------------------------------------ 日本語翻訳版覚書 この文書の原著は、 ［Internationalization of the Hypertext Markup Language］ "http://ds.internic.net/rfc/rfc2070.txt" で、正式版はこの英語版です。 RFC Index Search Formからも入手可能 翻訳版は、翻訳からくる間違いがあり得ます。 Yasutaka Kato 加藤泰孝 ------------------------------------------------------------------------