文字コード総合スレ part15 (413レス)
前次1-
抽出解除 レス栞

リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
73
(3): デフォルトの名無しさん [] 2024/11/10(日) 02:50:29.80 ID:NcxfIIMm(1) AAS
>>70
「U+」の部分はUTF-8だという意味
111
(3): デフォルトの名無しさん [sage] 2024/12/05(木) 16:18:11.64 ID:riH9D2sC(1) AAS
ファイル名がユニコードだと、
例えば2つのファイル名が同一かどうかの判定は、2つのユニコード列が同一かどうかの
判定をしなくてはならない。この場合の同一とはなんだろう。めんどくさい
177
(5): デフォルトの名無しさん [sage] 2025/01/18(土) 03:52:04.02 ID:CaguG0TX(1/7) AAS
RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう
204
(3): デフォルトの名無しさん [sage] 2025/01/20(月) 22:51:08.98 ID:uZ5HVjRv(1/3) AAS
WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない
UTF-8 のように単純に結合することできない
両サロゲートが含まれてるものはWTF-8ではない
209
(3): デフォルトの名無しさん [sage] 2025/01/20(月) 23:27:17.08 ID:fw0guZsp(4/5) AAS
>>206
OSがファイル名として扱えるバイナリ列を作れないのはむしろそちらのほうが問題になるので
失敗させるのはナシでは

>>206-207
で、今ソースを追いかけていてpushに関しては
https://stdrs.dev/nightly/x86_64-pc-windows-gnu/src/std/sys_common/wtf8.rs.html#337-359
>>204の処理がなされてるのを確認しました
つまりpushに関しては俺の杞憂でした(もちろん他の処理は別)
316
(3): デフォルトの名無しさん [sage] 2025/07/20(日) 21:42:09.27 ID:v9zpB8iu(1) AAS
Microsoft Print to PDFで出力したファイルからテキストをコピペしたら文字化けしてた…→実はPDFの仕様に潜む本質的な欠陥が原因なのでは?
https://togetter.com/li/2577928
317
(3): デフォルトの名無しさん [sage] 2025/07/20(日) 22:29:37.55 ID:0FYiUEbf(1) AAS
>>316
文字コードの問題ではなく単なるバグ
より正確にいうと大昔からある PDF のフォントの使い方の問題

PDF はウェブと違って文字コードをデフォルトでは埋め込んでなくてフォント内の番号で直接埋め込んでる
フィント番号と文字コードが1対1でマップしている保証はないのに、コピペの時はフォントに埋め込みの変換表で番号から文字コード生成する仕組になってる
複数の文字コードに同じフォントを割り当てているフォントを使うとこの問題が起きる
328
(3): デフォルトの名無しさん [sage] 2025/07/25(金) 01:59:47.04 ID:UKTPcfYB(1) AAS
PDFはPostScriptがベースなんだけど、これは元々プリンタ出力のために設計されたもの
後は紙に印刷するだけって状態のデータだから文字コードなんて概念はない

PostScriptの仕様をPDFに流用する時、検索ができないのは不便だからってんで
グリフ番号→文字コードのマッピング表をPDFファイルに埋め込める仕組みを作った
アプリがこの表を適宜生成しないと文字化けが発生する
336
(3): デフォルトの名無しさん [sage] 2025/07/26(土) 08:13:11.69 ID:PF0bui/v(1) AAS
>>335
うむ、意図が分からん
「斉」は独立コ
ードも与え、IVDにも登録、
「葛」は独立コー
ドなし、IVDには登録、のようだから、仕様作ったやつが馬鹿だな
実装には結局両対応が必要となり、発注価格には1000万程度の上乗せが各社で必要となる
無能が仕様を作るとこういった糞仕様による目に見えづらい税金が発生するから、
仕様は最初にガッツリ決めようぜというのが欧米流だが、相変わらず日本はこの辺糞だな
(大方やってるうちに足りなくなって途中で方針変更だろうが、これをやられると悲惨なことになる)

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

単一の文字コー
ドを目指すかぎり、字体のみならず、コードの割り当て方の方言も内包することになるわけだな
unicodeのバージョン管理って、完全上位互換?それとも後方互換切り捨て?
(例:16準拠の場合、15を完全に満たすのか、そうでないのか)
C#のように上手く古い仕様を廃止していかないと、確実にどこかで破綻する気はする(か、そもそも実装してもらえないか)
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.048s