文字コード総合スレ part15 (470ﾚｽ)
上下前次1-新
154: 01/11(土)13:52 ID:wkEhpAnW(1) AAS
>>153
あってる
MSYS2を使ってれば2,3ヶ月前には対策の副作用があったから知ってたよ
メディアはもっとこれを大きく報じてユーザー環境にもUTF8ロケールが広まって欲しい
155: 01/11(土)15:04 ID:mk8LdH4O(1) AAS
やべーやつだこれ
終わったな...
156: 01/11(土)15:07 ID:MN266Dik(1/4) AAS
とうとう Windows の Best-Fit-Conversion が槍玉にあげられたか
これって多数の個別アプリの問題に矮小化されてきたけどどう考えてもOSの設計ミスにしかみえない
157: 01/11(土)16:08 ID:IZON3iKr(1/3) AAS
件のBestFit機能のせいで、
windowsバッチでフルパスが半角スペースなし全角スペースありだと、
どのようにクォーティングをしようともまともに動かなくなったわけか
158: 01/11(土)16:17 ID:PjVvqmiz(1/2) AAS
システム設定でUTF8にするとメモ帳でSJISテキストファイルが文字化けする訳だけど
この特需で伸ばす代替エディタは何か？
159: 01/11(土)16:20 ID:PjVvqmiz(2/2) AAS
場合によっては情シスがSJISテキストファイルリストアップツールを用意する事になりそう
160(1): 01/11(土)16:29 ID:IZON3iKr(2/3) AAS
UTF-8に設定すると、JaneStyleは今度こそ本当に使えなくなるんだよな
161(1): 01/11(土)16:37 ID:8GlegYBS(1/2) AAS
ファイル名に禁則文字を増やしても避けられないのだろうか？
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 とは違う
別物なんだから混同しなければ脆弱性にはならない
上下前次1-新書関写板覧索設栞歴
あと 287 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.011s