文字コード総合スレ part15

**デフォルトの名無しさん** · 2024/08/17(土) 11:18:00.01

文字コードについて語り合うスレです

**デフォルトの名無しさん** · 2025/01/21(火) 22:39:07.66

rgは凄く効率を重視してるけどOsStringで扱うしかなくてロスが発生してる
(各ファイルを開くのにWTF-16名に戻す処理が必要)

**デフォルトの名無しさん** · 2025/01/22(水) 23:14:48.82

OsStringは異なる環境で統一的に容易にStringと相互変換して扱えるための標準ライブラリ機能
些細なロスすら深刻な影響が出る用途がもし存在するのならば
特定環境に特化した専用のライブラリを用意すればよいだけ
必要な条件を満たすライブラリが既に存在しているかどうかは各自の用途で調べて

**デフォルトの名無しさん** · 2025/01/24(金) 18:16:24.35

>>209
今の正しいソースはこっちな
githubcom/rust-lang/rust/blob/master/library/std/src/sys_common/wtf8.rs#L357

>>228
結果的にWTF-8でA+B問題は起きるな

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

>>239
WTF-8自体を自在に改変するインターフェイスが全くないため、WTF-8独自の問題は発生しない。
WTF-8はWTF-16と1対1に可逆なので、WTF-16で起こる問題は当然WTF-8でも起きる。
WTF-16とはWindows OSが許容している拡張UTF-16、すなわち本来のUTF-16とは異なる16bit列も許す。
したがって、WTF-8を用いて起こる問題は、Windows OSが許容してる範囲内の問題のみであり、新たな問題を持ち込むことはない。

**デフォルトの名無しさん** · 2025/01/25(土) 06:47:37.99

>>240
なんでもOSのせいにするのは良くないぞ
Windows は片サロゲートどうしを連結することを前提にしてはいない
あくまでも連結してるのはアプリの問題
WTF-8 の連結もアプリの問題OSとは独立

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

>>241
もちろんその通りで
当たり前の三つの同値
WTF-8で起こりうること＝ WTF-16で起こりうること＝ Windowsで起こりうること
これだけの話だな
それを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた

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

>>242
いや
WTF-8 で起こりうること = WTF-16 で起こりうることは定義上正しいけど
= Windows で起こりうること、は正しくないだろという指摘だぞ

**デフォルトの名無しさん** · 2025/01/25(土) 08:11:11.01

>>243
意図的にUTF-16から逸脱したコードを生成するアプリ次第でWindows上で起こりうるから全く同じ
もし違うというならばその差分となる具体例を出してください

**デフォルトの名無しさん** · 2025/01/25(土) 11:54:33.53

>>244
Linux とかでも意図的に逸脱したコード書けば起きるだろ
違うってなんら Windows 固有にコード示したら？

**デフォルトの名無しさん** · 2025/01/25(土) 12:08:02.89

>>245
それも正しい
WindowsもLinuxも正しいユニコード以外を許容している
だからUTF-16やUTF-8を前提としてはいけない
そのためWTF-16やWTF-8あるいは何らか他の枠組みの導入でようやく対応できる

その時に当たり前の三つの同値
WTF-8で起こりうること＝ WTF-16で起こりうること＝ Windowsで起こりうること
この事実を理解できるかどうか

これを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた

**デフォルトの名無しさん** · 2025/01/25(土) 12:36:14.63

>>246
= Windows で起こりうることに拘るのは何でだ？
UTF-8 と WTF-8 は別物なのに同じように扱ったら問題が起きる可能性がある OS とは独立

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

>>247
どのOSも正しいユニコード以外を許容している
したがってUTF-8/16以外も扱えなければならない
そして非UTF-8/16があった時にそれを認識して区別して扱えなければならない
その区別ができないと既存のUTF-8/16部分にもうっかり混入させて汚染を広げてしまう
この重要性が理解できるかね？

RustではUTF-8とWTF-8(など非ユニコード)は明確に別の型となっているため安全性が保証される
両者を扱えつつ型システムにより必ず区別できる

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

>>248
だからOSとは独立の文字コードの扱いの問題
もっといえば文字コードを正しく扱えないアプリの問題
OSのせいにするな

**デフォルトの名無しさん** · 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じゃなくて今後も全部に独立コードポイントが割り当てられることになった
－甲骨文字は漢字じゃないので独立コードポイントよこせって中国が言ってきたので漢字とは別に割り当てる予定