[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大文字・小文字不区別のときは、 既存の仕組みによらずに独自に正規化が必要となります。
[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[86] タグが現れていないのに取り消しタグが出現することや、 取り消しタグが出現した後に再び取り消しタグが出現することが認められるのかどうか、 明言はされていません。 取り消しタグの趣旨 (>>49) によれば、それも認められていたと解するべきでしょうか。
U+E007F
CANCEL TAG
を使った取り消しの位置... まで継続します。 >>13
[46] 同じ種別のタグが現れると、 それ以前の同じ種別のタグの効果はそこで終わります。 同じ種別のタグを入れ子にすることはできません。 >>13
[48] 違う種別のタグは独立した状態を持ちます。 別の種別のタグが現れたからといって効果が取り消されたり変更されたりはしません。 つまりタグの適用範囲が包含関係になっているとは限りません。 >>13
[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
[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。
[104] Unicode言語識別子は別物です。
[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
[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言語タグを出力しているようです。 行指向処理の便宜でしょう。
[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月号より)
lang=""
(空文字列) のような構文が後に追加されたのですが、 確かに IETF言語タグ自体にはそのような構文がないことから想像されるように、 当時はその必要性があまり意識されていなかったのでしょう。