[20] 結けつ 合ごう 文も 字じ combining character 基底文字 と合成 されて表示されるべき文字 です。
仕様書 [142] The Unicode Standard , Version 13.0 - ch02.pdf2020-03-09T17:53:32.000Z , 2020-12-06T08:54:12.180Z
https://www.unicode.org/versions/latest/ch02.pdf#G1708 [209] The Unicode Standard , Version 13.0 - ch03.pdf2020-03-09T17:53:34.000Z , 2020-12-31T08:45:19.650Z https://www.unicode.org/versions/latest/ch03.pdf#G50313 [9] The Unicode Standard , Version 12.0 - ch03.pdf2019-03-02 07:15:30 +09:00 ) http://www.unicode.org/versions/latest/ch03.pdf#G30602 [30] D53[38] D54[39] D55[45] D56[47] D56a[49] D57[115] Application of Combining Marks
https://www.unicode.org/versions/latest/ch03.pdf#G50030 [185] The Unicode Standard, Version 13.0 - ch05.pdf , 2020-03-09T17:53:36.000Z , 2020-12-08T11:02:06.579Z https://www.unicode.org/versions/latest/ch05.pdf#M9.31810.Heading.511.Strategies.for.Handling.NonSpacing.Marks [164] The Unicode Standard , Version 13.0 - ch07.pdf2020-03-09T17:53:38.000Z , 2020-12-07T09:15:13.901Z https://www.unicode.org/versions/latest/ch07.pdf#M9.37081.HeadingBreak.79.Combining.Marks [18] Glossary (2014-12-06 10:49:08 +09:00 版) https://unicode.org/glossary/#combining_mark
[278]
UAX #15: Unicode Normalization Forms , 2024-08-14T19:11:21.000Z , 2025-07-02T03:56:32.187Z https://unicode.org/reports/tr15/#UAX15-D3 [53] UAX #44: Unicode Character Database , 2020-03-06T22:23:11.000Z , 2020-10-21T06:24:49.510Z https://www.unicode.org/reports/tr44/#Default_Values_Table [103] UAX #44 : Unicode Character Database2016-06-21 02:42:04 +09:00 ) https://www.unicode.org/reports/tr44/#General_Category_Values [54] UAX #44: Unicode Character Database , 2020-03-06T22:23:11.000Z , 2020-10-21T08:24:32.981Z https://www.unicode.org/reports/tr44/#Derived_Extracted [55] UAX #44: Unicode Character Database , 2020-03-06T22:23:11.000Z , 2020-10-21T08:37:23.285Z https://www.unicode.org/reports/tr44/#Canonical_Combining_Class_Values [56] UAX #44: Unicode Character Database , 2020-03-06T22:23:11.000Z , 2020-10-21T08:49:23.551Z https://www.unicode.org/reports/tr44/#Property_Invariants [101] UTS #46 : Unicode IDNA Compatibility Processing2016-06-02 03:53:22 +09:00 ) https://www.unicode.org/reports/tr46/#Validity_Criteria [57] UAX #44: Unicode Character Database , 2020-03-06T22:23:11.000Z , 2020-10-21T08:53:55.034Z https://www.unicode.org/reports/tr44/#Invariants_in_Implementations [116]
結合文字 の適用 については、
The Unicode Standard
は規定 と指針 guideline 文字のレンダリング に関する指針については、
レンダリング について特に情報が与えられない場合の既定のレンダリングの挙動を示すものとされています。
個々の文字について typograph 的な慣習がある場合には、
適宜それを使って最適なレンダリング を実現することが期待されています。
>>115
[141]
文字 の扱いは文化と慣習に依存した部分が大きく、
フォント やレンダリングシステム文字のレンダリング の影響も大きいので、
厳密に規定 することには困難が多いのでしょう。
それにしても曖昧な規則が多く、
こんなので相互運用性 は保てるのか疑問に思ってしまいますが、
実際相互運用性 はかなり低いと言わざるを得ません。
違うシステムでレンダリング が違うのは当たり前で、
同じシステムでもインストールされているフォント の違い程度の些細な要因で違って表示されることがよくあるのが現状です。
結合文字とその分類 [10] 結合文字combining character 結合マークcombining mark General_Category が
Combining Mark (MarkM文字
(符号位置 )
です。
>>9 , >>101 , >>18
[12] 私用文字 (Co 結合文字 と解釈するか否かは、
実装 によります >>9 基底文字 扱いとされています。
基底文字 、私用文字
[143]
結合文字 は、
関連付けられた基底文字 に対して相対的に決まる位置に表示される文字 です
>>142
[150]
具体的には、
アルファベット 系文字などに対するダイアクリティカルマーク 、
アラビア文字 の harakat 、
デバナガリ文字 の matra 、
仮名 の濁点 ・半濁点 、
記号用ダイアクリティカルマークsymbol diacritic 、
囲み文字 を作るための外枠文字 などが結合文字 として用意されています。
[210]
異体列 に使われる異体選択子 も結合文字 とされています。
[23] 結合文字 の一覧 (結合文字 と解釈する Co を除く)
https://chars.suikawiki.org/set/%24unicode%3Acombining-character [31] General_Category =MMark https://chars.suikawiki.org/set/%24unicode%3AMark [144] 結合文字 には、
非前進マーク と前進マーク があります。
>>142
[24] 非前進マークnonspacing mark General Category
が
Nonspacing Mark (MnNonspacing Mark Enclosing Mark (MeEnclosing Mark 結合文字 です。
>>30
[29]
囲みマークenclosing mark 非前進マーク であって
General Category
が
Enclosing Mark (MeEnclosing Mark 囲みマーク は、
非前進マーク の部分クラス であって、
基底文字 の上中下に配置するのではなく、囲むものです。
>>38
[145]
非前進マーク は、
それ自体で表示上の位置 (spacing position)
を占有しません >>142 基線 上を先へと進み (baseline advance) ません
>>164 基底文字 が単独の場合と、
基底文字 と非前進マーク との組合せの場合とで文字幅 (advance width)
が変わってくることはあります
>>142
[40]
前進マークspacing mark 結合文字 であって非前進マーク ではないものです。
>>39
[165]
前進マーク は通常の文字のような挙動を示し >>164 >>164 [206]
General_Category は Mc[207]
異体選択子 と併用して異体列 を作ることが出来ます。 [166]
Unicode 以前の文字コード で結合文字 に相当するものは非spacing文字 などと言っていました。
しかし Unicode の結合文字 には spacing な文字も非spacing
な文字もあるのです。[113] この分類は書記素クラスター の定義に関わってきます。
[26]
General_Category の値
Mark = M
は、
Spacing Combining Mark (Mc Nonspacing Mark (Mn Enclosing Mark (Me >>9 , >>103
[44] nonspacing mark の一覧
https://chars.suikawiki.org/set/%24unicode%3Anonspacing-mark [43] enclosing mark の一覧
https://chars.suikawiki.org/set/%24unicode%3Aenclosing-mark [109] spacing mark の一覧 (結合文字 と解釈する Co を除く)
https://chars.suikawiki.org/set/%24unicode%3Aspacing-mark [110] General_Category =Mn https://chars.suikawiki.org/set/%24unicode%3AMn [111] General_Category =Me https://chars.suikawiki.org/set/%24unicode%3AMe [112] General_Category =Mc https://chars.suikawiki.org/set/%24unicode%3AMc [211]
ZWJ,
ZWNJ
は結合文字列 に含まれ得る文字 で、
結合文字 に近い扱いを受けていますが、
結合文字 ではありません。
結合文字列 [13] 結合文字 は、通常は単独では用いません。 >>9 基底文字 の後に0個以上の結合文字 を続ける形で使います。
結合文字 は、その依存 する基底文字 の後に続けます
>>115 P1, >>142 , >>164
[151]
この順序は、
Semitic scripts
とインド系文字 の論理順 と一貫したものとされます。
更に、
近代フォント 技術の nonspacing
なグリフ の取り扱いとも合致しているため処理しやすいとされます。
>>142 , >>164 [83]
Unicode
の結合文字 は後置です。
Unicode 以前の文字コード 規格には前置式を採用したものもありましたが、
Unicode
との変換では順序を入れ替える必要があります。
非spacing文字
[156]
結合文字 の数には制限がありません。
>>142 , >>115
[229]
現実には、セキュリティー のため実装は現実的な個数に制限する必要があります。
プラットフォーム制限条項
上限を超えた場合は、合成しないで表示するなど、代替手段を採ることになります。
[277]
Stream-Safe Text Format
では、 NFKD 状態で30個以下と制限されています。
この制限は、
実用よりも十分長く、実装上のバッファー長に余裕がある (UTF-8 でも
UTF-16 でも UTF-32 でも
128バイトを超えない)
と説明されています。
>>278 (UAX15-D3 )
[46]
結合文字列combining character sequence CCS ) は、
基底文字 が0個または1個の後に、
1つ以上 の結合文字 、
ZERO WIDTH JOINER、
ZERO WIDTH NON-JOINER
のいずれかが続くような列であって最長のものです。
>>45
?基底文字 +|結合文字 ZERO WIDTH JOINERZERO WIDTH NON-JOINER [48]
拡張済み結合文字列extended combining character sequence ECCS ) は、
拡張済み基底 が0個または1個の後に、
1つ以上 の結合文字 、
ZERO WIDTH JOINER、
ZERO WIDTH NON-JOINER
のいずれかが続くような列であって最長のものです。
>>47
?拡張済み基底 +|結合文字 ZERO WIDTH JOINERZERO WIDTH NON-JOINER [80] ただの結合文字列 とは、
標準韓音節ブロック が含まれるかどうかが違います。
拡張済み基底 [82]
「結合文字」の列というと0文字以上の結合文字 の列のように聞こえますが、
実はそうではなく基底文字 も (あれば) 含まれますし、
結合文字 のかわりに
ZWJ / ZWNJ
が含まれる列のこともあります。
[114]
結合文字列 、
拡張済結合文字列 は書記素クラスター と似ていますが、
違うこともあります。
書記素クラスター
[212]
結合文字 の順序には、意味があることも、ないこともあります。
(>>186 )
[146]
Unicode
と
Unicode
以外の文字コード を混在させられるシステムもあります。
例えば
ISO/IEC 2022
は
ISO/IEC 10646
と混在させる仕組みを定義しています。
すると
Unicode (ISO/IEC 10646 )
とそれ以外の基底文字 と結合文字 の組合せも理屈の上では存在し得ます。
しかし
Unicode
はそうしたものを想定していないので何も言及していませんし、
ISO/IEC 2022
側にもそうした規定 はありません。
結局そのようなシステムがどう動作するべきかは不明と言わざるを得ません。
[232]
現実的には、
そのシステムにおいて Unicode文字 と非Unicode文字 に対応関係が存在するなら、
その対応関係に基づきすべてUnicode文字 だった場合と同等に動作するのでしょうし、
そうでなくても非Unicode文字 が基底文字 であるか、
結合文字 相当のものであるかに応じて動作するのでしょう。
[233]
また非spacing文字 など Unicode にない概念の文字と Unicode文字 との組み合わせもありえます。
[234]
すると基底文字 、結合文字 、非spacing文字 のすべての組み合わせで構成される文字列 の出現の可能性も一応考えておかなければなりません。
基底文字と結合文字の関係性 [88]
結合文字 の関連付けられた基底文字associated base character 結合文字列 中の基底文字 です。
>>115 D61a
[14] 結合文字 の図形 の位置付けは、直前の基底文字 であって非結合文字 で
zero width joiner でも zero width nonjoiner でもないものに依存します。
この時結合文字 を基底文字 に適用するapply >>9 結合文字 は関連付けられた基底文字 に依存するdepend 依存性dependence >>115 D61a
[118] 関連付けられた書記素基底 とそれへの適用関連付けられた書記素基底
(図形的適用 )
と似た意味ですが、
少しずつ定義が違います。
依存性 はすべての種別の結合文字 に関係します。
図形的適用 は可視グリフ を持つ
nonspacing mark
に関係します。
孤立結合文字 [15] 結合文字 が適用 されるべき基底文字 がない場合
(結合文字 が文字列 の先頭の場合や、
制御文字 や書式文字 が前にある場合) には、
孤立結合文字 isolated combining character >>9
[81]
結合文字列 のうち基底文字 がないものを欠陥結合文字列defective combining character sequence >>49
[117]
欠陥結合文字列 中の結合文字 には関連付けられた基底文字 がありません。
どの基底文字 にも依存する とはいえません。
>>115 D61a
[19]
完全正規化済み など孤立した結合文字 が出現しないことを要求する応用 もあります。
[89]
意図的に使うことはあまりありませんが、
Unicode文字 の一覧表などに出現することがあります。
結合文字 を考慮しない文字列 の分断 (一定の文字列長での分割など)
で生じることもあります。
[198]
なお、
文頭において結合文字 を含まず
ZWJ,
ZWNJ
のみで構成される欠陥結合文字列 は、
正当に利用され得るものであるはずです。
続け字
[231]
結合文字 はフォント 上で現在位置 より前に表示されるなど、
単独でレンダリング するとき取り扱いに注意を要することがあります。
結合文字と空白の合成 [86]
結合文字 自体を単独の文字 として使いたいときは、
基底文字 として
U+00A0 NO-BREAK SPACE
を使うことが出来ます。
>>142 , >>164
[162]
Unicode 4.1
までは、
U+0020 SPACE
を使うことが推奨 recommended XML
などの
U+0020
の扱いと衝突することが理由とされています。
>>142 , >>164
[87]
HTML と CSS (white-space:normal)
のような空白 を正規化する処理が適用される環境では、
U+0020 を使うと思わぬ意図せぬ結果がもたらされることがあります。
[92]
CSS の text-emphasis は Z*
の文字かどうかで挙動が変わりますが、
間隔 と結合文字 が組み合わさったケースでは一般の文字と同じ扱いになります。
[163]
The Unicode Standard
の「推奨」
は変更されましたが、
互換分解 は変更されていません (一度決めたら変更されないこととされています)。
多くの単独のダイアクリティカルマーク は
NFKC 、
NFKD
を適用すると
U+0020
が生成されてしまいます >>164 U+00A0 も NFKC , NKFD では U+0020
になります。)
[269]
単独のダイアクリティカルマーク と、それを互換分解 したものとで、
期待されるレンダリング が異なることがあります。
発音区別符付き仮名
[235] 方向性 との相互作用にも注意が必要です (>>169 )。
[270]
縦書き との関係にも注意が必要です。
例えば゛ を空白 と結合文字 との組み合わせで表現したいからといって、
U+0020 や U+00A0 や U+2003 と U+3039 を組み合わせると、
縦書き したときに回転して寝かされて回転 (書字方向) しまいます。
[271]
U+3000 と U+3099 や U+309A を組み合わせると、
Windows の Firefox では適切に表示されますが、
Windows の Chrome ではなぜかフォント の指示に従って表示されません。
U+3099 や U+309A は明らかに別のフォント で、
基底文字 の隣に分かれてレンダリングされます。
すべてのUnicode符号位置 のグリフ を持つフォント を指定しても、
それではないフォント の濁点 が表示されてしまいます。謎です。
U+0020 や U+00A0 や U+2003 EM SPACE
ではこのような怪現象は発生しないのですが、
U+3000
だけ特殊な表示処理があるのでしょうか。
他の結合文字 でも発生しないようです。
2025-01-28T13:03:00.100Z
基底文字の種類 [85]
結合文字 が適用 される基底文字 には制約がありません。
すべての結合文字 は、すべての基底文字 に対して使うことが出来ます
>>142 基底文字 と結合文字 の組合せ、
例えば基底文字 を「。」 (句点 )、
結合文字 を濁点 とするような組合せは日本語 としておおよそあり得ませんが、
Unicode
として禁止されていません。
(それが意味を成すか、
意図した通りにレンダリングされるかどうかは、
また別の問題です。 >>148 )
[169]
U+00A0
を始め中立方向性 の文字 を基底文字 とするとき、
bidi
処理によって基底文字 とspacing結合文字 が分離されて意図せぬ形で表示される場合があります。
>>164 LRM,
RLM,
bdi
の類を適宜使う必要があります。
[139]
韓音節 の書記素クラスター にあっては、
結合文字 は最後の字母 だけではなく音節 全体に適用 されます。
enclosing combining mark
も音節 全体を囲みます。
>>115
[225]
ハングル音節 に対しては、声調符号 や濁点 が付与されることがあります。[161]
基底文字 の並びが合字 として表示される場合であっても、
結合文字 はそれが適用 されるべき各部分の基底文字 の後に置きます。
結合文字 は ligated glyph の各部分に対して表示します。
>>142 , >>164
[175] ただし合字 になるかどうかは
typographic 的な慣習に依存します。
ダイアクリティカルマーク が付かない時合字 化されても、
ダイアクリティカルマーク が付いたことで合字 化されないこともあります。
>>164 性質 [11] 正準結合クラス が 0 でない文字 は、結合文字 です。
しかし逆 は真ではありません。正準結合クラス が 0 の結合文字 もあります。 >>9
[22] >>21 は、正準結合クラス が 0 の結合文字 の一覧です。[21] Character set "$unicode:Mn | $unicode:Mc | $unicode:Me - $unicode:Canonical_Combining_Class:non-0" (2015-03-22 23:52:41 +09:00 版) https://chars.suikawiki.org/set?expr=%24unicode%3AMn+%7C+%24unicode%3AMc+%7C+%24unicode%3AMe+-+%24unicode%3ACanonical_Combining_Class%3Anon-0 [153]
多くのアルゴリズム (すべてではありません。) は、
基底文字 に結合文字 が続く列を、
基底文字 の特性特性 (UCD) を持つものとして扱います。
>>142 >>149 )。)
結合文字相互の順序 [186]
1つの基底文字 に対して、
結合文字 はいくつでも適用 できます。
結合文字 の順序には制約がありません。
順序が意味を持つケースと、
意味を持たないケースがあります。
正準等価 なものは同じようにレンダリングしなければなりません
>>185
[14]
typograph的てき 相互作用そうごさよう typographic interaction grapheme base
に対する相対的な位置が既に他の
nonspacing mark
に占有されているような
nonspacing mark
の図形的応用 であって判読不能な重ね打ちやグリフ の衝突を防ぐべく何らかのレンダリング 上の調整
(default stacking や side-by-side placement など)
が行われなければならないものをいいます。
>>209 D106
[119]
指針 として、
同じ結合クラス の
nonspacing mark
は、
通常、
適用 する書記素基底 から図形的に外側に向かって配置していきます
(inside-out application ,
default stacking behavior )。
>>115 P2, >>185 結合文字 は垂直に上方向へ、
下側に置く結合文字 は垂直に下方向へと重ねていきます。
>>142 , >>115 P2
[157]
タイ文字 にあっては、
子音文字 に対して
U+0E34 - U+0E37 の母音 を上に置き、
更に
U+0E48 - U+0E4B の声調記号 をその上に置きますので、
この順序で文字 を並べます。
>>142
[120]
指針 として、
特定の
nonspacing mark
については、
垂直に並べる default stacking behavior
ではなく、
書記素基底 の上下に横並びで、
言語 依存の正書法 規則に従い配置します
(side-by-side application )。
>>115 P3
[121]
side-by-side application
における結合文字 の視覚的なレンダリング順序は、
当該用字形 における支配的な順序に依ります。
>>115 P3, >>142 左横書き では左から右に並べます。
>>142 ギリシャ文字 では書記素基底 の上に、
1つ目の結合文字 を左側、
2つ目の結合文字 を右側に置きます。
ヘブライ文字 では逆側に置きます。
>>115 P3
[158]
例えばギリシャ文字 にあって、
breathing mark
の
U+0313 COMBINING COMMA ABOVE,
U+0314 COMBINING REVERSED COMMA ABOBE
は、
acute accent , grave accent
と併用する時、
side-by-side application
します。
基底文字 、
breathing mark 、
accent mark
の順に並べ、
基底文字 の上に左が
breathing mark 、
右が
accent mark
と表示されます。
>>142 [122]
U+1ABB COMBINING PARENTHESES ABOVE,
U+1ABC COMBINING DOUBLE PARENTHESES ABOVE,
U+1ABD COMBINING PARENTHESES BELOW
は side-by-side application します。
>>115 P3ドイツ語 の方言学 で、
発音 の修飾子 の効果が弱められることを表します。
これらよりも前にあるダイアクリティカルマーク を囲むように配置します。
>>164 [181] これも side-by-side application
の一種とされますが、その定義とは少し違う別種の配置のような...[123]
指針 として、
伝統的な
typographic
な挙動により
nonspacing mark
の既定の配置を上書きする場合があります。
>>115 P4
[168] 基底文字 との関係で結合文字 の字形 が変化するケース: >>124 , >>125 [126]
アラビア文字 の母音記号 の相対配置は
default stacking behavior
だけでは説明できず、
アラビア文字 typography
の伝統的規則に依存します。
>>115 P4[160]
ヘブライ文字 、
キリル文字 でも特別な扱いが必要となります。
>>142 [187]
現代越南語 では、
声調記号 の
acute accent や grave accent
は、
circumflex accent
の上ではなく横に配置されることがあります。
>>185 [136]
指針 として、
Soft_Dotted特性特性 (UCD) の文字 に
nonspacing mark above
(ccc = 230 結合文字 )
が適用 されるとき、
基底文字 に元々有る点 は、
表示しません。
>>115 P9
[137] i や j の類が該当します。
この上にダイアクリティカルマーク が来る時、
点 のかわりにダイアクリティカルマーク を書きます。
リトアニア語 のように点 とダイアクリティカルマーク の両方を書く言語 では、
U+0307 COMBINING DOT ABOVE
を使います
>>115 P9
[138] Soft_Dotted な文字の一覧
https://chars.suikawiki.org/set/%24unicode%3ASoft_Dotted [127]
0 でない 結合クラス の
non-spacing mark
の順序を入れ替えても、
結合文字列 の視覚的表示や解釈は変化しません
(nondistict order )。
>>115 P5>>142 >>185 正準再順序付けアルゴリズム はこの性質に関する正規化 の処理です。
NFC
などの正規化 を適用すると、
結合文字 の順序が交換されることがありますが、
それは解釈に影響が出ない場合に限られます。
[128]
combining grapheme joiner
を使うと
nondistinct order
であっても正準再順序付け を抑制できます。
>>115 P5
[129]
指針 として、
enclosing mark
は、
関連付けられた書記素基底 やそれとの間にある
enclosing mark
を囲むものとなります。
>>115 P6
[130]
囲み文字 に
nonspacing mark
を付けて更に囲むような入れ子の構造も記述できます。
[182]
U+1DC0 COMBINING DOTTED GRAVE ACCENT,
U+1DC1 COMBINING DOTTED ACUTE ACCENT
は、
ギリシャ文字 で使われ、
dialytika varia
と
dialytika oxia
の組み合わせの異体字 です。
U+0308 COMBINING DIAERESIS,
U+0300 COMBINING GRAVE ACCENT,
U+0301 COMBINING ACUTE ACCENT
と混じると通常の stacking rule
では結果が信頼できないcannot be reliably formed ために別の文字として追加されたといいます。
>>164
[183] 理由が「表現できない」ではなく「信用できない」であるところに闇 を感じます...二重ダイアクリティカルマーク [170]
二重ダイアクリティカルマーク の結合文字 は、
2つの基底文字 の上や下に表示されますが、
1つ目の基底文字 の後に続く結合文字 として使います。
[131]
指針 として、
二重ダイアクリティカルマーク な
nonspacing mark
は、
書記素基底 に適用 しますが、
次の書記素基底 も包むようなグリフ としてレンダリング されることが意図されています。
>>115 P7
[132] U+0360 COMBINING DOUBLE TILDE
が該当します。
>>115 P7[133]
指針 として、
二重ダイアクリティカルマーク な
nonspacing mark
は、
書記素基底 の上下に積んだ通常の
nonspacing mark
の最外側に「浮動」します。
>>115 P8, >>164 >>164
[135]
ただ
enclosing mark
と二重ダイアクリティカルマーク との図形的な相互作用は十分に定義されておらず、
多くのフォント やレンダリング 処理はこれを適切に扱えないかもしれません。
従って両者を同じ書記素クラスター に含めることは推奨 されませんnot recommended >>115 P8
[134]
二重ダイアクリティカルマーク な
nonspacing mark
の結合クラス は非常に高く設定されているので、
正準順序 では結合文字列 の最後の方に現れます。
>>115 P8, >>164 [171]
COMBINING GRAPHEME JOINER
を使うと正準再順序付け が抑制されます
>>164 結合文字 とそれ以後の結合文字 が区別されることになります。
これを使うと、通常なら二重ダイアクリティカルマーク より内側に表示される結合文字 を、
二重ダイアクリティカルマーク より外側に表示するよう指定できます。
COMBINING GRAPHEME JOINER
[178]
縦書き 時の扱いは特に規定されておらず、注意が必要となります。
縦書き字形 、組み合わせて使う文字
[172]
3文字以上に対するダイアクリティカルマーク は、
Unicode
では扱えないとされています。
マーク付け によって記述するべきだとされています。
>>164
[173]
限られた状況では combining half mark
が活用できることもあるものの、
平文 で満足できるレンダリング は成せないといいます。
>>164
[174]
こうしたものを用いる応用 の実装のためには、
Unicode
で結合文字 として記述できる二重ダイアクリティカルマーク だけでなく、
マーク付け言語 により記述される三重以上のダイアクリティカルマーク をも扱える仕組みが
(共通であれ別々であれ)
必要となってきます。
[260]
なお、後続の文字 (3文字以上の場合も含みます。) に作用する文字 として、
Prepended_Concatenation_Mark
たる文字 があります。
結合文字の前後連結 上下左右線の文字
[184]
二重ダイアクリティカルマーク を分割した結合文字 である
combining half marks
もあります。
これらは互換性文字 で、
二重ダイアクリティカルマーク が好ましいpreferred とされます。
>>164
レンダリング [148] 任意の結合文字 は任意の基底文字 に適用 できます (>>85 ) が、
実装はすべての組合せを等しく良く対応する必要はありません。
>>85
[189]
基底文字 + 結合文字 の組み合わせという仕組みから、
文字 の図形も合成で表示できそうな気がしますが、
現実には組み合わせごとに調整しなければ実用できる品質にはなりません。
[243]
例えば「A」と「a」の上部にアクセント記号を付け加えることを考えると、
汎用アクセント字形を単純に重ね合わせるだけでは美しくならないことがわかります。
[242]
大抵のフォント は、
一般的に用いられる組み合わせのグリフ を予め用意しています。
これが結合文字列 の表示方法の1つです >>185 グリフ 全体を別途用意しなくても、
基底文字 のどの位置に結合文字 を配置するかの情報があれば足りることもあります
>>185 フォント の ligature や kerning のような技術が使われることがあります
>>185
[190]
ですが、任意の組み合わせが許されている以上、
あらゆる組み合わせを想定したフォント を用意することは不可能です。
用意された組み合わせはフォント によっても異なります。
従って文字のレンダリング の実装は、
用意されていない組み合わせも何らかの形で扱える仕組みを持っていなければなりません
(>>244 )。
[194]
基底文字 と結合文字 の関係は、
書字方向 とは関係しません。
結合文字 は表示上表示順 の左側の文字に適用されるのではなく 、
論理順 の前の文字に適用されるのです。
従って右横書き では左側の文字ではなく右側の文字に適用されることになります
>>185
[152]
インド系文字 の母音記号 の結合文字 には、
子音文字 や子音クラスター の左側にレンダリング されるものもあります。
左横書き で左から右に文字 を並べ、
基底文字 の後に結合文字 を置く順序であっても、
基底文字 が右、結合文字 が左とそこだけ逆転します。
これは表示順ではなく発音順を取ったもので、
Unicode 以前の文字コード ISCII
の方式に倣ったものとされます。
>>142
[202]
結合文字 が組み合わさることで、
結合文字列 の幅と高さは基底文字 の幅と高さから変化させることがあります。
文字 や行 の配置、
字間 、行間 の調整においては、
結合文字列 の幅と高さを使って適切にレイアウトする必要が出てきます。
[203]
通常では使わないような異常な(1つ以上 の)結合文字 の利用によって、
上下左右の文字 その他の構造に重ねて表示させる悪戯があります。
悪戯で済めば良いですが、
フィッシング などに悪用できないとも限りません。
文字のセキュリティー
非前進マーク [32]
非前進マーク の表現 presentation 基底文字 に依存します。
通常はそれ自体に関して visual baseline に対して間隔を消費しません。
>>30
[33]
ただし、非前進マーク の大きさによって基底文字 の表示位置が影響されることはあります。
>>30
[34] 例えば U+20DD COMBINING ENCLOSING CIRCLE
を使うと (それ自体が独立して表示幅を取ることはありませんが)
その前の基底文字 の周りに円を描画して、かつ前後の文字 と表示が重ならないよう、
基底文字 の表示位置が通常と変化することになります。
[167]
U+0301 COMBINING ACUTE ACCENT
のように、
ラテン文字 としての字形 とギリシャ文字 としての字形 が異なるものもあります
>>164 基底文字 によって字形 が変化します。
なおラテン文字 であってもポーランド語 とフランス語 とでは字形
(角度) が違います
>>164 [124] g の下方と combining comma below
が衝突してしまうので、
かわりに
inverted comma above
として伝統的にレンダリング されてきました。
>>115 P4, >>164 [125] d の上方と
combining caron
が衝突してしまうので、
かわりに
apostrophe
として伝統的にレンダリング されてきました。
>>115 P4, >>164 [195]
字間 の調整は、
基底文字 と結合文字 の間で行うべきではありません
>>185 書記素クラスター の間で行うべきものでしょう
(が、二重ダイアクリティカルマーク など注意が必要なケースがあります)。
囲み結合マーク [149]
combining enclosing mark
は、
記号 symbol 文字 に使うのに留めるのがいいですbest to limit 。
>>142
[155]
その理由は、
文字特性 の不一致が起こることでの驚きを抑えられることとされています。
>>142
[236]
例えば
U+0021 EXCLAMATION MARK
と
U+20E4 COMBINING ENCLOSING UPWARD POINTING TRIANGLE
で警告マーク を表せますが、
!
が句読点 であるが故に改行 について通常の記号 とは異なる挙動を示します。
[237]
故に
U+26A0 WARNING SIGN
は別に単独の記号 として用意されており、
正規化 による分解 もされません。
>>153
[238]
その他一般に合成済の囲み文字 は互換分解 はあっても正準分解 はされません。
これは特性文字特性 の不一致が理由とされます
>>164 [239]
その種の特性は本来書記素クラスター に対して適切に設定されるべきだったのでしょう。
これは仕様の欠陥と言えますが、後方互換性 のため今更修正するわけにもいかないのでしょう。[154] Vertical_Orientation
は書記素クラスター に対して定義され、
Me
の場合だけ書記素基底 のものではなく固定値が割り当てられます。
Vertical_Orientation
[240]
このような扱いなのは Vertical_Orientation が比較的新しい特性であることと関係するのでしょう。[140]
古い実装は、
Indic consonant conjunct
や、
combining grapheme joiner
で連結された書記素クラスター 群全体に対して
enclosing combing mark
で囲んでいました。
そうした手法には数々の問題があるので、
推奨されませんnot recommended 。
>>115
[201]
なぜか非推奨であって禁止はされていないようです。
相互運用性 は低そうです。
[200]
非推奨とするだけで、
代替手段は用意されていないようです。
前進マーク [41]
前進マーク は一般に基底文字 とそう違わない挙動を示します。
>>39
[42]
しかし U+0BCA TAMIL VOWEL SIGN O
のように、
(囲みマーク でないにも関わらず)
基底文字 の両側にレンダリング されるものもあります。
>>39
フォント情報に基づく結合文字列のレンダリング [216] GSUB, cmap
[217] OpenType development (LEGACY INFORMATION) - Typography | Microsoft Docs , nihar , 2022-08-27T06:51:43.000Z https://docs.microsoft.com/ja-jp/typography/develop/otdevinfo#suggested-glyphs-for-complex-scripts
[220]
OpenType
におけるグリフ級 3 マークグリフmark glyph
[221]
グリフ におけるマークグリフ は文字 における結合文字 (結合マーク )
に近い概念です。
マークグリフ は単体で使うことが想定されず、
基底グリフ または合字グリフ と組み合わせて使います。
[222]
マークグリフ を基底グリフ や合字グリフ と組み合わせるには、
基底グリフ や合字グリフ の表すグリフ の形状や、
他のマークグリフ の形状が関係してきます。
フォント の設計者は関係グリフ の相互関係を記述しなければなりません。
OpenType フォント ではその情報を
GPOS 表OpenType表 に格納できます。
グリフ位置決定
[246]
マークグリフ であるかどうかはフォント の GDEF 表OpenType表 で指定でき、
結合文字 のグリフ をマークグリフ でなく基底グリフ とすることも可能です。
これがどのような意味を持つのか (同じフォント の GPOS 等からの参照以外に影響があるのか)
は十分明らかではありません。
[247]
例えば結合文字 のグリフ を基底グリフ とすることで、
グリフ の表示や文字列の選択 の挙動を基底文字 であるかのように変更できるでしょうか。
少なくても Windows の Chrome や Firefox では、
文字列の選択 の単位や (kern がないときの) 結合文字 のグリフ の描画位置について、
GDEF の指定は効果がないように見えます。
2023-11-10T13:28:10.400Z
[255]
>>247
GDEF によりマークグリフ として指定されると、
横書き なら横方向、
縦書き なら縦方向の現在位置 の進行が0とみなされます。
後続のグリフの描画位置に影響するのはもちろん、
文字列の選択 の範囲にも影響します。
[257]
>>247 GDEF で指定がないときの既定値が違うのか、
U+3099 だと進行しない、
U+16FF1 だと進行するのが何も指定しないときの挙動で、
GDEF で挙動を切り替えられます。
[249]
Windows の Chrome や Firefox では、
専用グリフ の有無に関わらず、結合列
(なのか書記素クラスター なのかその他なのか、詳細は要検証)
は文字列の選択 において1単位として扱われます。
[250]
Windows の Chrome や Firefox では、
GPOS
があれば、
結合文字 のグリフ の配置もそれに従うようになります。
それがない場合には、
結合文字 のグリフ を (結合文字 の X軸 の絶対値は無視して)
基底文字 上の左右中央に揃えて配置します。
2023-11-10T13:40:49.00Z
[251]
縦書き のとき、 Windows の Chrome も Firefox も、
GPOS
があれば結合文字 を下隣に、高さ方向の現在位置 を移動させずに配置します。
GPOS
がなければ結合文字 を右上に、高さ方向の現在位置 を移動させずに配置します。
[253]
なぜ右隣でも上隣でもなく右上なのか謎です。
本来ならフォントに情報がないときに最も好ましい挙動は、
書記素クラスター だけ縦中横 でレンダリング することで横書き 時と同じ表示にすることでしょうか。
濁点 や U+16FF0 が典型例でしょうが、
下に置くより右に置く方が遥かにマシな表示になるはずです。[252]
縦書き のときの文字列の選択 の挙動は、 Firefox は基底文字 部分を選択するまあ妥当な挙動ですが、
Windows はそれより大きく、しかし結合文字 部分を含めているわけでもない謎の範囲を選択するように見える謎挙動です。
[256]
現在位置 を移動しないので次のグリフ に重なる、という部分はマークグリフ にしないことで回避できます
(>>255 )。
基底グリフ でなくてもマークグリフ でも可で、 GDEF
が存在しないことでも回避可能です。
[254]
グリフ 間の位置関係は kern / vkrn で調整できそうなものですが、
Firefox でも Chrome でも効果があるようには見えません。
[261] Windows の Chrome で試してみました。 2025-01-24T09:58:16.600Z
[262] GDEF がなければ、結合文字 のグリフ は前進幅 に関わらず前進幅
0 とみなされます。つまり前のグリフ の続きで配置されますが、
前進幅 を加算せずに次のグリフ の処理になります。
GPOS mark があっても無視されます。[263] GDEF があって無指定なら、結合文字 のグリフ であっても基底グリフ とみなされるようで、
グリフ の前進幅 が無視されません。つまり前のグリフ の続きで配置され、
前進幅 を加算してから次のグリフ の処理になります。
GPOS mark があっても無視されます。[267]
ところが GDEF に指定がないのに結合文字 のグリフ に
GPOS mark
が指定され、
しかも前進幅 が加算されることがあります。何に依って挙動が変わっているのか不明です。[264] GDEF で結合グリフ と指定された結合文字 のグリフ は、
前進幅 に関わらず前進幅 0 とみなされます。 >>262 と同じ結果になります。
GPOS mark の指定対象になっていると、
結合グリフ は mark によって基底グリフ との位置が決定されます。[265]
mark に lookupType4 (MarkToBase)
を指定すれば適用されますが、
lookupType2 (pair)
を指定しても適用されません。[268]
しかし
lookupType8 (chained contexts) + lookupType1 (single)
を使えば基底グリフ ごと配置 や前進 を変更できます。
基底グリフ 上の位置に連動して MarkToBase の位置がずれるので、
結合グリフ も同期して移動することになります。[266]
mark でなく ccmp で MarkToBase を指定しても同じことになります。[272]
結合グリフ が複数ある場合、後続のものは適用可能な mkmk MarkToMark
があればそれを使い、なければ mark MarkToBase を使うようです。
[273]
同じ結合グリフ が複数あって mkmk で位置が指定されていないと、
同じ位置に同じグリフ が描画されるため1つしかないときと同じように見えます。
[274]
基底グリフ の左 にレンダリング されるべき U+302E
は何か特別な扱いになるらしく、
mark
がないとき、
Windows の Chrome では、
基底グリフ 、結合グリフ 、点線円グリフが左から順に並べられた状態になります。
基底文字 がないときは結合グリフ 、点線円グリフの順に並べられた状態になります。
[275]
mark があっても何か特別な扱いはされたままらしく、
基底グリフ と結合グリフ の原点 を揃えていても一般の文字だと >>274
と挙動が変わりません。
U+0020 , U+00A0
は結合グリフ 、空白、点線円グリフの順に並びます。
U+25CC は結合グリフ + 点線円グリフ、空白、点線円グリフの順に並びます
(1つ目が U+25CC 用のグリフで、2つ目が勝手に補われた点線円グリフでしょうか)。
左にある特殊な結合文字 故の特殊処理なのか、
それともハングル 絡み故の特殊処理なのでしょうか。
合成済グリフがない場合のレンダリング [244]
基底文字 と結合文字 の組み合わせは任意のものがあり得ますから、
従って文字のレンダリング の実装は、
フォント に用意されていない組み合わせも何らかの形で扱える仕組みを持っていなければなりません。
[17] Unicode 符号表 の代表画像 には点線の円が示されています。
>>9 , >>164 基底文字 と図形的結合して表示する場合には、基底文字 を点線円部分に示すことが想定されています。 >>9
[159]
default stacking behavior
は素朴な方法で基底文字 と結合文字 を重ねて表示することで
(品質はともかく)
一応実現可能です。
しかしその他の処理が必要となってくると、
表示位置や表示サイズを細かく制御する必要が生じてきます。
[188]
未対応の組み合わせの実装戦略
Simple Overlap
は、
基底文字 に重なる既定の固定の位置に結合文字 を描画するもので、
大文字 に合わせて高い位置に置くと小文字 との間に空間が生じたりします
>>185
[193]
nonspacing mark
は零幅 の文字で、現在位置 より左側に描画する、
という考え方が採られてきました。
この戦略は左横書き の場合にはそのままでうまくいきますが、
他に右横書き や上縦書き や下縦書き の場合も想定する必要があります。[16] 結合文字 が孤立結合文字 である場合や、図形的結合graphical combination を行えない場合には、
図形的結合なしに、基底文字 であるかのように表示して構いません。 >>9 Show Hidden
は、
基底文字 と結合文字 をそれぞれ独立した単位として配置し、
結合文字 には
Unicode
符号表 のように点線円を表示するといったものです
>>185
[191] 別々に表示されるとしても単独の書記素クラスター として、
1文字表示のときと同じようにカーソル 移動するべきかもしれません。
禁則処理 にも注意が必要となります。
また左横書き 以外に右横書き や上縦書き や下縦書き の場合も想定する必要があります。
[205]
点線の円は
U+25CC
DOTTED CIRCLE
(◌)
として用意されています。
これを基底文字 とすることで、
符号表 の字形を再現できます
(少なくても理屈の上では)。 IDS との関係は IDC
[248]
条件が複雑なので正確な挙動かどうかわかりませんが、
Windows の Chrome は基底文字 と結合文字 が同じフォント 内にないと次のフォント候補を探しフォントの選択 、
Windows の Firefox は基底文字 と結合文字 が別のフォント にあっても同じ位置に重ねるように見えます。
2023-11-10T13:35:25.100Z
(GPOS との絡みは要検証, 基底文字 側フォントの GPOS
の有無は影響しなそう。)
[258]
Windows の Chrome だと結合文字 に明示的に対応したグリフ がないとき (GPOS がないとき??)
に結合文字 の通常の配置に合わせて(?)基底文字 の上方にずらして結合文字 用グリフ を置くような未対応フォント向け制御も反映されているようです。
欠陥結合文字列のレンダリング [192]
欠陥結合文字列 は、
U+00A0 NO-BREAK SPACE
が基底文字 であるかのようにレンダリング するべきshould です。
>>185
[196]
とされますが、
実際には必ずしもそう実装されてはいないようです。
零幅 で、
直前の余白や他の構造に被さって表示されたりします。
[197]
欠陥結合文字列 のうち、
ZWJ,
ZWNJ
のみから構成されるものは、
零幅 でレンダリング されるべきものであるはずです。
またカーソル 移動なども直後の基底文字 と一体的に扱うべきかと思われます。
[245] >>16 も参照。
応用と結合文字 [223]
Unicode文字列 としては基底文字 とその後の0個以上 の結合文字 は連続していなければなりません。
しかし応用 によってはソースコード 上の文字列 と表示される文字列 とが違っていて、
基底文字 と結合文字 の関係性に変化が生じることがあります (例えば >>96 )。
また、文字列 とは別に与えられたフォント 指定等で基底文字 と結合文字 の関係性に変化が加えられることがあります。
[218]
OpenType 的にはフォント が違うと別の連なり に属するということになっています。
連なり
もし基底文字 と結合文字 で (または結合文字 と別の結合文字 で)
異なるフォント が指定されるとすると、
その両者は本来想定される「合成」状態で表示し得ないことになります。
[226] Unicode用字系特性値
データ形式と結合文字 [95]
テキスト 系のデータ形式 (マーク付け言語 )
と結合文字 の関係は、
テキストファイル としての表示や編集を考慮する時、
やや複雑になります。
[96]
例えば HTML のタグ の直後に結合文字 が来ると、
テキストファイル として見た時タグ の最後の > と結合文字 が合成されて表示されてしまいます。
[98]
文字参照 やエスケープ のような機能を使うと、
結合文字 を直接入力しづらいときでも、
代替表現で容易に指定できます。
[97]
完全正規化済 はこうした不思議な挙動を避けることを求めたものでしたが、
普及しませんでした。
CSS と結合文字 [94]
CSS の結合文字 の扱いは仕様書 上は必ずしも明らかではありません。
例えば基底文字 と結合文字 が連続する別の要素 に属する時でも合成されて表示されるべきかどうか、
両方の要素 で特性 (例えば 'color ') が違うときどう表示されるべきか、
明確ではありません。
[93]
::first-letter
は最初の文字 の後に結合文字 があれば、
それも含みます。
CSS2
仕様書には結合文字 だけ子要素 に入っている場合であっても、
そこまで含まれるという実例が示されていました。
CSS2
の改訂である
Selectors 3 CSS Pseudo-Elements Module Level 4 ::first-letter
[90] html - Highlighting Combining Characters - Stack Overflow , 2020-12-06T02:34:51.000Z https://stackoverflow.com/questions/26407896/highlighting-combining-characters
[91] 書字方向 は結合文字 処理などを経た grapheme cluster
を対象に挙動が定義されています。
CSS Writing Modes
関連 [68] 前置式の subtending mark もあります。
[199] IDS との相互作用は謎です。
IDS
文字のようなもの
特殊な利用例 [27] Xユーザーの風間さん: 「万博きた̷̡̤͕͖͓͉̯̪̅͊!̴̨̪͕̜̝̙̜̫̍̐̐͘ 今日で3581̵̡̫̞̗͖̱͍͔̿͂̎͆͐日め! 最̶̢̠͕͎̱͍͌高̷̡̢̠͚̮̳͂̓̕のお̴̨̙̲̗̗̘͐͂祭̵̡̨̪̗̦̞̟̔̓̏͂̕り̸̢̢̞͉̗͔͓̔̎͑̕だ〜! 人影はないけど、きょ̶̢͙̺̮̝̯̱̳̽̎̿̍͐̕う̵͎͓̠͚̦̼̽̅͐̔̚も̴̡̢̢͔̤̝͌̿̒͝回るぞ〜̵̨̥̝͓̙͚͍̾̋̋͆! #大̴̡̛̥阪̵̢̛̼万̴̡̛̦博̶̡̛͎2025 #大̴̡̛̥阪̵̢̛̼万̴̡̛̦博 https://t.co/SCHRR4PQWz」 / X , 午後0:14 · 2025年10月14日2025-10-14T03:14:37.000Z , 2025-10-16T02:30:02.000Z https://x.com/kazama_mm/status/1977936051152040176
歴史 [35]
Unicode 以前には色々な文字合成 技術がありました。
文字合成
ISO/IEC 10646 [107]
ISO/IEC 10646 は文字集合 として Unicode
と同じであるだけでなく結合文字 の扱いも一致しています。
ただし
Unicode
と
ISO/IEC 10646
とでは用語法に若干の違いが見られます。
[2]
結合文字 (combining character)
この規格群で規定する符号化文字集合の識別された部分集合の構成単位であって、先行する非結合文字 (以下、基底文字という。)
と組み合わせることを意図したもの、又は基底文字の後に結合文字の列が続いた形のものと組み合わせることを意図したもの (4.14 参照)。
(JIS X 0221 ‐1:2001 4.12) [1] 2002-11-03 (日) 15:52 名無しさん 非 結合文字は被 結合文字の typo じゃないかと一瞬思いますが、規格 を良く読むとこれで正しいことが分かります。
[28]
合成列 (composite sequence)
基底文字 とそれに続く一つ以上の結合文字 からなる図形文字 の列 (4.11 参照)。 備考 1. 合成列からなる図形記号 は、通常、
その合成列を構成する各文字 の図形記号の組合せからなる。
2. 合成列は、文字とはみなさない。したがって、
この規格群のレパートリ の構成単位ではない。
(JIS X 0221 ‐1:2001 4.14)
[108] 合成列 は結合文字列 と同じようなものですが、
基底文字 が必須で、
ZWJ
や
ZWNJ
は含まれません。
[104]
ISO/IEC 2022
にも合成に関する規定があります。
合成手法として、
重ね打ち式文字合成 、
Unicode 式結合文字 、
GCC
が示されています。
[4]
6.3.3 図形文字の結合 特に指定されない限り、図形文字 は、
結合文字 としてはならない。すなわち、
隣接する図形文字 と組み合わせようとしてはならない。
図形文字集合 によっては、複数の図形文字 を一つの図形記号 として可視化 することによって、
追加の図形記号 (例えば、アクセント付き文字 )
を図形表現 することを許しているものもある。この規格 では、
二つの結合方法があることを認識している。
a) 基底文字 の図形文字 は、制御文字 の
BACKSPACE 後退 CARRIAGE RETURN 復帰
b) 結合文字 として指定 されている図形文字 は、
基底文字 の図形文字 と組み合わせてもよい。
ISO 2375 に従って、図形文字集合 の登録を行おうとする申請者は、
集合 中の結合文字 を明らかにしておくことが期待される。
参考1. 登録では、これらの要件の詳細を求められないので、
文字集合 を規定する規格 は、結合文字 がある場合、
それ自身で、これを指定しその用法を示しておくのがよい。
2. ISO/IEC 646 の図形文字 では、
アクセント付き文字 を表現 するのに、 a)
の方法が認められている。
3. JIS X 0211 では、第3の方法として、文字 自身の仕様に関係なく、
GRAPHIC CHARACTER COMBINATION GCC 制御機能 を使った図形文字 の結合 を規定している。
JIS X 0202 :1998
[8]
結合文字 (combining character)
符号化文字集合 の識別された部分集合の構成単位であって、先行する非結合文字
(以下、基底文字 という。)
と組み合わせることを意図したもの、又は基底文字の後に結合文字の列が続いた形のものと組み合わせることを意図したもの。
(JIS X 0202 :1998 4.8) [105]
ISO/IEC 2022
の体系で使われる
ISO-IR
に登録された図形文字集合 では実はなぜかここに挙げられていない非spacing文字
(前置アクセント型)
方式の文字合成が一番よく使われているのではないかと思われます。
[106]
Unicode
型の結合文字 を使った
ISO-IR
に登録された図形文字集合 はどれだけあるのでしょうか。
JIS X 0213:2000
と
JIS X 0213:2004
が思い浮かびますが、
他にもあるのでしょうか。
[3] 10646 での結合文字の使い方は、 24.
に規定があります。結合文字の一覧は附属書 B
にあります。結合文字が使えるかどうかは実装水準 と関係します。
結合文字は、基底文字 の後でなければなりません。
(24.1) 結合文字自体を一つの結合列 としたい時は、
間隔 を基底文字とします。 (24.1)インド系用字系の matra (母音記号)
は特殊で、周囲の複数の文字に依存するので、
間隔と結合させるのは望ましくありません。 (24.1 備考) 一つの基底文字に結合できる結合文字の数は 10646
では規定しません。 (24.3) 結合文字同士が表示に影響する場合
(例えば COMBINING MACRON COMBINING DIAERESIS 縦方向ではなく横方向に並べたり、
隣接する結合文字と合字を作る結合文字もある。
横方向に進むときは、書字方向 に従う。 結合文字同士が影響を与えない場合
(例えば上につくものと下につくもの) は、
逆の順序の場合と同じに見えてもよい。 [147]
当初の
ISO/IEC 10646
は、
実装水準 を3つに区別していました。
その違いは主に結合文字 の利用の可否でした。
ISO/IEC 10646
現在はこの区分は廃止されました。実情にまったく即していなかったためでしょう。
JIS X 0208 と LARGE CIRCLE LARGE CIRCLE
JIS X 0213 JIS X 0213の結合文字
JIS X 4051 JIS X 0213の結合文字
[5] I'm not a Klingon (<span style="font-family:pIqaD,code2000"> </span>) : Most combining characters in a Unicode glyph/character/whatever
(2010-03-27 10:31:57 +09:00 版)
http://blogs.msdn.com/shawnste/archive/2010/01/25/most-combining-characters-in-a-unicode-glyph-character-whatever.aspx
[6] Web Applications 1.0 r6611 Allow combining characters wherever, per Mark Davis.
( (2011-10-02 16:17:00 +09:00 版))
http://html5.org/tools/web-apps-tracker?from=6610&to=6611
[7] Bug 13502 – Text run starting with composing character should be valid
( (2013-11-25 16:50:57 +09:00 版))
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13502
[25] 合成用の「☆」や「★」がほしい。合成用丸 があるんだしw
[50] た͜͜͏̘̣͔͙͎͎̘̜̫̗͍͚͓͜͜͏̘̣͔͙͎͎す͜͜͏̘̣͔͙͎͎ơ̟̤̖̗͖͇̍͋̀͆̓́͞͡け̜ͪ̅̍̅͂͊てとは (タスケテとは) [ 単語記事] - ニコニコ大百科
(2020-04-24 07:05:18 +09:00 )
https://dic.nicovideo.jp/a/%E3%81%9F%CD%9C%CD%9C%CD%8F%CC%98%CC%A3%CD%94%CD%99%CD%8E%CD%8E%CC%98%CC%9C%CC%AB%CC%97%CD%8D%CD%9A%CD%93%CD%9C%CD%9C%CD%8F%CC%98%CC%A3%CD%94%CD%99%CD%8E%CD%8E%E3%81%99%CD%9C%CD%9C%CD%8F%CC%98%CC%A3%CD%94%CD%99%CD%8E%CD%8E%C6%A1%CC%9F%CC%A4%CC%96%CC%97%CD%96%CD%87%CC%8D%CD%8B%CC%80%CD%86%CC%93%CC%81%CD%9E%CD%A1%E3%81%91%CC%9C%CD%AA%CC%85%CC%8D%CC%85%CD%82%CD%8A%E3%81%A6
[208] Quivira Combining Characters - QuiviraCombining.pdf , 2014-08-23T11:39:55.000Z , 2020-12-29T11:06:18.497Z http://www.quivira-font.com/files/QuiviraCombining.pdf
[213] さく҉らん҉̴҉҇ぼ小҉̷҉学校҉̶҉҇҉̨҉͌3.҉̸҉̕҉̢҉̔m҉̵҉͝҉̢҉̓҉̓҉̚҉͌҉p҉҉҉͠҉͢҉͋҉͋҉̈҉4҉̷҉͝҉̨҉̏҉̀҉͔҉̜҉̙ - ニコニコ動画
(2021-06-12 08:59:27 +09:00 )
https://www.nicovideo.jp/watch/sm38869649
[219] ず҈̡̟͎̙̗̪̓̀̓̃̆͊͗̆̕んだ̴̮̣̙͇҇̃̈̔͐͢も҈̨̳̱͍̗̑̍͂̎̕̚̚̚̚ん҉マンションの日常 - ニコニコ動画
(2022-08-31 10:23:42 +09:00 )
https://www.nicovideo.jp/watch/sm40995049
[228] Unicode正規化 用語の混乱について 第4.2版 – ものかの , 2023-05-24T01:20:54.000Z , 2023-05-24T11:39:28.589Z https://tama-san.com/unicode-normalize-confusion/
[259] 「文̥字̥打̥つ̥と̥車̥輪̥が̥つ̥く̥よ̥う̥に̥な̥っ̥た̥の̥で̥す̥が̥こ̥れ̥は̥な̥に̥な̥の̥か̥誰̥か̥ご̥存̥知̥な̥い̥で̥す̥か̥;;」謎のバグに苦しむVTuberに解決案が寄せられるもお手上げ状態 - Togetter
(2024-02-29T02:39:00.000Z )
https://togetter.com/li/2323359