RFC 6082

タグ文字 (Unicode)

仕様書

意味

[19] タグ文字のほとんど、 ASCII文字に相当するものを別の符号位置に割当て、 特殊用としたものです。 タグ文字を使うと、 ASCII ベースの文字列のタグを、 Unicode の通常の文字で記述したテキスト内容とは区別した形で埋め込むことが出来ます >>13

符号位置

[15] タグ文字 (tag character) は、 U+E0000 - U+E007F です。この範囲の Tags ブロック内に、 既に97文字が割り当てられています。 >>13 残りは未割当符号位置です。

[22] U+E0020 - U+E007F の95文字は、 ASCII文字 U+0020 - U+007E の95文字に相当するもので、 16進数下2桁がそのまま対応付けられています。 ASCII文字と対応関係にあるとしても、 まったく別の文字という扱いです。 正規化しても変わりません。

特性

[94] タグ文字正規化で変化しないようです。

[95] タグ文字ASCII文字相当が含まれますが、 大文字小文字関係性は設定されていないようです。 タグ文字が含まれる文字列case foldingタグ文字が変化してはまずいということでしょうか。

[96] Unicode言語タグのようにタグ文字で記述される値が本来 ASCII大文字・小文字不区別のときは、 既存の仕組みによらずに独自に正規化が必要となります。

構文

[36] タグは、 ASCII文字に対応するタグ文字に置き換えて、 先頭にタグ識別文字 (tag identification character) を置きます。 タグ識別文字によってタグ種別 (type) を識別します。 >>13

[37] タグの種別には、言語タグがありました。 将来的には他の種別のタグも追加し、 共存させることが想定されていました >>13

[81] The Unicode Standard は将来的な他の種別のタグを想定した規定が含まれていたものの、 Unicode言語タグ固有の規定と混ざっていて明確な区別はありませんでした。 Unicode言語タグ以外のタグの構文と処理方法は、 ほとんど定められておらず、 先方互換な実装は困難でした。

[85] タグは、 言語タグか、 全取り消しタグです。 >>13

[89] タグ
  1. |
    1. 言語タグ
    2. 全取り消しタグ

[38] タグは、 次の非タグ文字タグ識別文字の直前まで続くものとされ、 終端を表す特別な印はありませんでした。 タグ引数 (tag-argument) は、 1文字以上タグ文字です。 >>13

[91] タグ引数
  1. +
    1. タグ文字

[49] U+E007F CANCEL TAG (tag-cancel) は、 タグの効果を取り消すものです。 これを使うと文字列を連結するときに、 前の文字列タグが後の文字列に波及することを防げます >>13

[50] 意外なことにタグのない「素の状態」に戻すことが主に想定された用途ではなかったようです。 HTMLXML には lang="" (空文字列) のような構文が後に追加されたのですが、 確かに IETF言語タグ自体にはそのような構文がないことから想像されるように、 当時はその必要性があまり意識されていなかったのでしょう。
[92] 全取り消しタグ
  1. U+E007F

[86] タグが現れていないのに取り消しタグが出現することや、 取り消しタグが出現した後に再び取り消しタグが出現することが認められるのかどうか、 明言はされていません。 取り消しタグの趣旨 (>>49) によれば、それも認められていたと解するべきでしょうか。


[43] タグの効果は、

... まで継続します。 >>13

[72] つまりタグの効果は応用依存で、 応用を知らずに正しく処理することができません。

[46] 同じ種別のタグが現れると、 それ以前の同じ種別のタグの効果はそこで終わります。 同じ種別のタグ入れ子にすることはできません。 >>13

[48] 違う種別のタグは独立した状態を持ちます。 別の種別のタグが現れたからといって効果が取り消されたり変更されたりはしません。 つまりタグの適用範囲が包含関係になっているとは限りません。 >>13

レンダリング

[60] タグ文字自体は、 通常のテキストでの視覚的レンダリングを持ちません。 >>13

[62] デバッグその他のタグが可視化される操作では、 タグ文字を相当する ASCII文字グリフで (おそらくは体系的な変化を加えて通常の ASCII文字と区別できる形にして) 表示するのがよいです (advisable) >>13

[64] そんな気の利いたデバッグツールが実在するのかは不明。

[63] しかしタグ文字符号位置は、 そうした表示上の措置のないほとんどのデバッグ器でも、 解釈可能であるように選ばれました。 >>13

[65] だそうですか、つまり符号位置の16進下4桁が ASCII文字と一致することを言いたいのでしょう。 ASCII文字16進数くらい暗記してるでしょということでしょうかw (まあ多少の経験を積んだ技術者なら実際それくらい覚えてきますけどwww)

処理

[20] タグ文字を使うと、 ASCII文字タグを 本来のASCII文字とは別に区別した符号位置で表現できます。 タグ文字はタグとしか使わないので、 実装はタグ文字を使ったり、 無視したりする処理を簡単に記述できます >>13

[21] ・・・と当初は説明されており、未だそのまま残されているのですが、 絵文字の記述に流用されてしまったので、 タグ文字は通常のテキスト内容としても使われるようになってしまい、 それほど簡単ではなくなりました。

[74] Unicode への適合性に関して、 適合処理タグ文字を解釈しなければならないということはありません。 >>13

[78] 応用タグ文字を解釈しない場合には、 そのまま変えずにおいておき、 他の解釈しない文字と同じように扱うべき (should) です。 >>13

[54] Unicode言語タグは使用するべきではないとされますが (>>53)、 使わなければならない場合には、 The Unicode Standard に列挙された実装上の諸問題を検討して、 完全に対応していないタグをどう扱うかを決めるべき (should) です。 >>13

[66] テキスト逐次アクセスは普通です。 言語情報が不要な操作なら、ただ無視するべき (should) です。 一方ランダムアクセスは厄介で、 テキストの現在の状態は直前のタグまで (もしかすると先頭まで) 戻らないと確定できません。 >>13

[67] The Unicode Standard は、そういう例外はあってもテキスト編集しないならタグによってそう難しいことにはならない >>13、 としていました。 (この1点だけで十分難しい事態なようですが...)

[68] タグは状態を持ちますので、 テキストの変更は複雑になります。 変更する際にはタグの開始と終了の状態を注意して適切に操作しなければなりません。 対応していない編集プログラムでは利用者が意図しないでテキストを容易に壊してしまいます。 >>13

[69] タグを解釈しないプログラムであっても、 タグを壊す編集操作や、 組になっていないタグを放置する編集操作は認めるべきではありません (should not) 。 組になっていないタグは、 送信や保存の操作の前に捨てるべき (should) です。 >>13

[70] Unicode言語タグを無視しない実装は、 不正なタグの受信に備えなければなりません。 不正なタグや組になっていないタグを受信したら、 Unicode言語タグなし (NONE) にリセットしてタグを無視するべきです。 >>13


[58] タグ文字自体は、 line breaking, character shaping, character joining, その他の format or layout properties に影響しません。 タグを解釈する処理は、 タグ値をそうした処理に影響させても構いません。 >>13

言語タグ

[30] 言語タグ識別文字 (language tag identification character) U+E0001 LANGUAGE TAG (language-tag-introducer) は、 タグ文字列言語タグであると識別します。 言語タグ (language tag) は、 U+E0001 から始まるタグです。 >>13

[90] 言語タグ
  1. U+E0001
  2. |
    1. 言語タグ引数
    2. U+E007F

[39] 言語タグのタグ (value) language-tag-arg は、 タグ引数です。 BCP 47IETF言語タグであって、 登録されたタグか、 x- から始まる利用者定義のタグのみを用います。 IETF言語タグASCII文字列ですが、 これをタグ文字によって表記します。 >>13

[29] IETF言語タグの仕様として、 RFC の改訂を反映して RFC 1766 >>1RFC 3066 (or its successors) >>27RFC 4646 (or its successors)、 BCP 47 >>13 と参照先が変わっていきました。

[31] 実は改訂のたびに細部が少しずつ変わっていて、 非互換変更も含まれていました。 IETF言語タグ しかし The Unicode Standard は参照先を変更しただけで、 内容の変化に応じた規定内容の変更までは行っていないようです。

[40] 登録されたタグまたは x- という限定は RFC 2482 時代から変わっていませんが、 登録の考え方は歴代 IETF言語タグ仕様で少しずつ違っていますが、 それも規定に反映されていません。 それが想定通りなのか、 それとも誰も使っていないのでいちいちチェックしていないものなのか。

[41] IETF言語タグ大文字・小文字不区別ですので、 小文字タグ文字を使うことが推奨 (recommended) されます。 >>13 明記されていませんが、 処理側は IETF言語タグと同じく Unicode言語タグ大文字・小文字不区別で対応しなければならないということでしょう。 なおこの推奨は、 BCP 47 側の推奨される表記法とは一致していません。

[93] Unicode言語タグとしての構文は、 ただ単に1文字以上タグ文字とされており、 IETF言語タグの構文は組み込まれていません。 まず Unicode言語タグとして構文を解釈してタグ引数を取り出した上で、 それが更に IETF言語タグとして構文的に正しいかどうかを見ることになります。 IETF言語タグとしての構文的な正しさ如何は、 Unicodeタグの埋め込みの構造の決定には関与しないということでしょう。


[87] 既にタグ文字で記述されたのと同じIETF言語タグUnicode言語タグが重ねて記述されることが認められているのかどうか、 明言はされていません。特に禁止されていないのなら、 認められていると解するべきでしょうか。 その場合は特に効果はないと解するべきでしょうか。

[88] 言語情報によって違う処理を適用する場合、 Unicode言語タグの指定を境界とみなして、 そこで分割してそれぞれの部分文字列に対してその処理を適用しようと考えるかもしれません。 Unicode言語タグが毎回必ず異なる IETF言語タグを指定してあるとすればそれでいいのですが、 同じIETF言語タグが指定されているのにそこで分割してしまうと、 分割しないで処理を適用した場合と違う結果になるおそれがあります。

[32] 言語タグ識別文字およびそれを使った言語タグ付けの仕組みは、 非推奨 (deprecated) で、 使うべきではありません (should not) 。 とりわけ言語タグ付けの手段を他に用意しているプロトコルでは、 使うべきではありません。 HTMLXML のような、 マーク付けによって言語タグ付けを行う上位層プロトコルの利用が推奨 (recommended) されます。 >>13

[33] 平文に対する言語情報の埋め込みの要件はしばしば過大評価されるのであって、 マーク付けその他リッチテキストの仕組みが best current practice なのであります。 >>13The Unicode Standard は釈明しています。

[34] 現状マーク付け言語を使うのが最善なのは疑いありませんが、 それは Unicode言語タグの仕組みが酷いだけで、 言語情報の記述の要求の重要度にすり替えて正当化に走るのはいかがなものでしょう。

[35] Unicode言語タグは、 CJK統合漢字に代表される Unicode の強引な文字の統合への批判が Unicode そのものへの強い反発として現れていた時代の産物でした。

[79] なお、 整形式タグが現れたからといって、 正しくタグ付けされているとは限りません。 例えばフランス語を誤ってスペイン語とタグ付けしているかもしれません。 >>13

文脈

[3] Unicode言語タグは、 テキストの言語情報の記述方法の大本命とまで目されたほどの提案でしたが、 ほとんど誰にも使われず、大失敗に終わりました。

[14] U+E0001 LANGUAGE TAG は、 非推奨 (deprecated) であり、避けるべき (should) です。 Unicode言語タグpaired stateful controls ですが、 テキストの編集操作で壊れがちな問題が指摘されています (>>68)。 >>12

[53] Unicode言語タグは、 言語情報が必須であって、 受信者がタグを適切に認識し維持すると分かっている場合を除き、 平文では避けるべき (should) です。 追加の実装コストがあるからです。 >>13

[55] 上位層プロトコル言語情報を記述できるときは、 Unicode言語タグは避けるべき (should) です。 それによって両者の不整合を防げます。 >>13

[56] 2つ (以上) の記述方法がある以上、実装は不整合があっても何らかの対応を強いられるわけですが、 いかに処理するか Unicode では規定されていませんし、 上位層プロトコルで規定したものがあるのかは不明です (The Unicode Standardunicode-xml のように使うべきではない、と言っているだけの仕様書はありますが)。 誰もUnicode言語タグを使っていないので、 実世界では問題になっていません。

[5] MIME では、文字コードによって埋め込んだ言語の指定の方が MIME での符号化語での指定よりも柔軟であるとして、将来定義された際には文字コードによる指定を使うべきとしていました。 >>4

[7] 一方 The Unicode Standard は、 MIME など (と具体例の1つに敢えて挙げて) 上位層プロトコル言語情報の指定の仕組みがあるときは、 そちらを指定するべきとしていました。 >>13

[8] The Unicode StandardMIME と言っていたのは Content-Language: ヘッダーを指していたのでしょうか、 そちらは実体全体の言語情報を記述できるのに過ぎず、 Unicode言語タグの代わりには不十分です。

[73] Unicode言語タグが失敗に終わった以上、やはり符号化語では MIME 側の仕組みで記述するしかありません。


[98] ISO 2022 wchar_t encoding という提案でUnicode言語タグを使う案も示されていましたが、 とても実装可能なものだったとは思えません。

レンダリング

[61] Unicode言語タグ自体は表示されません。 >>13

[57] Unicode言語タグに対応した実装は、 hyphenationフォント選択のような特殊処理でUnicode言語タグ言語情報を考慮する必要があるかもしれません。 >>13

[59] それを「特殊処理」と呼ぶあたりに、当時の Unicode 関係者の認識がうかがえます。

処理

[75] 適合処理Unicode言語タグを解釈する場合は Unicode の規定に従うべき (should) ですが。 ある言語であるとタグ付けされているからといって、 テキストをいかに解釈するかには、 特に要件は定められておりません。 >>13

[76] 実装はタグ文字を解釈しなくても構いません (>>74)。 HTML のような上位層プロトコル言語情報の記述があるときは、 タグ文字を無視することが明示的に認められています >>13

[77] つまり Unicode言語タグ相互運用性はまったく保証されません。 この意味でも Unicode言語タグは使うべきではありません。

関連

[42] HTMLタグとは無関係。

歴史

[24] タグ文字Unicode言語タグの記述のために導入されました。 Unicode言語タグの定義はなぜか IETF情報提供RFC である RFC 2482 としてに出版されました >>1

[25] I-D 起草当時既に Unicode Consortium は承認済で、 ISO 側の承認待ち状態でした >>23, >>1RFCIESG 通過当時は WG2 承認済で >>1ISO/IEC 10646 に追加されるのは時間の問題でした。

[26] The Unicode Standard とは別に RFC 化する必然性は見いだせないのですが、 IETF言語タグを使っていることもあって、 IETF 方面での普及のための宣伝を兼ねていたのでしょうか。 この後タグ文字が追加された Unicode 3.1Unicode ConsortiumWebサイトで公開されることになるのですが、 RFC が参照する Unicode 2.0 やその次の Unicode 3.0 はまだ紙で出版されていました。 インターネットで広く情報を公開するという意味もあったのでしょう。

[80] RFC 2482 はしばらく (Unicode が改版されても) 放置されていましたが、 Unicode言語タグの失敗が認められた後、 に出版された RFC 6082 によって歴史的とされ >>2RFC として事実上廃止されました。

[28] Unicode 3.1 で正式に Unicodeタグ文字Unicode言語タグが追加されました。 仕様書の内容は RFC と大筋に於いて同じでした。 (その後の The Unicode Standard でも大枠は変わっていません。)

[18] ISO/IEC 10646TAGSUnicodeTags と同じ範囲を表しています。

[6] タグ文字は、 ASCII文字一式と同じものを別の符号位置に割り当てて特殊なものとして扱うという、 大変奇抜な仕組みでした。

[97] RFC 2244 - ACAP -- Application Configuration Access Protocol, , https://tools.ietf.org/html/rfc2244#page-62

[11] その後タグ文字絵文字に再利用されるとかいうまさかの復活w

[99] Aprotool TM tips collection, , http://hp.vector.co.jp/authors/VA002891/APROTIPS.HTM

[100] Aprotool TM Editor は付属ドキュメントによると Unicode LangTag >>99 と称してUnicode言語タグ入り Unicode (UTF-16BE, UTF-16LE, UTF-8) の読み書きに対応していたそうです。 ISO 2022, ESC:, TRONコードに対応していて、 「言語」 を相互変換できたようです。

[101] 厳密には Unicode自然言語ISO 2022符号化文字集合ESC:WindowsコードページTRONコードは言語の面 (自然言語に対応しているが実質は ISO 2022符号化文字集合に近い) と意味の違ったものが対応付けられていたようです。

[102] >>99 で配布されている実ファイルによると「言語」切り替え以外に行頭にもUnicode言語タグを出力しているようです。 行指向処理の便宜でしょう。

[103] Unicodeの最新動向, , https://web.archive.org/web/20010708150922/http://www.jagat.or.jp/story_memo_view.asp?StoryID=563

タグとは14面を使って文字ではなく制御コードを決めようというものである。現在,言語指定タグ,ルビタグ,異体字タグが提案されているが,いずれも詳細は未定である。

言語指定タグはテキストが何語かという情報をコードとして埋め込もうというものである。しかし,Unicodeはそもそも文字コードであり,言語はHTMLのタグや文書フォーマットの上位の指定でやるべきだという批判が強い。

ルビタグは言語タグよりももっと批判が多い。これはその名の通り,日本語で読みを小さい文字で書くいわゆるルビをコードとして埋め込もうというものである。日本からの代表は猛烈に反対しているが,通りそうな状況だという。

異体字タグ(Variant Tag)は賛成意見が多い。Super CJKで増やす漢字には異体字が含まれる。これらを一列に並べて別の字とするのではなく,異体字を横に並べるというのが異体字タグである。すべての文字にコードを割り振るのではなく,異体字を含むある文字の集合を一つのコードで表し,異体字をその1番,2番,3番と並べるのである。こうすれば新たなコードは不要で,現在の16面までのコードスペースで処理できる。 (テキスト&グラフィックス研究会) (JAGATinfo 1999年8月号より)