文字コード総合スレ part15

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

>>402
そういう話じゃねえ
てかお前も本気で文盲だな

317: 1:1でなら動くシステムに多:1をブッ込んでるから動かない

やぞ
ただここまで言っても通じないのだから、本件に対し、お前の知能/知識がまるで足りてないんだよ
普通レベルのプログラマなら317で、ああ、そういう事か、で終わるし
その後、これをどう評価するか(＝PDFが糞か、unicodeが糞か)で揉めるならまだしも、
お前は何故そういう動作になるのか未だに理解出来てない
そんなお前が書いたプログラムなんて、何であれ、動くはずもなし

しかしマジで無限ループ状態だから、もう止めようぜ
今のお前が理解するのは無理だよ

**デフォルトの名無しさん** · 2025/08/04(月) 22:38:19.37

>>403
文盲って言われても 317 は俺が言ってる通りの意味で、お前の解釈が間違ってるんだが？

**デフォルトの名無しさん** · 2025/08/04(月) 23:12:47.28

で、いつ検索プログラム書いてくれるの？

**デフォルトの名無しさん** · 2025/08/05(火) 17:39:03.31

>>401
え? 例えば箇条書きの部分 (Tom Dick Harry）の先頭は
● (<-文字化けするかな? U+25CF）で検索もコピペもできますが?
PDFの中を見てみました?

**デフォルトの名無しさん** · 2025/08/05(火) 17:45:25.95

>>406
全部でいくつあるか数えたか?
その他の/ActualText箇所が対応してない

**デフォルトの名無しさん** · 2025/08/05(火) 18:40:04.52

>>407
"T"の所? アクセシビリティをオンにしたらそこを"T"と読むので
これで機能している
多分/Spanとの組み合わせにする必要があるんじゃ?

**デフォルトの名無しさん** · 2025/08/05(火) 18:52:04.83

ところで、この手のPDFって/Encodingが/Identity-Hじゃないですか
もしかして/UniJIS-UTF16-Hとかなら元のコードが反映されるんじゃね? と思って
試してみたが... 駄目ですなーなるほどー
中間コンパイル的な感じでグリフの世界に行っちゃってる感じ?

**デフォルトの名無しさん** · 2025/08/05(火) 19:10:13.54

>>408
Thisで検索もコピペも機能してない

**デフォルトの名無しさん** · 2025/08/07(木) 22:53:42.70

というわけで、今のところActualTextが唯一の方法なのかな
本来は構造化とかタグ付け目的なのかもしれんけど、それでグリフとコードポイントの
対応もローカルにカスタマイズできるというか

**デフォルトの名無しさん** · 2025/08/07(木) 23:01:01.28

現状、それを生成できるPDFライブラリとそれを検索できるPDFビューアが限られるけど

ま、コピペするならPDFで出力する前の元の文書からどうぞ、って感じかね
そもそも元の文書の持つ論理構造はPDFにした時点で文書のレンダリング表現（って
言うのかな）に変換されるわけで、何かしら情報が変化しても不思議ではない、
というのが個人的感想ですが
もちろんこうしてアドビさんは頑張っている一方、それを理解していない人々も多々...

**デフォルトの名無しさん** · 2025/08/07(木) 23:05:14.12

そういえば、ネット上で色んなPDFが検索できるけど、中にはActualTextを使わずに
複数コードポイントが混在できているのもあった
それはフォントを切り替えることでグリフが重複していないのだった
PDFの生成主がそれを意図的にやったのかは不明だが

**デフォルトの名無しさん** · 2025/08/17(日) 14:45:32.19

康煕部首の「長」と普通の「長」がコピペで混在できる（こともある）PDFを
作ってみましたが、いかがでしょう
https://drive.google.com/file/d/1sqQ6lqQhvfC_zTkL3B4fQ_GV4_376O10/

とりあえずGoogle Driveが立ち上げるPDFビューアではうまくいかない模様w

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

ActualTextだとPDF内で該当文字が出てくるたび必要なので煩雑ではあるね

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

この手のPDFでは、フォントは部分埋め込みなのでCMapも対応する部分だけで
よく、すると一般的な文書の文字範囲では1対1対応にできる（場合が多い）のに
MSの場合はそれでもバグっている、わけね
埋め込みフォントを作る時点ではもうグリフしか見てないということか

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

Windowsのフォントをちょっと調べてみたら、MS明朝とか、「長」のグリフが重複していない
それでPDFを生成してみると... やはりコピペで文字化けしない

と言うわけでWindowsユーザーの皆さん、これからはMSのフォントだけを使う、
と言うのはどうだろうか。游明朝とかのことは忘れて
WindowsのPDF生成ドライバーもそれを望んでいるのかもしれない

**デフォルトの名無しさん** · 2025/08/19(火) 16:58:13.69

別にMSじゃなくても伝統的な日本語（JIS系や adobe-japan系）の文字しか入ってないフォントで重複してることなんてめったにないよ
複数の国の文字（中国漢字など）や異なる用途の文字（部首素片など）を同じフォントに収録してる場合にグリフ重複させる場合が多い
最近 google の Noto フォントみたいな多言語対応フォントを使い始めるやつが増えて問題を「再発見」してるだけ
そのせいで unicode のせいだとか言い出すアホが湧いてたわけだが（当然だがフォントには unicode に関係なく任意の文字とマップが登録できる）

**デフォルトの名無しさん** · 2025/08/19(火) 23:57:36.77

もちろんその通り
unicodeのせいだと主張してる人は根本的にわかっていない

**デフォルトの名無しさん** · 2025/08/20(水) 00:55:18.59

>>418みたいのって、どこかに書いてあるのでしょうか
それとも純粋に個人的な発想でしょうか

**デフォルトの名無しさん** · 2025/08/20(水) 01:07:20.10

>>420
opentype とか truetype とかもっと古い type1 とかフォントの規格と歴史を勉強しろ

**デフォルトの名無しさん** · 2025/08/20(水) 13:03:56.81

>>421
なるほど、そういったものを経て>>418のような知識につながったと。興味深いです

**デフォルトの名無しさん** · 2025/08/20(水) 14:23:04.97

>>418
お前が相変わらずアホなだけ
実際、SJIS時代に多言語対応フォントなんて誰も使ってなかったろ
お前は仕様的に出来る/出来ない事と、実際にみんながどう運用してるかの区別が付いてない

仕様が完全でなくても、通常の運用では十分カバー出来てた事を、
無駄に意識高いお前のような馬鹿が「仕様ガー悪いノデー僕は悪くアリマセンー」なノリで不用意に
そこらの意識低いド平民にも問題を強制的に「再発見」させたのはunicodeだろ
しかもunicodeでもグリフを重複させていなければ回避出来た話
(そもそも部首素片と一般の字のグリフが同じなのはただの手抜きな気がするのだが、
一般的に同じグリフにするのが正しいのだろうか？)

その他も含めて見る限り、unicodeは無駄に意識高い馬鹿が作った仕様で、実際の運用には向いてない感じだけど
MSはこの辺昔から泥臭くて、仕様の綺麗さより実際の使い勝手を重視するので、フォントもそうなってるだけ
(まあPDFのコピペ文字化けについては、
お前的にはunicodeではなくフォント『だけの』問題だ、としたいのだろうが、
unicodeがその他諸々糞で、この問題でも誘発源になってるのは事実だろ)
そしてふと考えてみるに、unicodeの利点って、

・文字化けしない

だけで、これ以外は全て以前のSJISの方が良い気がしてきた
勿論これだけで十分な利点だし、SJIS以前の仕様はCPUが非力な時代の産物だから運用向きなのも事実だが

**デフォルトの名無しさん** · 2025/08/20(水) 15:48:16.32

絶対負けを認めないマン

**デフォルトの名無しさん** · 2025/08/20(水) 16:40:06.57

勝った負けたではなく、俺の認識はこう、ということ
お前がそう思わないのはお前の自由
(というか、何でも勝った負けたになるのは議論出来ない馬鹿の特徴
そもそも「議論」に勝った負けたはない
勝った負けたがあるのは「討論」＝決を採る段階で、5chで(というよりネットで)決採る意味はないから、
そもそもネットでのほぼ全部の議論に勝った負けたはない
その辺ひろゆきも大幅に勘違いしてるし、信奉者も同程度
つかね、論破に拘ってる＝論破して喜べる＝普段なかなか論破出来てない＝馬鹿
ということなので、自分で自己紹介しなくても、とは思うのだが)

PDFの仕様が完璧でなかったにせよ、
SJIS時代にMS明朝等使ってた人＝一般の人ほぼ全員は遭遇しなかった問題だろ

・MSが上手く回避策を実行してくれてた事を感謝するタイプか、(正確にはMSがではなく、普通に作ったら回避出来るとも思うが)
・俺が何をやるにしても自由だからとにかく仕様が悪いと言い張るタイプかの違いだよ

俺は前者、unicode連中やお前らは後者、ということ
ただ実際、unicodeはもう一度綺麗に作り直さないと駄目な程度に酷い仕様になってきてるよ
しかしこれはunicodeの唯一の利点＝文字化けしないを消す事になるから、死んでもやらないのだろうけど
となると、どこまで行けるか？というチキンレースにはなってるよ

**デフォルトの名無しさん** · 2025/08/20(水) 16:44:32.21

さんざんマウント取る言い方してきて、勝った負けたの勝負じゃないだとw
クソダサ

**デフォルトの名無しさん** · 2025/08/20(水) 17:25:07.68

>>423
SJISなんてものを褒め称えるとはマイクロソフト信者かね
昔からメールなどネット上ではいわゆるJISコード(ISO-2022-JP)が使われてきてこちらが国際的にも通用する主流でUNIXなどではEUC-JPが標準
もちろん今では国際的にUNICODEで統一され符号化はネット上もファイル保存もUTF8だがマイクロソフトさんは

**デフォルトの名無しさん** · 2025/08/20(水) 18:20:43.93

unicode 出る前からフォントは複数の文字コード対応マップで多言語化されれたことを知らないんだろうな

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

SJISが世界の全てだった人なんだろうね

**デフォルトの名無しさん** · 2025/08/20(水) 21:05:49.55

>>427
JISがメールで使われてたのは7bit透過だからだぞ
SJIS信者だと思うのは自由だが、PDFのコピペに関しては、今風に言うと現場猫だよ
PDF仕様猫：グリフが重複して使われるフォントなんて普通ないからヨシッ
PDF出力アプリ猫：同上、ヨシッ
google猫：PDF出力アプリが対応してればグリフが重複してもヨシッ
unicode猫：同じ字(でもないが)に複数の文字コードを割り当てても、アプリかフォントが対応してればヨシッ

MS：普通、部首素片と通常文字は別グリフだろ、これで何も問題なくなるし
フォントがどうであれ、アプリ側で対応出来るのは事実なので、アプリが一番悪い
次に悪いのはフォントで、手抜きでなければ部首素片と通常文字は別グリフになるように思う
ただしそもそものunicodeの思想が間違ってて、そもそも統合漢字としてるCJKの通常文字、
日本人と台湾人と中国人の美的感覚は異なるだろうから、同一グリフで何とかなると考えてる所に無理がある
ただ、欧米も同様にアルファベットの美的感覚が微妙には異なるはずなので、連中が問題ないからCJKも問題ないと思ったのかな、とは思う
(ここらへんは文化の結合度によるが、欧米ほど人が交流してれば美的感覚もそれなりに共有されてるのかもしれん)

というか、具体的に言うと「骨」(0x9aa8)や「曜」(0x66dc)、これらは美的感覚ではなくモロに別形だが
CJK統合漢字という根本的なとこから間違ってるよねと
というかこれらが別コードとして登録されなかった理由は何なんだ？今更異体字ダーとかやってるのに

**デフォルトの名無しさん** · 2025/08/20(水) 21:08:26.58

ん？2行連続空行は削除されるようになったのか？
まあちと読みにくくなってるが、よろしく

**デフォルトの名無しさん** · 2025/08/21(木) 02:20:32.36

一つ一つの技術を正しく理解していないから、文字通り「個人の感想ですよね」という
まあ5ちゃんだし、酒飲み話みたいのもアリだとは思うけど
正しい知識が元になっていればそれは役に立つ話にもなる
一方読む方は間違いを間違いと見抜く力が.... って決してひろゆき信者ではないw

**デフォルトの名無しさん** · 2025/08/21(木) 02:56:06.57

私も世界にSJISさえアレば良かった人間です(過去形)。欲しい文字は外字にドット打ってました。
ROMに第2水準程度しか乗っていない8ビットや16ビット世代のマシンでUTF8を構築するのって、現実的に可能なのかしら。
興味本位の疑問だけど。

**デフォルトの名無しさん** · 2025/08/21(木) 04:47:17.94

交換用符号としての扱いは楽だけど
ROMのコードがJISだから変換マップをオンメモリにするのは厳しそう
索引付きでないと性能でないと思うから
これもROMで持てるならあり
もちろん幅や方向、合字なんかは扱えない

**デフォルトの名無しさん** · 2025/08/21(木) 05:18:08.01

>>433
そこはSJISとUTF8といった符号化方式の比較でなくてJIS漢字コードとユニコードの比較で十分
漢字ROMのデータ収録順序はJIS漢字コードの機械的変換できる範囲内だろうから
ユニコードからJIS漢字コードへのマッピング

**デフォルトの名無しさん** · 2025/08/21(木) 05:33:29.34

いわゆる半角カタカナ等(JIS X 0201)と全角漢字等(JIS X 0208)のほとんどは規則的変換できるようにユニコード内に収容されている
例外は一部の記号や文字のみ
したがって漢字ROM読み出しもほとんどは規則的変換できて例外のみ対応で実用的かな

**デフォルトの名無しさん** · 2025/08/21(木) 06:14:19.45

漢字は厳しいだろ
偶然だが半角の途中まではEF BDを前置するとUTF8
　A1　｡　EF BD A1

　AF　ｯ　EF BD AF
　B0　ｰ　EF BD B0
　B1　ｱ　EF BD B1
　B2　ｲ　EF BD B2
　B3　ｳ　EF BD B3
　B4　ｴ　EF BD B4
　B5　ｵ　EF BD B5

　BF　ｿ　EF BD BF

**デフォルトの名無しさん** · 2025/08/21(木) 08:42:01.26

>>436
JIS/SJIS/EUC: https://manuals.ricoh.com/mfp/p_manual/MPC6004JPN/ja/intro/int/r_cjr041.htm
unicode: https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/cjku_klist.html
さすがゆとりZ、無敵すぎ

**デフォルトの名無しさん** · 2025/08/21(木) 09:07:08.19

>>436
昔のAIにSJISをunicodeに変換するコード書かせたら何故かテーブルもってなくて機械的にシフトと論理演算で変換できますってコード出されたって話を思い出した
お前、そのAIだったりしないか？

**デフォルトの名無しさん** · 2025/08/21(木) 16:15:00.95

>>438
>JIS/SJIS/EUC: https://manuals.ricoh.com/mfp/p_manual/MPC6004JPN/ja/intro/int/r_cjr041.htm

区点コードで文字入力とはシブい。しかし字形が2004じゃないのは果たして
マニュアルだけの話でプリントで使うフォントとかは別なのかな。にしても

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

>>440
何が言いたいのか分からんが、こちらの意図を明確にしておくと、
ただ単に「JIS 漢字表」でググって並び順が見やすいのを選んだだけ
コードなら以下が見やすいかと
http://www.infonet.co.jp/ueyama/ip/binary/x0208txt.html

JIS等は漢字もあいうえお順(ricohのサイトはまんまアイウエオで見やすい)
てかunicodeって何順？

**デフォルトの名無しさん** · 2025/08/22(金) 21:59:54.85

https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/cjku_radical.html
＞UnicodeのCJK統合漢字は、概ね部首順(部首内は画数順)に並んでいます

**デフォルトの名無しさん** · 2025/08/23(土) 02:24:50.51

しかしこれらの部首って、例のUnicodeの漢字部首のコードポイントに頼らなくても
出せるのね。元々各国の文字コードに部首のコードがあってそれがUnicodeに
引き継がれているようで

JISでも第二水準にちょいちょい部首が入っている。冫（にすい）とか
だがしかし「さんずい」や「しんにょう」などは第二水準にはない
これって何故でしたっけ。まさかさんずい＝水に「包摂」とか? ???

**デフォルトの名無しさん** · 2025/08/23(土) 06:47:36.46

>>443
氵も辶もJISにあるだろ (JIIS補助漢字または第4水準だが、包摂ではない)
もちろん Unicode も部首素片以外に漢字側にも登録がある
冫だけ第2水準なのは教科書とかで使用例があったから（うろ覚え）

**デフォルトの名無しさん** · 2025/08/23(土) 07:30:15.06

大元の理由が知りたいというい意味ならこの辺は漢字の歴史に由来していて
「冫」は甲骨の時代から独立した漢字で「氷」は字源的には「冫+水」の「冰」の略字
「氵」は「水」が部首になった時の省略形で昔の漢字では2つは全く同じ字形

unicode でも「冫」は漢字としてのみ登録されていて、部首素片(CJK Radical)には無かったはず

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

>>444
「第二水準内で」（第四水準がなかった時代に）という意味です
第四がある現在では包摂の適用が変わりましたので

>>445
JISの中の人がどう考えていたのか気になりました
「冫」は康熙部首の方にありますね(U+2F0E）

どうやら康熙部首がメインでCJK部首が補助のようですが、件の「長」は何故か両方に

と思いきや、CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
そんなんわかるかあw

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

>>444
「第二水準内で」（第四水準がなかった時代に）という意味です
第三以降では包摂の適用が変わったので、同列には語れません

>>445
JISの中の人がどう考えていたのか気になりました
「冫」は康熙部首の方にありますね(U+2F0E）

どうやら康熙部首がメインでCJK部首にはそのバリエーションが
なのに「長」は何故か両方に同じものが入っている??

と思いきや、CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
そんなんわかるかあw

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

失礼、投稿が失敗したと思いダブリました（&少し書き直した）

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