文字コード総合スレ part15 (470ﾚｽ)
上下前次1-新
187: 01/18(土)11:36 ID:CaguG0TX(6/7) AAS
もう自分が何書いてるかもわかってなさそう
もう一度読んで？
188(1): 01/18(土)11:44 ID:rGNNXTeE(1/2) AAS
横通ります
Rustではディレクトリを開いてスキャンしたら各ファイル名はWTF-8とやらのスライスなのか？
189(1): 01/18(土)11:46 ID:rGNNXTeE(2/2) AAS
それとLinuxのファイルシステム自体もUTF-8文字コードを外れてもOKだから、Windowsに限った話ではないかと
LTF-8もあるのか？
190(2): 01/18(土)12:03 ID:CaguG0TX(7/7) AAS
>>188-189
型としてはOsStringとしてラップされてて、中身を取り出したらWindowsではWTF-8
不正な文字コードが入りうるのはどのOSでも同じだけどバイト列そのままな他OSと異なりWindowsだとUTF-16との変換も挟まって危なそうだなあって
(ちなmacOSやあとBSDのzfsなんかだと不正な文字コードは最初から入らないらしい？)
191: 188-189 01/18(土)12:30 ID:ZXpOcGU5(1) AAS
>>190
なるほどね納得
不正な文字コードに遭遇したら処理を進めないで即座にエラーにするが良さそう
問題は処理系がちゃんと不正な文字コードを感知するかどうかだけど、
WindowsでA系APIを使っていれば(RawワイドストリングのUTF-16解釈が試みられて)
不正なパラメータエラーとかで(ディレクトリスキャン時などの)早期に発見できそうな気がする
192: 01/18(土)12:32 ID:ryxfYm1H(5/5) AAS
なんだろうな？
UTF-8: 片サロゲートも両サロゲートも不可
WTF-8: 片サロゲートのみ可、両サロゲートは不可
CESU-8: サロゲート展開必須
という区別がちゃんとついてるんだろうかという疑問、これら混ぜれば冗長だが…
単独で冗長と言われても具体性がない
193: 01/20(月)21:45 ID:fFffNKjx(1/9) AAS
勘違いしてる人がいるため正しい情報
まずRustの文字列つまりstr型とString型はvalidなUTF-8のみであることが必ず保証されている
そこには当然サロゲートもなければinvalidなUTF-8もないため問題は一切起きない
そこにWTF-8など他のものが混ざることも絶対にない
つまりどんな文字列操作をしても冗長表現のない
validなUTF-8となる安全が保証されている
つづく
194: 01/20(月)21:46 ID:fFffNKjx(2/9) AAS
次に言語とは関係ない話
validなUTF-16は必ずサロゲートがペアとして対応するが
それに対してWindowsのUTF-16パス名などあちこちの環境でinvalidなUTF-16が使われている
つまり単なる16bitコード列として任意のものが通るinvalidなUTF-16を名付けてWTF-16と呼ぶ
UTFを擬してWTFはWobbly Transformation Formatの略である
集合としてはinvalidなものを含む分だけ大きくてWTF-16⊃UTF-16となる
つづく
195(1): 01/20(月)21:47 ID:fFffNKjx(3/9) AAS
UTF-16⇔UTF-8は常に可逆に変換できる
前述のWTF-16に対しても同様に可逆となるものとしてWTF-8が考えられる
つまりWTF-16⇔WTF-8は常に可逆に変換できる
前述のWTF-16⊃UTF-16と同様に
WTF-8⊃UTF-8となる
このWTF-8はあくまでもWTF-16との可逆を保証するための内部表現であり外で使われることはない
つづく
196: 01/20(月)21:48 ID:fFffNKjx(4/9) AAS
このWTF-8には以下の利点がある
・WTF-16(＝任意の16bit列)と可逆に1対1に変換できる
・元のWTF-16がUTF-16のみの場合は対応するWTF-8はUTF-8のみとなる
・特に元がアスキー文字のみならば対応するWTF-8は7bitアスキー文字となる
集合関係はWTF-8⊃UTF-8⊃7bitアスキー文字となる
つまり内部表現として非常に使い勝手が良いものとなっている
つづく
197: 01/20(月)21:49 ID:fFffNKjx(5/9) AAS
そしてようやく再びRustの話
Rustでは言語の外の世界とをつなぐFFI (Foreign Function Initerface)の一つとして
OS環境依存の文字列型としてOsString型とOsStr型がある
これはvalidなUTF-8文字列型であるString型とstr型にそれぞれ対応する
集合的にはOsString⊃StringとOsStr⊃strとなりinvalidなUTF-8を含む分だけ大きな集合を表す
Windows環境ではこの内部表現として前述のWTF-8が使われている
つづく
198(1): 01/20(月)21:50 ID:fFffNKjx(6/9) AAS
>>177 >>190
WTF-8を新たに作り出すにはvalidなUTF-8から作るか
あるいは16bit列から作るかのどちらかしか手段がない
つまり必ずWTF-16(＝任意の16bit列)⇔WTF-8は1対1に対応する
したがってあなたが主張する
「別の冗長表現」は生じることはなく危険なことは絶対に起こらない
199: 01/20(月)22:03 ID:SJIxPBxD(1) AAS
Rustスレから出てこないで欲しいなあ
200: 01/20(月)22:15 ID:fw0guZsp(1/5) AAS
>>198
普通に結合で新しくOsStringを作ってる例がありますやん
外部ﾘﾝｸ[html]:doc.rust-lang.org
201: 01/20(月)22:20 ID:SnLzVhb4(1/2) AAS
utf8とutf8を結合しても必ずutf8となるように
wtf8とwtf8を結合しても必ずwtf8だね
何を問題視しているのかな
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側の問題のみ
上下前次1-新書関写板覧索設栞歴
あと 254 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.008s