[105] [[Unicode]] の[DFN[タグ文字]]は、 [[Unicode]] 独特の特殊な意味を持つ[[文字]]群です。 * 仕様書 [REFS[ - [12] [CITE[[[The Unicode Standard]], Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-13T07:28:31.667Z]] - [13] [CITE[[[The Unicode Standard]], Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-18T09:45:06.805Z]] ]REFS] * 意味 [19] [[タグ文字]]のほとんど、 [[ASCII文字]]に相当するものを別の[[符号位置]]に割当て、 特殊用としたものです。 [[タグ文字]]を使うと、 [[ASCII]] ベースの[[文字列]]のタグを、 [[Unicode]] の通常の文字で記述したテキスト内容とは区別した形で埋め込むことが出来ます [SRC[>>13]]。 * 符号位置 [15] [DFN[[RUBYB[[[タグ文字]]][tag character]]]]は、 [DFN[[CODE[U+E0000]]]] - [DFN[[CODE[U+E007F]]]] です。この範囲の [DFN[Tags]] [[ブロック]]内に、 既に97文字が割り当てられています。 [SRC[>>13]] 残りは[[未割当符号位置]]です。 [22] [DFN[[CC[U+E0020]]]] - [DFN[[CC[U+E007E]]]] の95文字は、 [[ASCII文字]] [CC[U+0020]] - [CC[U+007E]] の95文字に相当するもので、 16進数下2桁がそのまま対応付けられています。 [[ASCII文字]]と対応関係にあるとしても、 まったく別の[[文字]]という扱いです。 [[正規化]]しても変わりません。 [REFS[ - [16] [CODE[Tags]] [[ブロック]] ]REFS] * 特性 [94] [[タグ文字]]は[[正規化]]で変化しないようです。 [95] [[タグ文字]]は [[ASCII文字]]相当が含まれますが、 [[大文字]]、[[小文字]]の[[関係性][case folding]]は設定されていないようです。 [[タグ文字]]が含まれる[[文字列]]の [[case folding]] で[[タグ文字]]が変化してはまずいということでしょうか。 [96] [[Unicode言語タグ]]のように[[タグ文字]]で記述される値が本来 [[ASCII大文字・小文字不区別]]のときは、 既存の仕組みによらずに独自に正規化が必要となります。 [149] [[ETS]] では一応[[大文字]]と[[小文字]]が構文上認められてはいるものの、 現在利用されている範囲ではすべて[[小文字]]だけ使うと定められています。 * 構文 [36] [[タグ]]は、 [[ASCII文字]]に対応する[[タグ文字]]に置き換えて、 先頭に[DFN[[RUBYB[タグ識別文字][tag identification character]]]]を置きます。 [[タグ識別文字]]によって[[タグ]]の[RUBYB[種別][type]]を識別します。 [SRC[>>13]] [37] [[タグ]]の種別には、[[言語タグ]]がありました。 将来的には他の種別の[[タグ]]も追加し、 共存させることが想定されていました [SRC[>>13]]。 [81] [CITE[The Unicode Standard]] は将来的な他の種別の[[タグ]]を想定した規定が含まれていたものの、 [[Unicode言語タグ]]固有の規定と混ざっていて明確な区別はありませんでした。 [[Unicode言語タグ]]以外の[[タグ]]の構文と処理方法は、 ほとんど定められておらず、 [[先方互換]]な実装は困難でした。 - [82] 新たな[[タグ識別文字]]は [CODE[Tags]] [[ブロック]]で未割当の [CODE[U+E0000]], [CODE[U+E0002]] - [CODE[U+E001F]] が使われると予想されますが、明言されていませんでした。 - [83] 新たな[[タグ]]は[[タグ識別文字]]の後に[[タグ文字]]がいくつか続く構文になると予想されますが、 明言されていませんでした。 このため新たな[[タグ]]構文を[[プラグイン]]方式で低コストに追加可能な実装手法を採るのも困難でした。 - [84] タグが使われるとタグ値という1つの状態を持つことが想定されたと規定から読み取れますが、 仮に将来他の用途のタグが追加されたとして、 それで十分といえるのかは不透明でした。 [85] [DFN[タグ]]は、 [[言語タグ][Unicode言語タグ]]か、 [[全取り消しタグ]]です。 [SRC[>>13]] [FIG(railroad)[ [89] [[タグ]] = | == [[言語タグ]] == [[全取り消しタグ]] ]FIG] [38] [[タグ]]は、 次の非[[タグ文字]]か[[タグ識別文字]]の直前まで続くものとされ、 終端を表す特別な印はありませんでした。 [DFN[[RUBYB[タグ引数][tag-argument]]]]は、 1文字[[以上]]の[[タグ文字]]です。 [SRC[>>13]] [FIG(railroad)[ [91] [[タグ引数]] = + == [[タグ文字]] ]FIG] -*-*- [49] [DFN[[CODE[U+E007F]]]] [DFN[[CODE(charname)@en[CANCEL TAG]]]] ([DFN[[CODE[tag-cancel]]]]) は、 [[タグ]]の効果を取り消すものです。 これを使うと[[文字列]]を連結するときに、 前の[[文字列]]の[[タグ]]が後の[[文字列]]に波及することを防げます [SRC[>>13]]。 ;; [50] 意外なことに[[タグ]]のない「素の状態」に戻すことが主に想定された用途ではなかったようです (必然的にそれと同じことになるにせよ)。 [[HTML]] や [[XML]] には [CODE[lang=""]] ([[空文字列]]) のような構文が後に追加されたのですが、 確かに [[IETF言語タグ]]自体にはそのような構文がないことから想像されるように、 当時はその必要性があまり意識されていなかったのでしょう。 - [51] [[タグ識別文字]]の後に [CODE[U+E007F]] を使うと、 当該種別のタグ値だけを取り消します。 例えば [CODE[<[[U+E0001]], [[U+E007F]]>]] は、 [[Unicode言語タグ]]が適用される部分を終了させます。 [SRC[>>13]] 現在規定されているのは、 [[言語タグ]]の取り消しだけです。 - [52] [DFN[[RUBYB[全取り消しタグ][[CODE[all-tag-cancel]]]]]]: [CODE[U+E007F]] を単独で使うと、 すべての種別のタグ値を取り消します。 [SRC[>>13]] [FIG(railroad)[ [92] [[全取り消しタグ]] = [CODE[U+E007F]] ]FIG] -*-*- [138] [[タグ]]が現れた後、[[タグ]]以外の[[文字]]が出現することなく次の[[タグ]]が現れるというものは、 認められるとも認められるとも特に記述がありません。普通に解釈すれば認められるということです。 [EG[ [139] 例えば「{日本語}{日本語}abc」のような意味のない[[日本語]]の指定は禁止されていません。 ]EG] [EG[ [140] 例えば「{日本語}{タイ語}abc」のような意味のない[[日本語]]の指定は禁止されていません。 ]EG] [EG[ [141] 例えば「{日本語}{取消}abc」のような意味のない[[日本語]の指定は禁止されていません。 ]EG] [86] [[タグ]]が現れていないのに[[取り消しタグ]]が出現することや、 [[取り消しタグ]]が出現した後に再び[[取り消しタグ]]が出現することが認められるのかどうか、 明言はされていません。 [[取り消しタグ]]の趣旨 (>>49) によれば、それも認められていたと解するべきでしょうか。 [EG[ [142] 例えば「{日本語}abc{取消}{取消}abc」のような意味のない取消し指定は禁止されていません。 ]EG] [EG[ [143] 例えば「{取消}abc」のような意味のない取消し指定は禁止されていません。 ]EG] -*-*- [43] [[タグ]]の効果は、 - [44] [[応用]]で定義される[[テキスト]]自体の[[適用範囲]]外となる位置、 例えば行指向プロトコルでは[[行]]末、 [[text stream]] では [[stream]] 末端。 - [45] [CODE[U+E007F]] [CODE(charname)@en[CANCEL TAG]] を使った取り消しの位置 - [47] 同じ種別の次の[[タグ]]の直前 - [71] 不正な[[タグ]] (>>70) ... まで継続します。 [SRC[>>13]] ;; [72] つまり[[タグ]]の効果は[[応用]]依存で、 [[応用]]を知らずに正しく処理することができません。 ;; [112] 特定の[[応用]]でだけ使うなら[[応用]]依存の方法で[[言語情報]]を記述すればよいわけで (それが推奨される方法でもあるわけで)、そうではない、 特定の[[応用]]に紐付かない[[平文]]のような場面でこそ[[Unicode言語タグ]]は有用なはずなのに、 [[応用]]依存だと放り投げることでその有用性を自ら毀損しているような。。。 [46] 同じ種別の[[タグ]]が現れると、 それ以前の同じ種別の[[タグ]]の効果はそこで終わります。 同じ種別の[[タグ]]を[[入れ子]]にすることはできません。 [SRC[>>13]] ;; [113] [[HTML]] の[[要素]]の [CODE[lang=""]] [[属性]]のように[[終了タグ]]の続きでは[[親]]の[[言語情報]]に復帰したりすることが [[Unicode言語タグ]]では起こらないということです。 [48] 違う種別の[[タグ]]は独立した状態を持ちます。 別の種別の[[タグ]]が現れたからといって効果が取り消されたり変更されたりはしません。 つまり[[タグ]]の適用範囲が包含関係になっているとは限りません。 [SRC[>>13]] [131] この「goto型」の状態制御は、先頭から順に表示していくだけの超古典的な処理には実装しやすいのでしょうが、 様々な[[文字列処理]]が必要な現代的な用途にはとても使いにくいものです。 [EG[ [132] 例えば「{日本語}漢漢」という文字列の見かけ上の2文字目に「{台湾華語}漢」 を挿入したいとします。 [133] そのまま普通に実行すると 「{日本語}漢{台湾華語}漢漢」になってしまい、 見かけ上の3文字目が[[日本語]]から[[台湾華語]]に変わってしまいます。 [134] そこで [CN[U+E007F]] を使って取消したくなりますが、それだと 「{日本語}漢{台湾華語}漢{取消}漢」になってしまい、 見かけ上の3文字目は[[日本語]]から「言語なし」に変わるので問題は解決していません。 [135] 正しく 「{日本語}漢{台湾華語}漢{日本語}漢」 にするには挿入位置の言語を直近のタグまで遡って調べて、挿入位置の後ろに新たに挿入しなおす、 という面倒な処理が必要になります。 ]EG] ;; [136] [[HTML]] のような[[木構造]]に[[言語タグ]]を付与するタイプや、 [[bidi]] の制御文字のように 「push/pop型」 で 「{日本語}漢{台湾華語}漢{pop}漢」 と表せるなら幾分楽になったでしょうに。 -*-*- [145] ここまでの伝統的な用法の他に、 [[ETS]] 構文があります (>>146)。 * レンダリング [60] [[タグ文字]]自体は、 通常のテキストでの視覚的レンダリングを持ちません。 [SRC[>>13]] [62] [[デバッグ]]その他の[[タグ]]が可視化される操作では、 [[タグ文字]]を相当する [[ASCII文字]]の[[グリフ]]で (おそらくは体系的な変化を加えて通常の [[ASCII文字]]と区別できる形にして) 表示するのが[RUBYB[よいです][advisable]]。 [SRC[>>13]] ;; [64] そんな気の利いたデバッグツールが実在するのかは不明。 [63] しかし[[タグ文字]]の[[符号位置]]は、 そうした表示上の措置のないほとんどの[[デバッグ]]器でも、 解釈可能であるように選ばれました。 [SRC[>>13]] ;; [65] だそうですか、つまり[[符号位置]]の16進下4桁が [[ASCII文字]]と一致することを言いたいのでしょう。 [[ASCII文字]]の[[16進数]]くらい暗記してるでしょということでしょうかw (まあ多少の経験を積んだ[[技術者]]なら実際それくらい覚えてきますけどwww) [148] [[ETS]] については別途の規定があります。 @@ * 処理 [20] [[タグ文字]]を使うと、 [[ASCII文字]]の[[タグ]]を 本来の[[ASCII文字]]とは別に区別した[[符号位置]]で表現できます。 [[タグ文字]]はタグとしか使わないので、 実装は[[タグ文字]]を使ったり、 無視したりする処理を簡単に記述できます [SRC[>>13]]。 [DEL[ [21] ・・・と当初は説明されており、未だそのまま残されているのですが、 [[絵文字]]の記述に流用されてしまったので、 [[タグ文字]]は通常のテキスト内容としても使われるようになってしまい、 それほど簡単ではなくなりました。 ]DEL] [74] [[Unicode]] への[[適合性]]に関して、 [[適合処理]]は[[タグ文字]]を解釈しなければならないということはありません。 [SRC[>>13]] [78] [[応用]]が[[タグ文字]]を解釈しない場合には、 そのまま変えずにおいておき、 他の解釈しない[[文字]]と同じように扱う[RUBYB[べき][should]]です。 [SRC[>>13]] [54] [[Unicode言語タグ]]は使用するべきではないとされますが (>>53)、 使わなければならない場合には、 [CITE[The Unicode Standard]] に列挙された実装上の諸問題を検討して、 完全に対応していない[[タグ]]をどう扱うかを決める[RUBYB[べき][should]]です。 [SRC[>>13]] [66] [[テキスト]]の[[逐次アクセス]]は普通です。 [[言語情報]]が不要な操作なら、ただ無視する[RUBYB[べき][should]]です。 一方[[ランダムアクセス]]は厄介で、 [[テキスト]]の現在の状態は直前の[[タグ]]まで (もしかすると先頭まで) 戻らないと確定できません。 [SRC[>>13]] ;; [67] [CITE[The Unicode Standard]] は、そういう例外はあってもテキスト編集しないなら[[タグ]]によってそう難しいことにはならない [SRC[>>13]]、 としていました。 (この1点だけで十分難しい事態なようですが...) [68] [[タグ]]は状態を持ちますので、 [[テキスト]]の変更は複雑になります。 変更する際にはタグの開始と終了の状態を注意して適切に操作しなければなりません。 対応していない編集プログラムでは[[利用者]]が意図しないでテキストを容易に壊してしまいます。 [SRC[>>13]] [69] [[タグ]]を解釈しない[[プログラム]]であっても、 [[タグ]]を壊す編集操作や、 組になっていない[[タグ]]を放置する編集操作は認める[RUBYB[べきではありません][should not]]。 組になっていない[[タグ]]は、 送信や保存の操作の前に捨てる[RUBYB[べき][should]]です。 [SRC[>>13]] [70] [[Unicode言語タグ]]を無視しない実装は、 不正なタグの受信に備えなければなりません。 不正なタグや組になっていないタグを受信したら、 [[Unicode言語タグ]]を[RUBYB[なし][NONE]]にリセットしてタグを無視するべきです。 [SRC[>>13]] -*-*- [58] [[タグ文字]]自体は、 [[line breaking]], [[character shaping]], [[character joining]], その他の format or layout properties に影響しません。 [[タグ]]を解釈する処理は、 [[タグ]]値をそうした処理に影響させても構いません。 [SRC[>>13]] -*-*- [114] [[Firefox]] も [[Chrome]] も、 > [PRE(HTML)[ 一󠀁󠁪󠁡󠁿 ]PRE] [115] のような文字列を与えると、[CH[一]]は表示しても、 その続きを表示しません。[[フォント]]に[[グリフ]]があっても、 無視して零幅で表示します。しかし[[文字列の選択]]においては [CC[U+E0001]] で1文字扱い、残りで1文字扱い2文字扱いします。 なんでこんな変な挙動になるんでしょう。 [116] [[Firefox]] だと[CH[一]]とその後の零幅2文字は選択でもその通りの動きをします。 [[Chrome]] も普通のフォントだとそうですが、 [CH[一]]とその続きが [CODE[GSUB]] で処理対象になっていると、 [CH[一]]とその続きがその字形を3等分するような選択の挙動に変わります。 ([CODE[GSUB]] のグリフ置換が起こらない場合であってもです。 同じフォントに含まれ処理対象になるかどうかが影響するのでしょうか。) ([[Firefox]] にはこの挙動はありません。) [TIME[2024-10-24T08:02:04.900Z]] [117] [[Chrome]] のこの挙動、[CH[一]]より前に[[タグ文字]]がある場合も[CH[一]]を構成するように分割されます。 ([CODE[GSUB]] で[CH[一]]より前に戻り読みしているわけでもないのに。つまり [CODE[GSUB]] で処理される対象になっていることまでが条件で(?)処理対象になっているグリフ列であることまではこの挙動が発生する条件には入っていません。) [118] [[Chrome]] でも [[Firefox]] でも、 [[タグ文字]]の[[グリフ]]は表示されないものの、 [CODE[GSUB]] による置き換えには寄与する。グリフの置き換えがあっても[[タグ文字]]由来グリフとそれ以外由来グリフはちゃんと追跡されていて、 以外由来グリフが増えたりしても、それらはちゃんと表示され、 [[タグ文字]]由来のものはしっかり非表示になる。 寄与する[[タグ文字]]がそれ以外の後にある場合も、前にある場合も同じ。 [119] [[Chrome]] も [[Firefox]] も、 [CC[U+E0001]] や [CC[U+E007F]] には [CODE[GSUB]] でグリフを置換することでグリフ表示させることはできる。 他の[[タグ文字]]はなぜかこれでもだめ。 [120] んー >>119 の挙動はもっと複雑で、ただ単にそうしても表示はされなくて、 [CC[U+E0001]] と [CC[U+E0076]] に同時に置換を発生させると [CC[U+E0001]] だけ表示されるような謎の現象が起こる。 [[Chrome]] でも [[Firefox]] でも。 [121] [CC[U+E0001]] と [CC[U+E0076]] の両方を[[グリフID]] [N[0]] にすると、 [[Firefox]] では [N[0]] が1つだけ表示される。これは一貫した挙動。 [[Chrome]] ではそれだけ次のフォント候補に fallback して表示する。 [122] [[Chrome]] は [CODE[GSUB]] で [N[0]] に置き換えるとその部分の文字列を次のフォント候補で再評価させられる。 次のフォントに [CODE[GSUB]] があればそれも適用される。 [[Firefox]] だと次のフォント候補には進まない。ここの挙動がやや謎で、 通常の文字は [CODE[GSUB]] なしの [CODE[cmap]] から決まるグリフになり、 [[タグ文字]]は [N[0]] ([CODE[cmap]] から決まるグリフでなく) になる。 [123] >>122 [[Firefox]] で [CODE[cmap]] から決まるグリフを [N[0]] にしておくと、次のフォント候補に進む。しかし[[タグ文字]]が前後にあってもそれは認識されない ([[タグ文字]]は [CODE[cmap]] から決まるグリフが [N[0]] ではないから? それも [N[0]] にすれば結果が変わるのかもしれないが、 そうすると [N[0]] の連続になって [CODE[GSUB]] を書くのが困難なんだよな)。 [124] [[iPhone]] の [[Safari]] は挙動が全然違って、[[タグ文字]]の多く (なぜか全部ではない?) はグリフが表示されるが [CODE[GSUB]] は反映されない。謎が多い。 [125] >>124 [CODE[GSUB]] による置換そのものは機能しているらしい。[[タグ文字]]が絡むとうまくいかないのか、なんなのか。 [126] >>125 [CN[U+E0001]] は[[グリフ]]があっても[[レンダリング]]されないで次のフォント候補に進み、 それを含む [CODE[GSUB]] 置換規則があっても無視されるらしい。他の[[タグ文字]]は通常の文字と同じ用にレンダリングと [CODE[GSUB]] の対象になる。しかし [CN[U+E0001]] も最終的には次のフォントでレンダリングされているわけで、何がいけないのかが謎。 [127] >>126 [CODE[GSUB]] なしで [CODE[cmap]] だけのフォントで試してみると普通の文字扱いになるのは [[タグ文字]]の 0-9 と a-z と [CN[U+E007F]] だけ。その他は零幅で字形は表示されるものとされないものと次のフォント候補に行くものがあり、変なところに表示されるものもあってわけがわからない。 [128] 国旗絵文字用なのかとも思うけど [CH[-]] が入ってないんだよなあ [129] lookup の chained substitution の index の数え方が [[Firefox]] = [[Chrome]] と [[Safari]] で違うっぽい。どっちもどっちでおかしい気がするがどうおかしいのかうまく説明できない。 どっちもなんか変だ。無視される文字のせい、ということでもなさそうでよくわからない。 これ自体はほかのフォントでもよく使われている機能なので、 こんなあからさまな挙動差が放置されてるとも思いづらく[[タグ文字]]の特殊事情のような気はするのだが。 [130] [[Chrome]] でも [[Firefox]] でも、[[タグ文字]]のそれぞれ一部が入った[[フォント]]を [CODE[font-family]] でいくつか指定したとき、最初の[[フォント]]が選ばれてしまって次のフォント候補に進まない。 なのでどの[[タグ文字]]から始まるかによって違う[[フォント]]を選ばせることができない。 [CODE[cmap]] で指定された[[グリフ]]の有無や [CODE[unicode-range]] の指定の有無など変えてみてもどうにもならない。どうも[[フォント]]の選択で[[タグ文字]]の[[グリフ]]の有無が寄与していないような。 でも [CODE[unicode-range]] がまったく効いていないというわけでもなく、 それが皆無だとそもそもその[[フォント]]が選ばれなかったりもするので、 挙動がよくわからない。 [TIME[2024-10-25T11:39:17.100Z]] [182] [[Chrome]] でも [[Firefox]] でも、[[基底文字]]と[[タグ文字]]が続くものを [CODE[GSUB]] で置換するものが[[横書き]]では機能していても、[[縦書き]]では機能しません。 [[グリフ]]を縦に並べる処理が[[合字]]化より先に実行されてしまうということでしょうか。 * 言語タグ [30] [DFN[[RUBYB[言語タグ識別文字][language tag identification character]]]] [DFN[[CODE[U+E0001]]]] [DFN[[CODE(charname)@en[LANGUAGE TAG]]]] ([DFN[[CODE[language-tag-introducer]]]]) は、 [[タグ文字列]]が[[言語タグ]]であると識別します。 [DFN[[RUBYB[言語タグ][language tag]]][Unicode言語タグ]]は、 [CODE[U+E0001]] から始まる[[タグ]]です。 [SRC[>>13]] [FIG(railroad)[ [90] [[言語タグ]] = [CODE[U+E0001]] = | == [[言語タグ引数]] == [CODE[U+E007F]] ]FIG] [39] [[言語タグ]]のタグ[RUBYB[値][value]] [DFN[[CODE[language-tag-arg]]]] は、 [[タグ引数]]です。 [[BCP 47]] の[[IETF言語タグ]]であって、 登録されたタグか、 [CODE[x-]] から始まる[[利用者]]定義のタグのみを用います。 [[IETF言語タグ]]は [[ASCII文字列]]ですが、 これを[[タグ文字]]によって表記します。 [SRC[>>13]] [NOTE[ [29] [[IETF言語タグ]]の仕様として、 [[RFC]] の改訂を反映して [[RFC 1766]] [SRC[>>1]]、 [[RFC 3066]] (or its successors) [SRC[>>27]]、 [[RFC 4646]] (or its successors)、 [[BCP 47]] [SRC[>>13]] と参照先が変わっていきました。 [31] 実は改訂のたびに細部が少しずつ変わっていて、 [[非互換変更]]も含まれていました。 [SEE[ [[IETF言語タグ]] ]] しかし [CITE[The Unicode Standard]] は参照先を変更しただけで、 内容の変化に応じた規定内容の変更までは行っていないようです。 [40] 登録されたタグまたは [CODE[x-]] という限定は [[RFC 2482]] 時代から変わっていませんが、 登録の考え方は歴代 [[IETF言語タグ]]仕様で少しずつ違っていますが、 それも規定に反映されていません。 それが想定通りなのか、 それとも誰も使っていないのでいちいちチェックしていないものなのか。 ]NOTE] [41] [[IETF言語タグ]]は[[大文字・小文字不区別]]ですので、 [[小文字]]の[[タグ文字]]を使うことが[RUBYB[[[推奨]]][recommended]]されます。 [SRC[>>13]] 明記されていませんが、 処理側は [[IETF言語タグ]]と同じく [[Unicode言語タグ]]も[[大文字・小文字不区別]]で対応しなければならないということでしょう。 なおこの推奨は、 [[BCP 47]] 側の推奨される表記法とは一致していません。 [93] [[Unicode言語タグ]]としての構文は、 ただ単に1文字[[以上]]の[[タグ文字]]とされており、 [[IETF言語タグ]]の構文は組み込まれていません。 まず [[Unicode言語タグ]]として構文を解釈して[[タグ引数]]を取り出した上で、 それが更に [[IETF言語タグ]]として構文的に正しいかどうかを見ることになります。 [[IETF言語タグ]]としての構文的な正しさ如何は、 [[Unicode]] の[[タグ]]の埋め込みの構造の決定には関与しないということでしょう。 -*-*- [87] 既に[[タグ文字]]で記述されたのと同じ[[IETF言語タグ]]の [[Unicode言語タグ]]が重ねて記述されることが認められているのかどうか、 明言はされていません。特に禁止されていないのなら、 認められていると解するべきでしょうか。 その場合は特に効果はないと解するべきでしょうか。 ;; [88] [[言語情報]]によって違う処理を適用する場合、 [[Unicode言語タグ]]の指定を境界とみなして、 そこで分割してそれぞれの部分文字列に対してその処理を適用しようと考えるかもしれません。 [[Unicode言語タグ]]が毎回必ず異なる [[IETF言語タグ]]を指定してあるとすればそれでいいのですが、 同じ[[IETF言語タグ]]が指定されているのにそこで分割してしまうと、 分割しないで処理を適用した場合と違う結果になるおそれがあります。 -*-*- [32] [[言語タグ識別文字]]およびそれを使った[[言語タグ]]付けの仕組みは、 [RUBYB[[[非推奨]]][deprecated]]で、 使う[RUBYB[べきではありません][should not]]。 とりわけ[[言語タグ]]付けの手段を他に用意している[[プロトコル]]では、 使うべきではありません。 [[HTML]] や [[XML]] のような、 [[マーク付け]]によって[[言語タグ]]付けを行う[[上位層プロトコル]]の利用が[RUBYB[[[推奨]]][recommended]]されます。 [SRC[>>13]] [NOTE[ [33] [[平文]]に対する[[言語情報]]の埋め込みの要件はしばしば過大評価されるのであって、 [[マーク付け]]その他[[リッチテキスト]]の仕組みが [[best current practice]] なのであります。 [SRC[>>13]] と [CITE[The Unicode Standard]] は釈明しています。 [34] 現状[[マーク付け言語]]を使うのが最善なのは疑いありませんが、 それは [[Unicode言語タグ]]の仕組みが酷いだけで、 [[言語情報]]の記述の要求の重要度にすり替えて正当化に走るのはいかがなものでしょう。 [35] [[Unicode言語タグ]]は、 [[CJK統合漢字]]に代表される [[Unicode]] の強引な[[文字の統合][unification]]への批判が [[Unicode]] そのものへの強い反発として現れていた時代の産物でした。 [109] 実際そのような批判には過剰で行き過ぎた要件を主張するものもあったようですから、 [[Unicode]] 側の釈明にも酌量の余地はあるのですが、 だからといって文化的多様性を軽視する [[Unicode]] 側関係者の態度 (e.g. [SEE[ [[CJK統合漢字]] ]]) もどうかと思われます。 「細かな表示の違いは言語情報で切り替えればいい」と言っておきながら 「言語情報は平文にはいらない」で済ませるのは実に無責任。 [110] 自分達のアーキテクチャーと経済的利益を守るために自分達が扱っている対象の[[文化的特性を軽視する態度][欧米中心主義]]は非難されても仕方がありません。 ]NOTE] [79] なお、 [[整形式]]タグが現れたからといって、 正しくタグ付けされているとは限りません。 例えば[[フランス語]]を誤って[[スペイン語]]とタグ付けしているかもしれません。 [SRC[>>13]] ** 文脈 [3] [[Unicode言語タグ]]は、 テキストの[[言語情報]]の記述方法の大本命とまで目されたほどの提案でしたが、 ほとんど誰にも使われず、大失敗に終わりました。 [14] [CODE[U+E0001]] [CODE(charname)@en[LANGUAGE TAG]] は、 [[[RUBYB[非推奨][deprecated]]であり、避ける[RUBYB[べき][should]]][Unicodeの非推奨の文字]]です。 [[Unicode言語タグ]]は [[paired stateful controls]] ですが、 [[テキスト]]の編集操作で壊れがちな問題が指摘されています (>>68)。 [SRC[>>12]] [53] [[Unicode言語タグ]]は、 [[言語情報]]が必須であって、 受信者がタグを適切に認識し維持すると分かっている場合を除き、 [[平文]]では避ける[RUBYB[べき][should]]です。 追加の実装コストがあるからです。 [SRC[>>13]] [55] [[上位層プロトコル]]が[[言語情報]]を記述できるときは、 [[Unicode言語タグ]]は避ける[RUBYB[べき][should]]です。 それによって両者の不整合を防げます。 [SRC[>>13]] ;; [56] 2つ (以上) の記述方法がある以上、実装は不整合があっても何らかの対応を強いられるわけですが、 いかに処理するか [[Unicode]] では規定されていませんし、 [[上位層プロトコル]]で規定したものがあるのかは不明です ([CITE[The Unicode Standard]] や [[unicode-xml]] のように使うべきではない、と言っているだけの[[仕様書]]はありますが)。 誰も[[Unicode言語タグ]]を使っていないので、 実世界では問題になっていません。 -*-*- [5] [[MIME]] では、[[文字コード]]によって埋め込んだ[[言語]]の指定の方が [[MIME]] での[[符号化語]]での指定よりも柔軟であるとして、将来定義された際には[[文字コード]]による指定を使う[SHOULD[べき]]としていました。 [SRC[>>4]] [7] 一方 [CITE[The Unicode Standard]] は、 [[MIME]] など (と具体例の1つに敢えて挙げて) [[上位層プロトコル]]に[[言語情報]]の指定の仕組みがあるときは、 そちらを指定するべきとしていました。 [SRC[>>13]] [8] [CITE[The Unicode Standard]] が [[MIME]] と言っていたのは [CODE(MIME)@en[Content-Language:]] [[ヘッダー]]を指していたのでしょうか、 そちらは[[実体]]全体の[[言語情報]]を記述できるのに過ぎず、 [[Unicode言語タグ]]の代わりには不十分です。 [73] [[Unicode言語タグ]]が失敗に終わった以上、やはり[[符号化語]]では [[MIME]] 側の仕組みで記述するしかありません。 [REFS[ - [4] [CITE@en[[[RFC 2231]] - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations]] ([TIME[2014-09-14 04:20:18 +09:00]] 版) ]REFS] -*-*- [98] [[ISO 2022 wchar_t encoding]] という提案で[[Unicode言語タグ]]を使う案も示されていましたが、 とても実装可能なものだったとは思えません。 -*-*- [106] 正しい [[Unicode]] の[[文字のレンダリング]]には[[言語情報]]が必須ですが、 各種の[[文書形式]]や[[プロトコル]]の[[文字列データ型]]は必ずしも[[言語情報]]を記述できません。 消去法的に[[Unicode言語タグ]]でしか記述のしようがないのですが、 [[Unicode言語タグ]]で記述したところで正常に扱える実装なんてありません。 ;; [108] いわゆる[[中華フォント問題]]のような形で一般利用者に意識される形で問題になってしまっています。 [107] 階層化された技術の境界面に当たる部分がうまく接続されず、誰も責任を持って技術設計しないために破綻する[[アンチパターン]]の好(?)例の1つです。 [111] もっと仕様を簡素にしていればちゃんと実装されて使われる道もあったんじゃないですかねえ。 [[bidi]] 系の制御の文字は複雑で厄介なのに何だかんだ実装されてるわけで。 ** レンダリング [61] [[Unicode言語タグ]]自体は表示されません。 [SRC[>>13]] [57] [[Unicode言語タグ]]に対応した実装は、 [[hyphenation]] や[[フォント]]選択のような特殊処理で[[Unicode言語タグ]]の[[言語情報]]を考慮する必要があるかもしれません。 [SRC[>>13]] ;; [59] それを「特殊処理」と呼ぶあたりに、当時の [[Unicode]] 関係者の認識がうかがえます。 ** 処理 [75] [[適合処理]]が[[Unicode言語タグ]]を解釈する場合は [[Unicode]] の規定に従う[RUBYB[べき][should]]ですが。 ある[[言語]]であるとタグ付けされているからといって、 [[テキスト]]をいかに解釈するかには、 特に要件は定められておりません。 [SRC[>>13]] [76] 実装は[[タグ文字]]を解釈しなくても構いません (>>74)。 [[HTML]] のような[[上位層プロトコル]]の[[言語情報]]の記述があるときは、 [[タグ文字]]を無視することが明示的に認められています [SRC[>>13]]。 ;; [77] つまり [[Unicode言語タグ]]の[[相互運用性]]はまったく保証されません。 この意味でも [[Unicode言語タグ]]は使うべきではありません。 ** Unicode LangTag 形式 [99] [CITE@ja[Aprotool TM tips collection]], [TIME[2006-11-13T17:59:52.000Z]], [TIME[2022-10-11T04:36:07.175Z]] [100] [CITE[Aprotool TM Editor]] は付属ドキュメントによると [DFN[Unicode LangTag]] [SRC[>>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] [DFN[[RUBYB[言語タグサンドイッチ列][language tag sandwich sequence]]]]は、 [[言語タグ]]を[[異体選択子]]の代替として使うものです。 [151] [[言語タグサンドイッチ列]]は、 [[基底文字]]と省略可能な[[異体選択子]]を、 同一の[[Unicode言語タグ]]で囲み、 [CC[U+E007F]] で終わるものです。 [FIG(railroad)[ [[言語タグサンドイッチ列]] = [VAR[言語タグ]] = [[基底文字]] = ? == [[異体選択子]] = [VAR[言語タグ]] = [CC[U+E007F]] ]FIG] [152] ここで、前後の[[言語タグ]]は同じものとします。また、 [CC[U+E007F]] を含まないものとします。 更に、[[大文字]]は使わないものとします。 [153] [DFN[[RUBYB[CJK言語タグサンドイッチ列][CJK language tag sandwich sequence]]]]は、 [[言語タグサンドイッチ列]]のうち、 - [154] [[基底文字]]が [[CJK統合漢字]]または[[CJK互換漢字]] - [155] [[異体選択子]]を含まない - [156] [[言語タグ]]が次の表のうちのいずれか であるものであり、次の表によってその意味が定まります。 [FIG(table)[ :l: [[言語タグ]]の2文字目以降に相当する [[ASCII文字]] :s: 意味 :l: [CODE[zh-cn]] :s: [[C]] 字形 :l: [CODE[zh-hk]] :s: [[H]] 字形 :l: [CODE[zh-mo]] :s: [[M]] 字形 :l: [CODE[zh-tw]] :s: [[T]] 字形 :l: [CODE[ja]] :s: [[J]] 字形 :l: [CODE[ko-kr]] :s: [[K]] 字形 :l: [CODE[ko-kp]] :s: [[KR]] 字形 :l: [CODE[vi]] :s: [[V]] 字形 :l: [CODE[zh-gb]] :s: [[UK]] 字形 :l: [CODE[lzh]] :s: [[S]] 字形 :l: [CODE[und]] :s: [[U]] 字形 :l: [CODE[mul]] :s: [[UCS2003]] 字形 ]FIG] [157] [[CJK言語タグサンドイッチ列]]は、その意味に示された [CITE[The Unicode Standard]] の[[代表字形]]に典型的に表される[[グリフ的部分集合]]を表します。 必ずしもその[[代表字形]]を使って実装される必要はありません。 [158] また、 [CITE[The Unicode Standard]] に[[代表字形]]が明記されていないからといって、 その[[Unicode符号点]]に関する[[CJK言語タグサンドイッチ列]]が使えないということもありません。 [EG[ [159] 例えば [[G]] 字形は [[GB 18030]] [[規格票]]により、 [[T]] 字形は [[CNS 11643]] の [[規格票]]等により、 [CITE[The Unicode Standard]] に掲載されていなくても[[例示字形]]を確認でき(ることがあり)ます。 ]EG] [EG[ [160] [[J]] 字形は[[仮想J字形]]のようなコミュニティー標準を参照できます。 ]EG] [EG[ [172] ただし、 [[UCS2003]] 字形は過去の [CITE[The Unicode Standard]] と [[ISO/IEC 10646]] の規格票以外に依るべきものがないので、 それが存在しない[[Unicode符号点]]では使うべきではありません。 ]EG] [161] [CITE[The Unicode Standard]] に示された[[代表字形]]や関連国内規格等の[[例示字形]]や[[包摂規準]]は、 各規格等の版によって変化することがあります。 [[CJK言語タグサンドイッチ列]]はそれらの特定の版を指し示すものではなく、 従って各規格等の変更によってその意味が変化する可能性があります。 [170] [[IVS]] で記述可能なものは、[[CJK言語タグサンドイッチ列]]を使う[SHOULD[べきではありません]]。 [EG[ [171] [[出典J]]が[[文字情報基盤]]で、それと同じ[[MJ文字図形]]の [[IVS]] がある場合は、 [[IVS]] を使うべきです。 ]EG] [173] [[CJK言語タグサンドイッチ列]]以外にも次のようなものの表現方法が検討されるべきでしょう。 - [174] 同じ [[IVS]] に統合された[[汎用電子]]と[[文字情報基盤]]の区別 - [175] [[JIS X 9051]], [[JIS X 9052]] 字形 - [176] [[傳承字形]] - [177] [[CNS 11643]] の旧版字形、[[楷書]]字形 - [178] [[教科書体]]字形 -*-*- [162] [[言語タグサンドイッチ列]]は、次の要件を満たすものとして設計されています。 - [163] 令和6年10月時点で [[Firefox]] および [[Chrome]] で適切に表示できる [[OpenType]] [[フォント]]を作成可能であること -- [168] かつあらゆる[[CJK言語タグサンドイッチ列]]を1つの[[フォント]]ファイルに収容しなくても済む、 何らかの分割方法が存在すること - [181] [[フォント]]切り替え等、[[Unicode符号点]]の[[列]]以外の手法を併用しないで記述できること - [164] [[Unicode]] で規定された[[Unicode符号点]]およびその[[列]]の正当な用法に反しないこと - [165] [[私用]]の機能をできるだけ避けること、 やむを得ず使う場合は他の用法との衝突の可能性が十分低いこと - [166] 1つの[[言語タグサンドイッチ列]]が1つの (概念上の) 文字を表し、 その内部の状態が前後の状態に影響を及ぼさないこと -- [167] ただし直前までの[[Unicode言語タグ]]の状態を破棄することはやむを得ない - [169] 一般的な[[エディター]]での編集が著しく複雑ではないこと [191] 本当は満たしたかった次の要件は、他の要件と同時に満たすのが困難なため断念しています。 - [192] [[Safari]] で適切に表示できる [[OpenType]] フォントを作成可能であること - [193] [[Firefox]] および [[Safari]] で編集用の表示モード (>>183) に切り替え可能であること - [194] [[Chrome]], [[Firefox]], [[Safari]] で[[縦書き]]でも適切に表示できる [[OpenType]] フォントを作成可能であること - [195] 冗長な[[Unicode符号点]]を含まないこと - [196] 短く表現できること - [197] 文字列の選択で1文字扱いになること - [198] 同じ[[基底文字]]について、[[言語]]によって異なる[[フォント]]にある[[グリフ]]を表示可能であること -*-*- [179] [[CJK言語タグサンドイッチ列]]の [[OpenType]] は、 次のように実装する[SHOULD[べきです]]。 - [180] [[基底文字]]の[[グリフ]]、[[言語タグ]]の[[グリフ]]列、 [CC[U+E007F]] の[[グリフ]]、がこの順で並ぶ[[グリフ]]列を、 [CODE[GSUB]] の [CODE[DFLT]] (および他の適当な[[言語系]]) における [CODE[ccmp]] によって、 [[基底文字]]の[[グリフ]]のかわりに[[CJK言語タグサンドイッチ列]]が表す[[グリフ]]が表示されるようにします。 - [183] 対応している[[言語タグ]]について、 [CODE[GSUB]] の [CODE[DFLT]] (および他の適当な[[言語系]]) における [CODE[ss20]] によって、 [CN[U+E0001]] の通常の[[グリフ]]のかわりに[[CJK言語タグサンドイッチ列]]の先頭を表す図形を、 [CN[U+E007F]] の通常の[[グリフ]]のかわりに[[CJK言語タグサンドイッチ列]]の末尾を表す図形を、 表示されるようにします。 ただしここで、[[CJK言語タグサンドイッチ列]]の2つ目の [CN[U+E0001]] にはこれを適用しません。 -- [184] 対応している[[言語タグ]]とは、 >>180 の方法で[[グリフ]]が1つ以上実装されているものすべておよびそれ以外の任意のものをいいます。 -- [185] [CODE[ss20]] は、 [[Chrome]] 等を使った編集用の表示を想定したものです。 [186] このフォントファイルを参照する [[CSS]] [CODE[@font-face]] [[規則]]の [CODE[unicode-range]] は、 - [187] 当該フォントファイルが提供する[[基底文字]]をすべて含む -- [188] その他の[[基底文字]]を含んでも構わない - [189] [[Chrome]] 用は [CODE[U+E0000-E007F]] を含む - [190] [[Firefox]] 用は [CODE[U+E0000-E007F]] を含まない とし、 [[Chrome]] と [[Firefox]] で使い分ける必要があります。 * ETS [146] [DFN[[RUBYB[絵文字タグ列][emoji tag sequence]]]] ([DFN[ETS]]) は、 [[絵文字]]の構文の一種です。 [SRC[>>9, >>10]] [147] 現在 [[ETS]] は[[国旗絵文字]]に類する地方旗の表記のための構文のみ定められていて、 他の用途には使われていません。 @@ [EG[ [200] [CH[🏴󠁧󠁢󠁳󠁣󠁴󠁿]] ([[スコットランド]]) ]EG] * 関連 [42] [[HTMLタグ]]とは無関係。 [104] [[Unicode言語識別子]]は別物です。 [144] [[Java]] 方面では [CODE[-u-]] のことを[[追加のUnicode言語タグ拡張機能]]などと呼んでいるようで。 この呼称は [[Unicode言語タグ]]と紛らわしいので、避けるべきです。 [CODE[-u-]] は [[Unicode言語タグ]]とは独立した概念です。 [[Unicode言語タグ]]を使うときに [CODE[-u-]] を指定することはできますが、 有意義かどうかは不明です。 * 歴史 [24] [[タグ文字]]は [[Unicode言語タグ]]の記述のために導入されました。 [[Unicode言語タグ]]の定義はなぜか [[IETF]] の[[情報提供RFC]] である [DFN[RFC 2482]] として[TIME[平成11(1999)年1月][1999-01]]に出版されました [SRC[>>1]]。 [25] [[I-D]] 起草当時既に [[Unicode Consortium]] は承認済で、 [[ISO]] 側の承認待ち状態でした [SRC[>>23, >>1]]。 [[RFC]] の [[IESG]] 通過当時は [[WG2]] 承認済で [SRC[>>1]]、 [[ISO/IEC 10646]] に追加されるのは時間の問題でした。 [26] [CITE[The Unicode Standard]] とは別に [[RFC]] 化する必然性は見いだせないのですが、 [[IETF言語タグ]]を使っていることもあって、 [[IETF]] 方面での普及のための宣伝を兼ねていたのでしょうか。 この後[[タグ文字]]が追加された [CITE[Unicode 3.1]] が [[Unicode Consortium]] の [[Webサイト]]で公開されることになるのですが、 [[RFC]] が参照する [CITE[Unicode 2.0]] やその次の [CITE[Unicode 3.0]] はまだ紙で出版されていました。 [[インターネット]]で広く情報を公開するという意味もあったのでしょう。 [80] [[RFC 2482]] はしばらく ([[Unicode]] が改版されても) 放置されていましたが、 [[Unicode言語タグ]]の失敗が認められた後、 [TIME[2010年11月][2010-11]]に出版された [DFN[RFC 6082]] によって[[歴史的]]とされ [SRC[>>2]]、 [[RFC]] として事実上[[廃止]]されました。 [REFS[ - [23] [CITE@en[[[draft-whistler-plane14-00]] - Language Tagging in Unicode Plain Text]], [TIME[2020-12-08T00:21:35.000Z]], [TIME[2020-12-19T03:31:48.628Z]] - [1] [CITE@en[[[RFC 2482]] - Language Tagging in Unicode Plain Text]] ([TIME[2014-08-04 15:25:44 +09:00]] 版) - [2] [CITE@en[[[RFC 6082]] - Deprecating Unicode Language Tag Characters: RFC 2482 is Historic]] ([TIME[2014-08-25 16:46:06 +09:00]] 版) ]REFS] [28] [[Unicode 3.1]] で正式に [[Unicode]] に[[タグ文字]]と[[Unicode言語タグ]]が追加されました。 [[仕様書]]の内容は [[RFC]] と大筋に於いて同じでした。 (その後の [CITE[The Unicode Standard]] でも大枠は変わっていません。) [REFS[ - [27] [CITE@en-us[UAX #27: Unicode 3.1]], [TIME[2002-07-24T21:19:39.000Z]], [TIME[2020-12-19T03:42:22.187Z]] ]REFS] [18] [[ISO/IEC 10646]] の [DFN[TAGS]] は [[Unicode]] の [CODE[Tags]] と同じ範囲を表しています。 [REFS[ - [17] [CODE[TAGS]] の[[文字一覧]] ]REFS] [6] [[タグ文字]]は、 [[ASCII文字]]一式と同じものを別の[[符号位置]]に割り当てて特殊なものとして扱うという、 大変奇抜な仕組みでした。 [97] [CITE@en[RFC 2244 - ACAP -- Application Configuration Access Protocol]], [TIME[2021-04-11T10:25:16.000Z]], [TIME[2021-04-21T09:56:32.243Z]] [11] その後[[タグ文字]]は[[絵文字]]に再利用されるとかいうまさかの復活w [REFS[ - [9] [CITE[UTS #51: Unicode Emoji]] ([TIME[2017-09-29 06:46:44 +09:00]]) - [10] [CITE[UTS #51: Unicode Emoji]] ([TIME[2017-09-29 06:46:44 +09:00]]) ]REFS] [103] [CITE[Unicodeの最新動向]], [TIME[2023-08-10T08:27:55.000Z]], [TIME[2001-07-08T15:10:23.993Z]] >タグとは14面を使って文字ではなく制御コードを決めようというものである。現在,言語指定タグ,ルビタグ,異体字タグが提案されているが,いずれも詳細は未定である。 > 言語指定タグはテキストが何語かという情報をコードとして埋め込もうというものである。しかし,Unicodeはそもそも文字コードであり,言語はHTMLのタグや文書フォーマットの上位の指定でやるべきだという批判が強い。 > ルビタグは言語タグよりももっと批判が多い。これはその名の通り,日本語で読みを小さい文字で書くいわゆるルビをコードとして埋め込もうというものである。日本からの代表は猛烈に反対しているが,通りそうな状況だという。 > 異体字タグ(Variant Tag)は賛成意見が多い。Super CJKで増やす漢字には異体字が含まれる。これらを一列に並べて別の字とするのではなく,異体字を横に並べるというのが異体字タグである。すべての文字にコードを割り振るのではなく,異体字を含むある文字の集合を一つのコードで表し,異体字をその1番,2番,3番と並べるのである。こうすれば新たなコードは不要で,現在の16面までのコードスペースで処理できる。 (テキスト&グラフィックス研究会) (JAGATinfo 1999年8月号より) [137] [CITE@ja-jp[タグ (Unicode) ‐ 通信用語の基礎知識]], [TIME[2024-10-26T03:29:12.000Z]] [199] [CITE@en-us[Google won’t fix new ASCII smuggling attack in Gemini]], [TIME[2025-10-07T20:45:44.000Z]], [TIME[2025-10-09T05:49:56.301Z]] >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.