文字コード総合スレ part15 (399ﾚｽ)
上下前次1-新
1: デフォルトの名無しさん [] 2024/08/17(土) 11:18:00.01 ID:VHa7+i59(1/2) AAS
文字コードについて語り合うスレです
375(1): デフォルトの名無しさん [sage] 2025/08/01(金) 08:03:21.63 ID:S37h8L9Z(2/4) AAS
>>373373(1): デフォルトの名無しさん [sage] 2025/08/01(金) 07:02:06.81 ID:7kydH/9J(1) AAS
>>372
グリフが完全に同じ時は同じ文字扱いなのがPDFで、
グリフが完全に同じでも違う文字の時があるのがunicodeだぞ
とはいえ、お前には理解出来ないことは理解したので終わりでいいが
SJIS の話してんのに unicode 関係ないだろ
お前は PDF のこと全く分かっってないだろ
PDF はお前が思ってるほど単純なしくみじゃないぞ
CMap って聞いたことあるか？ そのあたりから内部構造勉強してみ
/ActualText どころか ToUnicode CMap すらない PDF だって普通にあるんだよ（unicode 以前のフォントが unicode 対応してる訳ないだろ
PDFの内部の文字の記録は unicode ではなくてグリフID というフォント内の格納番号なんだよ、一部の日中韓フォント使った場合は CID というまた別のコードで記載されてることもある
376: デフォルトの名無しさん [sage] 2025/08/01(金) 08:41:40.71 ID:wR/jTASQ(1/2) AAS
>>375
その辺は316のリンク先読んだ程度しか知らないが、
それでも普通にプログラミング経験があれば理解出来る物なんだよ
グリフID->文字コードの変換表は、普通に実装すれば「その文書で最初にそのグリフを使った文字コード」が格納される
だから、「違う文字コードだが同じグリフ」が無い場合、この程度の仕様/実装でも検索もコピペも問題ない
実際、SJISでWindowsデフォのフォントを使ってる限り、問題なかった
ところがunicodeでは、「違う文字コードだが同じグリフ」が普通にあるので、
コピペでは「同じグリフの違う文字コード」に変更(縮退)されてしまう事が多発する
なお、PDF内では「同じグリフは同じ文字コード」に縮退されているので、検索では100%ヒットする
というか、ループしてるしこの辺でいいか？
ここでは知識(知れば済む事)を与える事は出来ても、
理解(考えて納得する事)を与える事は出来ない
いろんな言い方をする事は出来るけども、既にそうしてきてるし、
これで理解出来ないのはお前の知能の問題で、ここで一朝一夕に修正するのは無理だ
お前は知識＝頭がいいと考える文系馬鹿に近い存在のようだが、それは間違いだ
知識はちゃんと理解してナンボであってね
プログラミングが多少でも出来る奴なら、上記の俺の説明で、ああ、はいはい程度には理解出来ると思うし
377(2): デフォルトの名無しさん [sage] 2025/08/01(金) 09:32:26.46 ID:S37h8L9Z(3/4) AAS
お前は一回 PDF 検索を実装してみろ、失敗しない検索が実装できるか分かるぞ
検索文字列がフォント名とグリフIDのセットで降ってくるとでも思ってるのか？
378(1): デフォルトの名無しさん [sage] 2025/08/01(金) 22:01:15.19 ID:wR/jTASQ(2/2) AAS
>>377
> 検索文字列がフォント名とグリフIDのセットで降ってくるとでも思ってるのか？
お前のプログラミング能力はゼロで、文字列検索では具体的に何をしてるのか全く知らない事は分かった
ただこれはプログラマには常識過ぎるので、316のリンク先やこのスレ内でも、誰もわざわざ言及していない
だからお前は付いてこれないままだ
だが、それ以前に、お前は文字列とは何なのかも知らなそうだが
そもそも>>317317(3): デフォルトの名無しさん [sage] 2025/07/20(日) 22:29:37.55 ID:0FYiUEbf(1) AAS
>>316
文字コードの問題ではなく単なるバグ
より正確にいうと大昔からある PDF のフォントの使い方の問題
PDF はウェブと違って文字コードをデフォルトでは埋め込んでなくてフォント内の番号で直接埋め込んでる
フィント番号と文字コードが1対1でマップしている保証はないのに、コピペの時はフォントに埋め込みの変換表で番号から文字コード生成する仕組になってる
複数の文字コードに同じフォントを割り当てているフォントを使うとこの問題が起きる
もまるで理解できてないだろ
理解したければ、プログラミングのイロハから勉強するんだね
多分お前はPDFのヘビーユーザー、おそらくはイラレ使い、てなところか
お前が文字コードの問題まで理解できることは、短期的にはない。ベースの知識が足り無すぎる
そもそも何故お前がこの板にいるのかがかなり謎だが
PDFに不満があるのなら、「出力はAdobe純正ソフトで、マッピング情報等は全部含めて、ファイルは大きくなってもいいから」と依頼すれば、
お前の不満に対しての最適解にはなってるだろうさ
379(1): デフォルトの名無しさん [sage] 2025/08/01(金) 23:52:35.21 ID:S37h8L9Z(4/4) AAS
>>378
俺は実際にPDFの検索組んだことあるんだが、お前のその妄想はどっから来たのか知りたい
380: デフォルトの名無しさん [sage] 2025/08/02(土) 07:47:18.20 ID:xIFE1Go+(1/4) AAS
>>379
文盲か？最初の行にわざわざモロクソ書いただろ
> 検索文字列がフォント名とグリフIDのセットで降ってくるとでも思ってるのか？ (>>377)
ここからだよ
普通はたった2行のレスをわざわざ引用するのは冗長すぎるので文句言われるが、
それでもお前にはどちらの行か分かるようにしたほうが良さそうなので敢えて引用した
5chのコミュ障共はこの辺の配慮なんて汲めないから、
ひたすら「俺にとっては冗長だ」という基準で長い長い言うわけだが、
それでも馬鹿なお前に合わせて書いてるんだから、ちゃんと読め
というか、逆に言うと、そんな事を言うお前は、
> 検索文字列がフォント名とグリフIDのセットで降ってくる
場合に、検索出来るようになると思ってるわけだろ
そりゃお前の組んだプログラムなんて動作しないさ
初心者あるあるだが、
・間違った問題を、間違った方法で解決しようとして、余計におかしくなる
ケースに該当する
ただ正直、このレベルから相手にする気にはならんし、勝手によろしくやってくれだが
381: デフォルトの名無しさん [sage] 2025/08/02(土) 07:48:17.42 ID:xIFE1Go+(2/4) AAS
結局の所、>>317はよく書けていて、その通りだが、別の言い方をすると、
PDFの仕様は各文字が別々の字形(＝複数の文字コードが同じグリフを使うことがない)
の時に機能するように出来ていた
SJIS時代はだいたいこれが成立してたので、目立った問題はなかった
unicodeだとまるで動かなくなったので、新仕様を整備したが、対応してないPDFアプリは誤動作しまくり
で、これが上位の状況説明で、下位の詳細理由説明が317になってる
上位の説明はお前のような文系馬鹿でも分かるはずだが、下位の説明では、
・元々どのように動作していて、←これ(前提部分)が省略されてる
・〇〇すべき所
・△△になってるから、上手く動かない
の、後半部分しか通常は与えられない。全員が知ってる前提部分なんて無駄でしかないから
だから、前提部分の知識が全く無いお前には理解できない。これがお前が317以降空回りしてる理由
趣旨は異なるけど、例のバッテリー女も、同様の前提条件
・車のエンジンをかける際にバッテリーが必要なこと(＝セルモーターを回してエンジンをかけること)
を知らないからそうなるのであって、バッテリー女がクソ女なのは事実としても、
「バッテリーが上がってるとエンジンもかからないんだ。バッテリーなら15分ほどで修理できるから、試してみてくんない？」
と一言言えば回避できるんだが、これをやりたいか、ここまでやる必要があると考えるかは、人それぞれだね
ただ、会話する気があるのなら、相手が馬鹿と分かったのなら、馬鹿にも通じるように言うべきではある
そして俺は一応それをやってるつもりなのだから、ちゃんと読んでくれ
382(1): デフォルトの名無しさん [sage] 2025/08/02(土) 08:50:01.67 ID:jagzAmj3(1/4) AAS
糞長文書いてる暇があったらプログラム書けよ
そうすればすぐに unicode 関係ない
絶対に失敗しない検索も作れないってわかるぞ
そもそも暗号化されてもいないのに一切検索できないPDFをはくツールすらあるぞ
383: デフォルトの名無しさん [sage] 2025/08/02(土) 09:03:03.63 ID:tv/q+z7t(1) AAS
>>382
それも初心者あるあるだな
賢いお前にはこれで十分通じるはず(ｷﾘｯ
384(1): デフォルトの名無しさん [sage] 2025/08/02(土) 10:53:41.96 ID:jagzAmj3(2/4) AAS
日本語フォントとかだとグリフID の順がSJISやUnicodeと全く一致してないということを知らずに吹いてるんだろうな（SJIS時代は並び順が一致してたとでも妄想してるのかな？
検索文字列がSJISとかUnicodeで与えられた時にそれをどうやってグリフIDとマッチングされるか具体的な方法も知らないんだろうな
グリフIDと文字コードの対応がPDFに内蔵されてない場合に検索どうするか検討もつかないんだろうな
中には文字をグリフIDですらなくてアウトラインの図形データとして格納してるPDFだってあるということも知らないんだろうな
385(1): デフォルトの名無しさん [sage] 2025/08/02(土) 11:23:02.89 ID:xIFE1Go+(3/4) AAS
>>384
> 順が
なるほどやはりお前は分かってない
> 検索文字列がSJISとかUnicodeで与えられた時
実はこれには問題がある。だから注つけるかとも考えたが、
> 画面なぞって (>>361361(2): デフォルトの名無しさん [sage] 2025/07/31(木) 12:22:57.59 ID:1FIA24UI(4/8) AAS
>>360
Windowsの標準のフォントしか使ってないので、遭遇した事もないし、聞いた事もないが
(ただ、当時はそうなっても「文字化け」としてスルーされてたとも思うが
unicodeしか使った事無いゆとり以降は、文字化け＝バグ、とか言い出すから別の問題はあるにしても、
文字化けについて厳しくなってるから話題として出てきてるだけかもしれん)
しかし結局、文字コード->グリフで多対一写像があり、戻す時にどちらに戻すべきか分からなくなるのが問題なら、
(SJISな当時に)多対一写像がありまくるのはただの糞フォントだとも思うが
平仮名/片仮名は漢字の簡易形であり、当然似たような字形はあるので、
ほぼ全部のフォントでそれらを何となく区別出来るように大きさを変えてあるのが常だし
で、unicodeは多対一写像が仕様だから、
1:1写像な以前の世界向けに作られた物が当然誤動作してるだけだろ
(さっさと対応しろよ、なのは勿論だが)
して、「酷い」と考える奴は結局、後知恵でもいいからどうすべきだったと考えるのだ？
文字コードを埋め込む方式は、見た目同じだが検索に引っかからない、いわゆる正規化の問題が発生してしまう
同じグリフ->同じ文字コードなら、この問題は存在しない
だから「検索」と「コピペ」のどちら向けの仕様にするか、であり、PDFが
> 検索ができないのは不便だからってんで (>>328)
なら、そりゃ検索向けの仕様にするよ
(現在のPDFが検索時に正規化して対応してるとしても、
同じグリフに複数の文字コードを与えている糞フォントな場合、
画面なぞって検索したときに、見た目同じなのに引っかからないケースが発生する
同じグリフなら同じコードだ！の旧方式なら、これはない)
)
と既に言及してるし、どのみちunicodeだと手打ちでは無理で、画面なぞるしかない(後述)ので、まあいいかで省略した
賢いお前らなら当然気づくから、いちいち無駄ツッコミはないはずだし
> グリフIDと文字コードの対応がPDFに内蔵されてない場合
それは初(ry
> 中には文字を
それも初(ry
本質的には、unicodeの問題がPDFに輸出されてしまってるんだよ
仮にPDFがhtmlのようにunicode文字コードで構成されてても、正規化の問題は発生するし、
316の例みたいに同じグリフを複数のコードが使用してる場合、「手打ちでの」検索はヒットしないことがあり得る
PDFの仕様だと、「画面なぞれば」100%ヒットするだけまだましで、unicodeはこれすら保証できない
386(1): デフォルトの名無しさん [sage] 2025/08/02(土) 11:47:17.46 ID:jagzAmj3(3/4) AAS
>>385
結局何も分かってなかったのね？
既存のPDFビュワーの画面をなぞるのはコピペの機能だぞ
一旦グリフIDから文字コードに変換される、そして検索窓等に文字コードとして入力される、コピペが化けるのと同じ問題が起きる
それともお前がSJIS時代にグリフIDのままで検索できるビュワー書いたのか？ 本当に過去に存在してたのなら見せてくれ、ごめんなさいして今から書いても良いぞ
作るのなら
フォントごとにグリフIDが異なるんだが、まずは複数のフォントが使われてる時にあるフォントの「あ」の文字を選択したときに、別のフォントの「あ」の文字のグリフIDにどうやったら変換できるか考えてみろ
コードポイントによってはグリフがなくて表示されないやつすらある（単純な例ならスペースとか改行、もっと複雑なのが一杯ある）、
合字とかで複数の文字からなる文字列に1つだけのグリフIDが割り当てられていることもある（レパートリはフォントごとに違う）、
そういう時はどうする考えてみろ、PDFについて無知過ぎ
387(1): デフォルトの名無しさん [sage] 2025/08/02(土) 12:26:25.37 ID:xIFE1Go+(4/4) AAS
>>386
相変わらず分かってねえな
> コピペが化けるのと同じ問題が起きる
だからいいんだぞ
両方ともPDF内から生成された物だからこそ、確実に一致する
> PDFについて無知過ぎ
PDF博士なお前はマウントポイントなこの点にこだわるようだが、
既に言った通り、本質的にはPDFではなくunicodeの問題だ
実際、unicodeなhtmlでも「見た目同じだけど検索に引っかからない」ケースが普通にあるだろ
コピペに関しては、文字コードを保存してないのが問題で、既に仕様は追加済み、さっさと対応しろだが、
検索に関しては、元々unicodeは検索がまともに出来ない仕様で、それがPDFにも輸出されただけ
例えば、316で3つの「長」が同じグリフIDに紐づけされるのは、
当然その文書のそのフォントでは3つの「長」が同じグリフを使うからであり、見た目が同じだから
同じ文書をhtmlで表示させたら、当然画面上の見た目は同じ「長」になるが、
文字コードが3つのどれかは見た目では分からない
だから「手打ちで」「長」と打ち込んでも、当たらない時がある
これ、PDF全く関係ないだろ
388: デフォルトの名無しさん [sage] 2025/08/02(土) 15:48:00.24 ID:MvhBDlJ2(1) AAS
馬鹿はコード書けって言われると発狂するから分かりやすいね
389: デフォルトの名無しさん [sage] 2025/08/02(土) 18:36:31.34 ID:jagzAmj3(4/4) AAS
きっとここがプログラム技術板だってことにすら気付いていないんだろうな
プログラム書けば良いのに
390: デフォルトの名無しさん [sage] 2025/08/02(土) 19:21:29.66 ID:dbEqXJf9(1) AAS
ID:xIFE1Go+がニワカ知識だったでOK？
391: デフォルトの名無しさん [sage] 2025/08/04(月) 06:18:28.11 ID:QkMIbgCE(1/2) AAS
さてと
PDFの中を覗いてみたけど、/ActualTextという要素がある（場合がある）のね
Acrobatなどは検索やコピペのときにこれを参照するのかな?
392(1): デフォルトの名無しさん [sage] 2025/08/04(月) 06:44:34.21 ID:wGHus/El(1) AAS
画像に/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")
外部ﾘﾝｸ[pdf]:taggedpdf.com
393(1): デフォルトの名無しさん [sage] 2025/08/04(月) 07:42:52.49 ID:B+SwrOCa(1/3) AAS
Actual Text や Alt Text もそうなんだけど最近の PDF には大きな枠組みで「タグ付き PDF」という機能があって文章の構造化ができる
要はHTMLの段落タグや見出しタグと同じやつで読む順番やその文章内での意味付けや読み方や代替の指定が可能、補足を入れる Expansion Text みたいなのも
これによって改行を超えた検索とかリフローっぽいこととか、画像化された文字のテキスト化の指定とかとか色々HTMLっぽく使える
（文字コードとは独立した問題）
394: デフォルトの名無しさん [sage] 2025/08/04(月) 10:06:23.30 ID:QkMIbgCE(2/2) AAS
>>392
なるほどー。ただこれはどちらかというと /Span の使い方のデモ（濫用）って感じも
しかしこれでAcrobatのことが少しわかった感も、どうもです
>>393
> ... 文章の構造化ができる
>（文字コードとは独立した問題）
異なるコードポイントの文字を構造化することもできますね
395(2): デフォルトの名無しさん [sage] 2025/08/04(月) 12:31:11.59 ID:Dprx6XuC(1/2) AAS
一部訂正
× コピペに関しては、文字コードを保存してないのが問題で、(>>387)
○ unicodeのコピペに関しては、糞フォントと文字コードを保存してない組み合わせの時の問題で、
PDFの昔の仕様でも、文字コード->グリフが1:1の場合にはコピペ/検索共に全く問題なく機能する
316で「なんか低い…」になるのは、それらの文字コードには別のグリフが与えられているからであり、
PDF閲覧者の環境でその文書のPDFを作成した場合、(3つとも別のグリフなら)全く問題ないPDFが作成される
だから発生条件として、
・糞フォントで、違う文字コードで同じグリフを使いまくり
が必要であり、これを誘発しているのはunicodeの仕様
だからPDFがボロいと言うより、
unicodeが本質的にボロくて、以前の1:1な世界と親和性が皆無な事が問題なのだと思うよ
(なお316の件は、コードに戻す際、その文書で一度も使ってもない「長」に決め打ちで変換されていると思われ、
PDF出力アプリがポンコツなのもほぼ間違いない
376の通り、「その文書で最初にそのグリフを使った文字コード」を格納する実装なら、
単国籍な文書《≒大半のケース》で顕在化するのは防げる)
結論としては、やっぱunicode糞じゃね？と思うが
以前の文字コード：このコードはこう表示される程度の知識で全く問題ない
unicode：正しい作法(正規化等)を知らないと色々誤動作する
396(1): デフォルトの名無しさん [sage] 2025/08/04(月) 12:54:11.55 ID:B+SwrOCa(2/3) AAS
>>395
お前、まだあきらめて無かったのか
昔から1対1なんてことはないよ
グリフIDはフォントごとに異なる、1つのPDFで複数のフォントを使ったら異なるグリフIDになる、逆に同じグリフIDでも異なる文字を表現している
何度も言われただろ、理解できない部分を読み飛ばしてるのか？
397(1): デフォルトの名無しさん [sage] 2025/08/04(月) 13:40:26.46 ID:Dprx6XuC(2/2) AAS
>>396
いや、やはりお前は理解出来てない
もういいけど
(お前が理解出来ない事は理解しているし、お前の頭の悪さについては諦めている)
> グリフIDはフォントごとに異なる、1つのPDFで複数のフォントを使ったら異なるグリフIDになる
ここまでは全く問題ないが、
> 逆に同じグリフIDでも異なる文字を表現している
これが問題
「単射」と言った方が正しかったが、
俺は使ってきてなかったのと、後で使ってた「1:1」表現に揃えたのが不適切だったようだ
ただ、事実は変わらない
当たり前だがゴシックの「あ」と明朝の「あ」は別グリフIDになるが、
この場合にも検索/コピペは昔のPDFの仕様で全く問題なく動作する
まあunicodeは色々糞だというのが俺の見解
387の表現だとPDFに主たる問題があるとも読めるので訂正した
(unicode以前は問題なく機能していたので)
398: デフォルトの名無しさん [sage] 2025/08/04(月) 14:31:23.34 ID:B+SwrOCa(3/3) AAS
>>397
明朝体の「あ」のグリフIDが 325 でゴシック体の「ほ」のグリフIDが同じ 325 ということだってあり得るんだよ
明朝体の「あ」とゴシック体の「あ」は検索したいけど、ゴシック体の「ほ」は検索にひっかかると困る。常識だろ
399: デフォルトの名無しさん [sage] 2025/08/04(月) 14:37:31.31 ID:D3iy7z0J(1) AAS
>>395
>・糞フォントで、違う文字コードで同じグリフを使いまくり
自分の妄想をベースにAdobeに因縁を付けるのか
最近こういう人が増えている感じで怖い
>以前の文字コード：このコードはこう表示される程度の知識で全く問題ない
ある
前提の認識が間違っているのでそれをベースにした話も間違い
ただの間違いの積み重ね
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.250s*