文字コード総合スレ part15

**デフォルトの名無しさん** · 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の正規化の問題はもはや定期

**デフォルトの名無しさん** · 2025/11/18(火) 16:46:15.76

なんかMac上のAdobeのアプリが動かなくなってるらしいけどけどパス関連
じゃないだろうね
以前、システムのドライブを大文字小文字を区別するファイルシステムにすると
動かなくなったりしたことはある

**デフォルトの名無しさん** · 2025/11/19(水) 19:08:44.33

>>473
原因はまだ公表されていないが症状的にそういうOS寄りの話じゃなさそう
adobe がオンライン経由でライセンスの強制取り消しか何かの仕組みをいれようとしてバグったとかそんな感じのやつ

**デフォルトの名無しさん** · 2025/11/27(木) 22:04:02.60

AIにテキストが読み取られるのを防ぐために目に見えないUnicode文字を挿入する「Gibberifier」
https://gigazine.net/news/20251126-gibberifier-stun-llm-random-unicode/

文字コードの標準規格であるUnicodeには世界中で使われるさまざまな文字が登録されていますが、中には「目に見えないUnicode文字」も多数含まれています。また、そのうちの一部は目に見えない「ゼロ幅文字」となっています。

Gibberifierは入力したテキストの文字間に、ゼロ幅文字を挿入するツールです。目には見えないもののコンピューター上では存在しているゼロ幅文字を挿入することで、テキストの見た目はそのままに文字数が大幅に増加し、難読化されることでAIによる読み取りを防ぐとのこと。また、実際の文字数が見かけより大幅に増えるため、AIユーザーのトークンを無駄遣いさせることも可能です

**デフォルトの名無しさん** · 2025/11/27(木) 22:14:49.16

HTMLや画像でも文章認識できるのは前処理してるからで
こんなもん瞬で対策されておわりでしょ

**デフォルトの名無しさん** · 2025/12/10(水) 11:51:06.42

皆さんUTF-8 code pageでのテストしましょう

Fix corrupted file loading on Windows system using the full UTF-8 code page. (Fix #17234)
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/17234

**デフォルトの名無しさん** · 2025/12/10(水) 12:14:52.51

Windows で BOM 付き UTF-8 使った時にバグるのか。
ちゃんと実装できないんなら滅んでしまえ

**デフォルトの名無しさん** · 2025/12/10(水) 21:28:59.81

NPP v8.8.6 32bitでは再現出来なかった

**デフォルトの名無しさん** · 2025/12/11(木) 00:51:43.45

>>479
多分英語版の Windows のバグ
日本語版の Windows ならデフォルトロケールを英語 codepage 1252 に変更しないと再現しないと思う
SJISにはSJISで別の文字で類似バグがあったりするかもしれないけど

**デフォルトの名無しさん** · 2025/12/11(木) 04:34:26.04

そういえば少し前ベンダーから送られてくるログがやたら文字化けしていて
うんざりしたが、ちゃんと見てないが関係あるのかなあ
データ的にWindows上でSJISとUTF-8を混ぜこぜにしてる感じだったが
しかしいつまでこの手の問題が続くんだろ

**デフォルトの名無しさん** · 2025/12/11(木) 06:20:41.73

ちゃんと見て原因を特定しないお前のような奴がいる限り無理だろ

**デフォルトの名無しさん** · 2025/12/13(土) 06:14:20.73

>>482
自分がメンテしているソフトウェアで文字化けが発生しているのではなく
ベンダーがログのデータの扱い中になんかやらかしている
ログのデータをそのまんま送るだけでいいのに余計なことすんなと
そんなものに付き合ってるほど暇じゃない