ISO 15924

用字系符号

[6] ISO 15924 は、世界各地で用いられる用字系に対して符号を与えるものです。

仕様書

英字符号

[22]用字系ラテン文字4文字の符号が割り当てられています (一覧: >>251)。

[23] 通常、1文字目は大文字、2文字目以降は小文字で表記されます。

[27] 用字系符号を採用した各種プロトコルで大文字と小文字をどう扱うかは、 それぞれです。

[26] capitalize は奇妙な表記にも見えますが、 小文字表記する言語符号大文字表記する国符号と書き分けているようです。

私用

[24] ISO (と RA) が定める標準の符号の他に、 私用が認められる符号群があります。

[25] 各種規格や実装がその一部を使っています。

[235] >>123 には私用Qaaa .. Qabx も含まれます。 RFC 4646 2.2.3., RFC 5646 2.2.3.

[241] Unicode言語識別子Unicodeロケール識別子では Qaaq-Qabx は将来も意味を割り当てないので私用として使って良いとしています >>233。 それ以外の >>235用字系部分タグは特別な意味に使う意図があるようで、 >>236>>239>>240 の3つが定義されている他、残りも将来の拡張で使用できるように予約しているようです (明記されていませんが)。

Qaai

[236] Unicode言語識別子Unicodeロケール識別子では Qaai に「継承 (inherited) 」という意味を割り当てています >>233

[237] ただし、 Zinh を使うのがより好ましいともしています >>233

[238] Zinh は後から正式に ISO 15924符号として割り当てられたようです。

Qaac

[255] Unicode用字系特性値の別名として用字系符号に相当するものを定める PropertyValueAliases.txt によれば、 QaacCoptic / Copt と同義とされています。

その他

[13] 絵文字Qaae が用いられたことがありますが、 現在は Zsye が好ましいと考えられています >>1

[14] KlingonQaak が用いられたことがあります >>1, >>2 が、 現在は Piqd が好ましいと考えられています。

Zinh

[5] Zinh は「inherited script」を表すとされています。

[7] ただし IANA登録簿では、 言語タグでの利用は想定していないとされています。

[8] Unicode言語識別子Unicodeロケール識別子には他に Qaai がありますが、より新しい Zinh がより好ましいとされています >>233

[9] UCD では Inherited と同義とされています。

[15] IETF言語タグにはない XSL-FO の独自の拡張で inherit という値がありますが、言語タグ全体の "inherit" を表していて、 用字系だけが対象の Zinh とは少し違います。 >>17 も参照。

[44] ScriptLangTag では使うべきではありません (should not) >>43

Zxxx

[12] Zxxx は unwritten document を表すとされています。

[46] ScriptLangTag では使うべきではありません (should never) >>43

Zyyy

[239] Unicode言語識別子Unicodeロケール識別子では Zyyy に「共通 (common) 」という意味を割り当てています >>233

[3] UCD では Common と同義です。

[45] ScriptLangTag では使うべきではありません (should not) >>43

Zzzz

[240] Unicode言語識別子Unicodeロケール識別子では Zzzz に「不明 (unknown) 」という意味を割り当てています >>233

[4] UCD では Unknown と同義です。

[250] kr (>>246) においては Zzzzothers と同義とされており、明示されていない符号すべてを表す >>247 ことになっています。

[47] ScriptLangTag では使うべきではありません (should never) >>43

その他

[10] Zmth は Mathmatical notation を表すとされています。

[11] Zsye は記号 (絵文字版) を、 Zsym は記号を表すとされています。

[48] Kana仮名じゃなくて片仮名だけしかない罠にまたハマってしまった。 わかっているのについやってしまう、ほんと誰がこんなクソ仕様にしたんだよ

数字符号

[31] 0埋めありでASCII数字3桁で表される数値符号があります。

[32] >>244 に登録済み符号の一覧があります。

[33] 利用されているのかは不明です。

一覧

[251] ISO 15924用字系符号の一覧は >>244 にあり、 HTML および平文形式で公開されています。 Unicode用字系特性値との対応関係も記述されています (>>249)。

[252] BCP 47 の登録簿にも用字系部分タグの一覧が含まれています。 BCP 47 の項を参照してください。

[254] >>253 にも用字系部分タグkr の値とその実装に必要な情報が JSON として含まれています。

[37] >>34 符号の一覧および >>36 その名称の各言語翻訳テキストデータ。

[40] >>39 符号の一覧、 Unicode用字系特性値との対応関係入り。

文脈

[245] ラテン文字4文字の用字系符号は、次のように使われています。

[29] 用字系符号の用法

[17] XSL-FO'script' 特性では値に <ISO Script Code> / 'auto' / 'none' / 'inherit' を採用しています。

仕様書: Formatting Properties http://www.w3.org/TR/xsl/slice7.html#script


[18] Pronunciation Lexicon Specification (PLS) Version 1.0 http://www.w3.org/TR/pronunciation-lexicon/#S4.5 では orthography 属性に ISO 15924 の名前を採用しています。

[21] 同仕様 (や関連仕様) の alphabet 属性では ipa など表音字母の種類を指定しますが、 それもここでいう用字系札の範疇のような気もしますしむしろ言語札の特殊なもののような気もしますが自然言語は別レイヤで更に存在していますし(謎)。 結局言語と文字(の種類)と文字の使い方(の体系)は切っても切り離せないのに多対多対応なのが悪いのだ(謎)。

言語タグの用字系部分タグ

[120] IETF言語タグにおける用字系 (script) 部分タグは、 言語を書き表す時に使う用字系書字体系 (writing system) を表します。 ISO 15924 のラテン文字4文字による用字系符号がそのまま利用されています。

[231] 言語タグ全体については、「言語タグ」の項を参照してください。

[234] Unicode言語識別子Unicodeロケール識別子では Unicode 用字系符号 (script code) または unicode_script_subtag と呼ばれています >>233

仕様書

意味

[230] 用字系部分タグはその言語タグによって表される言語で主として使う用字系を表しているだけであって、 その言語タグが付された対象がその用字系だけによって構成されるとは限りません。 RFC 5646 4.2.

構文

[122] 用字系部分タグとして用いられる4文字のラテン文字である用字系は、 ISO 15924 で定義、またはそれに従い登録されたものを、更に IANA に登録したものです。 RFC 4646 2.2.3., RFC 5646 2.2.3.

[125] 用字系として ISO 15924 に含まれていないものは IANA に登録することはできません。 RFC 4646 には必要があれば異体として登録できると記述されていました RFC 4646 2.2.3. が、 RFC 5646 では削除されています。

文脈

[121] IETF言語タグでは、 用字系言語拡張言語の後で、他の部分タグの前に高々1つだけ置かなければなりません RFC 4646 2.2.3., RFC 5646 2.2.3.

[124] IETF言語タグ用字系部分タグを含めても他と区別する上で意味が無い時、 言語部分タグ拡張言語部分タグ登録Suppress-Script が含まれている時には、 用字系は省略するべきですRFC 4646 2.2.3., RFC 5646 2.2.3.

[41] ScriptLangTag では用字系部分タグは必須で、ちょうど1個だけ書けます。 言語部分タグの次に書きますが、 言語部分タグが省略された場合は先頭に来ます。

言語タグの用字系抑制

[200] IANA 登録簿には Suppress-Prefix (用字系抑制) 欄があります。 これは言語拡張言語の登録にのみ使われ、 当該言語拡張言語と指定された用字系を組み合わせて使うべきではないことを表します。 RFC 4646 3.1., RFC 5646 3.1.2.

[201] 使うべきではないというのは不適切な組み合わせというわけではなく、 自明な組み合わせであるので必要がない限り明示しなくても良いということです。 使わないことにより RFC 3066 以前の用字系が無い頃の言語タグとの互換性を維持できます RFC 5646 3.1.9.

[207] ほんと、なんで用字系を間に挟んだんでしょうね・・・。

[208] 例えば is (アイスランド語) は普通 Latn (ラテン文字) で表記されるので、 is の用字系抑制には Latn が指定されています。従って is-Latn ではなく、単に is とするべきです。

[211] しかし他の用字系と併用する場合には、敢えて明示する意味があるかもしれません。 例えばアイスランド語Brai (点字) 表記した文書ラテン文字で表記した文書が選択できるなら、それぞれ is-Braiis-Latn と表すのが良いでしょう。 RFC 4646 4.1., RFC 5646 4.1.

[212] 複数の用字系が使われることがある言語であっても、 用字系を明示せずに省略した方が良いこともあります。例えば音声だけなら、 用字系は意味が無いので省略して uz のように表すことができます。 あるいは、「書かれていない」ことを表す Zxxx を使って uz-Zxxx のように表すこともできます。 RFC 4646 4.1., RFC 5646 4.1.

[42] ScriptLangTag では用字系部分タグは必須で、 IETF言語タグ用字系抑制側の設計とは真逆です。

拡張Uの kr における用字系符号

[242] 用字系は、U拡張krの一部としても使うことができます。

[246] 言語タグ拡張Ukr では用字系符号以外の文字の種別を表す値も使える他、 利用可能な用字系の値も制限されています >>247

拡張Uの nu における用字系符号

[256] LDML および言語タグ拡張Unu では数字の種類に識別子を与えていますが、 対応する用字系符号をそのまま用いるのを原則とし、それで表現できないものに対してはそれより長い識別子を与えています。

Unicode用字系特性値における用字系符号

[248] Unicode用字系特性値用字系を識別するものですが、 UnicodeISO 15924 では用字系の粒度が異なっているため、必ずしも一対一対応していません。

[28] が、対応関係にあるものについては、 ISO 15924 の符号と同じ4文字符号が Unicode用字系特性値側でも短い別名となっていて、 区別なく使えます。 Unicode用字系特性値

[249] ISO 15924 の登録簿 (>>244) には、両者の対応関係も「Property Value Alias」として記載されています。

関連

[16] その他の符号体系は用字系参照。

歴史

[126] RFC 1766RFC 3066 の頃は用字系部分タグはありませんでした。

[19] RFC 1766 は用字系の識別までを含めた例として az-arabicaz-cyrillic を挙げていますが、 RFC 3066 にはそのような用途の例示さえありません。 [639FAQ] (>>3) は用字系の識別には言語符号より ISO15924 を使うようにと言っているのと関係があるかもしれません (しないかもしれません)。

[20] しかしなんにせよ用字系の指定も含めた言語札が使えた方が、 (用字系を別途指定出来る規格なんて多分ないので) 良いと思います。

[30] 正書法がどうこうを含んだ奴は用字系込みに近いよな。違うことは違うが。

[35] >>19-30 用字系札を使えるようにしる!

[148] RFC 3066 までは用字系部分タグはなかったので、 zh-TW のように言語地域を直接つなげたものが一般的で、 現在でも広く用いられていますが、 RFC 4646 はなぜか用字系を間に挟む構文としました。 そのため zh-Hant-TW のような表記がより厳密なものとされ、 実質的な非互換変更となっています。 前方一致などの一般的な比較方法でも zh-TWzh-Hant-TW は一致しません。

[149] zh-TW台湾で使われている伝統字中文を表す言語タグとして広く使われていますが、 RFC 4646 以降の定義に従うなら単に台湾中文を表すに過ぎず、 伝統字であることまで含めた意味でこの言語タグを使うことは不正確になります。 意味的な一貫性を考えれば確かにその方が良いのでしょうが、既存の慣習的解釈に対して非互換変更を行う価値があるようには到底思えません。 現に RFC 4646 が出版されてから数年が立ちますが、 zh-Hant-TW のような表記が普及している、あるいは普及していくようにはまったく思えません。