[2] 言語タグで使われる拡張である U は、
LDML で使われるロケールの識別子におけるロケールの特徴の記述を表します。
[52]
Java 方面では -u- のことを追加のUnicode言語タグ拡張機能などと呼んでいるようで。
この呼称は Unicode言語タグと紛らわしいので、避けるべきです。
[3] LDML は Unicode Consortium によるロケール情報の記述のためのマーク付け言語です。 現在の LDML ではロケールの識別子として BCP 47 言語タグを使っていますが、 ロケールの記述には照合順序などの純粋な BCP 47 の仕様だけでは表現できない要素が必要です。
[4] そこで LDML (UTS #35) は言語タグの中の -u-
よりも後の部分にそのような情報を記述する方法を規定しています。
[5] RFC 6067 は BCP 47 の規定に則り言語タグの拡張 u
を定義し、 IANA 登録簿に追加しています。実際の u の構文と意味は
UTS #35 に委ねられています。
[7] 拡張 u の部分タグは次のような構成を取ることとなっています。
[16] 言語タグは大文字・小文字不区別です >>31。
[13] 同じ属性が複数指定されている場合、最初のもの以外は無視されます RFC 6067 2.1.。
[15] 同じキーを複数使ってはなりません RFC 6067 2.1.。
[19] 順序には意味があります RFC 6067 2.1.。
[38] ka と vt の場合を除き、
型は部分タグ1つによって表現されます。 >>26
[45] 言及がありませんが、 kr も1つ以上の部分タグによって型が表現されます。
[46] 言及がありませんが、 ca には間に「-」が入る型が登録されています。
[28] 型が省略されている場合であって、型に true を指定できる場合には、
これが指定されたものとみなします >>26。それ以外の場合はどこでも定義されていません。
[21] 小文字が正準形です RFC 6067 2.1.1., >>31。
[22] 属性とキーの順序は意味がありませんが、ASCII 符号位置の順序で並べたものが正準形です RFC 6067 2.1.1., >>31。
[20] 属性、キー、型は追加されることがあります。 しかし削除されることや本質的な意味が変更されることは無いとされています。 RFC 6067 2.1.
[23] 既存の属性、キー、型の意味に本質的な変更が加わったり、 それらの構造自体が変わったりすることはないとされていますが、 仮にそのような変更がなされる場合には新しい RFC が発行されることとなっています RFC 6067 2.。
[37] u 拡張は BCP 47
言語タグの構文上利用可能なすべての拡張の部分タグの並びを構文的に正しい値として認めています。
従って言語タグの u 部分の整形式性と u
拡張としての構文的な正しさは等価です。
[36] しかし構文的に正しいすべての u 拡張の部分タグに対して意味が定義されているわけではありません。
UTS #35 や >>25 で属性やキーや型で妥当であるものの一覧が提供されており、
それに基づき u 拡張が妥当かどうかを判断できます。
[6] 言語タグde-DE-u-attr-co-phonebk
... を表します RFC 6067 2.1.。
[29] Unicodeロケール識別子 >>26de_DE_u_co_phonebk_cu_ddm
[32] >>31 ... は正準形ではありません。u-foo-bar-nu-thai-ca-buddhist
u-bar-foo-ca-buddhist-nu-thai
... は正準形です。
[50] [css-fonts-4] Clarify precedence of font-presentation versus lang/xml… (Litherum著, ) https://github.com/w3c/csswg-drafts/commit/ee2603f6fd2d90e070a3d393159033651eb0c1b7
[51] [css-fonts-4] Clarify precedence of font-presentation versus lang/xml:lang · Issue #2138 · w3c/csswg-drafts () https://github.com/w3c/csswg-drafts/issues/2138