[105] Unicode のタグ文字は、 Unicode 独特の特殊な意味を持つ文字群です。

仕様書

意味

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

符号位置

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

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

特性

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

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

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

[149] ETS では一応大文字と小文字が構文上認められてはいるものの、 現在利用されている範囲ではすべて小文字だけ使うと定められています。

構文

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

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

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

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

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

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

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

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

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

[138] タグが現れた後、タグ以外の文字が出現することなく次のタグが現れるというものは、 認められるとも認められるとも特に記述がありません。普通に解釈すれば認められるということです。

[139] 例えば「{日本語}{日本語}abc」のような意味のない日本語の指定は禁止されていません。

[140] 例えば「{日本語}{タイ語}abc」のような意味のない日本語の指定は禁止されていません。

[141] 例えば「{日本語}{取消}abc」のような意味のない日本語]の指定は禁止されていません。

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

[142] 例えば「{日本語}abc{取消}{取消}abc」のような意味のない取消し指定は禁止されていません。

[143] 例えば「{取消}abc」のような意味のない取消し指定は禁止されていません。

[43] タグの効果は、

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

[72] つまりタグの効果は応用依存で、 応用を知らずに正しく処理することができません。 [112] 特定の応用でだけ使うなら応用依存の方法で言語情報を記述すればよいわけで (それが推奨される方法でもあるわけで)、そうではない、 特定の応用に紐付かない平文のような場面でこそUnicode言語タグは有用なはずなのに、 応用依存だと放り投げることでその有用性を自ら毀損しているような。。。

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

[113] HTML の要素の lang="" 属性のように終了タグの続きでは親の言語情報に復帰したりすることが Unicode言語タグでは起こらないということです。

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

[131] この「goto型」の状態制御は、先頭から順に表示していくだけの超古典的な処理には実装しやすいのでしょうが、 様々な文字列処理が必要な現代的な用途にはとても使いにくいものです。

[132] 例えば「{日本語}漢漢」という文字列の見かけ上の2文字目に「{台湾華語}漢」 を挿入したいとします。

[133] そのまま普通に実行すると 「{日本語}漢{台湾華語}漢漢」になってしまい、 見かけ上の3文字目が日本語から台湾華語に変わってしまいます。

[134] そこで U+E007F を使って取消したくなりますが、それだと 「{日本語}漢{台湾華語}漢{取消}漢」になってしまい、 見かけ上の3文字目は日本語から「言語なし」に変わるので問題は解決していません。

[135] 正しく 「{日本語}漢{台湾華語}漢{日本語}漢」 にするには挿入位置の言語を直近のタグまで遡って調べて、挿入位置の後ろに新たに挿入しなおす、 という面倒な処理が必要になります。

[136] HTML のような木構造に言語タグを付与するタイプや、 bidi の制御文字のように 「push/pop型」 で 「{日本語}漢{台湾華語}漢{pop}漢」 と表せるなら幾分楽になったでしょうに。

[145] ここまでの伝統的な用法の他に、 ETS 構文があります (>>146)。

レンダリング

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

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

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

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

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

[148] ETS については別途の規定があります。

処理

[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

[114] Firefox も Chrome も、

一󠀁󠁪󠁡󠁿

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

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

[39] 言語タグのタグ値value 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] 実は改訂のたびに細部が少しずつ変わっていて、 非互換変更も含まれていました。 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。 とりわけ言語タグ付けの手段を他に用意しているプロトコルでは、 使うべきではありません。 HTML や XML のような、 マーク付けによって言語タグ付けを行う上位層プロトコルの利用が推奨recommendedされます。 >>13

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

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

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

[109] 実際そのような批判には過剰で行き過ぎた要件を主張するものもあったようですから、 Unicode 側の釈明にも酌量の余地はあるのですが、 だからといって文化的多様性を軽視する Unicode 側関係者の態度 (e.g. CJK統合漢字 ) もどうかと思われます。 「細かな表示の違いは言語情報で切り替えればいい」と言っておきながら 「言語情報は平文にはいらない」で済ませるのは実に無責任。

[110] 自分達のアーキテクチャーと経済的利益を守るために自分達が扱っている対象の文化的特性を軽視する態度欧米中心主義は非難されても仕方がありません。

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

文脈

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

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

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

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

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

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

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

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

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

  • [4] RFC 2231 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations ( 版) https://tools.ietf.org/html/rfc2231#section-8

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

[106] 正しい Unicode の文字のレンダリングには言語情報が必須ですが、 各種の文書形式やプロトコルの文字列データ型は必ずしも言語情報を記述できません。 消去法的にUnicode言語タグでしか記述のしようがないのですが、 Unicode言語タグで記述したところで正常に扱える実装なんてありません。

[108] いわゆる中華フォント問題のような形で一般利用者に意識される形で問題になってしまっています。

[107] 階層化された技術の境界面に当たる部分がうまく接続されず、誰も責任を持って技術設計しないために破綻するアンチパターンの好(?)例の1つです。

[111] もっと仕様を簡素にしていればちゃんと実装されて使われる道もあったんじゃないですかねえ。 bidi 系の制御の文字は複雑で厄介なのに何だかんだ実装されてるわけで。

レンダリング

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

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

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

処理

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

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

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

Unicode LangTag 形式

[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言語タグを出力しているようです。 行指向処理の便宜でしょう。

言語タグサンドイッチ列

[150] 言語タグサンドイッチ列language tag sandwich sequenceは、 言語タグを異体選択子の代替として使うものです。

[151] 言語タグサンドイッチ列は、 基底文字と省略可能な異体選択子を、 同一のUnicode言語タグで囲み、 U+E007F で終わるものです。

言語タグサンドイッチ列
  1. 言語タグ
  2. 基底文字
  3. ?
    1. 異体選択子
  4. 言語タグ
  5. U+E007F

[152] ここで、前後の言語タグは同じものとします。また、 U+E007F を含まないものとします。 更に、大文字は使わないものとします。

[153] CJK言語タグサンドイッチ列CJK language tag sandwich sequenceは、 言語タグサンドイッチ列のうち、

であるものであり、次の表によってその意味が定まります。

l
言語タグの2文字目以降に相当する ASCII文字
s
意味
l
zh-cn
s
C 字形
l
zh-hk
s
H 字形
l
zh-mo
s
M 字形
l
zh-tw
s
T 字形
l
ja
s
J 字形
l
ko-kr
s
K 字形
l
ko-kp
s
KR 字形
l
vi
s
V 字形
l
zh-gb
s
UK 字形
l
lzh
s
S 字形
l
und
s
U 字形
l
mul
s
UCS2003 字形

[157] CJK言語タグサンドイッチ列は、その意味に示された The Unicode Standard の代表字形に典型的に表されるグリフ的部分集合を表します。 必ずしもその代表字形を使って実装される必要はありません。

[158] また、 The Unicode Standard に代表字形が明記されていないからといって、 そのUnicode符号点に関するCJK言語タグサンドイッチ列が使えないということもありません。

[159] 例えば G 字形は GB 18030 規格票により、 T 字形は CNS 11643 の 規格票等により、 The Unicode Standard に掲載されていなくても例示字形を確認でき(ることがあり)ます。

[160] J 字形は仮想J字形のようなコミュニティー標準を参照できます。

[172] ただし、 UCS2003 字形は過去の The Unicode Standard と ISO/IEC 10646 の規格票以外に依るべきものがないので、 それが存在しないUnicode符号点では使うべきではありません。

[161] The Unicode Standard に示された代表字形や関連国内規格等の例示字形や包摂規準は、 各規格等の版によって変化することがあります。 CJK言語タグサンドイッチ列はそれらの特定の版を指し示すものではなく、 従って各規格等の変更によってその意味が変化する可能性があります。

[170] IVS で記述可能なものは、CJK言語タグサンドイッチ列を使うべきではありません。

[171] 出典Jが文字情報基盤で、それと同じMJ文字図形の IVS がある場合は、 IVS を使うべきです。

[173] CJK言語タグサンドイッチ列以外にも次のようなものの表現方法が検討されるべきでしょう。

[162] 言語タグサンドイッチ列は、次の要件を満たすものとして設計されています。

[191] 本当は満たしたかった次の要件は、他の要件と同時に満たすのが困難なため断念しています。

[179] CJK言語タグサンドイッチ列の OpenType は、 次のように実装するべきです。

[186] このフォントファイルを参照する CSS @font-face 規則の unicode-range は、

とし、 Chrome と Firefox で使い分ける必要があります。

ETS

[146] 絵文字タグ列emoji tag sequence (ETS) は、 絵文字の構文の一種です。 >>9, >>10

[147] 現在 ETS は国旗絵文字に類する地方旗の表記のための構文のみ定められていて、 他の用途には使われていません。

[200] 🏴󠁧󠁢󠁳󠁣󠁴󠁿 (スコットランド)

関連

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

[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)

[199] Google won’t fix new ASCII smuggling attack in Gemini, , https://www.bleepingcomputer.com/news/security/google-wont-fix-new-ascii-smuggling-attack-in-gemini/

The researcher reported the findings to Google on September 18 but the tech giant dismissed the issue as not being a security bug and may only be exploited in the context of social engineering attacks.