文字コード総合スレ part15

**デフォルトの名無しさん** · 2025/01/25(土) 13:31:18.17

>>249
どちらのOSも自由を許容している
そのため非ユニコードが混入しうる
OSは歯止めにならない

だからRustのように型で明確に区別できる言語を用いてアプリを作ればよい
非ユニコードが他へ波及することを防ぎつつ安全に扱うことができる

**デフォルトの名無しさん** · 2025/01/25(土) 14:44:40.60

from_encoded_bytes_uncheckedにoverlong UTF-8をブチ込んでinto_stringしたらOk返ってきちゃった

StringまたはWTF-16から変換されること以外は無い前提でチェックは最低限にされてるみたい
unsafe contractを破った俺が悪いのはそうなんだが、これを「WTF-8文字列コンテナ型」だと思ってたらまあまあ死にそう
バイト列からの変換にcheckedな版が無いのも、一応エンコーディング未規定なんだから好き勝手なバイト列から作るもんじゃねーよバーカってことだな

同じことをLinuxでもやったらこっちはinto_stringの時点でErrが返ってくる
OsStringの内部のバッファの不変条件としても違いがあって、Windows以外では任意のバイト列でいいけど、Windowsでは常にWTF-8でなくてはならないようだ

WTF-8それ自体が脆弱性の根源になることはなくても、こうしたややこしさが誤った使い方、ひいては脆弱性を生むことはあるかもしれないとは思った

**デフォルトの名無しさん** · 2025/01/25(土) 15:20:14.12

>>251
そのunsafe fn from_encoded_bytes_unchecked(byres: Vec<u8>)は安全性の対象外と明示されているね
unsafeとはC言語と同じようにプログラマーの責任で安全性を保証しなければならない
それを理解しない者や扱う技術を持たない者がunsafeを使ってはいけない
それ以前にRustは今回の件も自動的に安全性が保証されるコードを(unsafeを使わずに)書くことができる

**デフォルトの名無しさん** · 2025/01/25(土) 15:40:07.61

>>252
その通り、だからunsafe contractを破った俺が悪いと書いた
しかしぶっ壊すことで得られる学びは多い

**デフォルトの名無しさん** · 2025/01/25(土) 15:45:28.44

というかもうWTF-8の話じゃなくてRustの話になりつつあるしこの辺で終わっとこうぜ
続きがやりたければRust本スレで

**デフォルトの名無しさん** · 2025/01/25(土) 21:10:55.94

Rustスレから出てこないで欲しい

**デフォルトの名無しさん** · 2025/01/25(土) 22:20:25.13

構うから居座り続けるんだよ
学習しろ

**デフォルトの名無しさん** · 2025/01/26(日) 10:07:42.23

Macの濁点半濁点問題ってUTF-8の正規化とやらの範疇に入るのかな
文字構成の解釈の仕方の問題だから正規化を実装する人の思想に強く依存してしまうと思うけど

**デフォルトの名無しさん** · 2025/01/26(日) 10:56:58.06

日本人からすると濁点半濁点の違うMacうぜーとなるけど
欧州でもdiacriticsがあるから同じくMacうぜーだろうな

**デフォルトの名無しさん** · 2025/01/26(日) 11:31:33.02

>>257
このスレにいるなら文字コードとエンコーディングの区別を理解しよう
UTF-8はエンコーディング方法なので
そこでの正規化は冗長表現の排除やサロゲートペアの排除を指す
一方濁点半濁点の話は文字コードであるUnicodeの正規化の話であってUTF-8は一切関係がない

**デフォルトの名無しさん** · 2025/01/26(日) 11:52:28.72

>>257
Unicode の正規化は規格で決まっている
基本的に実装者の自由にやってはいけない
・複数の正規化が規定されてるのでそのうちの1つに過ぎない
・MacOSの正規化は一部規格から外れてる
という問題はある

**デフォルトの名無しさん** · 2025/01/26(日) 12:03:07.52

Macの濁点半濁点問題はEBCDICのカナ（半角カタカナ）をきれいに表示する努力をした結果なのだろうか？

**デフォルトの名無しさん** · 2025/01/27(月) 11:38:12.00

ファイル名は正規化するべきなのかするべきでないのか、という問題があり
Macは正規化する派
正規化するとした場合、どういう正規化がいいか、それが次の問題

**デフォルトの名無しさん** · 2025/01/27(月) 18:51:09.07

日本語のフォントを外国人が作っているせいで日本語の記号の見た目がおかしくなった

**デフォルトの名無しさん** · 2025/01/27(月) 18:52:15.56

>>262
Macのアップル社もGoogle社も改行コードに対しては意地悪すぎだろ

**デフォルトの名無しさん** · 2025/01/27(月) 22:05:41.27

Apple の改行コードはCRだったものがMac OS X でLFになったのを意地悪と言っているのだろうか？

**デフォルトの名無しさん** · 2025/01/27(月) 23:31:59.65

>>265
WindowsのCRLFをどちらも改行と見做すところ

どう考えても1つの改行なのにEメールなどでは2つの改行として送り返してくる

**デフォルトの名無しさん** · 2025/01/28(火) 10:08:29.84

CR=改行(Macのみ)
CRLF=改行(WindowsやRFC)
LF=改行(Unix)

>>266
それはアプリのバグ

**デフォルトの名無しさん** · 2025/01/28(火) 11:39:24.54

>>267
いろいろ間違えてるぞ
正確さが足りない

**デフォルトの名無しさん** · 2025/01/30(木) 07:10:47.96

ワシの霊感では、
CR LF → LF 変換　は無理
CR LF → CR 変換　も無理
その逆、は可能、スナワチ
LF → CR LF 変換等は、可能

なんでかって❓　霊感的には、
それが可能と仮定すれば、そのような問題は解決済
しかし未だに未解決の模様なので、

では、霊感的にではなく、数学的にはどうなのか
吟味しようかな。てか不可能が証明されても
その証明は、闇に葬る必要があるよな
by 💃🥳🤔

とにかく、アプリの改行バグなくせぇーー
by 👤🤡

**デフォルトの名無しさん** · 2025/01/30(木) 10:13:34.95

RFCもいまどき入力は寛容にとは書いてないんだっけか

**デフォルトの名無しさん** · 2025/01/30(木) 23:31:56.82

改行の話をするならこのTRには目を通しているよね?
https://www.unicode.org/reports/tr14/tr14-32.html#BreakingRules

**デフォルトの名無しさん** · 2025/01/31(金) 19:55:09.44

CRの直後にLFが現れたなら、改行2つではないとわかる。
それなのに改行2つと解釈するのは悪意でしかないり

**デフォルトの名無しさん** · 2025/01/31(金) 20:06:45.58

CR や LF より前に CRLF を処理しないのは悪意でしか無いな

**デフォルトの名無しさん** · 2025/01/31(金) 20:07:21.09

>>260
NFD、NFC等を名乗るならそうだが最初からmodified NFD言ってるしなあ
当時は異体字セレクタなどなく、ただのNFDで字形まで変えるUnicodeの定義のほうがおかしかった

**デフォルトの名無しさん** · 2025/01/31(金) 20:25:32.29

>>274
みんながみんな勝手に modified NFD とか作り始めたら互換性とか規格とか何の意味もなくなる
勝手なオレオレ基準は非難されるべき
単に古い規格準拠というだけなら許されるが Apple のはそうじゃない

**デフォルトの名無しさん** · 2025/01/31(金) 20:45:51.19

そもそも正規化自体は都合に合わせて勝手にやるもんだぜ？
Windowsの.で終わるファイル名を拡張子なしと同一視するのも正規化だし
掲示板への書き込みで行頭のスペースが消えるのも正規化だ
Unicodeで定義されたやつだけが正規化ではないというのは大前提として

字形を変えない範囲で厄介な合成分解で別ファイル扱いになるのを避けたい
というのは他の文字コードからUnicodeへの過渡期では当然の要求だろう
他のOSとのやりとりでトラブルが起きるようになったのはもっと考えるべきだったとは思うが

**デフォルトの名無しさん** · 2025/01/31(金) 20:53:12.36

>>276
それは違う
Apple はユニコード・コンソーシアムの設立からのメンバー
技術的に規格に問題があるののならそれを変えればいい、それをやらなければいけない立場
中核メンバーが自分たちが作った規格を勝手に無視してたら、規格の意味なんてない
この件はどう言い訳しても Apple はクソという結論にしかならない

**デフォルトの名無しさん** · 2025/01/31(金) 20:55:58.32

>>277
Appleは提案したが通らなかったってどっかで見たぞ

**デフォルトの名無しさん** · 2025/01/31(金) 20:57:03.60

技術的に無理な仕様作ったん？

**デフォルトの名無しさん** · 2025/01/31(金) 21:06:00.74

>>278
どこで見たんだ？
技術的に変な提案したら通らないだろうが、それが規格を無視して良い理由にはならない
それを理由に脱退したんなら一理あるけど

**デフォルトの名無しさん** · 2025/01/31(金) 21:19:51.37

規格があるのにそれを使わない分野なんて沢山ありそうだが
実際のところ金を出せて声がでかければ規格なんていくらでも通せるんだから

**デフォルトの名無しさん** · 2025/01/31(金) 21:24:04.22

>>280
俺が見た記事は残ってないだろうけど検索したら出てきたunicode.org内の議事録はたぶんこれ
ttps://www.unicode.org/review/resolved-pri.html#pri7

**デフォルトの名無しさん** · 2025/01/31(金) 21:26:16.69

>>281
ヒデェ

**デフォルトの名無しさん** · 2025/01/31(金) 22:22:23.03

>>282
ｗｗｗ
一部除外したら一貫性が無くなって正規化が正規化じゃなくなるから勝手な除外は駄目って明確に指摘されてるな
なんで実装したんだろう？いやVFとか使いたくなかったんだろうけど、

どうしてもやりたければ任意の除外ではなく VF のみ除外みたいなので再提案すべきだったのでは

**デフォルトの名無しさん** · 2025/02/16(日) 22:21:14.00

https://gigazine.net/news/20250214-unicode-hidden-message/
Unicodeでは一見すると普通の文字の中に「秘密のメッセージ」を埋め込むことが可能だという指摘

**デフォルトの名無しさん** · 2025/02/16(日) 23:51:54.49

>>285
なるほどね
https://i.gzn.jp/img/2025/02/14/unicode-hidden-message/03.png

**デフォルトの名無しさん** · 2025/02/17(月) 16:59:47.72

Unicodeはそのうちオーディオブック用やa11yで読み上げ音声用のVSが定義されそう

**デフォルトの名無しさん** · 2025/02/17(月) 17:34:45.48

漢字みたいな複数の読み方があるのは難しいだろうね

**デフォルトの名無しさん** · 2025/02/17(月) 18:36:11.68

MSOfiiceでIME入力がphoneticsとして保存されてて読み仮名表示出来るのは、他に広まっても良いのにな

**デフォルトの名無しさん** · 2025/02/18(火) 12:25:03.72

>>286
なるほどね
fn byte_to_variation_selector(byte: u8) -> char {
if byte < 16 {
char::from_u32(0xFE00 + byte as u32).unwrap()
} else {
char::from_u32(0xE0110 + (byte - 16) as u32).unwrap()
}
}

**デフォルトの名無しさん** · 2025/02/28(金) 17:04:23.70

fn byte_to_variation_selector(byte: u8) -> Option<char> {
if byte < 16 {
char::from_u32(0xFE00 + byte as u32)
} else {
char::from_u32(0xE0110 + (byte - 16) as u32)
}
}

**デフォルトの名無しさん** · 2025/04/03(木) 21:05:53.03

「Windows11でファイル名に絵文字が使えることを知って、1つ賢くなった」便利と思われる機能が追加→情シスがバールを担いで暴れ出す案件
https://posfie.com/@blackstaragent/p/kpHrLMR

今まで使えなかったんだっけ？と思って最後まで見たら
ちゃんと前から使えてたって突っ込まれてたわ

**デフォルトの名無しさん** · 2025/04/06(日) 16:37:54.44

普通に文を書く時でも()?!などの記号をASCII文字にするか全角文字にするか
濁点と半濁点を結合済み文字にするか別の文字にするかで迷ってしまう

**デフォルトの名無しさん** · 2025/04/07(月) 21:43:17.60

濁点と半濁点が別の文字だと認識しているのはおかしい

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

まし"て"

**デフォルトの名無しさん** · 2025/04/09(水) 01:54:47.78

Windowsのエクスプローラーで見るとキャラクタセットによっては濁点が別の文字だとわからないことがある

**デフォルトの名無しさん** · 2025/04/11(金) 20:08:58.20

朝鮮系の奴隷労働者が造ったと思われるサイトは
濁点が抜けてる気持ち悪いところがいくつかある

**デフォルトの名無しさん** · 2025/04/12(土) 06:35:11.93

調整
https://techracho.bpsinc.jp/hachi8833/2021_09_08/48435
https://gigazine.net/news/20231005-unicode/
477414164X

**デフォルトの名無しさん** · 2025/05/02(金) 09:50:51.92

不可視化トラップで教育素材造るのはいいね
https://www.youtube.com/watch?v=cXTBwD798Lk

**デフォルトの名無しさん** · 2025/05/02(金) 18:10:04.97

ユニコード悪用ヤバいな

>>298
＞公式アプリと同じ開発者に見える名前で偽アプリが提供されました。
＞この詐欺師は、印刷に現れないスペース文字を開発者名に混ぜ込むことでバリデーションのすり抜けに成功しました。
＞このハックによって100万人以上が騙されました。

**デフォルトの名無しさん** · 2025/05/02(金) 20:30:48.79

>印刷に現れないスペース文字

誤訳だな
AIあほすぎ

**デフォルトの名無しさん** · 2025/05/07(水) 21:40:30.18

https://github.com/microsoft/cascadia-code/releases/tag/cascadia-next

Joyo, JIS1, JIS2って何だよ
日本人向けのフォントなら日本人に分かるような書き方してくれ

**デフォルトの名無しさん** · 2025/05/08(木) 02:26:11.93

>>258
多分Mac OS Xのファイル名にNFDを採用したのは
辞書順がdiacriticsを無視する言語文化圏の人だったのでは
欧州では多数派だけど唯一ではない
>>121
OS kernelのsyscall部分で矯正してるわけではなくて
file system driverがやってる(ただしDarwinソースを確認したのは10年以上前)
だからUSBメモリだとかNFSだと、NFCでも書ける
ただし他の人も書いてる通りライブラリでも強制してる
CLIだと関係ない

**デフォルトの名無しさん** · 2025/05/08(木) 03:01:55.71

ちなみにライブラリで必ずやることに変えれば
規格準拠にしやすいと思う
フル準拠にするとカーネルに入れるにはテーブルが大きすぎる
けどじゃあPython処理系はどうするんだ
osモジュールに担当させるのか
osモジュールみたいな機構がない言語処理系ではどうするんだ
とか色々大変

**デフォルトの名無しさん** · 2025/05/08(木) 03:15:04.31

要するにパス名正規化は無意味で無駄

**デフォルトの名無しさん** · 2025/05/08(木) 12:28:18.82

ちっぱいでもいいじゃん

**デフォルトの名無しさん** · 2025/05/08(木) 16:10:03.97

>>305
いや正規化やっても良いんだよ
ただしやるなら規格書どおりにやれ
勝手仕様でやられると対応に困る

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

規格には則ってる
複数あって非互換なのが問題

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

>>308
MacOS のやつは規格にあってないんだよ
しったかすんな

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

せめてNFCにしてればな
殆どの文書はNFCで構成されるんだから
それでもUnicodeは規格がバージョンごとに違うからなあ
正規化が無駄な努力

**デフォルトの名無しさん** · 2025/05/09(金) 02:29:43.44

>>303
ファイルコピーとかするときは毎回、正規化の変換が発生する感じ?
（不明な正規化）->（特定の正規化）ってのは問題ないんだっけ?

一方でファイルビューア（Finder)とか上の方はどのFS上にいるとか意識
したくないだろうからなあ。そこでも正規化の変換が起こるのかな?

**デフォルトの名無しさん** · 2025/05/09(金) 11:12:25.67

ファイルビューア
↓正規化
ファイルヒ゛ューア

こんなのやだな

**デフォルトの名無しさん** · 2025/05/09(金) 12:07:16.82

EBCDICカナ文字の話みたい。
ごめんなさい、ごめんなさい、ごめんなさい。

**デフォルトの名無しさん** · 2025/05/09(金) 15:56:58.76

>>311
最近macOSは余り触ってないが昔は
(様々な理由により以下の状況が起きて)
ファイルビューア
ファイルヒ゛ューア
の両方がディレクトリにある場合に、Finder.appでは
ファイルビューア
ファイルビューア
と表示され後者しかアクセス出来なかった
Cocoaが正規化してユーザやカーネルに渡すから

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

字にはヒラギノール

**デフォルトの名無しさん** · 2025/07/20(日) 21:42:09.27

Microsoft Print to PDFで出力したファイルからテキストをコピペしたら文字化けしてた…→実はPDFの仕様に潜む本質的な欠陥が原因なのでは？
https://togetter.com/li/2577928

**デフォルトの名無しさん** · 2025/07/20(日) 22:29:37.55

>>316
文字コードの問題ではなく単なるバグ
より正確にいうと大昔からある PDF のフォントの使い方の問題

PDF はウェブと違って文字コードをデフォルトでは埋め込んでなくてフォント内の番号で直接埋め込んでる
フィント番号と文字コードが1対1でマップしている保証はないのに、コピペの時はフォントに埋め込みの変換表で番号から文字コード生成する仕組になってる
複数の文字コードに同じフォントを割り当てているフォントを使うとこの問題が起きる

**デフォルトの名無しさん** · 2025/07/22(火) 01:09:42.93

>>316 みたいな奴が参政党に投票する

**デフォルトの名無しさん** · 2025/07/22(火) 12:00:50.20

アドビはタイプセッター屋じゃけぇ、フォントファーストじゃけぇ

**デフォルトの名無しさん** · 2025/07/22(火) 12:55:59.74

>>317
しかし1:1になるように、
つまり同じ字形が複数の文字コードで使われるなら、同じ字形のフォントを別登録してしまえば回避出来るのでは？
ならPDF出力ソフトが糞なだけ

**デフォルトの名無しさん** · 2025/07/22(火) 13:37:16.00

>>320
そんなことしたらサイズが無駄にでかくなるだろ
PDFがアホなのは同意だが、unicode普及以前の技術なのを思い出せ

**デフォルトの名無しさん** · 2025/07/22(火) 15:01:08.85

>>321
大きくはなるが、1%も変わらんだろ、その文書で使った物だけそうすればいいのだし

> unicode普及以前の技術なのを思い出せ
unicode以外では特に問題なかったのなら、unicode側の問題であり、
unicodeをPDF化するときには数パーセント大きくなる、で済んだ話だろ

お前がPDF嫌いなのは分かるが、技術的には、unicodeで仕様を拡大したのにPDF出力ソフトが対応出来てないだけだろ

**デフォルトの名無しさん** · 2025/07/22(火) 19:20:34.51

>>322
違うんだ。unicode その他の対応の拡張で PDF の仕様自体は更新されてるんだ
でもその機能にちゃんと対応している pdf 作成ツールや pdf viewer が少ないだけなんだ
本家の Adobe で作成して Adobe で読めば問題なかったりするんだよ

**デフォルトの名無しさん** · 2025/07/22(火) 22:22:27.85

>>323
となるとPDF側はすべき事はやってて、unicodeと糞ソフトの問題だな

とはいえ今更本家からの統制は無理だし、
この問題を認識した上で各自が対応するしかなさそうだな
(そういえば最近無駄にコピペさせないPDFが増えた気がするが、実は糞ソフト側のパッチ対応であったか)

**デフォルトの名無しさん** · 2025/07/24(木) 18:46:53.48

>>316
PDFの仕様が自由すぎるからだぞ？

**デフォルトの名無しさん** · 2025/07/24(木) 19:36:31.51

adobeはPDF2.0に対応したのか、やる気もないのか、とふと思った

**デフォルトの名無しさん** · 2025/07/24(木) 21:57:49.45

>>326
対応とは？
PDF-2.0 が何か知ってて言ってるのか？↓

**デフォルトの名無しさん** · 2025/07/25(金) 01:59:47.04

PDFはPostScriptがベースなんだけど、これは元々プリンタ出力のために設計されたもの
後は紙に印刷するだけって状態のデータだから文字コードなんて概念はない

PostScriptの仕様をPDFに流用する時、検索ができないのは不便だからってんで
グリフ番号→文字コードのマッピング表をPDFファイルに埋め込める仕組みを作った
アプリがこの表を適宜生成しないと文字化けが発生する

**デフォルトの名無しさん** · 2025/07/25(金) 07:07:21.05

>>328
それで、unicode以外ではグリフと文字コードが1:1だから問題にならなかったのなら、
アプリ製作者がunicodeについて無知なのが原因だろう

ただ、unicodeも無駄に冗長すぎるようにも見える
K(0x212a:Kelvin sign)とか、K(0x4b:大文字K)が今までの全ての文書で使われてるのに今更どうしろと？
今後「KをKに修正しろ」と誤字を指摘するKelvin警察が生まれるとウザい

そして割と問題なのが、検索で引っかからなくなる事
検索時には区別しないのなら、最初から今まで通り同じフォントでよくね？だし

unicodeが何を目指してどういう着地点を想定してるのかさっぱり分からん

**デフォルトの名無しさん** · 2025/07/25(金) 09:21:41.11

>>329
元々の unicode は実践主義、御都合主義ともいう。
過去に別の文字として同時に実装された記録があれば別の文字として登録。

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

>>330
つまり、あらゆる文字コードの上位セットにしてしまえば、文字コードを統一出来るとの考えか

しかしこれだとあらゆる方言を内包する事になるので、おかしくなりかけてるのが今か
どこかの自治体が「斉」の文字を外字で19種登録してたら、これもいつか実装されるというわけか
(と思ったらもうあった、0x9f4a～8文字のようだ)

仕様を適宜整理出来ず、ムダ仕様が膨らみ、メンテ不能になるのは、あるあるだけど、
unicodeもこの軌道に乗ってるな
(もしかして欧米連中はこの辺の仕様の整理が上手くて、下手糞なCJKを混入したからおかしくなってるだけか？)

**デフォルトの名無しさん** · 2025/07/25(金) 14:05:16.33

>>331
戸籍／汎用電子情報交換環境／文字情報基盤の「斎」の変種のことなら unicode には IVD として全部登録されてる

**デフォルトの名無しさん** · 2025/07/25(金) 18:28:38.05

>>332
正式名称は知らんが、俺が言ってるのはそれだな
ググったら総務省が音頭取ってやってるのか？色々出てきたが、
少なくとも規格化してから登録してるようだから、最低限の重複チェック等はあるはずで、まあ何とかなるのかな？

にしても検索どうするんだこれ？だし、
最近の絵文字の氾濫も、当初の想定からかなり逸脱してるのではないかと思うが

**デフォルトの名無しさん** · 2025/07/25(金) 19:02:45.52

と思ったが、IVSは直後に枝番付加する方式か
まあ、比較的マシ、というか、真面目にやるならこれしかない程度には洗練されてる

ちなみにこれ、実際のグリフを算出するにはどうするのだ？
異体字が全部Exxxなようで、辞書引きするしかなく、それがIVDなのか？
というか各者の説明読む限り、845B+E0100指定すれば勝手にそれが出てくる的な書き方で、
もしかして「斉」のようにunicode側に独立したコードを割り当てておらず、
必ず元字＋枝番のセットで使うのが仕様か？(この方がいいが)

**デフォルトの名無しさん** · 2025/07/25(金) 19:10:28.15

>>334
IVD は重複登録が許されてる。ソースが異なれば完全に同じ字形でも異なる IVS が与えられる（こともある）

**デフォルトの名無しさん** · 2025/07/26(土) 08:13:11.69

>>335
うむ、意図が分からん
「斉」は独立コ
ードも与え、IVDにも登録、
「葛」は独立コー
ドなし、IVDには登録、のようだから、仕様作ったやつが馬鹿だな
実装には結局両対応が必要となり、発注価格には1000万程度の上乗せが各社で必要となる
無能が仕様を作るとこういった糞仕様による目に見えづらい税金が発生するから、
仕様は最初にガッツリ決めようぜというのが欧米流だが、相変わらず日本はこの辺糞だな
（大方やってるうちに足りなくなって途中で方針変更だろうが、これをやられると悲惨なことになる)

> ソースが異なれば完全に同じ字形でも異なる IVS が与えられる（こともある）
検索でヒットする必要がなく、たまたま同じフォントで見た目が同じなだけだから、
プログラム側には全く問題ないだろうさ
ただ、入力側が正しく入力できるかは大問題だろうけどさ

単一の文字コー
ドを目指すかぎり、字体のみならず、コードの割り当て方の方言も内包することになるわけだな
unicodeのバージョン管理って、完全上位互換?それとも後方互換切り捨て？
(例：16準拠の場合、15を完全に満たすのか、そうでないのか)
C#のように上手く古い仕様を廃止していかないと、確実にどこかで破綻する気はする(か、そもそも実装してもらえないか)

**デフォルトの名無しさん** · 2025/07/26(土) 12:33:33.50

>>336
最近の仕様だけ見たら混乱するよな

－もともとは同じ文字の別字形については昔の資産（unicode が作られるより前の20世紀の文字コード）にある文字だけ独立したコードポイントが割り当てられる方針だった
－その後の他の字形も使いたい、実際に使ってる現場があるという要望に答えるために IVS が整備された
－でもある文字と別の文字の字形が同じかどうかをフォント抜きで確実に判別する手段がないので字体表をそのまま IVD として登録していく方針にした
－中国政府が「 IVD とか知るか、独立したコードポイント割り当ててくれないんなら、自分たちで勝手に割り当ててオレオレ unicode の利用を中国国内では強制することにするがよろしいか？」と言い出した
－ unicode 側が折れて漢字に関しては中国が要望してきた分に関してはIVDじゃなくて今後も全部に独立コードポイントが割り当てられることになった
－甲骨文字は漢字じゃないので独立コードポイントよこせって中国が言ってきたので漢字とは別に割り当てる予定

**デフォルトの名無しさん** · 2025/07/26(土) 13:22:34.55

>>337
日本側の状況はさもありなん
全自治体の異体字をカバーする為にはIVS/IVDしかないので、最初からここを目指せればベストだったが

中国側の言い分は正直分からん、というか連中は日本政府以上に馬鹿だな
検索考えたらIVS/IVD方式の方が独立コード方式より断然いいのに
とはいえ状況知らんが、簡体/繁体もある意味異体字だから、最早どうしようもないのかもしれんが

> オレオレ unicode の利用を中国国内では強制することにする
それは中国規格なので勝手にしろでいいと思うが
> unicode 側が折れて
となるのは、unicode陣営は統一コードの夢を見続けている、ということか
なら、日本政府が、どうにもならないからやっぱ止めて新規格作ります、とか言いだしたら、(見る限りこの必要はないと思うが)
非関税障壁ガーで、足抜けは許さないコードヤクザになるわけだな

まあ、検索考えたら独立コードになってるのも全部IVS/IVD方式に寄せた方がいい
現実的には入力後に独立コード→IVS/IVDに変換してDB登録すれば実害はあまりない
可能であればさっさと独立コードになってる物を仕様から落とすべきだが、これは難しいのだろうね

**デフォルトの名無しさん** · 2025/07/27(日) 09:27:25.30

>>328
>PDFはPostScriptがベースなんだけど、これは元々プリンタ出力のために設計されたもの
>後は紙に印刷するだけって状態のデータだから文字コードなんて概念はない

これはひどい

**デフォルトの名無しさん** · 2025/07/27(日) 09:52:00.68

>>339
酷くはない
その当時はそれでも素晴らしかったから普及した
そして実際、unicode以前は完全に機能していたわけだし

どちらかというとunicodeが既存技術に対してかなり異端で、
当然アプリは別対応が求められるが、それが適切に為されていない場合、誤動作してるだけ
Adobe謹製環境では動作してるのなら、Adobe側がこれ以上できることはない

**デフォルトの名無しさん** · 2025/07/27(日) 10:08:59.26

>>336
単純な例で
カ
と
力
だな
こんなの一緒にされたら困る

**デフォルトの名無しさん** · 2025/07/27(日) 10:52:09.39

>>341
ソース違いで自体が同じ例か？
カと力は、何か変だと気づく程度には字形も微妙に違い、怪しい中華の説明書で間違って使われる程度だろ
問題になるのは全角チルダと波ダッシュとか、あと伸ばし棒も何種類かあって、
これらは日本人でも割とデタラメに使っているので、検索に引っかからなくなって困る

だから、unicodeのCJK統合漢字＝見た目が同じなら同じ文字、は、
検索の結果がユーザーにも予期出来る、という意味では正しい思想で、
逆に、同じ字体にも違うコードを割り付け、『ユーザーが正しくそれらを使い分けられない場合』、どうにもならなくなる

この辺の思想が、unicodeは徹底出来ていない

**デフォルトの名無しさん** · 2025/07/27(日) 15:00:47.82

>>340
そうじゃない
PostScriptと当時のフォントの詳細をほとんど知らないだろ?
だから妄想で適当なことを書く、酷いのはお前だ
ってこのぐらい書けばわかるんかな

**デフォルトの名無しさん** · 2025/07/27(日) 15:43:44.47

>>343
PostScript以前はプリンタによって出力結果が異なっていた為、
ファイルを渡しても印刷結果が異なる事が普通だった
(だから厳密にやるには紙でやりとりするしかなかった)
これに対し、PostScriptだとどのプリンタでも見た目の出力結果が同じ為、
あっという間にデファクトスタンダードをとった

PostScriptはベジエなフォントをプリンタでラスタライズする
だからフォントを埋め込めば、同じ見た目の出力になる
以前のプリンタは、プリンタ内蔵のビットマップフォントを印刷してたか、
PCから送られてくるラスタデータを印刷してたかなので、環境によって印刷結果が異なっていた
(なおその後PostScriptが若干落ち目なのは、特許料金が高いのと、
プリンタ上で処理する仕組み上、プリンタ側にそこそこのCPUが必要となり、プリンタ代が高くなるから)

PDFはPostScriptをバイナリ化したものなので、基本思想はPostScriptから引き継いでいる
当時は(今もだが)WordもExcelも有料であり、その他のソフトも、全員が確実に持っている物はなかった
AdobeはPDFの生成は有料だが、開くだけなら無料(AcrobatReaderは無料)という方針で、
あらゆる人に対して確実に読める環境を提示した為、PDFもあっという間に普及した
MSがWord/Excelのリーダーを無料で提供したのはその後

俺が知ってる概略はこんな所だ
PostScriptも、PDFも、当時としては素晴らしかったし、完全に機能してたよ
(今でも十分素晴らしいとも思うが)

ぼくはおまえよりしってるんだ！！！とか要らんから、最初から知ってる事書けばいいと思うけどね
はいどうぞ

**デフォルトの名無しさん** · 2025/07/27(日) 16:00:29.88

>PDFはPostScriptをバイナリ化したもの
doubt

**デフォルトの名無しさん** · 2025/07/27(日) 16:39:24.93

PSはプログラム言語でPDFは描画データ
門外漢のオレの理解はここまで

**デフォルトの名無しさん** · 2025/07/27(日) 16:40:00.92

>>345
ああ確かに、asciiと言った方が近いようだな
ただそんな関係ない所ではなく、本筋の、

> PostScriptと当時のフォントの詳細
に(自称)詳しい人から見て
> 酷い
と考える根拠を述べよ、だな

俺は、PostScriptもPDFも素晴らしかったから普及した、だから全く酷くない、と考える根拠を344で述べた
実際これで現在も機能してるんだから、文字コードの概念はPostScriptとPDFには不要だったという証明になってるし
unicodeが色々おかしくしただけだよ

**デフォルトの名無しさん** · 2025/07/28(月) 09:30:10.58

https://www.adobe.com/jp/creativecloud/file-types/image/vector/ps-file.html

PostScriptとPDFの違いは何ですか？

PDFは、PSファイルの後継形式で、webと印刷の両方で最も広くサポートされているもののひとつです。ただし、PDFは表示形式であり、簡単には編集できませんが、PostScriptはプリンター制御言語であり、そのコード内でデザイン要件を伝達する機能があるため、印刷の可能性が広がります。

**デフォルトの名無しさん** · 2025/07/28(月) 11:28:12.87

postscript は紙に印刷する専用なので検索とかコピー・ペーストとかは不要だが
PDF はディスプレイ表示を前提でそれらの機能がある。初期の PDF の仕様決める時に検索やコピペの国際化についての考慮が足りてなかった

unicode が存在しなくても国際化が必要になったら同じ問題が起きて、PDF仕様の拡張が必要になってた
問題は単にPDFの仕様が膨らみ過ぎて全部実装するのが困難になってて、サブセットでしか実装していない不十分なアプリが氾濫し過ぎてるってだけ
直接的には文字コードの問題ではない

**デフォルトの名無しさん** · 2025/07/28(月) 13:24:28.88

ワニ□クリップも同じか

**デフォルトの名無しさん** · 2025/07/29(火) 12:35:56.91

ちゃんと知らん奴に限って総括するような話をしたがるが、悲しいかな理解が
浅いので全然正しく総括できてないあるある
これは例の何ちゃら効果の一種かもしれんね

**デフォルトの名無しさん** · 2025/07/29(火) 13:59:09.33

詳しく知らないと総括しかできない

**デフォルトの名無しさん** · 2025/07/29(火) 14:07:42.49

WebでもHTMLのimgで例えばブランドロゴを画像表示したときに
alt属性がなければテキストとして得られないがalt属性があればテキストとしても得られる
そういう対応をきちんとするか否かでテキスト文字としてもコピペできるかどうか道が分かれる

**デフォルトの名無しさん** · 2025/07/29(火) 14:44:03.99

>>353
alt に対応してないメイン・ブラウザとかはほぼ存在しないんだが…
PDF はなぁ…

**デフォルトの名無しさん** · 2025/07/29(火) 19:25:27.31

HTMLは画像表示できずにテキスト表示のみの環境でも読めるように
そして目の不自由な人たちもテキストの音声読み上げで読めるように
HTMLコンテンツを作る側もブラウザ側両方が対応してきた
いわゆるアクセスビリティ対応が必須で常識
PDFはその常識を欠いた者が対応を欠いたソフトを用いるとテキスト読み出し出来なくなる

**デフォルトの名無しさん** · 2025/07/29(火) 22:35:36.96

altなんて実際のところ機能してないだろ
隠しメッセージに使うとかおもちゃになってる

**デフォルトの名無しさん** · 2025/07/31(木) 07:07:13.35

>>343
結局、何も言えないのか？
だからゆとりZは死ねなんだな

俺は5chにいるゆとりZは全員殺処分が妥当だと考えてる
理由は長いが以下に書き散らしたので興味あれば読んでみてくれ
https://mevius.5ch.net/test/read.cgi/tech/1739527246/529-

お前らはお互いに足を引っ張り合ってるので成長出来てない
今回も、無駄に喧嘩を売ってきて、正面から受けてもだんまりとか、
だから議論もろくに出来ず、幼稚なままだ
そもそも俺はPostScriptやフォントの事に一言も触れてないのに、どうして
> PostScriptと当時のフォントの詳細をほとんど知らないだろ?
> だから妄想で適当なことを書く、酷いのはお前だ
になったのかさっぱり分からない

ゆとりZは妄想で適当なことを書く、酷い連中だから
存在するだけで邪魔だし、議論も紛糾するだけなので、殺処分が妥当
お前も死ね
ってこのぐらい書けばわかるんかな

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

>>349
> 問題は単にPDFの仕様が膨らみ過ぎて全部実装するのが困難になってて、サブセットでしか実装していない不十分なアプリが氾濫し過ぎてるってだけ
> 直接的には文字コードの問題ではない
その通りだが、お前も感づいているとおり、間接的にはunicodeの問題だ
実際、フォントと文字コードが1:1対応してたSJIS等だと問題にならなかったのも事実だろ

つまりunicodeが
> 異端 (>>340:俺)
で、
> 確実にどこかで破綻する気はする(か、そもそも実装してもらえないか) (>>336:俺)
に現時点でなってるのも事実ではないか
PDFに関してはパチもん使わずAdobe純正品使え、だろうが、
unicodeも十分複雑すぎる仕様だから、同様の状況(＝フル実装されてないのが氾濫)になってる気はするが
(だから足抜けは許さねえ！！！なコードヤクザになるのも納得)

そもそもサロゲートペアも初段階で必須だと判断出来たはず
(だからutf-16はナンセンスだとも)
> https://skawa68.com/2024/07/31/post-81230/
大漢和辞典で5万+、康熙字典で4.7万だから、ギリ行けると判断したのかもしれんが、
常識的には、いや無理でしょ、余裕無さすぎ、だし
(よく知らんがハングルも1.2万程あるようだし、参考: https://tagengo-gakushuu.study-tips.info/app/web-form/korean/unicode_all_with_ancient_hangul/doc/all_hangul_chars_unicode.pdf)

あとふと思ったが、IVS/IVD方式はもしかしてutf-32でも8バイトか？
なら中国が独立コードに拘る理由もありえる、というか、
これだと事実上utf-32も捨てる事になる
まあほぼutf-8なので今更どうでもいいのも事実だが

**デフォルトの名無しさん** · 2025/07/31(木) 07:55:06.21

思うにunicodeは、文字化けのない世界を提示したのは素晴らしいにしても、
一つでやろうとするが故、仕様が包括的になるのは避けられず、破綻に向かっている気はする
全ての言語を話せる人が居ない以上、
IVS/IVDなんて欧米連中からすれば意味不明で、逆に欧米側の仕様は俺らには意味不明になる
だから実装側は誰も仕様の妥当性を判断出来ず、ただひたすらに仕様に従うしかない
これ自体は自治体向けや会計ソフト等、一般プログラマの領域外の分野では普通の事で、
だから橋渡しとして両方が分かる人を入れ、仕様でガチガチに固定するわけだが、
実際破綻しまくっているのも、元々無理があるからだ

つまり、例のブランコ、
「顧客が本当に必要だったもの」を解決出来る人が、本質的に存在しない
(会計等の分野なら、会計知ってる奴にプログラミングを教える、等の解があるが、
全ての言語を話せる人が存在しない以上、unicodeにはこの解が存在しない)

まあIT版バベルの塔であり、どこまで行けるかという話だが
実際、自分には関係ない機能なんて、実装するモチベわかないものだし
(大体において実際困ってるから動くのがほぼ全員で、困ってなければ誰も動かない
この意味では、unicodeがフル実装される未来なんて多分存在しない)

**デフォルトの名無しさん** · 2025/07/31(木) 10:38:37.81

>>359
気付いてないようだが unicode 以前の SJIS とかの時代から PDF では使うフォントによっては同じ問題が起きてた
変なフォント使うやつ少ないし、同じ国の中の文字の揺れなので気づくやつが少なかったのが、国際化の影響で別の国の文字だの部首素片だのに変換されて目立つようになっただけ
PDF は文字コード表にない文字（フォント）まで扱えることを知ってればコピペ等で化ける（別の字への置き換え）は当然の仕様と知れる

**デフォルトの名無しさん** · 2025/07/31(木) 12:22:57.59

>>360
Windowsの標準のフォントしか使ってないので、遭遇した事もないし、聞いた事もないが
(ただ、当時はそうなっても「文字化け」としてスルーされてたとも思うが
unicodeしか使った事無いゆとり以降は、文字化け＝バグ、とか言い出すから別の問題はあるにしても、
文字化けについて厳しくなってるから話題として出てきてるだけかもしれん)

しかし結局、文字コード->グリフで多対一写像があり、戻す時にどちらに戻すべきか分からなくなるのが問題なら、
(SJISな当時に)多対一写像がありまくるのはただの糞フォントだとも思うが
平仮名/片仮名は漢字の簡易形であり、当然似たような字形はあるので、
ほぼ全部のフォントでそれらを何となく区別出来るように大きさを変えてあるのが常だし

で、unicodeは多対一写像が仕様だから、
1:1写像な以前の世界向けに作られた物が当然誤動作してるだけだろ
(さっさと対応しろよ、なのは勿論だが)

して、「酷い」と考える奴は結局、後知恵でもいいからどうすべきだったと考えるのだ？
文字コードを埋め込む方式は、見た目同じだが検索に引っかからない、いわゆる正規化の問題が発生してしまう
同じグリフ->同じ文字コードなら、この問題は存在しない
だから「検索」と「コピペ」のどちら向けの仕様にするか、であり、PDFが
> 検索ができないのは不便だからってんで (>>328)
なら、そりゃ検索向けの仕様にするよ
(現在のPDFが検索時に正規化して対応してるとしても、
同じグリフに複数の文字コードを与えている糞フォントな場合、
画面なぞって検索したときに、見た目同じなのに引っかからないケースが発生する
同じグリフなら同じコードだ！の旧方式なら、これはない)

**デフォルトの名無しさん** · 2025/07/31(木) 12:57:26.17

長文は読み手の負担になるし
希薄化して本当に書きたいことも伝わらなくなるよ

**デフォルトの名無しさん** · 2025/07/31(木) 13:09:41.59

>>361
フォントが1種類しか使われてないと思い込んでるのがお前の妄想の原因なんだよ
アラビア語のフォントが一部に使われてるPDFをSJISのテキストにコピペしたらどうなるか想像つくだろ

**デフォルトの名無しさん** · 2025/07/31(木) 14:31:26.32

∃〆ﾚば良いんょ

**デフォルトの名無しさん** · 2025/07/31(木) 14:51:39.49

>>363
それはSJISの範囲を超えているから当然誤動作する
(俺は知らんがwiki等読む限り)仕様としてはエスケープシーケンスで各国語を切り替えられたらしいが、
そんな事が必要な奴は90年代でも既にunicodeを使ってたので、
SJISに貼り付けて誤動作ガーとか言ってるお前が狂ってる

資本主義＝商用ベースでやる以上、訳の分からないマイナーな使い方は無視されて当然
(良い悪いではなく、そうなる構造)

**デフォルトの名無しさん** · 2025/07/31(木) 15:58:32.58

>>365
基本的な部分が分かってないな
・全ての文字（フォント）が SJIS と1対1でマップされている保証はない
というのが
・全ての文字（フォント）が Unicode と1対1でマップされている保証はない
というのに変わっただけで unicode など文字コードの問題だと思ってるのがお前の勘違い、文字コードで解決する問題ではない

**デフォルトの名無しさん** · 2025/07/31(木) 17:19:12.01

対象文書に閉じた形式（情報量が削減されたグリフオリエンテッドな形式）で表現されている以上、どうしようもない

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

>>366
> ・全ての文字（フォント）が SJIS と1対1でマップされている保証はない
それはそうだが、実際はされてるから問題にならなかったんだろ
SJISで正規化問題なんて聞いた事無いし
unicodeでは色々な所で多対一がモロ仕様だから顕在化しただけ

とはいえこれ以上は平行線だろうし終わりでいい
合意とる必要もないし

俺は、

・見た目全く同じなのに検索に引っかからない事があるunicode仕様
・コピペ時に見た目は全く同じな別のコードに変わる事があるPDF仕様

なら、PDFには後者の方が断然いいと考える
PDFに対して検索はよくやるが、コピペはあまりしないし
(ただ、ファイル容量なんてどうでもいい昨今なら、両方入れとけだろうし、
それが316リンク先内の/ActualTextだろうから、
俺らがやるべきは、「/ActualTextを出力しないPDF作成アプリはゴミ」と吹聴する事だろうよ)

**デフォルトの名無しさん** · 2025/07/31(木) 22:46:51.26

>>368
昔から発生してた、特に字体の多いプロフォント使った印刷用のPDFとか外国語関係とかだと当たり前に起きてた、お前の経験が浅いだけ
単にSJISとかしょっちゅう文字化けするんで、文字化けしても特段話題にならなかっただけ、検索とかコピペ失敗しても単に機種依存文字wって言ってすましてた
unicode が普及したことで環境依存って思わなくなったのと外国の文字が含まれてるフォントを常用するようになって話題になった

**デフォルトの名無しさん** · 2025/07/31(木) 22:58:34.81

>>369
> 検索とかコピペ失敗しても
それはお前の理解が間違ってて、PDF内では検索失敗しないのがPDFの仕様だ
まあお前みたいなタイプは沢山居るけども

**デフォルトの名無しさん** · 2025/07/31(木) 23:10:14.79

>>369
もしかして検索はPDFではなくSJISにかかってた？
だとしたら、俺はSJISで「見た目同じだが引っかからない」検索失敗は、一度も経験した事がない
経験不足なのか、SJISにはなくunicodeで発生した問題なのかについては、俺は後者だと考えてる

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

アホ過ぎる「検索失敗しないのがPDFの仕様だ」とか小学生レベル
失敗するのは人間。
見えてる文字で検索したつもりでも内部的には別の文字になってるので検索に引掛からなかったり、その逆で見た目が全然違う文字が検索でひっかかたりする。原因はコピペの失敗と同じ。

**デフォルトの名無しさん** · 2025/08/01(金) 07:02:06.81

>>372
グリフが完全に同じ時は同じ文字扱いなのがPDFで、
グリフが完全に同じでも違う文字の時があるのがunicodeだぞ

とはいえ、お前には理解出来ないことは理解したので終わりでいいが

**デフォルトの名無しさん** · 2025/08/01(金) 07:18:07.89

だれかTeXで例えて

**デフォルトの名無しさん** · 2025/08/01(金) 08:03:21.63

>>373
SJIS の話してんのに unicode 関係ないだろ
お前は PDF のこと全く分かっってないだろ
PDF はお前が思ってるほど単純なしくみじゃないぞ

CMap って聞いたことあるか？そのあたりから内部構造勉強してみ
/ActualText どころか ToUnicode CMap すらない PDF だって普通にあるんだよ（unicode 以前のフォントが unicode 対応してる訳ないだろ
PDFの内部の文字の記録は unicode ではなくてグリフID というフォント内の格納番号なんだよ、一部の日中韓フォント使った場合は CID というまた別のコードで記載されてることもある

**デフォルトの名無しさん** · 2025/08/01(金) 08:41:40.71

>>375
その辺は316のリンク先読んだ程度しか知らないが、
それでも普通にプログラミング経験があれば理解出来る物なんだよ

グリフID->文字コードの変換表は、普通に実装すれば「その文書で最初にそのグリフを使った文字コード」が格納される
だから、「違う文字コードだが同じグリフ」が無い場合、この程度の仕様/実装でも検索もコピペも問題ない
実際、SJISでWindowsデフォのフォントを使ってる限り、問題なかった

ところがunicodeでは、「違う文字コードだが同じグリフ」が普通にあるので、
コピペでは「同じグリフの違う文字コード」に変更(縮退)されてしまう事が多発する
なお、PDF内では「同じグリフは同じ文字コード」に縮退されているので、検索では100%ヒットする

というか、ループしてるしこの辺でいいか？
ここでは知識(知れば済む事)を与える事は出来ても、
理解(考えて納得する事)を与える事は出来ない
いろんな言い方をする事は出来るけども、既にそうしてきてるし、
これで理解出来ないのはお前の知能の問題で、ここで一朝一夕に修正するのは無理だ
お前は知識＝頭がいいと考える文系馬鹿に近い存在のようだが、それは間違いだ
知識はちゃんと理解してナンボであってね
プログラミングが多少でも出来る奴なら、上記の俺の説明で、ああ、はいはい程度には理解出来ると思うし

**デフォルトの名無しさん** · 2025/08/01(金) 09:32:26.46

お前は一回 PDF 検索を実装してみろ、失敗しない検索が実装できるか分かるぞ
検索文字列がフォント名とグリフIDのセットで降ってくるとでも思ってるのか？

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

>>377
> 検索文字列がフォント名とグリフIDのセットで降ってくるとでも思ってるのか？
お前のプログラミング能力はゼロで、文字列検索では具体的に何をしてるのか全く知らない事は分かった
ただこれはプログラマには常識過ぎるので、316のリンク先やこのスレ内でも、誰もわざわざ言及していない
だからお前は付いてこれないままだ
だが、それ以前に、お前は文字列とは何なのかも知らなそうだが
そもそも>>317もまるで理解できてないだろ

理解したければ、プログラミングのイロハから勉強するんだね
多分お前はPDFのヘビーユーザー、おそらくはイラレ使い、てなところか
お前が文字コードの問題まで理解できることは、短期的にはない。ベースの知識が足り無すぎる
そもそも何故お前がこの板にいるのかがかなり謎だが
PDFに不満があるのなら、「出力はAdobe純正ソフトで、マッピング情報等は全部含めて、ファイルは大きくなってもいいから」と依頼すれば、
お前の不満に対しての最適解にはなってるだろうさ

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

>>378
俺は実際にPDFの検索組んだことあるんだが、お前のその妄想はどっから来たのか知りたい

**デフォルトの名無しさん** · 2025/08/02(土) 07:47:18.20

>>379
文盲か？最初の行にわざわざモロクソ書いただろ
> 検索文字列がフォント名とグリフIDのセットで降ってくるとでも思ってるのか？ (>>377)
ここからだよ
普通はたった2行のレスをわざわざ引用するのは冗長すぎるので文句言われるが、
それでもお前にはどちらの行か分かるようにしたほうが良さそうなので敢えて引用した
5chのコミュ障共はこの辺の配慮なんて汲めないから、
ひたすら「俺にとっては冗長だ」という基準で長い長い言うわけだが、
それでも馬鹿なお前に合わせて書いてるんだから、ちゃんと読め

というか、逆に言うと、そんな事を言うお前は、
> 検索文字列がフォント名とグリフIDのセットで降ってくる
場合に、検索出来るようになると思ってるわけだろ
そりゃお前の組んだプログラムなんて動作しないさ

初心者あるあるだが、
・間違った問題を、間違った方法で解決しようとして、余計におかしくなる
ケースに該当する
ただ正直、このレベルから相手にする気にはならんし、勝手によろしくやってくれだが

**デフォルトの名無しさん** · 2025/08/02(土) 07:48:17.42

結局の所、>>317はよく書けていて、その通りだが、別の言い方をすると、

PDFの仕様は各文字が別々の字形(＝複数の文字コードが同じグリフを使うことがない)
の時に機能するように出来ていた
SJIS時代はだいたいこれが成立してたので、目立った問題はなかった
unicodeだとまるで動かなくなったので、新仕様を整備したが、対応してないPDFアプリは誤動作しまくり

で、これが上位の状況説明で、下位の詳細理由説明が317になってる
上位の説明はお前のような文系馬鹿でも分かるはずだが、下位の説明では、
・元々どのように動作していて、←これ(前提部分)が省略されてる
・〇〇すべき所
・△△になってるから、上手く動かない
の、後半部分しか通常は与えられない。全員が知ってる前提部分なんて無駄でしかないから
だから、前提部分の知識が全く無いお前には理解できない。これがお前が317以降空回りしてる理由

趣旨は異なるけど、例のバッテリー女も、同様の前提条件
・車のエンジンをかける際にバッテリーが必要なこと(＝セルモーターを回してエンジンをかけること)
を知らないからそうなるのであって、バッテリー女がクソ女なのは事実としても、
「バッテリーが上がってるとエンジンもかからないんだ。バッテリーなら15分ほどで修理できるから、試してみてくんない？」
と一言言えば回避できるんだが、これをやりたいか、ここまでやる必要があると考えるかは、人それぞれだね
ただ、会話する気があるのなら、相手が馬鹿と分かったのなら、馬鹿にも通じるように言うべきではある
そして俺は一応それをやってるつもりなのだから、ちゃんと読んでくれ

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

糞長文書いてる暇があったらプログラム書けよ
そうすればすぐに unicode 関係ない
絶対に失敗しない検索も作れないってわかるぞ
そもそも暗号化されてもいないのに一切検索できないPDFをはくツールすらあるぞ

**デフォルトの名無しさん** · 2025/08/02(土) 09:03:03.63

>>382
それも初心者あるあるだな
賢いお前にはこれで十分通じるはず(ｷﾘｯ

**デフォルトの名無しさん** · 2025/08/02(土) 10:53:41.96

日本語フォントとかだとグリフID の順がSJISやUnicodeと全く一致してないということを知らずに吹いてるんだろうな（SJIS時代は並び順が一致してたとでも妄想してるのかな？

検索文字列がSJISとかUnicodeで与えられた時にそれをどうやってグリフIDとマッチングされるか具体的な方法も知らないんだろうな

グリフIDと文字コードの対応がPDFに内蔵されてない場合に検索どうするか検討もつかないんだろうな

中には文字をグリフIDですらなくてアウトラインの図形データとして格納してるPDFだってあるということも知らないんだろうな

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

>>384
> 順が
なるほどやはりお前は分かってない

> 検索文字列がSJISとかUnicodeで与えられた時
実はこれには問題がある。だから注つけるかとも考えたが、
> 画面なぞって (>>361)
と既に言及してるし、どのみちunicodeだと手打ちでは無理で、画面なぞるしかない(後述)ので、まあいいかで省略した
賢いお前らなら当然気づくから、いちいち無駄ツッコミはないはずだし

> グリフIDと文字コードの対応がPDFに内蔵されてない場合
それは初(ry

> 中には文字を
それも初(ry

本質的には、unicodeの問題がPDFに輸出されてしまってるんだよ
仮にPDFがhtmlのようにunicode文字コードで構成されてても、正規化の問題は発生するし、
316の例みたいに同じグリフを複数のコードが使用してる場合、「手打ちでの」検索はヒットしないことがあり得る
PDFの仕様だと、「画面なぞれば」100%ヒットするだけまだましで、unicodeはこれすら保証できない

**デフォルトの名無しさん** · 2025/08/02(土) 11:47:17.46

>>385
結局何も分かってなかったのね？

既存のPDFビュワーの画面をなぞるのはコピペの機能だぞ
一旦グリフIDから文字コードに変換される、そして検索窓等に文字コードとして入力される、コピペが化けるのと同じ問題が起きる

それともお前がSJIS時代にグリフIDのままで検索できるビュワー書いたのか？本当に過去に存在してたのなら見せてくれ、ごめんなさいして今から書いても良いぞ

作るのなら
フォントごとにグリフIDが異なるんだが、まずは複数のフォントが使われてる時にあるフォントの「あ」の文字を選択したときに、別のフォントの「あ」の文字のグリフIDにどうやったら変換できるか考えてみろ
コードポイントによってはグリフがなくて表示されないやつすらある（単純な例ならスペースとか改行、もっと複雑なのが一杯ある）、
合字とかで複数の文字からなる文字列に1つだけのグリフIDが割り当てられていることもある（レパートリはフォントごとに違う）、
そういう時はどうする考えてみろ、PDFについて無知過ぎ

**デフォルトの名無しさん** · 2025/08/02(土) 12:26:25.37

>>386
相変わらず分かってねえな

> コピペが化けるのと同じ問題が起きる
だからいいんだぞ
両方ともPDF内から生成された物だからこそ、確実に一致する

> PDFについて無知過ぎ
PDF博士なお前はマウントポイントなこの点にこだわるようだが、
既に言った通り、本質的にはPDFではなくunicodeの問題だ
実際、unicodeなhtmlでも「見た目同じだけど検索に引っかからない」ケースが普通にあるだろ
コピペに関しては、文字コードを保存してないのが問題で、既に仕様は追加済み、さっさと対応しろだが、
検索に関しては、元々unicodeは検索がまともに出来ない仕様で、それがPDFにも輸出されただけ

例えば、316で3つの「長」が同じグリフIDに紐づけされるのは、
当然その文書のそのフォントでは3つの「長」が同じグリフを使うからであり、見た目が同じだから
同じ文書をhtmlで表示させたら、当然画面上の見た目は同じ「長」になるが、
文字コードが3つのどれかは見た目では分からない
だから「手打ちで」「長」と打ち込んでも、当たらない時がある
これ、PDF全く関係ないだろ

**デフォルトの名無しさん** · 2025/08/02(土) 15:48:00.24

馬鹿はコード書けって言われると発狂するから分かりやすいね

**デフォルトの名無しさん** · 2025/08/02(土) 18:36:31.34

きっとここがプログラム技術板だってことにすら気付いていないんだろうな
プログラム書けば良いのに

**デフォルトの名無しさん** · 2025/08/02(土) 19:21:29.66

ID:xIFE1Go+がニワカ知識だったでOK？

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

さてと

PDFの中を覗いてみたけど、/ActualTextという要素がある（場合がある）のね
Acrobatなどは検索やコピペのときにこれを参照するのかな?

**デフォルトの名無しさん** · 2025/08/04(月) 06:44:34.21

画像に/actualtextや/altが付いているのでたしかめて見ては？
{}内のテキストが入っている

Actual Text
{T}
his is an example of actual text.

Alt Text
{Je t'aime (French for "I love you")}
This image has alt text: Je t'aime (French for "I love you")

https://taggedpdf.com/wp-content/uploads/2015/12/Actual-Alt-Expansion-Text.pdf

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

Actual Text や Alt Text もそうなんだけど最近の PDF には大きな枠組みで「タグ付き PDF」という機能があって文章の構造化ができる

要はHTMLの段落タグや見出しタグと同じやつで読む順番やその文章内での意味付けや読み方や代替の指定が可能、補足を入れる Expansion Text みたいなのも

これによって改行を超えた検索とかリフローっぽいこととか、画像化された文字のテキスト化の指定とかとか色々HTMLっぽく使える

（文字コードとは独立した問題）

**デフォルトの名無しさん** · 2025/08/04(月) 10:06:23.30

>>392
なるほどー。ただこれはどちらかというと /Span の使い方のデモ（濫用）って感じも
しかしこれでAcrobatのことが少しわかった感も、どうもです

>>393
> ... 文章の構造化ができる
>（文字コードとは独立した問題）
異なるコードポイントの文字を構造化することもできますね

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

一部訂正
× コピペに関しては、文字コードを保存してないのが問題で、(>>387)
○ unicodeのコピペに関しては、糞フォントと文字コードを保存してない組み合わせの時の問題で、

PDFの昔の仕様でも、文字コード->グリフが1:1の場合にはコピペ/検索共に全く問題なく機能する
316で「なんか低い…」になるのは、それらの文字コードには別のグリフが与えられているからであり、
PDF閲覧者の環境でその文書のPDFを作成した場合、(3つとも別のグリフなら)全く問題ないPDFが作成される

だから発生条件として、

・糞フォントで、違う文字コードで同じグリフを使いまくり

が必要であり、これを誘発しているのはunicodeの仕様
だからPDFがボロいと言うより、
unicodeが本質的にボロくて、以前の1:1な世界と親和性が皆無な事が問題なのだと思うよ
(なお316の件は、コードに戻す際、その文書で一度も使ってもない「長」に決め打ちで変換されていると思われ、
PDF出力アプリがポンコツなのもほぼ間違いない
376の通り、「その文書で最初にそのグリフを使った文字コード」を格納する実装なら、
単国籍な文書《≒大半のケース》で顕在化するのは防げる)

結論としては、やっぱunicode糞じゃね？と思うが

以前の文字コード：このコードはこう表示される程度の知識で全く問題ない
unicode：正しい作法(正規化等)を知らないと色々誤動作する

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

>>395
お前、まだあきらめて無かったのか
昔から1対1なんてことはないよ
グリフIDはフォントごとに異なる、1つのPDFで複数のフォントを使ったら異なるグリフIDになる、逆に同じグリフIDでも異なる文字を表現している
何度も言われただろ、理解できない部分を読み飛ばしてるのか？

**デフォルトの名無しさん** · 2025/08/04(月) 13:40:26.46

>>396
いや、やはりお前は理解出来てない
もういいけど
(お前が理解出来ない事は理解しているし、お前の頭の悪さについては諦めている)

> グリフIDはフォントごとに異なる、1つのPDFで複数のフォントを使ったら異なるグリフIDになる
ここまでは全く問題ないが、
> 逆に同じグリフIDでも異なる文字を表現している
これが問題

「単射」と言った方が正しかったが、
俺は使ってきてなかったのと、後で使ってた「1:1」表現に揃えたのが不適切だったようだ
ただ、事実は変わらない
当たり前だがゴシックの「あ」と明朝の「あ」は別グリフIDになるが、
この場合にも検索/コピペは昔のPDFの仕様で全く問題なく動作する

まあunicodeは色々糞だというのが俺の見解
387の表現だとPDFに主たる問題があるとも読めるので訂正した
(unicode以前は問題なく機能していたので)

**デフォルトの名無しさん** · 2025/08/04(月) 14:31:23.34

>>397
明朝体の「あ」のグリフIDが 325 でゴシック体の「ほ」のグリフIDが同じ 325 ということだってあり得るんだよ
明朝体の「あ」とゴシック体の「あ」は検索したいけど、ゴシック体の「ほ」は検索にひっかかると困る。常識だろ

**デフォルトの名無しさん** · 2025/08/04(月) 14:37:31.31

>>395
>・糞フォントで、違う文字コードで同じグリフを使いまくり
自分の妄想をベースにAdobeに因縁を付けるのか
最近こういう人が増えている感じで怖い

>以前の文字コード：このコードはこう表示される程度の知識で全く問題ない
ある

前提の認識が間違っているのでそれをベースにした話も間違い
ただの間違いの積み重ね

**デフォルトの名無しさん** · 2025/08/04(月) 15:13:22.04

>>398
それは初(ry

あとちなみに、「1:1」の表現は317から使われてるだろ
お前以外の誰も「1:1」表現を気にしてないのは、お前だけが特殊(＝非プログラマ)だから
まあ方言っちゃ方言だが、この場合の意味は可逆/非可逆であって、写像形式自体を示しているわけではない

>>399
> 自分の妄想をベースにAdobeに因縁を付けるのか
俺はAdobeは順当で、unicodeがウンコだとずっと言ってる
とはいえ文盲と5chで話をするのは無理なのでもういいが

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

>>392-394
Adobe Acrobatで検索もコピペも出来ない/ActualTextの例

**デフォルトの名無しさん** · 2025/08/04(月) 17:34:36.02

>>400
だから 317が1対1じゃないって言ってるだろ
フォントと文字コードが1対1じゃないのは Unicode どころかPDFよりもっと前の PostScript のフォントで使われ始めた技術
それが現在までそのまま引き継がれてる
Unicode で始まった話ではない

**デフォルトの名無しさん** · 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コピペ文字化けの元凶だな
日本人の美的感覚では、(この辺は習字を見れば分かりやすい)
「長」の縦棒は、上よりも下のほうが少し左側(下のほうが広く見える)が美しいとされるので、
真面目にフォントを作れば同じグリフになることはない