文字コード総合スレ part15 (470ﾚｽ)
上下前次1-新
202(1): 01/20(月)22:26 ID:fw0guZsp(2/5) AAS
何度も書いてるじゃないですか
サロゲートの片方だけなWTF-8同士を結合するとサロゲートペアが揃ってしまって本来あるべき形の別表現となるでしょ
その状態で比較等をすると狂いが生じる話
203: 01/20(月)22:44 ID:SnLzVhb4(2/2) AAS
>>202
wtf16の1文字(16bit値)とwtf8の1文字が可逆対応だよ
それぞれ結合してN文字同士になっても可逆対応だよ
別表現なし
何を問題視しているのかな
204(3): 01/20(月)22:51 ID:uZ5HVjRv(1/3) AAS
WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない
UTF-8 のように単純に結合することできない
両サロゲートが含まれてるものはWTF-8ではない
205(1): 01/20(月)23:00 ID:fw0guZsp(3/5) AAS
>>204
そうそうそれそれ。ようやく話が通じそうな人が来てくれた
で、現実には？と
206(2): 01/20(月)23:18 ID:uZ5HVjRv(2/3) AAS
>>205
片サロゲートはユニコード的には文字コードではないので片サロゲートの結合をどう処理するかは実装依存
捨てる、未定義文字に置き変える、文字だったことにしてUTF-8変換する、なんかのセパレータを挟むとかできるかもしれない
でも一般的と思われるのは結合処理自体をエラーで失敗させる
WTF-8 にも UTF-8 にも冗長性はない、WTF-8 を UTF-8 と同じように使ってはいけないだけ、両者は別物
207(1): 01/20(月)23:19 ID:fFffNKjx(7/9) AAS
>>204
そこで問題は生じない
WTF-8の2つの文字(列)の結合は
個別にWTF-16へ変換してからWTF-16として結合してそれをWTF-8へ変換したもの
と同等になるように処理が定義されている
つまり結合後も必ずWTF-8とWTF-16は1対1に対応する
WTF-8の2つの文字(列)をAとBとし結合を+で表すと
A + B ≡ to-WTF-8(to-WTF-16(A) + to-WTF-16(B))
が常に成り立ち1対1に可逆が保証される
別の冗長表現は生じない
208(1): 01/20(月)23:26 ID:uZ5HVjRv(3/3) AAS
>>206
一応補足しておくと、エラーなどの処理するのは結合時点でなくて、それを何か使おうとしたり、他の文字コードに変換しようとした時点とすることもできる
Invalid な WTF-8 のチェックをどの時点でするかだけの問題
209(3): 01/20(月)23:27 ID:fw0guZsp(4/5) AAS
>>206
OSがファイル名として扱えるバイナリ列を作れないのはむしろそちらのほうが問題になるので
失敗させるのはナシでは
>>206-207
で、今ソースを追いかけていてpushに関しては
外部ﾘﾝｸ[html]:stdrs.dev
で>>204の処理がなされてるのを確認しました
つまりpushに関しては俺の杞憂でした(もちろん他の処理は別)
210: 01/20(月)23:35 ID:fw0guZsp(5/5) AAS
>>208
他言語のStringBuilder等ならそうだけど
OsStringには直接の比較関数等もあるので結合時点以外に選択肢は無いと思う
211: 01/20(月)23:45 ID:fFffNKjx(8/9) AAS
>>209
それは任意の16bit列に対応するWTF-8を作れるようになっているのでその場合も対応できて大丈夫
use std::os::windows::ffi::OsStringExt
OsString::from_wide(wide: &[u16])
つまりWTF-16⇔WTF-8は必ず1対1に対応するため別の冗長表現は生じず問題は起こらない
212(1): 01/20(月)23:52 ID:fFffNKjx(9/9) AAS
つまり話をまとめると
WTF-8の新規生成はUTF-8もしくはWTF-16(＝任意の16bit列)からのみ生成できるため常にWTF-16と1対1に対応する
WTF-8の結合は個別にWTF-16にしてから結合してWTF-8に戻した処理と同等と定義されているため常にWTF-16と1対1に対応する
したがって問題が発生する箇所はない
213: 01/21(火)00:05 ID:HFAykEjr(1/7) AAS
>>212
異論というわけじゃないが、そもそもWTF-16どうしをそのまま結合して良いかというと必ずしもそうではない
WTF-16をそのまま結合して許される条件下まらWTF-8の結合を終端でサロゲートが並んだらUTF-8変換するというのは間違ってないけど
まあどっちにしろ正しく処理すれば冗長性はない
214: 01/21(火)00:39 ID:HFAykEjr(2/7) AAS
ファイル名に文字ではないゴミが含まれている → 実際に含まれているだから仕方ないOSの問題
ゴミとゴミをくっつけると文字になる → OSの問題でも文字コードの問題でもない、許すかどうかはアプリの問題
215(1): 01/21(火)00:52 ID:HFAykEjr(3/7) AAS
ゴミの結合をして文字になることを許すと冗長性とは別のセキュリティホールになることがある
文字のフィルターとかで文字列Aにも文字列Bにも含まれてないことを確認した文字が A+B に含まれるかもしれない
これは最近に始まったことではなくて SJIS
とか EUC-JP とかでもあった問題で、セキュリティ要件ではゴミの単純な結合は許さないのがベスト・プラクティス
216(1): 01/21(火)01:27 ID:cx2WozxM(1) AAS
いずれにせよRustの文字列処理には何ら問題なくて
WTF-8の処理にも何ら問題ないことがわかったのだから
最初の書き込みのこの人が間違っていたな
>>177
>>RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8で脆弱性が引き起こされないことも今回はっきりした
あとはもし何かあるとすればWindows側の問題のみ
217(1): 01/21(火)06:06 ID:/BTcOxxh(1) AAS
Rustは何も解決してないのにWTF-8型で解決したかの様な振る舞い勘違いが一番質が悪い
その意味で>>177は的を射ている
>>216は>いずれにせよ..., で誤魔化さないでまき散らした勘違いを訂正しないとな
例えば>>195
> WTF-8⊃UTF-8となる
など
218: 01/21(火)07:33 ID:CGf2GAkC(1/3) AAS
>>217
ウソはいかんよ
Rustは正しく解決している
>>177氏は冗長表現ができると勘違いしていた
冗長表現は原理的に不可能だ
そして誰もその生成プログラム例を示せなかった
WTF-8⊃UTF-8は定義から当たり前の話であるとともに
この性質によりUTF-8からWTF-8へはエラーなく常に変換できる
219(1): 01/21(火)07:42 ID:4+X4XnDl(1/2) AAS
まあ抽象的なコードポイントの話じゃなくて、エンコーディングの話、例えば
> WTF-16(＝任意の16bit列)
と言ってるから
> WTF-8⊃UTF-8となる
も8bit列を意図してるのなら、成り立たないな。
WTF-8に関しては、WTF-8(＝任意の16bit列)ではなくて、
絵文字などをUTF-8エンコードした8bit列は、WTF-8では不正な8bit列となる。
220: 01/21(火)07:43 ID:4+X4XnDl(2/2) AAS
訂正
WTF-8に関しては、WTF-8(＝任意の8bit列)ではなくて、
221(1): 01/21(火)08:02 ID:CGf2GAkC(2/3) AAS
>>219
>>絵文字などをUTF-8エンコードした8bit列は、WTF-8では不正な8bit列となる。
それは君が勘違いしてるよ
UTF-8エンコードした8bit列は必ず有効なWTF-8になるが正しい
反論があるならUTF-8がWTF-8とならない場合のプログラム例を出そう
222(1): 01/21(火)08:06 ID:6E3WwSvm(1) AAS
>>221
それを含めた時が冗長性誕生の瞬間である
223: 01/21(火)08:11 ID:CGf2GAkC(3/3) AAS
>>222
冗長表現となる事例とその生成プログラム例を出そうよ
世界中で誰も示せていないよ
224(1): 01/21(火)08:59 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対応 → ○
基本が分かってないやつがいるので議論が噛み合ってないだけのようだ
225: 01/21(火)09:11 ID:nn8C9EMv(1) AAS
>>224
> 基本が分かってないやつ
ごめんごめんWTF-8の定義見て来た。
あと>>209見て明らかな脆弱性はないと納得した。
pushでsurrogate pairになってもself.is_known_utf8 = falseにしてるんだな。
226: 01/21(火)09:23 ID:snb5MXpj(1) AAS
WTF-8に冗長表現は起きず脆弱性はないね
冗長が起きると書き込んでる人は、理解できずに間違った思い込みをしているのか、悔しくてデマを繰り返してるのか、わからんけどさ
冗長表現を生成する具体例を一つ示せば済むのに、ここまで来ても一つも示せていない
227: 01/21(火)10:25 ID:uiolM7XA(1) AAS
帰れ
228(2): 01/21(火)11:37 ID:q2HQSFd2(1) AAS
>>215の言うAにもBにも含まれない「文字」がA+Bに含まれるかもしれない問題、
処理の正しさの観点では(脆弱性の話は置いておいて)
NFC/NFDやIVS/IVD/ZWJ絡みで(well formed UTF-8同士の範囲でも)発生する気がするけど
実際にA+Bを作ってからチェックするのが鉄則なのか？
「文字」じゃなくて「文字列」ならA+Bを作るのが普通と思う
(それと正規表現なら部分マッチが出来たりする)
229: 01/21(火)12:16 ID:HFAykEjr(5/7) AAS
>>228
結合文字とか変種指定は機能性の問題なのでさらに一段回上のレイヤーの要件だな
「が」と「か＋結合濁点」を同じとみなすか別とみなすかは目的による（文字コード的にはどちらもありえる
230: 01/21(火)12:47 ID:mXSJj++Z(1) AAS
そんなの要件定義考慮漏れで溢れかえってる
何かあったら現状を仕様にする
231(1): 01/21(火)16:35 ID:3Vt9EG/U(1) AAS
ライブラリ側に問題がないとはいえ過信はよろしくない
OsStringでは機能が足りず中身を取り出しての直接処理はよくやられてるし
余計な変換をかましてるせいで考慮することが増えてしまってる一方でアプリ側にはWindowsの特殊事情なんて考慮してないコードも山ほどあろう
上下前次1-新書関写板覧索設栞歴
あと 239 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.009s