文字コード総合スレ part15 (413ﾚｽ)
文字コード総合スレ part15 http://mevius.5ch.net/test/read.cgi/tech/1723861080/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
73: デフォルトの名無しさん [] 2024/11/10(日) 02:50:29.80 ID:NcxfIIMm >>70 「U+」の部分はUTF-8だという意味 http://mevius.5ch.net/test/read.cgi/tech/1723861080/73
111: デフォルトの名無しさん [sage] 2024/12/05(木) 16:18:11.64 ID:riH9D2sC ファイル名がユニコードだと、 例えば2つのファイル名が同一かどうかの判定は、２つのユニコード列が同一かどうかの 判定をしなくてはならない。この場合の同一とはなんだろう。めんどくさい http://mevius.5ch.net/test/read.cgi/tech/1723861080/111
177: デフォルトの名無しさん [sage] 2025/01/18(土) 03:52:04.02 ID:CaguG0TX RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな… WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう http://mevius.5ch.net/test/read.cgi/tech/1723861080/177
204: デフォルトの名無しさん [sage] 2025/01/20(月) 22:51:08.98 ID:uZ5HVjRv WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない UTF-8 のように単純に結合することできない 両サロゲートが含まれてるものはWTF-8ではない http://mevius.5ch.net/test/read.cgi/tech/1723861080/204
209: デフォルトの名無しさん [sage] 2025/01/20(月) 23:27:17.08 ID:fw0guZsp >>206 OSがファイル名として扱えるバイナリ列を作れないのはむしろそちらのほうが問題になるので 失敗させるのはナシでは >>206-207 で、今ソースを追いかけていてpushに関しては ttps://stdrs.dev/nightly/x86_64-pc-windows-gnu/src/std/sys_common/wtf8.rs.html#337-359 で>>204の処理がなされてるのを確認しました つまりpushに関しては俺の杞憂でした(もちろん他の処理は別) http://mevius.5ch.net/test/read.cgi/tech/1723861080/209
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
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
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
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.029s