[105] Unicode のタグ文字は、 Unicode 独特の特殊な意味を持つ文字群です。
[19] タグ文字のほとんど、 ASCII文字に相当するものを別の符号位置に割当て、 特殊用としたものです。 タグ文字を使うと、 ASCII ベースの文字列のタグを、 Unicode の通常の文字で記述したテキスト内容とは区別した形で埋め込むことが出来ます >>13。
[15]
タグ文字は、
U+E0000 - U+E007F
です。この範囲の
Tags
ブロック内に、
既に97文字が割り当てられています。
>>13
残りは未割当符号位置です。
[22]
U+E0020 - U+E007E
の95文字は、
ASCII文字 U+0020 - U+007E
の95文字に相当するもので、
16進数下2桁がそのまま対応付けられています。
ASCII文字と対応関係にあるとしても、
まったく別の文字という扱いです。
正規化しても変わりません。
[95] タグ文字は ASCII文字相当が含まれますが、 大文字、小文字の関係性は設定されていないようです。 タグ文字が含まれる文字列の case folding でタグ文字が変化してはまずいということでしょうか。
[96] Unicode言語タグのようにタグ文字で記述される値が本来 ASCII大文字・小文字不区別のときは、 既存の仕組みによらずに独自に正規化が必要となります。
[149] ETS では一応大文字と小文字が構文上認められてはいるものの、 現在利用されている範囲ではすべて小文字だけ使うと定められています。
[36] タグは、 ASCII文字に対応するタグ文字に置き換えて、 先頭にタグ識別文字を置きます。 タグ識別文字によってタグの種別を識別します。 >>13
[37] タグの種別には、言語タグがありました。 将来的には他の種別のタグも追加し、 共存させることが想定されていました >>13。
[81] The Unicode Standard は将来的な他の種別のタグを想定した規定が含まれていたものの、 Unicode言語タグ固有の規定と混ざっていて明確な区別はありませんでした。 Unicode言語タグ以外のタグの構文と処理方法は、 ほとんど定められておらず、 先方互換な実装は困難でした。
Tags ブロックで未割当の
U+E0000, U+E0002 - U+E001F
が使われると予想されますが、明言されていませんでした。[85] タグは、 言語タグか、 全取り消しタグです。 >>13
[38] タグは、 次の非タグ文字かタグ識別文字の直前まで続くものとされ、 終端を表す特別な印はありませんでした。 タグ引数は、 1文字以上のタグ文字です。 >>13
[49]
U+E007F CANCEL TAG
(tag-cancel)
は、
タグの効果を取り消すものです。
これを使うと文字列を連結するときに、
前の文字列のタグが後の文字列に波及することを防げます
>>13。
U+E007F
を使うと、
当該種別のタグ値だけを取り消します。
例えば
<U+E0001, U+E007F>
は、
Unicode言語タグが適用される部分を終了させます。
>>13
現在規定されているのは、
言語タグの取り消しだけです。U+E007F
を単独で使うと、
すべての種別のタグ値を取り消します。
>>13[138] タグが現れた後、タグ以外の文字が出現することなく次のタグが現れるというものは、 認められるとも認められるとも特に記述がありません。普通に解釈すれば認められるということです。
[141] 例えば「{日本語}{取消}abc」のような意味のない日本語]の指定は禁止されていません。
[86] タグが現れていないのに取り消しタグが出現することや、 取り消しタグが出現した後に再び取り消しタグが出現することが認められるのかどうか、 明言はされていません。 取り消しタグの趣旨 (>>49) によれば、それも認められていたと解するべきでしょうか。
[142] 例えば「{日本語}abc{取消}{取消}abc」のような意味のない取消し指定は禁止されていません。
[143] 例えば「{取消}abc」のような意味のない取消し指定は禁止されていません。
U+E007F CANCEL TAG
を使った取り消しの位置... まで継続します。 >>13
[46] 同じ種別のタグが現れると、 それ以前の同じ種別のタグの効果はそこで終わります。 同じ種別のタグを入れ子にすることはできません。 >>13
[48] 違う種別のタグは独立した状態を持ちます。 別の種別のタグが現れたからといって効果が取り消されたり変更されたりはしません。 つまりタグの適用範囲が包含関係になっているとは限りません。 >>13
[131] この「goto型」の状態制御は、先頭から順に表示していくだけの超古典的な処理には実装しやすいのでしょうが、 様々な文字列処理が必要な現代的な用途にはとても使いにくいものです。
[132] 例えば「{日本語}漢漢」という文字列の見かけ上の2文字目に「{台湾華語}漢」 を挿入したいとします。
[133] そのまま普通に実行すると 「{日本語}漢{台湾華語}漢漢」になってしまい、 見かけ上の3文字目が日本語から台湾華語に変わってしまいます。
[134]
そこで U+E007F を使って取消したくなりますが、それだと
「{日本語}漢{台湾華語}漢{取消}漢」になってしまい、
見かけ上の3文字目は日本語から「言語なし」に変わるので問題は解決していません。
[135] 正しく 「{日本語}漢{台湾華語}漢{日本語}漢」 にするには挿入位置の言語を直近のタグまで遡って調べて、挿入位置の後ろに新たに挿入しなおす、 という面倒な処理が必要になります。
[60] タグ文字自体は、 通常のテキストでの視覚的レンダリングを持ちません。 >>13
[62] デバッグその他のタグが可視化される操作では、 タグ文字を相当する ASCII文字のグリフで (おそらくは体系的な変化を加えて通常の ASCII文字と区別できる形にして) 表示するのがよいです。 >>13
[63] しかしタグ文字の符号位置は、 そうした表示上の措置のないほとんどのデバッグ器でも、 解釈可能であるように選ばれました。 >>13
[20] タグ文字を使うと、 ASCII文字のタグを 本来のASCII文字とは別に区別した符号位置で表現できます。 タグ文字はタグとしか使わないので、 実装はタグ文字を使ったり、 無視したりする処理を簡単に記述できます >>13。
[21] ・・・と当初は説明されており、未だそのまま残されているのですが、 絵文字の記述に流用されてしまったので、 タグ文字は通常のテキスト内容としても使われるようになってしまい、 それほど簡単ではなくなりました。
[74] Unicode への適合性に関して、 適合処理はタグ文字を解釈しなければならないということはありません。 >>13
[78] 応用がタグ文字を解釈しない場合には、 そのまま変えずにおいておき、 他の解釈しない文字と同じように扱うべきです。 >>13
[54] Unicode言語タグは使用するべきではないとされますが (>>53)、 使わなければならない場合には、 The Unicode Standard に列挙された実装上の諸問題を検討して、 完全に対応していないタグをどう扱うかを決めるべきです。 >>13
[66] テキストの逐次アクセスは普通です。 言語情報が不要な操作なら、ただ無視するべきです。 一方ランダムアクセスは厄介で、 テキストの現在の状態は直前のタグまで (もしかすると先頭まで) 戻らないと確定できません。 >>13
[68] タグは状態を持ちますので、 テキストの変更は複雑になります。 変更する際にはタグの開始と終了の状態を注意して適切に操作しなければなりません。 対応していない編集プログラムでは利用者が意図しないでテキストを容易に壊してしまいます。 >>13
[69] タグを解釈しないプログラムであっても、 タグを壊す編集操作や、 組になっていないタグを放置する編集操作は認めるべきではありません。 組になっていないタグは、 送信や保存の操作の前に捨てるべきです。 >>13
[70] Unicode言語タグを無視しない実装は、 不正なタグの受信に備えなければなりません。 不正なタグや組になっていないタグを受信したら、 Unicode言語タグをなしにリセットしてタグを無視するべきです。 >>13
[58] タグ文字自体は、 line breaking, character shaping, character joining, その他の format or layout properties に影響しません。 タグを解釈する処理は、 タグ値をそうした処理に影響させても構いません。 >>13
一󠀁󠁪󠁡󠁿
[115] のような文字列を与えると、一は表示しても、
その続きを表示しません。フォントにグリフがあっても、
無視して零幅で表示します。しかし文字列の選択においては
U+E0001 で1文字扱い、残りで1文字扱い2文字扱いします。
なんでこんな変な挙動になるんでしょう。
[116]
Firefox だと一とその後の零幅2文字は選択でもその通りの動きをします。
Chrome も普通のフォントだとそうですが、
一とその続きが GSUB で処理対象になっていると、
一とその続きがその字形を3等分するような選択の挙動に変わります。
(GSUB のグリフ置換が起こらない場合であってもです。
同じフォントに含まれ処理対象になるかどうかが影響するのでしょうか。)
(Firefox にはこの挙動はありません。)
[117]
Chrome のこの挙動、一より前にタグ文字がある場合も一を構成するように分割されます。
(GSUB で一より前に戻り読みしているわけでもないのに。つまり
GSUB で処理される対象になっていることまでが条件で(?)処理対象になっているグリフ列であることまではこの挙動が発生する条件には入っていません。)
[118]
Chrome でも Firefox でも、 タグ文字のグリフは表示されないものの、
GSUB による置き換えには寄与する。グリフの置き換えがあってもタグ文字由来グリフとそれ以外由来グリフはちゃんと追跡されていて、
以外由来グリフが増えたりしても、それらはちゃんと表示され、
タグ文字由来のものはしっかり非表示になる。
寄与するタグ文字がそれ以外の後にある場合も、前にある場合も同じ。
[119]
Chrome も Firefox も、 U+E0001 や U+E007F には GSUB
でグリフを置換することでグリフ表示させることはできる。
他のタグ文字はなぜかこれでもだめ。
[120]
んー >>119 の挙動はもっと複雑で、ただ単にそうしても表示はされなくて、
U+E0001 と U+E0076 に同時に置換を発生させると
U+E0001 だけ表示されるような謎の現象が起こる。
Chrome でも Firefox でも。
[121]
U+E0001 と U+E0076 の両方をグリフID 0
にすると、 Firefox では 0 が1つだけ表示される。これは一貫した挙動。
Chrome ではそれだけ次のフォント候補に fallback して表示する。
[122]
Chrome は GSUB で 0 に置き換えるとその部分の文字列を次のフォント候補で再評価させられる。
次のフォントに GSUB があればそれも適用される。
Firefox だと次のフォント候補には進まない。ここの挙動がやや謎で、
通常の文字は GSUB なしの cmap から決まるグリフになり、
タグ文字は 0 (cmap から決まるグリフでなく) になる。
[123]
>>122 Firefox で cmap から決まるグリフを 0
にしておくと、次のフォント候補に進む。しかしタグ文字が前後にあってもそれは認識されない
(タグ文字は cmap から決まるグリフが 0 ではないから?
それも 0 にすれば結果が変わるのかもしれないが、
そうすると 0 の連続になって GSUB を書くのが困難なんだよな)。
[124]
iPhone の Safari は挙動が全然違って、タグ文字の多く (なぜか全部ではない?)
はグリフが表示されるが GSUB は反映されない。謎が多い。
[125] >>124 GSUB による置換そのものは機能しているらしい。タグ文字が絡むとうまくいかないのか、なんなのか。
[126]
>>125 U+E0001 はグリフがあってもレンダリングされないで次のフォント候補に進み、
それを含む GSUB 置換規則があっても無視されるらしい。他のタグ文字は通常の文字と同じ用にレンダリングと
GSUB の対象になる。しかし U+E0001 も最終的には次のフォントでレンダリングされているわけで、何がいけないのかが謎。
[127]
>>126 GSUB なしで cmap だけのフォントで試してみると普通の文字扱いになるのは
タグ文字の 0-9 と a-z と U+E007F だけ。その他は零幅で字形は表示されるものとされないものと次のフォント候補に行くものがあり、変なところに表示されるものもあってわけがわからない。
[128]
国旗絵文字用なのかとも思うけど - が入ってないんだよなあ
[129] lookup の chained substitution の index の数え方が Firefox = Chrome と Safari で違うっぽい。どっちもどっちでおかしい気がするがどうおかしいのかうまく説明できない。 どっちもなんか変だ。無視される文字のせい、ということでもなさそうでよくわからない。 これ自体はほかのフォントでもよく使われている機能なので、 こんなあからさまな挙動差が放置されてるとも思いづらくタグ文字の特殊事情のような気はするのだが。
[130]
Chrome でも Firefox でも、タグ文字のそれぞれ一部が入ったフォントを
font-family でいくつか指定したとき、最初のフォントが選ばれてしまって次のフォント候補に進まない。
なのでどのタグ文字から始まるかによって違うフォントを選ばせることができない。
cmap で指定されたグリフの有無や
unicode-range
の指定の有無など変えてみてもどうにもならない。どうもフォントの選択でタグ文字のグリフの有無が寄与していないような。
でも
unicode-range がまったく効いていないというわけでもなく、
それが皆無だとそもそもそのフォントが選ばれなかったりもするので、
挙動がよくわからない。
[182]
Chrome でも Firefox でも、基底文字とタグ文字が続くものを GSUB
で置換するものが横書きでは機能していても、縦書きでは機能しません。
グリフを縦に並べる処理が合字化より先に実行されてしまうということでしょうか。
[30]
言語タグ識別文字
U+E0001 LANGUAGE TAG
(language-tag-introducer)
は、
タグ文字列が言語タグであると識別します。
言語タグは、
U+E0001
から始まるタグです。
>>13
[39]
言語タグのタグ値 language-tag-arg は、
タグ引数です。
BCP 47
のIETF言語タグであって、
登録されたタグか、
x-
から始まる利用者定義のタグのみを用います。
IETF言語タグは
ASCII文字列ですが、
これをタグ文字によって表記します。
>>13
[29] IETF言語タグの仕様として、 RFC の改訂を反映して RFC 1766 >>1、 RFC 3066 (or its successors) >>27、 RFC 4646 (or its successors)、 BCP 47 >>13 と参照先が変わっていきました。
[31]
実は改訂のたびに細部が少しずつ変わっていて、
非互換変更も含まれていました。
[40]
登録されたタグまたは x- という限定は
RFC 2482
時代から変わっていませんが、
登録の考え方は歴代
IETF言語タグ仕様で少しずつ違っていますが、
それも規定に反映されていません。
それが想定通りなのか、
それとも誰も使っていないのでいちいちチェックしていないものなのか。
[41] IETF言語タグは大文字・小文字不区別ですので、 小文字のタグ文字を使うことが推奨されます。 >>13 明記されていませんが、 処理側は IETF言語タグと同じく Unicode言語タグも大文字・小文字不区別で対応しなければならないということでしょう。 なおこの推奨は、 BCP 47 側の推奨される表記法とは一致していません。
[93] Unicode言語タグとしての構文は、 ただ単に1文字以上のタグ文字とされており、 IETF言語タグの構文は組み込まれていません。 まず Unicode言語タグとして構文を解釈してタグ引数を取り出した上で、 それが更に IETF言語タグとして構文的に正しいかどうかを見ることになります。 IETF言語タグとしての構文的な正しさ如何は、 Unicode のタグの埋め込みの構造の決定には関与しないということでしょう。
[87] 既にタグ文字で記述されたのと同じIETF言語タグの Unicode言語タグが重ねて記述されることが認められているのかどうか、 明言はされていません。特に禁止されていないのなら、 認められていると解するべきでしょうか。 その場合は特に効果はないと解するべきでしょうか。
[32] 言語タグ識別文字およびそれを使った言語タグ付けの仕組みは、 非推奨で、 使うべきではありません。 とりわけ言語タグ付けの手段を他に用意しているプロトコルでは、 使うべきではありません。 HTML や XML のような、 マーク付けによって言語タグ付けを行う上位層プロトコルの利用が推奨されます。 >>13
[33] 平文に対する言語情報の埋め込みの要件はしばしば過大評価されるのであって、 マーク付けその他リッチテキストの仕組みが best current practice なのであります。 >>13 と The Unicode Standard は釈明しています。
[34] 現状マーク付け言語を使うのが最善なのは疑いありませんが、 それは Unicode言語タグの仕組みが酷いだけで、 言語情報の記述の要求の重要度にすり替えて正当化に走るのはいかがなものでしょう。
[35] Unicode言語タグは、 CJK統合漢字に代表される Unicode の強引な文字の統合への批判が Unicode そのものへの強い反発として現れていた時代の産物でした。
[109]
実際そのような批判には過剰で行き過ぎた要件を主張するものもあったようですから、
Unicode 側の釈明にも酌量の余地はあるのですが、
だからといって文化的多様性を軽視する Unicode 側関係者の態度
(e.g.
[110] 自分達のアーキテクチャーと経済的利益を守るために自分達が扱っている対象の文化的特性を軽視する態度は非難されても仕方がありません。
[79] なお、 整形式タグが現れたからといって、 正しくタグ付けされているとは限りません。 例えばフランス語を誤ってスペイン語とタグ付けしているかもしれません。 >>13
[3] Unicode言語タグは、 テキストの言語情報の記述方法の大本命とまで目されたほどの提案でしたが、 ほとんど誰にも使われず、大失敗に終わりました。
[14]
U+E0001
LANGUAGE TAG
は、
非推奨であり、避けるべきです。
Unicode言語タグは
paired stateful controls
ですが、
テキストの編集操作で壊れがちな問題が指摘されています (>>68)。
>>12
[53] Unicode言語タグは、 言語情報が必須であって、 受信者がタグを適切に認識し維持すると分かっている場合を除き、 平文では避けるべきです。 追加の実装コストがあるからです。 >>13
[55] 上位層プロトコルが言語情報を記述できるときは、 Unicode言語タグは避けるべきです。 それによって両者の不整合を防げます。 >>13
[5] MIME では、文字コードによって埋め込んだ言語の指定の方が MIME での符号化語での指定よりも柔軟であるとして、将来定義された際には文字コードによる指定を使うべきとしていました。 >>4
[7] 一方 The Unicode Standard は、 MIME など (と具体例の1つに敢えて挙げて) 上位層プロトコルに言語情報の指定の仕組みがあるときは、 そちらを指定するべきとしていました。 >>13
[8]
The Unicode Standard
が
MIME
と言っていたのは
Content-Language:
ヘッダーを指していたのでしょうか、
そちらは実体全体の言語情報を記述できるのに過ぎず、
Unicode言語タグの代わりには不十分です。
[73] Unicode言語タグが失敗に終わった以上、やはり符号化語では MIME 側の仕組みで記述するしかありません。
[98] ISO 2022 wchar_t encoding という提案でUnicode言語タグを使う案も示されていましたが、 とても実装可能なものだったとは思えません。
[106] 正しい Unicode の文字のレンダリングには言語情報が必須ですが、 各種の文書形式やプロトコルの文字列データ型は必ずしも言語情報を記述できません。 消去法的にUnicode言語タグでしか記述のしようがないのですが、 Unicode言語タグで記述したところで正常に扱える実装なんてありません。
[107] 階層化された技術の境界面に当たる部分がうまく接続されず、誰も責任を持って技術設計しないために破綻するアンチパターンの好(?)例の1つです。
[111] もっと仕様を簡素にしていればちゃんと実装されて使われる道もあったんじゃないですかねえ。 bidi 系の制御の文字は複雑で厄介なのに何だかんだ実装されてるわけで。
[61] Unicode言語タグ自体は表示されません。 >>13
[57] Unicode言語タグに対応した実装は、 hyphenation やフォント選択のような特殊処理でUnicode言語タグの言語情報を考慮する必要があるかもしれません。 >>13
[75] 適合処理がUnicode言語タグを解釈する場合は Unicode の規定に従うべきですが。 ある言語であるとタグ付けされているからといって、 テキストをいかに解釈するかには、 特に要件は定められておりません。 >>13
[76] 実装はタグ文字を解釈しなくても構いません (>>74)。 HTML のような上位層プロトコルの言語情報の記述があるときは、 タグ文字を無視することが明示的に認められています >>13。
[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コードに対応していて、 「言語」 を相互変換できたようです。
[102] >>99 で配布されている実ファイルによると「言語」切り替え以外に行頭にもUnicode言語タグを出力しているようです。 行指向処理の便宜でしょう。
[150] 言語タグサンドイッチ列は、 言語タグを異体選択子の代替として使うものです。
[151]
言語タグサンドイッチ列は、
基底文字と省略可能な異体選択子を、
同一のUnicode言語タグで囲み、
U+E007F
で終わるものです。
[152] ここで、前後の言語タグは同じものとします。また、 U+E007F
を含まないものとします。 更に、大文字は使わないものとします。
[153] CJK言語タグサンドイッチ列は、 言語タグサンドイッチ列のうち、
であるものであり、次の表によってその意味が定まります。
[157] CJK言語タグサンドイッチ列は、その意味に示された The Unicode Standard の代表字形に典型的に表されるグリフ的部分集合を表します。 必ずしもその代表字形を使って実装される必要はありません。
[158] また、 The Unicode Standard に代表字形が明記されていないからといって、 そのUnicode符号点に関するCJK言語タグサンドイッチ列が使えないということもありません。
[159] 例えば G 字形は GB 18030 規格票により、 T 字形は CNS 11643 の 規格票等により、 The Unicode Standard に掲載されていなくても例示字形を確認でき(ることがあり)ます。
[172] ただし、 UCS2003 字形は過去の The Unicode Standard と ISO/IEC 10646 の規格票以外に依るべきものがないので、 それが存在しないUnicode符号点では使うべきではありません。
[161] The Unicode Standard に示された代表字形や関連国内規格等の例示字形や包摂規準は、 各規格等の版によって変化することがあります。 CJK言語タグサンドイッチ列はそれらの特定の版を指し示すものではなく、 従って各規格等の変更によってその意味が変化する可能性があります。
[170] IVS で記述可能なものは、CJK言語タグサンドイッチ列を使うべきではありません。
[173] CJK言語タグサンドイッチ列以外にも次のようなものの表現方法が検討されるべきでしょう。
[162] 言語タグサンドイッチ列は、次の要件を満たすものとして設計されています。
[191] 本当は満たしたかった次の要件は、他の要件と同時に満たすのが困難なため断念しています。
[179] CJK言語タグサンドイッチ列の OpenType は、 次のように実装するべきです。
U+E007F のグリフ、がこの順で並ぶグリフ列を、
GSUB の DFLT (および他の適当な言語系) における
ccmp によって、
基底文字のグリフのかわりにCJK言語タグサンドイッチ列が表すグリフが表示されるようにします。GSUB の DFLT (および他の適当な言語系) における
ss20 によって、
U+E0001 の通常のグリフのかわりにCJK言語タグサンドイッチ列の先頭を表す図形を、
U+E007F の通常のグリフのかわりにCJK言語タグサンドイッチ列の末尾を表す図形を、
表示されるようにします。
ただしここで、CJK言語タグサンドイッチ列の2つ目の U+E0001
にはこれを適用しません。[186]
このフォントファイルを参照する CSS @font-face 規則の
unicode-range は、
U+E0000-E007F を含むU+E0000-E007F を含まない[146] 絵文字タグ列 (ETS) は、 絵文字の構文の一種です。 >>9, >>10
[147] 現在 ETS は国旗絵文字に類する地方旗の表記のための構文のみ定められていて、 他の用途には使われていません。
[104] Unicode言語識別子は別物です。
[144]
Java 方面では -u- のことを追加のUnicode言語タグ拡張機能などと呼んでいるようで。
この呼称は Unicode言語タグと紛らわしいので、避けるべきです。
-u- は Unicode言語タグとは独立した概念です。
Unicode言語タグを使うときに -u- を指定することはできますが、
有意義かどうかは不明です。
[24] タグ文字は Unicode言語タグの記述のために導入されました。 Unicode言語タグの定義はなぜか IETF の情報提供RFC である RFC 2482 としてに出版されました >>1。
[25] I-D 起草当時既に Unicode Consortium は承認済で、 ISO 側の承認待ち状態でした >>23, >>1。 RFC の IESG 通過当時は WG2 承認済で >>1、 ISO/IEC 10646 に追加されるのは時間の問題でした。
[26] The Unicode Standard とは別に RFC 化する必然性は見いだせないのですが、 IETF言語タグを使っていることもあって、 IETF 方面での普及のための宣伝を兼ねていたのでしょうか。 この後タグ文字が追加された Unicode 3.1 が Unicode Consortium の Webサイトで公開されることになるのですが、 RFC が参照する Unicode 2.0 やその次の Unicode 3.0 はまだ紙で出版されていました。 インターネットで広く情報を公開するという意味もあったのでしょう。
[80] RFC 2482 はしばらく (Unicode が改版されても) 放置されていましたが、 Unicode言語タグの失敗が認められた後、 に出版された RFC 6082 によって歴史的とされ >>2、 RFC として事実上廃止されました。
[28] Unicode 3.1 で正式に Unicode にタグ文字とUnicode言語タグが追加されました。 仕様書の内容は RFC と大筋に於いて同じでした。 (その後の The Unicode Standard でも大枠は変わっていません。)
[18]
ISO/IEC 10646
の
TAGS
は
Unicode
の
Tags
と同じ範囲を表しています。
[6] タグ文字は、 ASCII文字一式と同じものを別の符号位置に割り当てて特殊なものとして扱うという、 大変奇抜な仕組みでした。
[97] RFC 2244 - ACAP -- Application Configuration Access Protocol, , https://tools.ietf.org/html/rfc2244#page-62
[11] その後タグ文字は絵文字に再利用されるとかいうまさかの復活w
[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月号より)
[137] タグ (Unicode) ‐ 通信用語の基礎知識, https://www.wdic.org/w/WDIC/%E3%82%BF%E3%82%B0%20(Unicode)
lang=""(空文字列) のような構文が後に追加されたのですが、 確かに IETF言語タグ自体にはそのような構文がないことから想像されるように、 当時はその必要性があまり意識されていなかったのでしょう。