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

* 構文

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

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

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

-*-*-

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

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

- [51] 
[[タグ識別文字]]の後に [CODE[U+E007F]]
を使うと、
当該種別のタグ値だけを取り消します。
例えば
[CODE[<[[U+E0001]], [[U+E007F]]>]]
は、
[[Unicode言語タグ]]が適用される部分を終了させます。
[SRC[>>13]]
- [52] 
[CODE[U+E007F]]
を単独で使うと、
すべての種別のタグ値を取り消します。
[SRC[>>13]]


-*-*-

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

[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[言語タグ][Unicode言語タグ]]は、
[CODE[U+E0001]] 
から始まる[[タグ]]です。
[SRC[>>13]]

[39] 
[[言語タグ]]のタグ[RUBYB[値][value]]は、
[[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]] 側の推奨される表記法とは一致していません。


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







[3] [[Unicode]] の[[第14面]] ([CODE(char)[U+E00[VAR[hh]]]]) に割り当てられている[DFN[タグ文字]]を使った[[言語タグ]]は、
90年代末に[[言語]]指定の方法の大本命として提案されていましたが、後に失敗だったとして非推奨とされています。




[REFS[
- [2] [CITE@en[[[RFC 6082]] - Deprecating Unicode Language Tag Characters: RFC 2482 is Historic]] ([TIME[2014-08-25 16:46:06 +09:00]] 版) <http://tools.ietf.org/html/rfc6082>
]REFS]



** 文脈


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


** レンダリング

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

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

;; [59] それを「特殊処理」と呼ぶあたりに、当時の
[[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]]
はまだ紙で出版されていました。
[[インターネット]]で広く情報を公開するという意味もあったのでしょう。

[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>
]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文字]]一式と同じものを別の[[符号位置]]に割り当てて特殊なものとして扱うという、
大変奇抜な仕組みでした。


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