文字コード総合スレ part15 (406ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
27(1): デフォルトの名無しさん [] 2024/09/02(月) 20:00:21.60 ID:Mm7rASpk(1) AAS
UTF-8で見た目が同じものを二重に定義してしまった。
①～⑩までは昔からあるが、丸0と丸11以降を作り出してしまい、環境依存がさらに進んでいる。
185: デフォルトの名無しさん [] 2025/01/18(土) 11:27:52.60 ID:7Jaib8zo(1) AAS
m1Hは馬鹿ちんちん
215(1): デフォルトの名無しさん [sage] 2025/01/21(火) 00:52:01.60 ID:HFAykEjr(3/7) AAS
ゴミの結合をして文字になることを許すと冗長性とは別のセキュリティホールになることがある
文字のフィルターとかで文字列Aにも文字列Bにも含まれてないことを確認した文字が A+B に含まれるかもしれない
これは最近に始まったことではなくて SJIS
とか EUC-JP とかでもあった問題で、セキュリティ要件ではゴミの単純な結合は許さないのがベスト・プラクティス
251(1): デフォルトの名無しさん [sage] 2025/01/25(土) 14:44:40.60 ID:6/VZHgMn(1/3) AAS
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それ自体が脆弱性の根源になることはなくても、こうしたややこしさが誤った使い方、ひいては脆弱性を生むことはあるかもしれないとは思った
279: デフォルトの名無しさん [sage] 2025/01/31(金) 20:57:03.60 ID:h9+hJoTP(1) AAS
技術的に無理な仕様作ったん？
294: デフォルトの名無しさん [] 2025/04/07(月) 21:43:17.60 ID:1UVr/FZP(1) AAS
濁点と半濁点が別の文字だと認識しているのはおかしい
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s