817.txt

* 仕様書

[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]] <https://www.unicode.org/versions/latest/ch23.pdf#G27446>
- [13] [CITE[[[The Unicode Standard]], Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-18T09:45:06.805Z]] <https://www.unicode.org/versions/latest/ch23.pdf#G30110>
]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[[CODE[U+E0020]]]] - [DFN[[CODE[U+E007F]]]]
の95文字は、
[[ASCII文字]] [CODE[U+0020]] -  [CODE[U+007E]]
の95文字に相当するもので、
16進数下2桁がそのまま対応付けられています。
[[ASCII文字]]と対応関係にあるとしても、
まったく別の[[文字]]という扱いです。
[[正規化]]しても変わりません。


[REFS[
- [16] [CODE[Tags]]
[[ブロック]]
<https://chars.suikawiki.org/set/%24unicode%3ABlock%3ATags>
]REFS]

* 特性

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

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

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


* 構文

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

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

-*-*-

[43] 
[[タグ]]の効果は、

- [44] [[応用]]で定義される[[テキスト]]自体の[[適用範囲]]外となる位置、
例えば行指向プロトコルでは[[行]]末、
[[text stream]] では [[stream]] 末端。
- [45] 
[CODE[U+E007F]] [CODE(charname)@en[CANCEL TAG]]
を使った取り消しの位置
- [47] 
同じ種別の次の[[タグ]]の直前
- [71] 不正な[[タグ]] (>>70)

... まで継続します。
[SRC[>>13]]

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

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

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

* レンダリング

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

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

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


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

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


* 処理

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

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

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





* 言語タグ

[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]]
そのものへの強い反発として現れていた時代の産物でした。

]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]] 版) <https://tools.ietf.org/html/rfc2231#section-8>
]REFS]

-*-*-

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


** レンダリング

[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言語タグ]]は使うべきではありません。

* 関連

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

* 歴史

[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]] <https://tools.ietf.org/html/draft-whistler-plane14-00>
- [1] [CITE@en[[[RFC 2482]] - Language Tagging in Unicode Plain Text]] ([TIME[2014-08-04 15:25:44 +09:00]] 版) <https://tools.ietf.org/html/rfc2482>
- [2] [CITE@en[[[RFC 6082]] - Deprecating Unicode Language Tag Characters: RFC 2482 is Historic]] ([TIME[2014-08-25 16:46:06 +09:00]] 版) <https://tools.ietf.org/html/rfc6082>
]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]] <https://www.unicode.org/reports/tr27/tr27-4.html#tag>
]REFS]


[18] 
[[ISO/IEC 10646]]
の
[DFN[TAGS]]
は
[[Unicode]]
の
[CODE[Tags]]
と同じ範囲を表しています。

[REFS[
- [17] [CODE[TAGS]]
の[[文字一覧]]
<https://chars.suikawiki.org/set/%24isoiec10646%3ATAGS>
]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]] <https://tools.ietf.org/html/rfc2244#page-62>

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

[REFS[
- [9] [CITE[UTS #51: Unicode Emoji]] ([TIME[2017-09-29 06:46:44 +09:00]]) <http://www.unicode.org/reports/tr51/#Emoji_Sequences>
- [10] [CITE[UTS #51: Unicode Emoji]] ([TIME[2017-09-29 06:46:44 +09:00]]) <http://www.unicode.org/reports/tr51/#valid-emoji-tag-sequences>
]REFS]


[99] 
[CITE@ja[Aprotool TM tips collection]], [TIME[2006-11-13T17:59:52.000Z]], [TIME[2022-10-11T04:36:07.175Z]] <http://hp.vector.co.jp/authors/VA002891/APROTIPS.HTM>

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