文字コード総合スレ part15 (348ﾚｽ)
文字コード総合スレ part15 http://mevius.5ch.net/test/read.cgi/tech/1723861080/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
1: デフォルトの名無しさん [] 2024/08/17(土) 11:18:00.01 ID:VHa7+i59 文字コードについて語り合うスレです http://mevius.5ch.net/test/read.cgi/tech/1723861080/1
222: デフォルトの名無しさん [sage] 2025/01/21(火) 08:06:50.62 ID:6E3WwSvm >>221 それを含めた時が冗長性誕生の瞬間である http://mevius.5ch.net/test/read.cgi/tech/1723861080/222
223: デフォルトの名無しさん [sage] 2025/01/21(火) 08:11:27.09 ID:CGf2GAkC >>222 冗長表現となる事例とその生成プログラム例を出そうよ 世界中で誰も示せていないよ http://mevius.5ch.net/test/read.cgi/tech/1723861080/223
224: デフォルトの名無しさん [sage] 2025/01/21(火) 08:59:02.25 ID:HFAykEjr WTF-8 は定義からして冗長性はない、プログラム以前の問題 WTF-8 は UTF-8 に加えて片サロゲートをUTF-8変換したものが含まれているだけ サロゲート前半とサロゲート後半の連続も許されてない それが混じったらWTF-8じゃない WTF-8∋UTF-8 → ✕ WTF-8⊃UTF-8 → ○ 任意の16bit列 = WTF-16 → ○ （未定義文字などを許す前提） 任意の8bit列 = WTF-8 → ✕ WTF-16 と WTF-8 は冗長性なく1対1対応 → ○ 基本が分かってないやつがいるので議論が噛み合ってないだけのようだ http://mevius.5ch.net/test/read.cgi/tech/1723861080/224
225: デフォルトの名無しさん [sage] 2025/01/21(火) 09:11:27.73 ID:nn8C9EMv >>224 > 基本が分かってないやつ ごめんごめんWTF-8の定義見て来た。 あと>>209見て明らかな脆弱性はないと納得した。 pushでsurrogate pairになってもself.is_known_utf8 = falseにしてるんだな。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/225
226: デフォルトの名無しさん [sage] 2025/01/21(火) 09:23:46.18 ID:snb5MXpj WTF-8に冗長表現は起きず脆弱性はないね 冗長が起きると書き込んでる人は、理解できずに間違った思い込みをしているのか、悔しくてデマを繰り返してるのか、わからんけどさ 冗長表現を生成する具体例を一つ示せば済むのに、ここまで来ても一つも示せていない http://mevius.5ch.net/test/read.cgi/tech/1723861080/226
227: デフォルトの名無しさん [sage] 2025/01/21(火) 10:25:40.02 ID:uiolM7XA 帰れ http://mevius.5ch.net/test/read.cgi/tech/1723861080/227
228: デフォルトの名無しさん [sage] 2025/01/21(火) 11:37:21.93 ID:q2HQSFd2 >>215の言うAにもBにも含まれない「文字」がA+Bに含まれるかもしれない問題、 処理の正しさの観点では(脆弱性の話は置いておいて) NFC/NFDやIVS/IVD/ZWJ絡みで(well formed UTF-8同士の範囲でも)発生する気がするけど 実際にA+Bを作ってからチェックするのが鉄則なのか？ 「文字」じゃなくて「文字列」ならA+Bを作るのが普通と思う (それと正規表現なら部分マッチが出来たりする) http://mevius.5ch.net/test/read.cgi/tech/1723861080/228
229: デフォルトの名無しさん [sage] 2025/01/21(火) 12:16:20.66 ID:HFAykEjr >>228 結合文字とか変種指定は機能性の問題なのでさらに一段回上のレイヤーの要件だな 「が」と「か＋結合濁点」を同じとみなすか別とみなすかは目的による（文字コード的にはどちらもありえる http://mevius.5ch.net/test/read.cgi/tech/1723861080/229
230: デフォルトの名無しさん [sage] 2025/01/21(火) 12:47:14.29 ID:mXSJj++Z そんなの要件定義考慮漏れで溢れかえってる 何かあったら現状を仕様にする http://mevius.5ch.net/test/read.cgi/tech/1723861080/230
231: デフォルトの名無しさん [sage] 2025/01/21(火) 16:35:46.77 ID:3Vt9EG/U ライブラリ側に問題がないとはいえ過信はよろしくない OsStringでは機能が足りず中身を取り出しての直接処理はよくやられてるし 余計な変換をかましてるせいで考慮することが増えてしまってる一方でアプリ側にはWindowsの特殊事情なんて考慮してないコードも山ほどあろう http://mevius.5ch.net/test/read.cgi/tech/1723861080/231
232: デフォルトの名無しさん [sage] 2025/01/21(火) 17:20:43.69 ID:HFAykEjr >>231 だから最初から WTF-8 は UTF-8 とは別物 混同したら問題、混同しなければ問題はない UTF-8 ではサロゲート断片は許されない WTF-8 ではサロゲートの片側だけ許されるがそのせいで追加の処理が必要 冗長性うんぬんを言い出すのはこの違いが分かってないやつという話題だろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/232
233: デフォルトの名無しさん [sage] 2025/01/21(火) 17:51:44.82 ID:ARY2cBPO Windowsも対応しているRipGrepの場合、OsStringのまま処理してるけど ユーザーアプリレベルでWTF-8は必要なのか？ (すぐにpub fn into_string(self) -> Result<String, OsString>してる気がする) http://mevius.5ch.net/test/read.cgi/tech/1723861080/233
234: デフォルトの名無しさん [sage] 2025/01/21(火) 20:27:12.14 ID:81VrkBbA 10年以上経ってv0.1.0な時点でネタライブラリでは http://mevius.5ch.net/test/read.cgi/tech/1723861080/234
235: デフォルトの名無しさん [sage] 2025/01/21(火) 20:36:26.03 ID:vcWEfek9 >>233 OsStringとWTF-8は別物だと理解できてる？ OsStringは元が正規ユニコードならUTF-8となり、異なるならUTF-8を含む拡大集合になる、という抽象的な型 たまたまWindows環境の時は内部がWTF-8になるかもしれないがそんなことを意識せずに使えるところがカギ 自分の管轄範囲を処理する多くのアプリでは元がユニコードでなければエラーとして無視できる そのためto_string()で文字列すなわちUTF-8へ変換するがそこで実際に変換する必要がなく変換コストはゼロとなる点が実際の目的 このような特性を備えつつUTF-8にできない場合も元の情報を保つ抽象的な型がOsString そしてWindowsの場合はその内部実装をWTF-8にすると上述の特性群を満たせるというだけの話 http://mevius.5ch.net/test/read.cgi/tech/1723861080/235
236: デフォルトの名無しさん [sage] 2025/01/21(火) 22:03:34.94 ID:HFAykEjr Rust の OsString という基準だと Linux とかだと任意のバイト列なんでそっちがもともとの形だな たまたま Windows 版で効率考えて WTF-8 変換したものを使ってるだけ http://mevius.5ch.net/test/read.cgi/tech/1723861080/236
237: デフォルトの名無しさん [sage] 2025/01/21(火) 22:39:07.66 ID:p3RcK7RU rgは凄く効率を重視してるけどOsStringで扱うしかなくてロスが発生してる (各ファイルを開くのにWTF-16名に戻す処理が必要) http://mevius.5ch.net/test/read.cgi/tech/1723861080/237
238: デフォルトの名無しさん [sage] 2025/01/22(水) 23:14:48.82 ID:qi7PZ6q/ OsStringは異なる環境で統一的に容易にStringと相互変換して扱えるための標準ライブラリ機能 些細なロスすら深刻な影響が出る用途がもし存在するのならば 特定環境に特化した専用のライブラリを用意すればよいだけ 必要な条件を満たすライブラリが既に存在しているかどうかは各自の用途で調べて http://mevius.5ch.net/test/read.cgi/tech/1723861080/238
239: デフォルトの名無しさん [sage] 2025/01/24(金) 18:16:24.35 ID:3xtC4p+Z >>209 今の正しいソースはこっちな githubcom/rust-lang/rust/blob/master/library/std/src/sys_common/wtf8.rs#L357 >>228 結果的にWTF-8でA+B問題は起きるな http://mevius.5ch.net/test/read.cgi/tech/1723861080/239
240: デフォルトの名無しさん [sage] 2025/01/24(金) 21:50:18.47 ID:VaG4uwwC >>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が許容してる範囲内の問題のみであり、新たな問題を持ち込むことはない。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/240
241: デフォルトの名無しさん [sage] 2025/01/25(土) 06:47:37.99 ID:IEhZAzOs >>240 なんでもOSのせいにするのは良くないぞ Windows は片サロゲートどうしを連結することを前提にしてはいない あくまでも連結してるのはアプリの問題 WTF-8 の連結もアプリの問題OSとは独立 http://mevius.5ch.net/test/read.cgi/tech/1723861080/241
242: デフォルトの名無しさん [sage] 2025/01/25(土) 07:40:49.86 ID:oQSzfWfA >>241 もちろんその通りで 当たり前の三つの同値 WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること これだけの話だな それを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた http://mevius.5ch.net/test/read.cgi/tech/1723861080/242
243: デフォルトの名無しさん [sage] 2025/01/25(土) 08:02:54.69 ID:IEhZAzOs >>242 いや WTF-8 で起こりうること = WTF-16 で起こりうることは定義上正しいけど = Windows で起こりうること、は正しくないだろという指摘だぞ http://mevius.5ch.net/test/read.cgi/tech/1723861080/243
244: デフォルトの名無しさん [sage] 2025/01/25(土) 08:11:11.01 ID:oQSzfWfA >>243 意図的にUTF-16から逸脱したコードを生成するアプリ次第でWindows上で起こりうるから全く同じ もし違うというならばその差分となる具体例を出してください http://mevius.5ch.net/test/read.cgi/tech/1723861080/244
245: デフォルトの名無しさん [sage] 2025/01/25(土) 11:54:33.53 ID:IEhZAzOs >>244 Linux とかでも意図的に逸脱したコード書けば起きるだろ 違うってなんら Windows 固有にコード示したら？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/245
246: デフォルトの名無しさん [sage] 2025/01/25(土) 12:08:02.89 ID:oQSzfWfA >>245 それも正しい WindowsもLinuxも正しいユニコード以外を許容している だからUTF-16やUTF-8を前提としてはいけない そのためWTF-16やWTF-8あるいは何らか他の枠組みの導入でようやく対応できる その時に当たり前の三つの同値 WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること この事実を理解できるかどうか これを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた http://mevius.5ch.net/test/read.cgi/tech/1723861080/246
247: デフォルトの名無しさん [sage] 2025/01/25(土) 12:36:14.63 ID:IEhZAzOs >>246 = Windows で起こりうることに拘るのは何でだ？ UTF-8 と WTF-8 は別物なのに同じように扱ったら問題が起きる可能性がある OS とは独立 http://mevius.5ch.net/test/read.cgi/tech/1723861080/247
248: デフォルトの名無しさん [sage] 2025/01/25(土) 13:00:31.67 ID:oQSzfWfA >>247 どのOSも正しいユニコード以外を許容している したがってUTF-8/16以外も扱えなければならない そして非UTF-8/16があった時にそれを認識して区別して扱えなければならない その区別ができないと既存のUTF-8/16部分にもうっかり混入させて汚染を広げてしまう この重要性が理解できるかね？ RustではUTF-8とWTF-8(など非ユニコード)は明確に別の型となっているため安全性が保証される 両者を扱えつつ型システムにより必ず区別できる http://mevius.5ch.net/test/read.cgi/tech/1723861080/248
249: デフォルトの名無しさん [sage] 2025/01/25(土) 13:07:40.11 ID:IEhZAzOs >>248 だからOSとは独立の文字コードの扱いの問題 もっといえば文字コードを正しく扱えないアプリの問題 OSのせいにするな http://mevius.5ch.net/test/read.cgi/tech/1723861080/249
250: デフォルトの名無しさん [sage] 2025/01/25(土) 13:31:18.17 ID:oQSzfWfA >>249 どちらのOSも自由を許容している そのため非ユニコードが混入しうる OSは歯止めにならない だからRustのように型で明確に区別できる言語を用いてアプリを作ればよい 非ユニコードが他へ波及することを防ぎつつ安全に扱うことができる http://mevius.5ch.net/test/read.cgi/tech/1723861080/250
251: デフォルトの名無しさん [sage] 2025/01/25(土) 14:44:40.60 ID:6/VZHgMn 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それ自体が脆弱性の根源になることはなくても、こうしたややこしさが誤った使い方、ひいては脆弱性を生むことはあるかもしれないとは思った http://mevius.5ch.net/test/read.cgi/tech/1723861080/251
252: デフォルトの名無しさん [sage] 2025/01/25(土) 15:20:14.12 ID:0Kd0a2wN >>251 そのunsafe fn from_encoded_bytes_unchecked(byres: Vec<u8>)は安全性の対象外と明示されているね unsafeとはC言語と同じようにプログラマーの責任で安全性を保証しなければならない それを理解しない者や扱う技術を持たない者がunsafeを使ってはいけない それ以前にRustは今回の件も自動的に安全性が保証されるコードを(unsafeを使わずに)書くことができる http://mevius.5ch.net/test/read.cgi/tech/1723861080/252
253: デフォルトの名無しさん [sage] 2025/01/25(土) 15:40:07.61 ID:6/VZHgMn >>252 その通り、だからunsafe contractを破った俺が悪いと書いた しかしぶっ壊すことで得られる学びは多い http://mevius.5ch.net/test/read.cgi/tech/1723861080/253
254: デフォルトの名無しさん [sage] 2025/01/25(土) 15:45:28.44 ID:6/VZHgMn というかもうWTF-8の話じゃなくてRustの話になりつつあるしこの辺で終わっとこうぜ 続きがやりたければRust本スレで http://mevius.5ch.net/test/read.cgi/tech/1723861080/254
255: デフォルトの名無しさん [sage] 2025/01/25(土) 21:10:55.94 ID:yCgioYGI Rustスレから出てこないで欲しい http://mevius.5ch.net/test/read.cgi/tech/1723861080/255
256: デフォルトの名無しさん [sage] 2025/01/25(土) 22:20:25.13 ID:LC7IJQQw 構うから居座り続けるんだよ 学習しろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/256
257: デフォルトの名無しさん [sage] 2025/01/26(日) 10:07:42.23 ID:QXh9thRU Macの濁点半濁点問題ってUTF-8の正規化とやらの範疇に入るのかな 文字構成の解釈の仕方の問題だから正規化を実装する人の思想に強く依存してしまうと思うけど http://mevius.5ch.net/test/read.cgi/tech/1723861080/257
258: デフォルトの名無しさん [sage] 2025/01/26(日) 10:56:58.06 ID:14aIx6OH 日本人からすると濁点半濁点の違うMacうぜーとなるけど 欧州でもdiacriticsがあるから同じくMacうぜーだろうな http://mevius.5ch.net/test/read.cgi/tech/1723861080/258
259: デフォルトの名無しさん [sage] 2025/01/26(日) 11:31:33.02 ID:orn1Lem+ >>257 このスレにいるなら文字コードとエンコーディングの区別を理解しよう UTF-8はエンコーディング方法なので そこでの正規化は冗長表現の排除やサロゲートペアの排除を指す 一方濁点半濁点の話は文字コードであるUnicodeの正規化の話であってUTF-8は一切関係がない http://mevius.5ch.net/test/read.cgi/tech/1723861080/259
260: デフォルトの名無しさん [sage] 2025/01/26(日) 11:52:28.72 ID:OHuPDl3g >>257 Unicode の正規化は規格で決まっている 基本的に実装者の自由にやってはいけない ・複数の正規化が規定されてるのでそのうちの1つに過ぎない ・MacOSの正規化は一部規格から外れてる という問題はある http://mevius.5ch.net/test/read.cgi/tech/1723861080/260
261: デフォルトの名無しさん [sage] 2025/01/26(日) 12:03:07.52 ID:Lrs5O7+s Macの濁点半濁点問題はEBCDICのカナ（半角カタカナ）をきれいに表示する努力をした結果なのだろうか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/261
262: デフォルトの名無しさん [sage] 2025/01/27(月) 11:38:12.00 ID:ss2Vvpwv ファイル名は正規化するべきなのかするべきでないのか、という問題があり Macは正規化する派 正規化するとした場合、どういう正規化がいいか、それが次の問題 http://mevius.5ch.net/test/read.cgi/tech/1723861080/262
263: デフォルトの名無しさん [] 2025/01/27(月) 18:51:09.07 ID:5zVfH4ct 日本語のフォントを外国人が作っているせいで日本語の記号の見た目がおかしくなった http://mevius.5ch.net/test/read.cgi/tech/1723861080/263
264: デフォルトの名無しさん [] 2025/01/27(月) 18:52:15.56 ID:5zVfH4ct >>262 Macのアップル社もGoogle社も改行コードに対しては意地悪すぎだろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/264
265: デフォルトの名無しさん [sage] 2025/01/27(月) 22:05:41.27 ID:1OoDt+VN Apple の改行コードはCRだったものがMac OS X でLFになったのを意地悪と言っているのだろうか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/265
266: デフォルトの名無しさん [] 2025/01/27(月) 23:31:59.65 ID:5zVfH4ct >>265 WindowsのCRLFをどちらも改行と見做すところ どう考えても1つの改行なのにEメールなどでは2つの改行として送り返してくる http://mevius.5ch.net/test/read.cgi/tech/1723861080/266
267: デフォルトの名無しさん [] 2025/01/28(火) 10:08:29.84 ID:dqvH8r5C CR=改行(Macのみ) CRLF=改行(WindowsやRFC) LF=改行(Unix) >>266 それはアプリのバグ http://mevius.5ch.net/test/read.cgi/tech/1723861080/267
268: デフォルトの名無しさん [sage] 2025/01/28(火) 11:39:24.54 ID:JQ2UpNE9 >>267 いろいろ間違えてるぞ 正確さが足りない http://mevius.5ch.net/test/read.cgi/tech/1723861080/268
269: デフォルトの名無しさん [] 2025/01/30(木) 07:10:47.96 ID:gms+ATb5 ワシの霊感では、 CR LF → LF 変換 は無理 CR LF → CR 変換 も無理 その逆、は可能、スナワチ LF → CR LF 変換等は、可能 なんでかって❓ 霊感的には、 それが可能と仮定すれば、そのような問題は解決済 しかし未だに未解決の模様なので、 では、霊感的にではなく、数学的にはどうなのか 吟味しようかな。てか不可能が証明されても その証明は、闇に葬る必要があるよな by 💃🥳🤔 とにかく、アプリの改行バグなくせぇーー by 👤🤡 http://mevius.5ch.net/test/read.cgi/tech/1723861080/269
270: デフォルトの名無しさん [sage] 2025/01/30(木) 10:13:34.95 ID:lxoi8Hgj RFCもいまどき入力は寛容にとは書いてないんだっけか http://mevius.5ch.net/test/read.cgi/tech/1723861080/270
271: デフォルトの名無しさん [sage] 2025/01/30(木) 23:31:56.82 ID:xDtExgvT 改行の話をするならこのTRには目を通しているよね? https://www.unicode.org/reports/tr14/tr14-32.html#BreakingRules http://mevius.5ch.net/test/read.cgi/tech/1723861080/271
272: デフォルトの名無しさん [] 2025/01/31(金) 19:55:09.44 ID:0CYGlf8F CRの直後にLFが現れたなら、改行2つではないとわかる。 それなのに改行2つと解釈するのは悪意でしかないり http://mevius.5ch.net/test/read.cgi/tech/1723861080/272
273: デフォルトの名無しさん [sage] 2025/01/31(金) 20:06:45.58 ID:RSTFpkS7 CR や LF より前に CRLF を処理しないのは悪意でしか無いな http://mevius.5ch.net/test/read.cgi/tech/1723861080/273
274: デフォルトの名無しさん [sage] 2025/01/31(金) 20:07:21.09 ID:B141IEhK >>260 NFD、NFC等を名乗るならそうだが最初からmodified NFD言ってるしなあ 当時は異体字セレクタなどなく、ただのNFDで字形まで変えるUnicodeの定義のほうがおかしかった http://mevius.5ch.net/test/read.cgi/tech/1723861080/274
275: デフォルトの名無しさん [sage] 2025/01/31(金) 20:25:32.29 ID:uF0JLDg9 >>274 みんながみんな勝手に modified NFD とか作り始めたら互換性とか規格とか何の意味もなくなる 勝手なオレオレ基準は非難されるべき 単に古い規格準拠というだけなら許されるが Apple のはそうじゃない http://mevius.5ch.net/test/read.cgi/tech/1723861080/275
276: デフォルトの名無しさん [sage] 2025/01/31(金) 20:45:51.19 ID:B141IEhK そもそも正規化自体は都合に合わせて勝手にやるもんだぜ？ Windowsの.で終わるファイル名を拡張子なしと同一視するのも正規化だし 掲示板への書き込みで行頭のスペースが消えるのも正規化だ Unicodeで定義されたやつだけが正規化ではないというのは大前提として 字形を変えない範囲で厄介な合成分解で別ファイル扱いになるのを避けたい というのは他の文字コードからUnicodeへの過渡期では当然の要求だろう 他のOSとのやりとりでトラブルが起きるようになったのはもっと考えるべきだったとは思うが http://mevius.5ch.net/test/read.cgi/tech/1723861080/276
277: デフォルトの名無しさん [sage] 2025/01/31(金) 20:53:12.36 ID:uF0JLDg9 >>276 それは違う Apple はユニコード・コンソーシアムの設立からのメンバー 技術的に規格に問題があるののならそれを変えればいい、それをやらなければいけない立場 中核メンバーが自分たちが作った規格を勝手に無視してたら、規格の意味なんてない この件はどう言い訳しても Apple はクソという結論にしかならない http://mevius.5ch.net/test/read.cgi/tech/1723861080/277
278: デフォルトの名無しさん [sage] 2025/01/31(金) 20:55:58.32 ID:B141IEhK >>277 Appleは提案したが通らなかったってどっかで見たぞ http://mevius.5ch.net/test/read.cgi/tech/1723861080/278
279: デフォルトの名無しさん [sage] 2025/01/31(金) 20:57:03.60 ID:h9+hJoTP 技術的に無理な仕様作ったん？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/279
280: デフォルトの名無しさん [sage] 2025/01/31(金) 21:06:00.74 ID:uF0JLDg9 >>278 どこで見たんだ？ 技術的に変な提案したら通らないだろうが、それが規格を無視して良い理由にはならない それを理由に脱退したんなら一理あるけど http://mevius.5ch.net/test/read.cgi/tech/1723861080/280
281: デフォルトの名無しさん [sage] 2025/01/31(金) 21:19:51.37 ID:1pwkweKb 規格があるのにそれを使わない分野なんて沢山ありそうだが 実際のところ金を出せて声がでかければ規格なんていくらでも通せるんだから http://mevius.5ch.net/test/read.cgi/tech/1723861080/281
282: デフォルトの名無しさん [sage] 2025/01/31(金) 21:24:04.22 ID:B141IEhK >>280 俺が見た記事は残ってないだろうけど検索したら出てきたunicode.org内の議事録はたぶんこれ ttps://www.unicode.org/review/resolved-pri.html#pri7 http://mevius.5ch.net/test/read.cgi/tech/1723861080/282
283: デフォルトの名無しさん [sage] 2025/01/31(金) 21:26:16.69 ID:gGXkx70A >>281 ヒデェ http://mevius.5ch.net/test/read.cgi/tech/1723861080/283
284: デフォルトの名無しさん [sage] 2025/01/31(金) 22:22:23.03 ID:mygoMuj6 >>282 ｗｗｗ 一部除外したら一貫性が無くなって正規化が 正規化じゃなくなるから勝手な除外は駄目って明確に指摘されてるな なんで実装したんだろう？ いやVFとか使いたくなかったんだろうけど、 どうしてもやりたければ任意の除外ではなく VF のみ除外みたいなので再提案すべきだったのでは http://mevius.5ch.net/test/read.cgi/tech/1723861080/284
285: デフォルトの名無しさん [sage] 2025/02/16(日) 22:21:14.00 ID:y/0wzlVz https://gigazine.net/news/20250214-unicode-hidden-message/ Unicodeでは一見すると普通の文字の中に「秘密のメッセージ」を埋め込むことが可能だという指摘 http://mevius.5ch.net/test/read.cgi/tech/1723861080/285
286: デフォルトの名無しさん [sage] 2025/02/16(日) 23:51:54.49 ID:hLnUvUfF >>285 なるほどね https://i.gzn.jp/img/2025/02/14/unicode-hidden-message/03.png http://mevius.5ch.net/test/read.cgi/tech/1723861080/286
287: デフォルトの名無しさん [sage] 2025/02/17(月) 16:59:47.72 ID:GjzIkJ/e Unicodeはそのうちオーディオブック用やa11yで読み上げ音声用のVSが定義されそう http://mevius.5ch.net/test/read.cgi/tech/1723861080/287
288: デフォルトの名無しさん [sage] 2025/02/17(月) 17:34:45.48 ID:9sDD+e7d 漢字みたいな複数の読み方があるのは難しいだろうね http://mevius.5ch.net/test/read.cgi/tech/1723861080/288
289: デフォルトの名無しさん [sage] 2025/02/17(月) 18:36:11.68 ID:tdbxV0fJ MSOfiiceでIME入力がphoneticsとして保存されてて読み仮名表示出来るのは、他に広まっても良いのにな http://mevius.5ch.net/test/read.cgi/tech/1723861080/289
290: デフォルトの名無しさん [sage] 2025/02/18(火) 12:25:03.72 ID:HbHlBTpR >>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() } } http://mevius.5ch.net/test/read.cgi/tech/1723861080/290
291: デフォルトの名無しさん [] 2025/02/28(金) 17:04:23.70 ID:kF3VgEHE 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) } } http://mevius.5ch.net/test/read.cgi/tech/1723861080/291
292: デフォルトの名無しさん [sage] 2025/04/03(木) 21:05:53.03 ID:tEk54HNS 「Windows11でファイル名に絵文字が使えることを知って、1つ賢くなった」便利と思われる機能が追加→情シスがバールを担いで暴れ出す案件 https://posfie.com/@blackstaragent/p/kpHrLMR 今まで使えなかったんだっけ？と思って最後まで見たら ちゃんと前から使えてたって突っ込まれてたわ http://mevius.5ch.net/test/read.cgi/tech/1723861080/292
293: デフォルトの名無しさん [sage] 2025/04/06(日) 16:37:54.44 ID:+flcOJuk 普通に文を書く時でも()?!などの記号をASCII文字にするか全角文字にするか 濁点と半濁点を結合済み文字にするか別の文字にするかで迷ってしまう http://mevius.5ch.net/test/read.cgi/tech/1723861080/293
294: デフォルトの名無しさん [] 2025/04/07(月) 21:43:17.60 ID:1UVr/FZP 濁点と半濁点が別の文字だと認識しているのはおかしい http://mevius.5ch.net/test/read.cgi/tech/1723861080/294
295: デフォルトの名無しさん [] 2025/04/08(火) 17:04:31.43 ID:UfxEZoR8 まし"て" http://mevius.5ch.net/test/read.cgi/tech/1723861080/295
296: デフォルトの名無しさん [] 2025/04/09(水) 01:54:47.78 ID:t8BwIxsD Windowsのエクスプローラーで見るとキャラクタセットによっては濁点が別の文字だとわからないことがある http://mevius.5ch.net/test/read.cgi/tech/1723861080/296
297: デフォルトの名無しさん [sage] 2025/04/11(金) 20:08:58.20 ID:i2PY9ZNn 朝鮮系の奴隷労働者が造ったと思われるサイトは 濁点が抜けてる気持ち悪いところがいくつかある http://mevius.5ch.net/test/read.cgi/tech/1723861080/297
298: デフォルトの名無しさん [sage] 2025/04/12(土) 06:35:11.93 ID:IMDrBc8a 調整 https://techracho.bpsinc.jp/hachi8833/2021_09_08/48435 https://gigazine.net/news/20231005-unicode/ 477414164X http://mevius.5ch.net/test/read.cgi/tech/1723861080/298
299: デフォルトの名無しさん [] 2025/05/02(金) 09:50:51.92 ID:k5bGwZZ0 不可視化トラップで教育素材造るのはいいね https://www.youtube.com/watch?v=cXTBwD798Lk http://mevius.5ch.net/test/read.cgi/tech/1723861080/299
300: デフォルトの名無しさん [sage] 2025/05/02(金) 18:10:04.97 ID:9xoZUliT ユニコード悪用ヤバいな >>298 ＞公式アプリと同じ開発者に見える名前で偽アプリが提供されました。 ＞この詐欺師は、印刷に現れないスペース文字を開発者名に混ぜ込むことでバリデーションのすり抜けに成功しました。 ＞このハックによって100万人以上が騙されました。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/300
301: デフォルトの名無しさん [] 2025/05/02(金) 20:30:48.79 ID:rPO248eK >印刷に現れないスペース文字 誤訳だな AIあほすぎ http://mevius.5ch.net/test/read.cgi/tech/1723861080/301
302: デフォルトの名無しさん [sage] 2025/05/07(水) 21:40:30.18 ID:9JkcRkxN https://github.com/microsoft/cascadia-code/releases/tag/cascadia-next Joyo, JIS1, JIS2って何だよ 日本人向けのフォントなら日本人に分かるような書き方してくれ http://mevius.5ch.net/test/read.cgi/tech/1723861080/302
303: デフォルトの名無しさん [] 2025/05/08(木) 02:26:11.93 ID:US+UAC1U >>258 多分Mac OS Xのファイル名にNFDを採用したのは 辞書順がdiacriticsを無視する言語文化圏の人だったのでは 欧州では多数派だけど唯一ではない >>121 OS kernelのsyscall部分で矯正してるわけではなくて file system driverがやってる(ただしDarwinソースを確認したのは10年以上前) だからUSBメモリだとかNFSだと、NFCでも書ける ただし他の人も書いてる通りライブラリでも強制してる CLIだと関係ない http://mevius.5ch.net/test/read.cgi/tech/1723861080/303
304: デフォルトの名無しさん [] 2025/05/08(木) 03:01:55.71 ID:US+UAC1U ちなみにライブラリで必ずやることに変えれば 規格準拠にしやすいと思う フル準拠にするとカーネルに入れるにはテーブルが大きすぎる けどじゃあPython処理系はどうするんだ osモジュールに担当させるのか osモジュールみたいな機構がない言語処理系ではどうするんだ とか色々大変 http://mevius.5ch.net/test/read.cgi/tech/1723861080/304
305: デフォルトの名無しさん [] 2025/05/08(木) 03:15:04.31 ID:US+UAC1U 要するにパス名正規化は無意味で無駄 http://mevius.5ch.net/test/read.cgi/tech/1723861080/305
306: デフォルトの名無しさん [sage] 2025/05/08(木) 12:28:18.82 ID:of3Q4Bd7 ちっぱいでもいいじゃん http://mevius.5ch.net/test/read.cgi/tech/1723861080/306
307: デフォルトの名無しさん [sage] 2025/05/08(木) 16:10:03.97 ID:n8dUtc6U >>305 いや正規化やっても良いんだよ ただしやるなら規格書どおりにやれ 勝手仕様でやられると対応に困る http://mevius.5ch.net/test/read.cgi/tech/1723861080/307
308: デフォルトの名無しさん [sage] 2025/05/08(木) 23:33:49.27 ID:pZAMgdYa 規格には則ってる 複数あって非互換なのが問題 http://mevius.5ch.net/test/read.cgi/tech/1723861080/308
309: デフォルトの名無しさん [sage] 2025/05/08(木) 23:40:58.88 ID:n8dUtc6U >>308 MacOS のやつは規格にあってないんだよ しったかすんな http://mevius.5ch.net/test/read.cgi/tech/1723861080/309
310: デフォルトの名無しさん [] 2025/05/08(木) 23:51:00.29 ID:US+UAC1U せめてNFCにしてればな 殆どの文書はNFCで構成されるんだから それでもUnicodeは規格がバージョンごとに違うからなあ 正規化が無駄な努力 http://mevius.5ch.net/test/read.cgi/tech/1723861080/310
311: デフォルトの名無しさん [sage] 2025/05/09(金) 02:29:43.44 ID:3ts3cFTs >>303 ファイルコピーとかするときは毎回、正規化の変換が発生する感じ? （不明な正規化）->（特定の正規化） ってのは問題ないんだっけ? 一方でファイルビューア（Finder)とか上の方はどのFS上にいるとか意識 したくないだろうからなあ。そこでも正規化の変換が起こるのかな? http://mevius.5ch.net/test/read.cgi/tech/1723861080/311
312: デフォルトの名無しさん [] 2025/05/09(金) 11:12:25.67 ID:oh4Slinf ファイルビューア ↓正規化 ファイルヒ゛ューア こんなのやだな http://mevius.5ch.net/test/read.cgi/tech/1723861080/312
313: デフォルトの名無しさん [sage] 2025/05/09(金) 12:07:16.82 ID:OoJ+JMZS EBCDICカナ文字の話みたい。 ごめんなさい、ごめんなさい、ごめんなさい。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/313
314: デフォルトの名無しさん [] 2025/05/09(金) 15:56:58.76 ID:yePfNbNe >>311 最近macOSは余り触ってないが昔は (様々な理由により以下の状況が起きて) ファイルビューア ファイルヒ゛ューア の両方がディレクトリにある場合に、Finder.appでは ファイルビューア ファイルビューア と表示され後者しかアクセス出来なかった Cocoaが正規化してユーザやカーネルに渡すから http://mevius.5ch.net/test/read.cgi/tech/1723861080/314
315: デフォルトの名無しさん [] 2025/05/13(火) 18:18:02.49 ID:El9a77up 字にはヒラギノール http://mevius.5ch.net/test/read.cgi/tech/1723861080/315
316: デフォルトの名無しさん [sage] 2025/07/20(日) 21:42:09.27 ID:v9zpB8iu Microsoft Print to PDFで出力したファイルからテキストをコピペしたら文字化けしてた…→実はPDFの仕様に潜む本質的な欠陥が原因なのでは？ https://togetter.com/li/2577928 http://mevius.5ch.net/test/read.cgi/tech/1723861080/316
317: デフォルトの名無しさん [sage] 2025/07/20(日) 22:29:37.55 ID:0FYiUEbf >>316 文字コードの問題ではなく単なるバグ より正確にいうと大昔からある PDF のフォントの使い方の問題 PDF はウェブと違って文字コードをデフォルトでは埋め込んでなくてフォント内の番号で直接埋め込んでる フィント番号と文字コードが1対1でマップしている保証はないのに、コピペの時はフォントに埋め込みの変換表で番号から文字コード生成する仕組になってる 複数の文字コードに同じフォントを割り当てているフォントを使うとこの問題が起きる http://mevius.5ch.net/test/read.cgi/tech/1723861080/317
318: デフォルトの名無しさん [sage] 2025/07/22(火) 01:09:42.93 ID:g3Tn7WHZ >>316 みたいな奴が参政党に投票する http://mevius.5ch.net/test/read.cgi/tech/1723861080/318
319: デフォルトの名無しさん [sage] 2025/07/22(火) 12:00:50.20 ID:Yl+nv6VH アドビはタイプセッター屋じゃけぇ、フォントファーストじゃけぇ http://mevius.5ch.net/test/read.cgi/tech/1723861080/319
320: デフォルトの名無しさん [sage] 2025/07/22(火) 12:55:59.74 ID:nZDCfJLI >>317 しかし1:1になるように、 つまり同じ字形が複数の文字コードで使われるなら、同じ字形のフォントを別登録してしまえば回避出来るのでは？ ならPDF出力ソフトが糞なだけ http://mevius.5ch.net/test/read.cgi/tech/1723861080/320
321: デフォルトの名無しさん [sage] 2025/07/22(火) 13:37:16.00 ID:bKhKMrtD >>320 そんなことしたらサイズが無駄にでかくなるだろ PDFがアホなのは同意だが、unicode普及以前の技術なのを思い出せ http://mevius.5ch.net/test/read.cgi/tech/1723861080/321
322: デフォルトの名無しさん [sage] 2025/07/22(火) 15:01:08.85 ID:yoaKkUTS >>321 大きくはなるが、1%も変わらんだろ、その文書で使った物だけそうすればいいのだし > unicode普及以前の技術なのを思い出せ unicode以外では特に問題なかったのなら、unicode側の問題であり、 unicodeをPDF化するときには数パーセント大きくなる、で済んだ話だろ お前がPDF嫌いなのは分かるが、技術的には、unicodeで仕様を拡大したのにPDF出力ソフトが対応出来てないだけだろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/322
323: デフォルトの名無しさん [sage] 2025/07/22(火) 19:20:34.51 ID:bKhKMrtD >>322 違うんだ。unicode その他の対応の拡張で PDF の仕様自体は更新されてるんだ でもその機能にちゃんと対応している pdf 作成ツールや pdf viewer が少ないだけなんだ 本家の Adobe で作成して Adobe で読めば問題なかったりするんだよ http://mevius.5ch.net/test/read.cgi/tech/1723861080/323
324: デフォルトの名無しさん [sage] 2025/07/22(火) 22:22:27.85 ID:yoaKkUTS >>323 となるとPDF側はすべき事はやってて、unicodeと糞ソフトの問題だな とはいえ今更本家からの統制は無理だし、 この問題を認識した上で各自が対応するしかなさそうだな (そういえば最近無駄にコピペさせないPDFが増えた気がするが、実は糞ソフト側のパッチ対応であったか) http://mevius.5ch.net/test/read.cgi/tech/1723861080/324
325: デフォルトの名無しさん [] 2025/07/24(木) 18:46:53.48 ID:bvlLnJ99 >>316 PDFの仕様が自由すぎるからだぞ？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/325
326: デフォルトの名無しさん [sage] 2025/07/24(木) 19:36:31.51 ID:Gx5EDFfz adobeはPDF2.0に対応したのか、やる気もないのか、とふと思った http://mevius.5ch.net/test/read.cgi/tech/1723861080/326
327: デフォルトの名無しさん [sage] 2025/07/24(木) 21:57:49.45 ID:PCIysLOC >>326 対応とは？ PDF-2.0 が何か知ってて言ってるのか？↓ http://mevius.5ch.net/test/read.cgi/tech/1723861080/327
328: デフォルトの名無しさん [sage] 2025/07/25(金) 01:59:47.04 ID:UKTPcfYB PDFはPostScriptがベースなんだけど、これは元々プリンタ出力のために設計されたもの 後は紙に印刷するだけって状態のデータだから文字コードなんて概念はない PostScriptの仕様をPDFに流用する時、検索ができないのは不便だからってんで グリフ番号→文字コードのマッピング表をPDFファイルに埋め込める仕組みを作った アプリがこの表を適宜生成しないと文字化けが発生する http://mevius.5ch.net/test/read.cgi/tech/1723861080/328
329: デフォルトの名無しさん [sage] 2025/07/25(金) 07:07:21.05 ID:yWMF+wv2 >>328 それで、unicode以外ではグリフと文字コードが1:1だから問題にならなかったのなら、 アプリ製作者がunicodeについて無知なのが原因だろう ただ、unicodeも無駄に冗長すぎるようにも見える K(0x212a:Kelvin sign)とか、K(0x4b:大文字K)が今までの全ての文書で使われてるのに今更どうしろと？ 今後「KをKに修正しろ」と誤字を指摘するKelvin警察が生まれるとウザい そして割と問題なのが、検索で引っかからなくなる事 検索時には区別しないのなら、最初から今まで通り同じフォントでよくね？だし unicodeが何を目指してどういう着地点を想定してるのかさっぱり分からん http://mevius.5ch.net/test/read.cgi/tech/1723861080/329
330: デフォルトの名無しさん [sage] 2025/07/25(金) 09:21:41.11 ID:5+UAzUxo >>329 元々の unicode は実践主義、御都合主義ともいう。 過去に別の文字として同時に実装された記録があれば別の文字として登録。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/330
331: デフォルトの名無しさん [sage] 2025/07/25(金) 11:08:12.46 ID:yWMF+wv2 >>330 つまり、あらゆる文字コードの上位セットにしてしまえば、文字コードを統一出来るとの考えか しかしこれだとあらゆる方言を内包する事になるので、おかしくなりかけてるのが今か どこかの自治体が「斉」の文字を外字で19種登録してたら、これもいつか実装されるというわけか (と思ったらもうあった、0x9f4a〜8文字のようだ) 仕様を適宜整理出来ず、ムダ仕様が膨らみ、メンテ不能になるのは、あるあるだけど、 unicodeもこの軌道に乗ってるな (もしかして欧米連中はこの辺の仕様の整理が上手くて、下手糞なCJKを混入したからおかしくなってるだけか？) http://mevius.5ch.net/test/read.cgi/tech/1723861080/331
332: デフォルトの名無しさん [sage] 2025/07/25(金) 14:05:16.33 ID:TViBdD0W >>331 戸籍／汎用電子情報交換環境／文字情報基盤の「斎」の変種のことなら unicode には IVD として全部登録されてる http://mevius.5ch.net/test/read.cgi/tech/1723861080/332
333: デフォルトの名無しさん [sage] 2025/07/25(金) 18:28:38.05 ID:yWMF+wv2 >>332 正式名称は知らんが、俺が言ってるのはそれだな ググったら総務省が音頭取ってやってるのか？色々出てきたが、 少なくとも規格化してから登録してるようだから、最低限の重複チェック等はあるはずで、まあ何とかなるのかな？ にしても検索どうするんだこれ？だし、 最近の絵文字の氾濫も、当初の想定からかなり逸脱してるのではないかと思うが http://mevius.5ch.net/test/read.cgi/tech/1723861080/333
334: デフォルトの名無しさん [sage] 2025/07/25(金) 19:02:45.52 ID:yWMF+wv2 と思ったが、IVSは直後に枝番付加する方式か まあ、比較的マシ、というか、真面目にやるならこれしかない程度には洗練されてる ちなみにこれ、実際のグリフを算出するにはどうするのだ？ 異体字が全部Exxxなようで、辞書引きするしかなく、それがIVDなのか？ というか各者の説明読む限り、845B+E0100指定すれば勝手にそれが出てくる的な書き方で、 もしかして「斉」のようにunicode側に独立したコードを割り当てておらず、 必ず元字＋枝番のセットで使うのが仕様か？(この方がいいが) http://mevius.5ch.net/test/read.cgi/tech/1723861080/334
335: デフォルトの名無しさん [sage] 2025/07/25(金) 19:10:28.15 ID:5+UAzUxo >>334 IVD は重複登録が許されてる。ソースが異なれば完全に同じ字形でも異なる IVS が与えられる（こともある） http://mevius.5ch.net/test/read.cgi/tech/1723861080/335
336: デフォルトの名無しさん [sage] 2025/07/26(土) 08:13:11.69 ID:PF0bui/v >>335 うむ、意図が分からん 「斉」は独立コ ードも与え、IVDにも登録、 「葛」は独立コー ドなし、IVDには登録、のようだから、仕様作ったやつが馬鹿だな 実装には結局両対応が必要となり、発注価格には1000万程度の上乗せが各社で必要となる 無能が仕様を作るとこういった糞仕様による目に見えづらい税金が発生するから、 仕様は最初にガッツリ決めようぜというのが欧米流だが、相変わらず日本はこの辺糞だな （大方やってるうちに足りなくなって途中で方針変更だろうが、これをやられると悲惨なことになる) > ソースが異なれば完全に同じ字形でも異なる IVS が与えられる（こともある） 検索でヒットする必要がなく、たまたま同じフォントで見た目が同じなだけだから、 プログラム側には全く問題ないだろうさ ただ、入力側が正しく入力できるかは大問題だろうけどさ 単一の文字コー ドを目指すかぎり、字体のみならず、コードの割り当て方の方言も内包することになるわけだな unicodeのバージョン管理って、完全上位互換?それとも後方互換切り捨て？ (例：16準拠の場合、15を完全に満たすのか、そうでないのか) C#のように上手く古い仕様を廃止していかないと、確実にどこかで破綻する気はする(か、そもそも実装してもらえないか) http://mevius.5ch.net/test/read.cgi/tech/1723861080/336
337: デフォルトの名無しさん [sage] 2025/07/26(土) 12:33:33.50 ID:JK5RKkw3 >>336 最近の仕様だけ見たら混乱するよな − もともとは同じ文字の別字形については昔の資産（unicode が作られるより前の20世紀の文字コード）にある文字だけ独立したコードポイントが割り当てられる方針だった − その後の他の字形も使いたい、実際に使ってる現場があるという要望に答えるために IVS が整備された − でもある文字と別の文字の字形が同じかどうかをフォント抜きで確実に判別する手段がないので字体表をそのまま IVD として登録していく方針にした − 中国政府が「 IVD とか知るか、独立したコードポイント割り当ててくれないんなら、自分たちで勝手に割り当ててオレオレ unicode の利用を中国国内では強制することにするがよろしいか？」 と言い出した − unicode 側が折れて漢字に関しては中国が要望してきた分に関してはIVDじゃなくて今後も全部に独立コードポイントが割り当てられることになった − 甲骨文字は漢字じゃないので独立コードポイントよこせって中国が言ってきたので漢字とは別に割り当てる予定 http://mevius.5ch.net/test/read.cgi/tech/1723861080/337
338: デフォルトの名無しさん [sage] 2025/07/26(土) 13:22:34.55 ID:IhScHI/D >>337 日本側の状況はさもありなん 全自治体の異体字をカバーする為にはIVS/IVDしかないので、最初からここを目指せればベストだったが 中国側の言い分は正直分からん、というか連中は日本政府以上に馬鹿だな 検索考えたらIVS/IVD方式の方が独立コード方式より断然いいのに とはいえ状況知らんが、簡体/繁体もある意味異体字だから、最早どうしようもないのかもしれんが > オレオレ unicode の利用を中国国内では強制することにする それは中国規格なので勝手にしろでいいと思うが > unicode 側が折れて となるのは、unicode陣営は統一コードの夢を見続けている、ということか なら、日本政府が、どうにもならないからやっぱ止めて新規格作ります、とか言いだしたら、(見る限りこの必要はないと思うが) 非関税障壁ガーで、足抜けは許さないコードヤクザになるわけだな まあ、検索考えたら独立コードになってるのも全部IVS/IVD方式に寄せた方がいい 現実的には入力後に独立コード→IVS/IVDに変換してDB登録すれば実害はあまりない 可能であればさっさと独立コードになってる物を仕様から落とすべきだが、これは難しいのだろうね http://mevius.5ch.net/test/read.cgi/tech/1723861080/338
339: デフォルトの名無しさん [sage] 2025/07/27(日) 09:27:25.30 ID:y0cxqRG2 >>328 >PDFはPostScriptがベースなんだけど、これは元々プリンタ出力のために設計されたもの >後は紙に印刷するだけって状態のデータだから文字コードなんて概念はない これはひどい http://mevius.5ch.net/test/read.cgi/tech/1723861080/339
340: デフォルトの名無しさん [sage] 2025/07/27(日) 09:52:00.68 ID:s52NuiMb >>339 酷くはない その当時はそれでも素晴らしかったから普及した そして実際、unicode以前は完全に機能していたわけだし どちらかというとunicodeが既存技術に対してかなり異端で、 当然アプリは別対応が求められるが、それが適切に為されていない場合、誤動作してるだけ Adobe謹製環境では動作してるのなら、Adobe側がこれ以上できることはない http://mevius.5ch.net/test/read.cgi/tech/1723861080/340
341: デフォルトの名無しさん [] 2025/07/27(日) 10:08:59.26 ID:4jy4lfp7 >>336 単純な例で カ と 力 だな こんなの一緒にされたら困る http://mevius.5ch.net/test/read.cgi/tech/1723861080/341
342: デフォルトの名無しさん [sage] 2025/07/27(日) 10:52:09.39 ID:s52NuiMb >>341 ソース違いで自体が同じ例か？ カと力は、何か変だと気づく程度には字形も微妙に違い、怪しい中華の説明書で間違って使われる程度だろ 問題になるのは全角チルダと波ダッシュとか、あと伸ばし棒も何種類かあって、 これらは日本人でも割とデタラメに使っているので、検索に引っかからなくなって困る だから、unicodeのCJK統合漢字＝見た目が同じなら同じ文字、は、 検索の結果がユーザーにも予期出来る、という意味では正しい思想で、 逆に、同じ字体にも違うコードを割り付け、『ユーザーが正しくそれらを使い分けられない場合』、どうにもならなくなる この辺の思想が、unicodeは徹底出来ていない http://mevius.5ch.net/test/read.cgi/tech/1723861080/342
343: デフォルトの名無しさん [sage] 2025/07/27(日) 15:00:47.82 ID:xJMx5cyL >>340 そうじゃない PostScriptと当時のフォントの詳細をほとんど知らないだろ? だから妄想で適当なことを書く、酷いのはお前だ ってこのぐらい書けばわかるんかな http://mevius.5ch.net/test/read.cgi/tech/1723861080/343
344: デフォルトの名無しさん [sage] 2025/07/27(日) 15:43:44.47 ID:s52NuiMb >>343 PostScript以前はプリンタによって出力結果が異なっていた為、 ファイルを渡しても印刷結果が異なる事が普通だった (だから厳密にやるには紙でやりとりするしかなかった) これに対し、PostScriptだとどのプリンタでも見た目の出力結果が同じ為、 あっという間にデファクトスタンダードをとった PostScriptはベジエなフォントをプリンタでラスタライズする だからフォントを埋め込めば、同じ見た目の出力になる 以前のプリンタは、プリンタ内蔵のビットマップフォントを印刷してたか、 PCから送られてくるラスタデータを印刷してたかなので、環境によって印刷結果が異なっていた (なおその後PostScriptが若干落ち目なのは、特許料金が高いのと、 プリンタ上で処理する仕組み上、プリンタ側にそこそこのCPUが必要となり、プリンタ代が高くなるから) PDFはPostScriptをバイナリ化したものなので、基本思想はPostScriptから引き継いでいる 当時は(今もだが)WordもExcelも有料であり、その他のソフトも、全員が確実に持っている物はなかった AdobeはPDFの生成は有料だが、開くだけなら無料(AcrobatReaderは無料)という方針で、 あらゆる人に対して確実に読める環境を提示した為、PDFもあっという間に普及した MSがWord/Excelのリーダーを無料で提供したのはその後 俺が知ってる概略はこんな所だ PostScriptも、PDFも、当時としては素晴らしかったし、完全に機能してたよ (今でも十分素晴らしいとも思うが) ぼくはおまえよりしってるんだ！！！とか要らんから、最初から知ってる事書けばいいと思うけどね はいどうぞ http://mevius.5ch.net/test/read.cgi/tech/1723861080/344
345: デフォルトの名無しさん [] 2025/07/27(日) 16:00:29.88 ID:IiX+k+fy >PDFはPostScriptをバイナリ化したもの doubt http://mevius.5ch.net/test/read.cgi/tech/1723861080/345
346: デフォルトの名無しさん [sage] 2025/07/27(日) 16:39:24.93 ID:gwhcenFf PSはプログラム言語でPDFは描画データ 門外漢のオレの理解はここまで http://mevius.5ch.net/test/read.cgi/tech/1723861080/346
347: デフォルトの名無しさん [sage] 2025/07/27(日) 16:40:00.92 ID:s52NuiMb >>345 ああ確かに、asciiと言った方が近いようだな ただそんな関係ない所ではなく、本筋の、 > PostScriptと当時のフォントの詳細 に(自称)詳しい人から見て > 酷い と考える根拠を述べよ、だな 俺は、PostScriptもPDFも素晴らしかったから普及した、だから全く酷くない、と考える根拠を344で述べた 実際これで現在も機能してるんだから、文字コードの概念はPostScriptとPDFには不要だったという証明になってるし unicodeが色々おかしくしただけだよ http://mevius.5ch.net/test/read.cgi/tech/1723861080/347
348: デフォルトの名無しさん [sage] 2025/07/28(月) 09:30:10.58 ID:BMbzFeOA https://www.adobe.com/jp/creativecloud/file-types/image/vector/ps-file.html PostScriptとPDFの違いは何ですか？ PDFは、PSファイルの後継形式で、webと印刷の両方で最も広くサポートされているもののひとつです。ただし、PDFは表示形式であり、簡単には編集できませんが、PostScriptはプリンター制御言語であり、そのコード内でデザイン要件を伝達する機能があるため、印刷の可能性が広がります。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/348
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.018s