文字コード総合スレ part15 (470ﾚｽ)
上下前次1-新
162: 01/11(土)16:50 ID:SJ4Pziuh(1) AAS
これを機に932以外では文字化けするレガシーアプリは駆逐されれば良い
163: 01/11(土)17:11 ID:MN266Dik(2/4) AAS
>>161
ファイル名の禁則レベルでは無理
Unicode の一部の文字がバックスラッシュとか空白とかクォートとかの区切り文字や特殊処理する文字に化けるので、これを利用して入力を誤魔化せるという技
どう化けるかはコードページ次第
全部のアプリがユニコード対応になるか Windows が BestFit やめない限りは多くのアプリで同様の問題が量産される（オープンソース系のアプリはこれはOSの仕様のせいでアプリのバグじゃないので直すつもりはないとか言ってる）
UTF-8だとBestFit使われないので Windows 12 とかで SJIS とか Win-1521 とか捨ててデフォルトが UTF-8 になれば解決するけど
164(1): 01/11(土)17:17 ID:IZON3iKr(3/3) AAS
システムをUTF-8に設定した上で、
CP932なアプリについて、個別のマニフェストの"activeCodePage"を"CP932"することで使えるようにならないんだろうか？
165: 01/11(土)17:23 ID:MN266Dik(3/4) AAS
>>164
今のところできないし、できたとしてもその cp932 に設定したプログラムで BestFit による抜け穴が使われるリスクがある
166(1): 01/11(土)17:41 ID:8GlegYBS(2/2) AAS
ファイル名に英数字以外禁止したら何とかなりそうな気はした
167: 01/11(土)17:49 ID:MN266Dik(4/4) AAS
>>166
ファイル名だけじゃないから
コマンドのオプションスイッチとか、URL とか、環境変数とか、レジストリとか、とにかくプログラムの入力全部
168: 01/11(土)22:53 ID:ftPdDy1W(3/4) AAS
Windows全然詳しくないんだけど、Windows APIのANSI APIとUnicode APIとの違いって
標準Cライブラリの文字出力で言えばprintfとwprintfとの違いってことだよね?
世の中のOSSのほとんどはwprintf等のワイド文字関数なんて使っていないんだから
OSSをWindowsで動かした場合ほぼ全部WorstFitの影響を受けることになるはず
今後基本的にワイド文字関数で書くべきってなると、Hello Worldは
#include <stdio.h>
#include <locale.h>
#include <wchar.h>
int main(int argc, char **argv)
{
setlocale(LC_ALL, "");
wprintf(L"こんにちは世界\n");
}
こうすべきってこと?
169: 01/11(土)23:28 ID:ftPdDy1W(4/4) AAS
あ、
int main(int argc, char **argv)
エントリーポイントの時点で引数がワイド文字じゃないから脆弱性の影響を受ける可能性があるのか
wmainがあるのはそういう理由なのね
170(1): 01/12(日)08:20 ID:xo4UH4ro(1) AAS
MS的には「いまだにワイド文字列使ってないアプリが悪い」なんだよな
171: 01/12(日)11:43 ID:2Lg/ICMd(1) AAS
>>170
最近は ANSI は UTF-8 に固定しろとか言い出してる
172: 01/12(日)12:45 ID:/g6mpPgl(1) AAS
>>160
Jane大好きマウイ君がウォームアップしてそう
ああ見えてフッ軽だから今度はflutterで作ったりしてなw
173: 01/13(月)13:47 ID:g4/CTboD(1) AAS
UTF-8に一本化されるなら嬉しいな
174: 01/13(月)21:19 ID:5zeCvv1K(1) AAS
Windows アプリで UTF-8 コード ページを使用する
外部ﾘﾝｸ:learn.microsoft.com
175: 01/13(月)23:50 ID:ux79df1f(1) AAS
初めから文字列はUTF-8と言語仕様＆標準ライブラリで決めてあるRustが楽でいいね
もちろん必要ならUTF-8以外も読み書き可
176: 01/17(金)17:07 ID:GO6/DX25(1) AAS
pythonも楽ちんちん
177(5): 01/18(土)03:52 ID:CaguG0TX(1/7) AAS
RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう
178(1): 01/18(土)09:40 ID:ryxfYm1H(1/5) AAS
>>177
気のせいじゃない？
規格どおり実装されてればUTF-8にサロゲートなんて概念は存在しない
最短表記のみが正式なので冗長性はないよ
179(1): 01/18(土)10:15 ID:CaguG0TX(2/7) AAS
>>178
UTF-8では違反なサロゲートの片方だけを許すのがWTF-8なので
正常なサロゲートペアをUTF-8に変換したときの4〜6バイト表現に対して
WTF-8ではペアの片割れを別々に変換して結合した3バイトのサロゲート片☓2な別表現が存在できてしまうでしょ
これらはUTF-16に戻したら同じ文字列になってしまうので
WTF-8で比較等の処理をしてUTF-16に戻すと脆弱性になっちゃう
180(1): 01/18(土)10:40 ID:ryxfYm1H(2/5) AAS
>>179
色々間違えてる
UTF-8では片側だろうと両方だろうとサロゲート領域のコードは許されてない。あったらUTF-8じゃない
サロゲート導入前の古いUTF-8規格を参照してるアホがいるだけ
UTF-8は最大長で1文字4バイト、それ以上長いのは今のUTF-8では許されない
ましてWTF-8とか名前変えてもユニコード規格の対象外、UTF-8ではない
181: 01/18(土)10:44 ID:CaguG0TX(3/7) AAS
>>180
最初っからWTF-8って言ってるじゃん
182: 01/18(土)10:49 ID:CaguG0TX(4/7) AAS
Windowsのファイルシステムでは文字コードとしては不正なバイト列がファイル名として存在できる
それを8バイト文字列で無理やり扱うためRustではWTF-8という本来エラーになる表現も許容した規格違反UTF-8を使っている
OK？
183: 01/18(土)11:09 ID:ryxfYm1H(3/5) AAS
だから WTF-8 は UTF-8 とは違う
別物なんだから混同しなければ脆弱性にはならない
184: 01/18(土)11:15 ID:CaguG0TX(5/7) AAS
Rustではファイル名をWTF-8で扱うけどWTF-8で文字列処理すると危なくね？ってそれだけの話だよ
UTF-8の話と混同して絡んできたのはあんたじゃね
185: 01/18(土)11:27 ID:7Jaib8zo(1) AAS
m1Hは馬鹿ちんちん
186: 01/18(土)11:33 ID:ryxfYm1H(4/5) AAS
WTF-8 の文字列を UTF-8 の比較関数とかで処理しようとしてもうまくいかない → 当たり前
これは脆弱性ではないし、冗長性も関係ない
ここまでは理解できてるんだよな？
WTF-8 が別規格なんだからそれ専用の処理コードが必要ってだけだろ
UTF-8ではないので混同するなって話
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解釈が試みられて)
不正なパラメータエラーとかで(ディレクトリスキャン時などの)早期に発見できそうな気がする
上下前次1-新書関写板覧索設栞歴
あと 279 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.021s