文字コード総合スレ part15 (410ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
213: デフォルトの名無しさん [sage] 2025/01/21(火) 00:05:41.71 ID:HFAykEjr(1/7) AAS
>>212
異論というわけじゃないが、そもそもWTF-16どうしをそのまま結合して良いかというと必ずしもそうではない
WTF-16をそのまま結合して許される条件下まらWTF-8の結合を終端でサロゲートが並んだらUTF-8変換するというのは間違ってないけど
まあどっちにしろ正しく処理すれば冗長性はない
214: デフォルトの名無しさん [sage] 2025/01/21(火) 00:39:07.85 ID:HFAykEjr(2/7) AAS
ファイル名に文字ではないゴミが含まれている → 実際に含まれているだから仕方ないOSの問題
ゴミとゴミをくっつけると文字になる → OSの問題でも文字コードの問題でもない、許すかどうかはアプリの問題
215(1): デフォルトの名無しさん [sage] 2025/01/21(火) 00:52:01.60 ID:HFAykEjr(3/7) AAS
ゴミの結合をして文字になることを許すと冗長性とは別のセキュリティホールになることがある
文字のフィルターとかで文字列Aにも文字列Bにも含まれてないことを確認した文字が A+B に含まれるかもしれない
これは最近に始まったことではなくて SJIS
とか EUC-JP とかでもあった問題で、セキュリティ要件ではゴミの単純な結合は許さないのがベスト・プラクティス
224(1): デフォルトの名無しさん [sage] 2025/01/21(火) 08:59:02.25 ID:HFAykEjr(4/7) AAS
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対応 → ○
基本が分かってないやつがいるので議論が噛み合ってないだけのようだ
229: デフォルトの名無しさん [sage] 2025/01/21(火) 12:16:20.66 ID:HFAykEjr(5/7) AAS
>>228
結合文字とか変種指定は機能性の問題なのでさらに一段回上のレイヤーの要件だな
「が」と「か＋結合濁点」を同じとみなすか別とみなすかは目的による（文字コード的にはどちらもありえる
232: デフォルトの名無しさん [sage] 2025/01/21(火) 17:20:43.69 ID:HFAykEjr(6/7) AAS
>>231
だから最初から WTF-8 は UTF-8 とは別物
混同したら問題、混同しなければ問題はない
UTF-8 ではサロゲート断片は許されない
WTF-8 ではサロゲートの片側だけ許されるがそのせいで追加の処理が必要
冗長性うんぬんを言い出すのはこの違いが分かってないやつという話題だろ
236: デフォルトの名無しさん [sage] 2025/01/21(火) 22:03:34.94 ID:HFAykEjr(7/7) AAS
Rust の OsString という基準だと Linux とかだと任意のバイト列なんでそっちがもともとの形だな
たまたま Windows 版で効率考えて WTF-8 変換したものを使ってるだけ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.020s