[3] CJK統合漢字は、 Unicode の漢字集合です。
[71] 「CJK統合」とは中国, 日本, 韓国の漢字を統合したことを意味しています。
[72] 当初は CJK 3種4欄 (中華人民共和国, TCA (台湾、政治的理由。), 日本, 韓国) でしたが、後に越南が加わり CJKV とも呼ばれます (が用語としては CJK のまま)。 更に香港, 澳門, シンガポール, 朝鮮民主主義人民共和国等も出典に加わっています。
[10] UCD の Unihan データベースには Unicode CJK統合漢字の情報が入っています。
[29] UAX #38: Unicode Han Database (Unihan), , https://www.unicode.org/reports/tr38/
[2] UAX #44: Unicode Character Database, , http://www.unicode.org/reports/tr44/#Unihan
[101] GitHub - unicode-org/unihan-database: For review of draft Unihan database changes, removals, and additions by experts., https://github.com/unicode-org/unihan-database
[11] The Unicode Han Character Cross-Reference, , https://www.unicode.org/Public/1.1-Update/CJKXREF.TXT
[12] Unicode 1.1 時代の Unihan に相当するファイル (今とファイル形式が違う)。
[18] これより古い版の前まで Fujitsu corporate character set があったらしい。低品質のため削除されたとのこと。 >>11
[19] Unihan database, , https://www.unicode.org/Public/2.0-Update/Unihan-1.txt
[20] Unicode 2.0。 Unihan という名前のファイルの始まり?
kBigFive, kCNS1986, kGB0, kGB1, kGB3, kGB5, kGB7, kGB8, kJis0, kJis1, kKSC0, kKSC1, kPseudoGB1, kCCCII, kCNS1992, kEACC, kIBMJapan
[21] Unihan database, , https://www.unicode.org/Public/2.1-Update/Unihan-2.txt
[22] Unihan database, , https://www.unicode.org/Public/3.0-Update/Unihan-3.txt
kBigFive, kCNS1986, kGB0, kGB1, kGB3, kGB5, kGB7, kGB8, kJis0, kJis1, kKSC0, kKSC1, kPseudoGB1, kCCCII, kCNS1992, kEACC, kIBMJapan
kIRG_GSource
kIRG_JSource
kIRG_KSource
kIRG_TSource
kIRG_VSource
[28] UTR #38: A User’s Guide to the Unihan Database, , https://www.unicode.org/reports/tr38/tr38-3.html
UTR #38 の最古の公開案。
[74] Unicode は符号点ごとに代表字形を1つ示していますが、 CJK統合漢字は特例で出典ごとの字形が示されています。
[89] 符号表の相互参照で使う場合 (例えばCJK互換漢字の符号表にある CJK統合漢字への参照) には1つ字形が選ばれて表示されています。 その唯一の字形がどのように決められているのかは謎です。
[41] CJKUI修正笔记(一):WG2 N5006R(未竟) - 知乎, https://zhuanlan.zhihu.com/p/44819911
変更事例集
[42] CJKUI落地中待解决的问题搜集(未竟) - 知乎, https://zhuanlan.zhihu.com/p/57501943
[45] CJK统一汉字区块认同问题存疑处收集(未竟) - 知乎, https://zhuanlan.zhihu.com/p/27005748
[46] 多すぎて草も生えない
[69] >>68 U+236AD
が
ISO/IEC 10646-2:2001
で誤字形だったらしい。
CNS 14649-2, X 5066-2 (中華民国92年版) #page=144 は誤字形。
>>64 #page=66 Unicode 3.1 は正しい。
>>56 #page=110 ISO/IEC 10646:2003 は正しい.
[73] 22287-irgn2585-wg2n5186-hanja.pdf, , https://www.unicode.org/L2/L2022/22287-irgn2585-wg2n5186-hanja.pdf
[98] Unicode 15.1 で KP1 字形が追加されました。
[99] CJK統合漢字拡張Bは以前から2欄幅 × 4で1ページで、3つ以上の字形があるときは次の行に続けていました。 KP1 追加でこの行折返しが新規に非常に多く発生しています。
[100]
U+29520
には KP1 の字形と出典が追加されたのに加えて、
出典Uの出典のみ (UTC-00035, 字形空白) が追加されています。
この
UTC-00035
は元々
U+9855
に対応付けられていた (出典ではない) ものでした。
[117] https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_action_common_download&item_id=71855&item_no=1&attribute_id=1&file_no=1
第3版の符号表開発について
[33] ここまでのまとめ:10646次版ドラフトの字体チェック - しろもじメモランダム, https://shiromoji.hatenablog.jp/entry/20090612/1244830975
[34] >>33 Unicode 5.2 の頃の時代の新符号表の不審な字形差のリスト
[35] Unicode 5.2 で新符号表に置き換えられた時に各国の字形がそれまでと変わっていることが多く、 誤りとしてその後変更されているものも多い。特に拡張Bはこの時初めて多欄符号表が作られて、 仕様の不具合 (統合ミス) は明るみに出たのがこの時ということが多いらしい。
[36] 各国字形の変更の情報は断片的なものがあちこちに転がってはいるものの、 全体像がさっぱりつかめない。
[91] >>90 >>92 >>93 この時代は URO も1欄だけの符号表。
[141] ISO/IEC 10646:2011 は Unicode 6.0 相当、 ISO/IEC 10646:2012 は Unicode 6.2 相当。
[143] ISO/IEC 10646:2014/Amd.2:2016 で出典J が JIS X 0213:2004 版に置き換わる。
[154] Unicode 6.1 で導入されました。 >>153
[157] U+28F99 は少しややこしいケース。 GKX と T6 で少し字形が違う。 UCS2003 はどちらとも違う。 UCS2003 が削除されたかわりに近年「復活」した KP1 は UCS2003 に近い。 最近水平拡張された JMJ も UCS2003 に近い。
[32] UTN #53: CJK Unified Ideographs Extension B, UCS2003 Reference Glyphs, , https://www.unicode.org/notes/tn53/
[70]
RFC 1815 の ISO-10646-J-1
は、
CJK統合漢字のJ欄字形によるべきと規定していました。
[213] CJK統合漢字の適切なレンダリングには、 言語情報によるフォント選択、 言語情報によるグリフ選択が必要となります。
[221] 中文言語タグのうち台湾華語系のものが指定された場合は、 台湾華語用の字形を使うべきです。
[231] 台湾原住民の言語が指定された場合は、 台湾華語用の字形を使うべきです。
[218] 例えば言語タグ zh-TW
や zh-Hant-TW
が指定されたら、
台湾華語字形となるべきです。
[223] 中文言語タグのうち中華人民共和国, シンガポール, マレーシア系のもの (他に該当しないもの) が指定された場合は、 中華人民共和国用の新字形を使うべきです。
[250] 朝鮮語言語タグのうち中華人民共和国や朝鮮民主主義人民共和国を表すものが指定された場合は、 中華人民共和国用の新字形を使うべきです。
[226] 中文言語タグのうち中華人民共和国香港特別行政区系のものが指定された場合は、 中華人民共和国香港特別行政区用の繁体字を使うべきです。
[227] 利用できるフォントがない場合は、 台湾華語の場合にフォールバックするべきです。
[233] 英語のうち中華人民共和国香港特別行政区系のものが指定された場合も、 これに準じるべきです。
[229] 中文言語タグのうち中華人民共和国澳門特別行政区系のものが指定された場合は、 中華人民共和国澳門特別行政区用の繁体字を使うべきです。
[230] 利用できるフォントがない場合は、 中華人民共和国香港特別行政区の場合にフォールバックするべきです。
[234] ポルトガル語のうち中華人民共和国澳門特別行政区系のものが指定された場合も、 これに準じるべきです。
[236] 日本語言語タグのうち旧字体表記を意味するもの、 近代を意味するものが指定された場合は、 旧字体を使うべきです。
[249] アイヌ語言語タグのうち旧字体表記を意味するもの、 近代を意味するものが指定された場合は、 旧字体を使うべきです。
[245] 朝鮮語言語タグのうち近代を意味するものが指定された場合は、 旧字体を使うべきです。
[239] 中文言語タグのうち傳承字形表記や康熙字典体表記を意味するものが指定された場合は、 傳承字形を使うべきです。
[240] 利用できるフォントがない場合は、 台湾華語, 中華人民共和国香港特別行政区の中文, 中華人民共和国澳門特別行政区の中文の場合のいずれかにフォールバックするべきです。
[242] 朝鮮語言語タグ (他に該当しないもの) が指定された場合は、 大韓民国の漢字の字形を使うべきです。
[243] 利用できるフォントがない場合は、 中文の傳承字形, 日本語の旧字体の場合のいずれかにフォールバックするべきです。
[247] 越南語言語タグが指定された場合は、 越南の漢字の字形を使うべきです。
[248] 利用できるフォントがない場合は、 中文の傳承字形, 日本語の旧字体, 朝鮮語の場合のいずれかにフォールバックするべきです。
[30] U-Source Ideographs, UK-Source Ideographs, SAT外字, 文字情報基盤
[121]
UCS符号位置とその出典の関係や、
出典の字形は、頻繁に変更されています。
[81] IRGN2275PnP10.pdf, , https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg49/IRGN2275PnP10.pdf#page=7
[79] 関連: 出典V, MJ, Pan-CJK, 文字情報基盤
[80] IRG N1964 (Continued National Standards Development & Horizontal Extensions) for IRG41 - 13192-irgn1964.pdf, , https://www.unicode.org/L2/L2013/13192-irgn1964.pdf
[62] IRG Working Document Series, https://appsrv.cse.cuhk.edu.hk/~irg/irgwds.html
[77] GitHub - kawabata/iwds: IRG Working Document Standards, https://github.com/kawabata/iwds
[78] GitHub - yi-bai/iwds: IRG Working Document Standards, https://github.com/yi-bai/iwds
[203] IRGN2338Disunify7Ideographs.pdf, , https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg51/IRGN2338Disunify7Ideographs.pdf
[204] IRGN2329MiscEditorialReport.pdf, , https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg51/IRGN2329MiscEditorialReport.pdf
[48] Universal Multiple-Octet Coded Character Set - IRGN2517DisunifiedIRGcharacters.pdf, , https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg58/IRGN2517DisunifiedIRGcharacters.pdf
iso10646:annexp:withoutposition
[82] 03670 | ⿱蟲鳥 | WS2021v5.0, https://hc.jsecs.org/irg/ws2021/app/?id=03670
[43] >>82 誤字だからフォントの合字にするべき派 vs 誤字だとしても実用されたから符号化するべき派
[83] CJK ligature: This is a project for handling the CJK ligature., https://gitee.com/eisoch/cjkliga
[40] >>83 は >>82 を実装したデモ。
ccmp
で
U+87F2 U+200D U+9CE5
を、
liga
で
U+87F2 U+9CE5
を合字グリフにしています。
[84] 23073-irgn2581-fdbk.pdf, , https://www.unicode.org/L2/L2023/23073-irgn2581-fdbk.pdf
[85] >>84 合字記述用の新しいUnicode文字を追加するべきとの提案。 >>82 の例の他に、 ⿰阿迎、 ⿰哈雜、 ⿰鴉尼 などをCJK統合漢字でなくこの新手法で記述するべきと主張している。
[86] UTC-03224 | WS2021v5.0, https://hc.jsecs.org/irg/ws2021/app/index.php?find=UTC-03224
[87] >>86 ⿱敕令 も合字で表すべきで提案を取り下げると。
[182] UK-20508 | WS2021v5.0, https://hc.jsecs.org/irg/ws2021/app/index.php?find=UK-20508
[187] >>182 ⿱即哩 も合字で表すべきだとして提案を取り下げ。
[37] BabelStone Fonts : BabelStone Han Ligatures, https://www.babelstone.co.uk/Fonts/BSH_ZWJ.html
[38] BabelStone Han は
ZWJ
入、
liga
で4組実装しています。
>>37
(>>82 >>86 >>182 と「二合」)
[39] GSUB
の仕様上、同じグリフを共有する他のUnicode符号位置でも有効なので、
合計7通りの表現ができます。
[198]
>>38 この ZWJ
を使った合字、
横書きならうまくいきますが、
縦書きだと Windows の Chrome だと
liga
だろうと ccmp
だろうと、
認識されずに前後2文字ばらばらに縦に並べられてしまいます。
[200]
ZWJ
の合字でなく基底文字と結合文字の
ccmp
だと縦書きでも正常に表示されます。
結合文字でなく ZWJ
が入る時は合字化の処理より先に縦書きのための書記素クラスターの分割が行われてしまうということなのでしょうか。
[201]
Windows の Firefox だと ccmp
は正常に合字化されます。
liga
はデフォルトで無視されますが、
font-feature-settings: "liga"
だと正常に合字化されます。
(Chrome はそれを指定しても変わらない。)
横書きなら自動適用される liga
が縦書きだとデフォルト無効なのでしょうか。
[197] Microsoft Word - IRGN2622IRG61MiscEditorialReport - 23249-irgn2622-irg61-ed-rept.pdf, , https://www.unicode.org/L2/L2023/23249-irgn2622-irg61-ed-rept.pdf#page=3
[260] n360-Resolutions.pdf, , https://www.unicode.org/irg/docs/n360-Resolutions.pdf#page=2
[261] >>260 Unicode Consortium (だけ)、 拡張Aの BMP への追加に反対していた
[262] 1990年代のUnicode Consortium はほんとクソだなあ
日本語の漢字は、戸籍などに使われているものも含めると6万字あるのに対し、コンピューターは、実は1万字しか扱うことができません。これに対し、このほど15年越しの作業の末、6万字すべてが統一の規格にまとめられて、コンピューターがすべての漢字を扱えるようになり、ビッグデータの活用をはじめさまざまな効果が期待されています。
[5] NS39012siba, , http://web.archive.org/web/20000903220115/http://www.itscj.ipsj.or.jp/jp/ns39012.html
[6] , https://standards.iso.org/iso-iec/10646/ed-6/en/CJKSrc.txt
[7] 情報学広場:情報処理学会電子図書館, <情報処理学会>, https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=62547&item_no=1&page_id=13&block_id=8
[9] 漢字の国際提案の歴史を図にしてみた - 帰ってきた💫Unicode刑事〔デカ〕リターンズ, https://moji-memo.hatenablog.jp/entry/20130808/1375949975
[44] GitHub - Kushim-Jiang/Zhuanlan-Zhihu: 知乎专栏内容存档。, https://github.com/Kushim-Jiang/Zhuanlan-Zhihu
[47] Possible unification · Issue #28 · eisoch/irg · GitHub, https://github.com/eisoch/irg/issues/28
[97] 漢字の国際提案の歴史を図にしてみた - 帰ってきた💫Unicode刑事〔デカ〕リターンズ, https://moji-memo.hatenablog.jp/entry/20130808/1375949975
[205] Activity Report from TCA - IRGN2597_TCA_ActivityReport.pdf, , https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg60/IRGN2597_TCA_ActivityReport.pdf#page=1
[206] >>205 なぜか台湾の人名漢字追加提案だけエビデンスがないとしつこく拒絶される(他の国は通っているのに)と激おこ案件
[207] 03433 | 〾⿱蒜心 | WS2021v6.0, https://hc.jsecs.org/irg/ws2021/app/index.php?id=03433
[208] >>207 台湾が提出した代表字形が台湾の基準(どこにも明示されてない)に反していると主張する海外勢という地獄絵図。 台湾は人名用字なので原字形を替えるわけにはいかないといっている(つまり海外勢が主張する台湾基準の字形とやらは台湾には存在していない)。
[209] Unicode の規定上は、各国の例示字形がどうであれ結局統合基準の範囲内のものは統合されるのだから問題にならないはずなのに、 なぜ各国が自国の判断で決めている字形差に頑なに口出しするのかが謎だ。 どうしてもというならU字形にすればいいのに。
[210] なんかどうしても中華人民共和国には甘くて中華民国には厳しく見えちゃうのよねえ。
[212] 24125-cjk-abbrev-block.pdf, , https://www.unicode.org/L2/L2024/24125-cjk-abbrev-block.pdf
[253] Xユーザーの拾萬字鏡🐦さん: 「例のユニコードに申請された日本の略字、ネット記事になったので反応見てみたが否定意見を読むとゲバ文字を残したい左翼による劣った起案だとか、職の略字や曜日の曜の略字を入れたほうがマシ(実はすでにユニコードに入ってる)とかコメントされていてやはり漢字やユニコードに無知な人だらけだけだった」 / X, , https://x.com/JUMANJIKYO/status/1798379273038057568
[254] 24135-response-to-l2-24-126.pdf, , https://www.unicode.org/L2/L2024/24135-response-to-l2-24-126.pdf
[255] >>254 善意の提案者が「これは左派プロパガンダ目的の提案ではない」と至極当然の釈明を迫られている。実に馬鹿馬鹿しい事態。
[256] Microsoft Word - IRGN2678WS2021ProposalToWG2.doc - n5257R-IRGN2678Proposal.pdf, , https://www.unicode.org/wg2/docs/n5257R-IRGN2678Proposal.pdf
[257] L2/24-165 (CJK & Unihan Working Group Recommendations for UTC #180 Meeting) - 24165-cjk-unihan-wg-utc180.pdf, , https://www.unicode.org/L2/L2024/24165-cjk-unihan-wg-utc180.pdf#page=13
[263] 24201-script-hybrid-cjk-block.pdf, , https://www.unicode.org/L2/L2024/24201-script-hybrid-cjk-block.pdf
ZWJ
入の絵文字列だと (表示上は1文字だろうが2文字だろうが) 文字列の選択に対して1文字扱いになりますが、 漢字列の方は2文字扱いです。 適切なフォントがあれば Firefox は横書きでも縦書きでも1文字、なければ2文字で表示し、 Chrome は横書きなら1文字か2文字、縦書きならフォントがあろうが2文字で表示します。 ということは Firefox も Chrome も既知のZWJ
かどうかで挙動を変えているのですが、 Chrome はそれとは別に縦書きの実装が弱いと考えられます。