文字コード総合スレ part15

**デフォルトの名無しさん** · 2025/08/23(土) 09:10:23.66

>>446
> CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
ならばgoogle猫が手抜きで糞フォントを作ったのがPDFコピペ文字化けの元凶だな
日本人の美的感覚では、(この辺は習字を見れば分かりやすい)
「長」の縦棒は、上よりも下のほうが少し左側(下のほうが広く見える)が美しいとされるので、
真面目にフォントを作れば同じグリフになることはない

**デフォルトの名無しさん** · 2025/08/23(土) 12:38:53.36

>>447
そういう意味なら「康熙部首」はもともと部品じゃなくて普通に使われる漢字なのでJIS的には漢字として登録されるのは問題ない
（康煕部首を漢字以外に登録しているunicode が変というかローマ数字の ⅰ がアルファベットの i と別にあるみたいな変さ)

「氵」とかは伝統的な漢字じゃないので（辞典類の索引くらいしか）単独の用例が存在していなかったのが理由じゃないかな
国語の教科書とかでも康煕準拠で「冫の部」とういう表記は使われるけど「氵の部」という部首は存在してなくて「水の部」と書かれてる

第3、第4水準の包摂基準は原則として第1、第2の基準を援用してるので第2水準で包摂されていたら第4水準に追加できないので、逆説的に第4水準に追加されたことは包摂されていなかった解釈になる（補助漢字はかなりあやしい

**デフォルトの名無しさん** · 2025/08/23(土) 12:45:02.17

>>449
文字をどのようにデザインするかはフォントごとの勝手、文字コードでは規定していない
いやならそのフォントを使わなければ良い
ゴシック体で画数と意識してられるかアホらしい

**デフォルトの名無しさん** · 2025/08/23(土) 14:58:11.95

あ、すみません

> CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話

ちょっとこの部分はガセかもしないので皆さん一旦忘れてもらえますか?
「長」が康熙部首とCJK部首（補助）に登場するのは事実ですが

**デフォルトの名無しさん** · 2025/08/23(土) 15:25:52.11

>>452
unicode には4つの「長」の部首素片が登録されてるメインに1つ、補助に3つ
多分メインのやつが字形を無視した意味上の部首素片で、補助のやつが unicode の包摂基準に従って分離された字形

**デフォルトの名無しさん** · 2025/08/23(土) 15:38:45.17

>>450
> 「氵」とかは伝統的な漢字じゃないので（辞典類の索引くらいしか）単独の用例が存在していなかったのが理由じゃないかな

なるほど、そんな感じですかね

**デフォルトの名無しさん** · 2025/08/23(土) 15:54:04.18

>>453
基底クラスに派生クラスが3つ、みたいな感じですかね

部首周りは思ったより複雑ですなw

**デフォルトの名無しさん** · 2025/08/25(月) 08:21:51.64

今回の話はほぼ部首由来だけど、そうでないのも少しありそう

U+6AF8（櫸）は「ケヤキ」らしいがこれ以外にU+237F1（𣟱）という字もあり、
この両者に同じグリフを使う場合がある
ちなみに例の坂道グループのはU+6B05（欅）、つくりの下側が「手」

ここらへんの文字がちゃんと扱えるのかのテストでもある

**デフォルトの名無しさん** · 2025/08/25(月) 08:51:42.49

ちなみに台湾の日本アイドルファン系のサイトには、U+6AF8を使っている
サイトが散見される.。まあ無理もないことではある
しかしそれだと日本の情報を十分に集められなかったのではなかろうか

まさかそれを嫌って櫻坂に改名したとしたら、なかなかの文字コード通か?
しかし今度は中国本土の人がU+6A31（樱）を使ってしまう可能性もある

**デフォルトの名無しさん** · 2025/08/25(月) 08:56:46.72

そもそも unicode の統合基準がグダグダなので unicode では同じ字形の文字が複数あるのが当然になってる（IVS/IVDも入れると同じ字形の漢字が3つも4つもあったり
あと1つのフォントには最大で65536グリフしか登録できないので多くの文字を登録したい場合やフォントサイズを圧縮したい場合は同じ字形は一つのグリフで表すというのも普通のテクニックになってる

**デフォルトの名無しさん** · 2025/08/25(月) 15:28:01.56

>>456
Unicodeは各国にある規格を取り込む、というのはまあまあやっていて
U+6AF8は台湾で使われる字、U+237F1は日本などで用例のある字、
で本来グリフにも差があるらしい

**デフォルトの名無しさん** · 2025/08/25(月) 18:00:18.28

>>459
U+6B05 は旁の下部が手なのでおいておいて

もともとU+6AF8 は横棒二本と横棒三本が統合(unify)されてる（日本語フォントだと三本、中国語フォントだと二本で表示されるのが一般的、
二本と三本を指定したい時は IVS をつけるのがルール、具体的には U+E0100 をつければ日本で一般的な adobe-japan の横棒三本の字体を明示的に示せる

IVS なんか知るか独立のコードポイントよこせという大陸様のゴリ押しで、横棒三本が別に U+237F1 に登録された
このせいで日本語フォントで表示すると両方が横棒三本の同じ字形という状態になってる（中国語フォントなら二本と三本で別の字形になる

**デフォルトの名無しさん** · 2025/08/26(火) 15:23:22.74

>>460
例えば
>IVS なんか知るか
U+237F1が入ったのはIVSより前じゃね?

**デフォルトの名無しさん** · 2025/08/26(火) 17:54:44.18

>>461
ちょうど同じ時期に並行して議論されてたんだよ
正式な規格書にコード位置が載ったのは Ext-B の方が少しだけ早かったかも

**デフォルトの名無しさん** · 2025/09/10(水) 21:44:22.92

Unicode 17.0 Release Announcement
https://blog.unicode.org/2025/09/unicode-170-release-announcement.html
「Unicode 17.0」がリリース～8つの新しい絵文字、日中韓(CJK)文字の拡充も継続
サウジアラビア通貨「リヤル」の記号も
https://forest.watch.impress.co.jp/docs/news/2046141.html

**デフォルトの名無しさん** · 2025/09/10(水) 22:23:52.97

>>463
漢字10万字突破とか笑える事態は置いとくとして
誰だ？ウサ耳の絵文字とか登録したやつは

**デフォルトの名無しさん** · 2025/09/10(水) 23:25:55.02

https://asset.watch.impress.co.jp/img/wf/docs/2046/141/image3_l.png

**デフォルトの名無しさん** · 2025/09/11(木) 14:48:21.23

>>464
合成でバニーガールとバニーボーイを使い分けられてジェンダーフリー、
ってそこまでしてw

絆創膏のデフォルトの色をどうするか、みたいな話もあったり
めんどくさい世の中だ
そういえばインド人から送られてきたthumbs-upの絵文字は茶色かった

**デフォルトの名無しさん** · 2025/09/11(木) 15:09:06.69

>>466
ああ、なるほど
「うさ耳」固有の絵文字が追加されたわけではなくて
今まであった「バニーガール」の絵文字を合成で使うと「うさ耳」の追加として処理するルールが追加されたのか

**デフォルトの名無しさん** · 2025/09/15(月) 20:12:18.82

>>464
しかしリアルな中国の辞書でも10万字を超えるのはないはずだけど
10万字突破ってどういう文字集合になってるんすかねえ
あと文字情報と汎用電子が追加したIVDはこの場合カウントされるのかな?

**デフォルトの名無しさん** · 2025/09/16(火) 03:15:46.45

>>468
手元に「汉字海」の2018年版があるけど、10万2千字超えてるよ
音未詳、義未詳、同〇〇、みたいな漢字が多数掲載

**デフォルトの名無しさん** · 2025/09/17(水) 13:27:21.24

>>469
なるほど。しかしそのうちどれだけにUnicodeのコードポイントがあるのか
興味深いですね

ちなみにこの場合の「海」は中心が点々で表示されるべきなんだろうけど
異体字セレクタにある点々の海を使うのは正解じゃないんでしたっけ

**デフォルトの名無しさん** · 2025/11/07(金) 08:24:41.35

macOS 26 Tahoeアップグレード後に、正規化形式(NFD/NFC)の不具合により日本語環境でNASに接続されたTime Machineバックアップが行えない問題はmacOS 26.1でも修正されていないので注意を。
https://applech2.com/archives/20251106-time-machine-bug-still-unresolved-on-macos-26-1-tahoe.html

Synologyサポートチームによる調査の結果、この問題はTime MachineバックアップをNASストレージ上に作成すると、日本語環境ではデフォルトで「Hogeのバックアップ」という名前がUnicde NFC形式で自動的に付けられ保存されるものの、macOS 26.0 Tahoeではボリューム名をNFD形式で探すようになっていることが原因だとして、
SynologyはAppleがこの問題を修正するまでの一時的な対応策として、バックアップ先のフォルダ名およびボリューム名をアルファベットのみで構成するという対処法を公開していましたが、Appleが2025年11月03日にリリースした「macOS 26.1 Tahoe」でもこの問題は修正されていませんでした。

**デフォルトの名無しさん** · 2025/11/10(月) 05:32:30.23

>>471
macOSの正規化の問題はもはや定期