文字コード総合スレ part15 (472ﾚｽ)
文字コード総合スレ part15 http://mevius.5ch.net/test/read.cgi/tech/1723861080/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
135: デフォルトの名無しさん [sage] 2024/12/07(土) 16:00:13.39 ID:2Ddhf3xH Mac で日本語を駆逐でいいんじゃね？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/135
136: デフォルトの名無しさん [sage] 2024/12/07(土) 21:42:37.76 ID:1sWZyE4C ファイル名にはASCIIにある文字しか使わないようにすれば解決 http://mevius.5ch.net/test/read.cgi/tech/1723861080/136
137: デフォルトの名無しさん [sage] 2024/12/07(土) 21:44:45.68 ID:prVW7qhX >>136 ASCII のバックスラッシュが円記号になってしまう OS がるらしい http://mevius.5ch.net/test/read.cgi/tech/1723861080/137
138: デフォルトの名無しさん [sage] 2024/12/08(日) 03:07:43.02 ID:h9KuPnHR >>136 じゃあまずはASCII以外でここに書き込むのやめろよ http://mevius.5ch.net/test/read.cgi/tech/1723861080/138
139: デフォルトの名無しさん [sage] 2024/12/08(日) 04:05:29.89 ID:Xxla/ZnP >>138 ここにファイル名を書いてる人あまりいないと思うんだけど？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/139
140: デフォルトの名無しさん [] 2024/12/09(月) 11:25:01.55 ID:uh4vUAM3 波ダッシュ（〜）と全角チルダ（〜）は違う文字 http://mevius.5ch.net/test/read.cgi/tech/1723861080/140
141: デフォルトの名無しさん [sage] 2024/12/09(月) 12:17:56.89 ID:Ne3E3UJU JISで全角チルダ定義したのがアレだよな 全角しか表示できない場面のためだろうけど http://mevius.5ch.net/test/read.cgi/tech/1723861080/141
142: デフォルトの名無しさん [sage] 2024/12/09(月) 14:00:31.58 ID:4HU/GnaT >>141 JIS は全角と半角とか定義してない（定期 http://mevius.5ch.net/test/read.cgi/tech/1723861080/142
143: デフォルトの名無しさん [sage] 2024/12/09(月) 14:37:46.18 ID:+G8yezOA >>142 えー、をMSIMEで変換したら 全角チルダ(U+FF5E)でした 抑揚のある伸ばし棒はこれが正解ですか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/143
144: デフォルトの名無しさん [sage] 2024/12/09(月) 15:02:44.75 ID:4HU/GnaT >>143 知らん MS が決めたことは MS に聞け 全角とか半角とか関係ない http://mevius.5ch.net/test/read.cgi/tech/1723861080/144
145: デフォルトの名無しさん [sage] 2024/12/09(月) 17:46:32.24 ID:bX1qj24S この板には表層的にMSを持ち出すだけで思考停止する若干一名がいるね http://mevius.5ch.net/test/read.cgi/tech/1723861080/145
146: デフォルトの名無しさん [sage] 2024/12/09(月) 18:34:12.95 ID:4HU/GnaT >>145 シフトJISの「波ダーシ」を unicode の「全角チルダ」にマッピングする CP932 を規定したのはマイクロソフト マイクロソフト以外の Linux とか MacOS とかその他の各社OSではそうなっていない マイクロソフトが何でこんなマッピングにしたのかは専門家でも分かんない謎 unicode がまだドラフトの時代にあわてて作業したのでミスっただけの可能性も指摘されてるが、一度決めたものは互換性のために変えられないのだろう点は理解できる http://mevius.5ch.net/test/read.cgi/tech/1723861080/146
147: デフォルトの名無しさん [sage] 2024/12/09(月) 23:51:59.27 ID:TvtcjS7H マイクロソフト憎しにも程がある デマだめ絶対 http://mevius.5ch.net/test/read.cgi/tech/1723861080/147
148: デフォルトの名無しさん [sage] 2024/12/13(金) 01:50:01.54 ID:XDI5kMlm マイクロソフトの場合親の敵の可能性があるから俺は許すね 気の済むまでじゃんじゃんやっといてくれ http://mevius.5ch.net/test/read.cgi/tech/1723861080/148
149: デフォルトの名無しさん [sage] 2024/12/13(金) 02:14:20.18 ID:OiDxg/7M unicode 規格が最初に作られた時サイトに参考情報として JIS と unicode のマッピング表が置いてあった Linux も Mac も商用Unixもこの表に従ってJISの波ダーシを unicode の wave dash にマッピングした。さらに JISの規格書にもこのマッピングで記載された ただ Microsoft 1社だけは JIS の波ダーシを unicode の fullwidth tilde にマッピングした こんなんマイクロソフトの中の人以外に理由が分かるわけねーだろ http://mevius.5ch.net/test/read.cgi/tech/1723861080/149
150: デフォルトの名無しさん [sage] 2024/12/13(金) 11:09:50.07 ID:ncXjn+FF 初期のUnicode仕様書の文字の形がおかしかったのがそもそもの原因なんだけどね いまの仕様書では、〜（U+301C、波ダッシュ）は、～（U+FF5E、全角チルダ）と同じ字形だけど、 古いものは、上下反転した存在しない文字の形だったので、どちらに合わせるかを決める時点で、 MSは形の相似した全角チルダのU+FF5Eを、その他は仕様どおりの波ダッシュのU+301Cを割り当てた 更にMacは仕様書を無視して字形を変更し、現在の仕様書と同じようにU+301Cに本来の波ダッシュの形を割り当てた ただ、上下反転した字形は、縦書きの際の全角チルダ（左右の順）文字を横書きにしたために紛れ込んだとも言われているので、 仕様書制定の段階で縦書きのある日本語を理解した人が加わっていなかったのだろうな まぁ、仕様書の字形がおかしかったことがそもそもの原因ではあるけれど、 これの対応を話し合いをすることなく各社で独自に行なってしまったというのが一番大きいな 結局、日本語が軽んじられていたんだろうけど、なんとも間抜けな話 http://mevius.5ch.net/test/read.cgi/tech/1723861080/150
151: デフォルトの名無しさん [sage] 2024/12/13(金) 11:39:54.50 ID:OiDxg/7M >>150 仕様書も文字の形がおかしかったはネットの素人が勝手に推測した迷信、文字形は規定していない 文字コード的にはフォントで変わる文字の形は意味がない unicode の wave dash は JIS 第一水準の波ダージなどに対応する文字として準備された unicode の互換領域の fullwidth tilde は EUC-JP とかで使用されいたJIS補助漢字のチルダをマッピングするために準備された EUC-JP では ASCII の1バイト文字のチルダと補助漢字の2倍と文字のチルダに両方が使われていたので互換領域が必要だった http://mevius.5ch.net/test/read.cgi/tech/1723861080/151
152: デフォルトの名無しさん [sage] 2025/01/11(土) 13:26:51.55 ID:ftPdDy1W なんか文字コード絡みでWindowsに特大級のセキュリティホールが見つかったぽい https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/ http://mevius.5ch.net/test/read.cgi/tech/1723861080/152
153: デフォルトの名無しさん [] 2025/01/11(土) 13:36:00.86 ID:ftPdDy1W CP65001で緩和可能ってことであってるよね? 超ヤバげなんでageるよ http://mevius.5ch.net/test/read.cgi/tech/1723861080/153
154: デフォルトの名無しさん [sage] 2025/01/11(土) 13:52:24.87 ID:wkEhpAnW >>153 あってる MSYS2を使ってれば2,3ヶ月前には対策の副作用があったから知ってたよ メディアはもっとこれを大きく報じてユーザー環境にもUTF8ロケールが広まって欲しい http://mevius.5ch.net/test/read.cgi/tech/1723861080/154
155: デフォルトの名無しさん [sage] 2025/01/11(土) 15:04:27.58 ID:mk8LdH4O やべーやつだこれ 終わったな... http://mevius.5ch.net/test/read.cgi/tech/1723861080/155
156: デフォルトの名無しさん [sage] 2025/01/11(土) 15:07:44.39 ID:MN266Dik とうとう Windows の Best-Fit-Conversion が槍玉にあげられたか これって多数の個別アプリの問題に矮小化されてきたけどどう考えてもOSの設計ミスにしかみえない http://mevius.5ch.net/test/read.cgi/tech/1723861080/156
157: デフォルトの名無しさん [sage] 2025/01/11(土) 16:08:55.10 ID:IZON3iKr 件のBestFit機能のせいで、 windowsバッチでフルパスが半角スペースなし全角スペースありだと、 どのようにクォーティングをしようともまともに動かなくなったわけか http://mevius.5ch.net/test/read.cgi/tech/1723861080/157
158: デフォルトの名無しさん [sage] 2025/01/11(土) 16:17:43.05 ID:PjVvqmiz システム設定でUTF8にするとメモ帳でSJISテキストファイルが文字化けする訳だけど この特需で伸ばす代替エディタは何か？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/158
159: デフォルトの名無しさん [sage] 2025/01/11(土) 16:20:20.66 ID:PjVvqmiz 場合によっては情シスがSJISテキストファイルリストアップツールを用意する事になりそう http://mevius.5ch.net/test/read.cgi/tech/1723861080/159
160: デフォルトの名無しさん [sage] 2025/01/11(土) 16:29:41.49 ID:IZON3iKr UTF-8に設定すると、JaneStyleは今度こそ本当に使えなくなるんだよな http://mevius.5ch.net/test/read.cgi/tech/1723861080/160
161: デフォルトの名無しさん [sage] 2025/01/11(土) 16:37:08.97 ID:8GlegYBS ファイル名に禁則文字を増やしても避けられないのだろうか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/161
162: デフォルトの名無しさん [sage] 2025/01/11(土) 16:50:18.36 ID:SJ4Pziuh これを機に932以外では文字化けするレガシーアプリは駆逐されれば良い http://mevius.5ch.net/test/read.cgi/tech/1723861080/162
163: デフォルトの名無しさん [sage] 2025/01/11(土) 17:11:19.10 ID:MN266Dik >>161 ファイル名の禁則レベルでは無理 Unicode の一部の文字がバックスラッシュとか空白とかクォートとかの区切り文字や特殊処理する文字に化けるので、これを利用して入力を誤魔化せるという技 どう化けるかはコードページ次第 全部のアプリがユニコード対応になるか Windows が BestFit やめない限りは多くのアプリで同様の問題が量産される（オープンソース系のアプリはこれはOSの仕様のせいでアプリのバグじゃないので直すつもりはないとか言ってる） UTF-8だとBestFit使われないので Windows 12 とかで SJIS とか Win-1521 とか捨ててデフォルトが UTF-8 になれば解決するけど http://mevius.5ch.net/test/read.cgi/tech/1723861080/163
164: デフォルトの名無しさん [sage] 2025/01/11(土) 17:17:54.37 ID:IZON3iKr システムをUTF-8に設定した上で、 CP932なアプリについて、個別のマニフェストの"activeCodePage"を"CP932"することで使えるようにならないんだろうか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/164
165: デフォルトの名無しさん [sage] 2025/01/11(土) 17:23:40.51 ID:MN266Dik >>164 今のところできないし、できたとしてもその cp932 に設定したプログラムで BestFit による抜け穴が使われるリスクがある http://mevius.5ch.net/test/read.cgi/tech/1723861080/165
166: デフォルトの名無しさん [sage] 2025/01/11(土) 17:41:24.43 ID:8GlegYBS ファイル名に英数字以外禁止したら何とかなりそうな気はした http://mevius.5ch.net/test/read.cgi/tech/1723861080/166
167: デフォルトの名無しさん [sage] 2025/01/11(土) 17:49:38.65 ID:MN266Dik >>166 ファイル名だけじゃないから コマンドのオプションスイッチとか、URL とか、環境変数とか、レジストリとか、とにかくプログラムの入力全部 http://mevius.5ch.net/test/read.cgi/tech/1723861080/167
168: デフォルトの名無しさん [sage] 2025/01/11(土) 22:53:43.82 ID:ftPdDy1W 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"); } こうすべきってこと? http://mevius.5ch.net/test/read.cgi/tech/1723861080/168
169: デフォルトの名無しさん [sage] 2025/01/11(土) 23:28:05.92 ID:ftPdDy1W あ、 int main(int argc, char **argv) エントリーポイントの時点で引数がワイド文字じゃないから脆弱性の影響を受ける可能性があるのか wmainがあるのはそういう理由なのね http://mevius.5ch.net/test/read.cgi/tech/1723861080/169
170: デフォルトの名無しさん [sage] 2025/01/12(日) 08:20:59.76 ID:xo4UH4ro MS的には「いまだにワイド文字列使ってないアプリが悪い」なんだよな http://mevius.5ch.net/test/read.cgi/tech/1723861080/170
171: デフォルトの名無しさん [sage] 2025/01/12(日) 11:43:06.44 ID:2Lg/ICMd >>170 最近は ANSI は UTF-8 に固定しろとか言い出してる http://mevius.5ch.net/test/read.cgi/tech/1723861080/171
172: デフォルトの名無しさん [sage] 2025/01/12(日) 12:45:56.54 ID:/g6mpPgl >>160 Jane大好きマウイ君がウォームアップしてそう ああ見えてフッ軽だから今度はflutterで作ったりしてなw http://mevius.5ch.net/test/read.cgi/tech/1723861080/172
173: デフォルトの名無しさん [] 2025/01/13(月) 13:47:41.46 ID:g4/CTboD UTF-8に一本化されるなら嬉しいな http://mevius.5ch.net/test/read.cgi/tech/1723861080/173
174: デフォルトの名無しさん [sage] 2025/01/13(月) 21:19:29.06 ID:5zeCvv1K Windows アプリで UTF-8 コード ページを使用する https://learn.microsoft.com/ja-jp/windows/apps/design/globalizing/use-utf8-code-page http://mevius.5ch.net/test/read.cgi/tech/1723861080/174
175: デフォルトの名無しさん [sage] 2025/01/13(月) 23:50:34.22 ID:ux79df1f 初めから文字列はUTF-8と言語仕様＆標準ライブラリで決めてあるRustが楽でいいね もちろん必要ならUTF-8以外も読み書き可 http://mevius.5ch.net/test/read.cgi/tech/1723861080/175
176: デフォルトの名無しさん [] 2025/01/17(金) 17:07:09.01 ID:GO6/DX25 pythonも楽ちんちん http://mevius.5ch.net/test/read.cgi/tech/1723861080/176
177: デフォルトの名無しさん [sage] 2025/01/18(土) 03:52:04.02 ID:CaguG0TX RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな… WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう http://mevius.5ch.net/test/read.cgi/tech/1723861080/177
178: デフォルトの名無しさん [sage] 2025/01/18(土) 09:40:44.96 ID:ryxfYm1H >>177 気のせいじゃない？ 規格どおり実装されてればUTF-8にサロゲートなんて概念は存在しない 最短表記のみが正式なので冗長性はないよ http://mevius.5ch.net/test/read.cgi/tech/1723861080/178
179: デフォルトの名無しさん [sage] 2025/01/18(土) 10:15:43.69 ID:CaguG0TX >>178 UTF-8では違反なサロゲートの片方だけを許すのがWTF-8なので 正常なサロゲートペアをUTF-8に変換したときの4〜6バイト表現に対して WTF-8ではペアの片割れを別々に変換して結合した3バイトのサロゲート片☓2な別表現が存在できてしまうでしょ これらはUTF-16に戻したら同じ文字列になってしまうので WTF-8で比較等の処理をしてUTF-16に戻すと脆弱性になっちゃう http://mevius.5ch.net/test/read.cgi/tech/1723861080/179
180: デフォルトの名無しさん [sage] 2025/01/18(土) 10:40:31.12 ID:ryxfYm1H >>179 色々間違えてる UTF-8では片側だろうと両方だろうとサロゲート領域のコードは許されてない。あったらUTF-8じゃない サロゲート導入前の古いUTF-8規格を参照してるアホがいるだけ UTF-8は最大長で1文字4バイト、それ以上長いのは今のUTF-8では許されない ましてWTF-8とか名前変えてもユニコード規格の対象外、UTF-8ではない http://mevius.5ch.net/test/read.cgi/tech/1723861080/180
181: デフォルトの名無しさん [sage] 2025/01/18(土) 10:44:27.05 ID:CaguG0TX >>180 最初っからWTF-8って言ってるじゃん http://mevius.5ch.net/test/read.cgi/tech/1723861080/181
182: デフォルトの名無しさん [sage] 2025/01/18(土) 10:49:44.07 ID:CaguG0TX Windowsのファイルシステムでは文字コードとしては不正なバイト列がファイル名として存在できる それを8バイト文字列で無理やり扱うためRustではWTF-8という本来エラーになる表現も許容した規格違反UTF-8を使っている OK？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/182
183: デフォルトの名無しさん [sage] 2025/01/18(土) 11:09:46.05 ID:ryxfYm1H だから WTF-8 は UTF-8 とは違う 別物なんだから混同しなければ脆弱性にはならない http://mevius.5ch.net/test/read.cgi/tech/1723861080/183
184: デフォルトの名無しさん [sage] 2025/01/18(土) 11:15:32.70 ID:CaguG0TX Rustではファイル名をWTF-8で扱うけどWTF-8で文字列処理すると危なくね？ってそれだけの話だよ UTF-8の話と混同して絡んできたのはあんたじゃね http://mevius.5ch.net/test/read.cgi/tech/1723861080/184
185: デフォルトの名無しさん [] 2025/01/18(土) 11:27:52.60 ID:7Jaib8zo m1Hは馬鹿ちんちん http://mevius.5ch.net/test/read.cgi/tech/1723861080/185
186: デフォルトの名無しさん [sage] 2025/01/18(土) 11:33:32.09 ID:ryxfYm1H WTF-8 の文字列を UTF-8 の比較関数とかで処理しようとしてもうまくいかない → 当たり前 これは脆弱性ではないし、冗長性も関係ない ここまでは理解できてるんだよな？ WTF-8 が別規格なんだからそれ専用の処理コードが必要ってだけだろ UTF-8ではないので混同するなって話 http://mevius.5ch.net/test/read.cgi/tech/1723861080/186
187: デフォルトの名無しさん [sage] 2025/01/18(土) 11:36:02.21 ID:CaguG0TX もう自分が何書いてるかもわかってなさそう もう一度読んで？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/187
188: デフォルトの名無しさん [sage] 2025/01/18(土) 11:44:30.94 ID:rGNNXTeE 横通ります Rustではディレクトリを開いてスキャンしたら各ファイル名はWTF-8とやらのスライスなのか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/188
189: デフォルトの名無しさん [sage] 2025/01/18(土) 11:46:24.96 ID:rGNNXTeE それとLinuxのファイルシステム自体もUTF-8文字コードを外れてもOKだから、Windowsに限った話ではないかと LTF-8もあるのか？ http://mevius.5ch.net/test/read.cgi/tech/1723861080/189
190: デフォルトの名無しさん [sage] 2025/01/18(土) 12:03:49.92 ID:CaguG0TX >>188-189 型としてはOsStringとしてラップされてて、中身を取り出したらWindowsではWTF-8 不正な文字コードが入りうるのはどのOSでも同じだけどバイト列そのままな他OSと異なりWindowsだとUTF-16との変換も挟まって危なそうだなあって (ちなmacOSやあとBSDのzfsなんかだと不正な文字コードは最初から入らないらしい？) http://mevius.5ch.net/test/read.cgi/tech/1723861080/190
191: 188-189 [sage] 2025/01/18(土) 12:30:08.19 ID:ZXpOcGU5 >>190 なるほどね納得 不正な文字コードに遭遇したら処理を進めないで即座にエラーにするが良さそう 問題は処理系がちゃんと不正な文字コードを感知するかどうかだけど、 WindowsでA系APIを使っていれば(RawワイドストリングのUTF-16解釈が試みられて) 不正なパラメータエラーとかで(ディレクトリスキャン時などの)早期に発見できそうな気がする http://mevius.5ch.net/test/read.cgi/tech/1723861080/191
192: デフォルトの名無しさん [sage] 2025/01/18(土) 12:32:48.77 ID:ryxfYm1H なんだろうな？ UTF-8: 片サロゲートも両サロゲートも不可 WTF-8: 片サロゲートのみ可、両サロゲートは不可 CESU-8: サロゲート展開必須 という区別がちゃんとついてるんだろうかという疑問、これら混ぜれば冗長だが… 単独で冗長と言われても具体性がない http://mevius.5ch.net/test/read.cgi/tech/1723861080/192
193: デフォルトの名無しさん [sage] 2025/01/20(月) 21:45:49.79 ID:fFffNKjx 勘違いしてる人がいるため正しい情報 まずRustの文字列つまりstr型とString型はvalidなUTF-8のみであることが必ず保証されている そこには当然サロゲートもなければinvalidなUTF-8もないため問題は一切起きない そこにWTF-8など他のものが混ざることも絶対にない つまりどんな文字列操作をしても冗長表現のない validなUTF-8となる安全が保証されている つづく http://mevius.5ch.net/test/read.cgi/tech/1723861080/193
194: デフォルトの名無しさん [sage] 2025/01/20(月) 21:46:25.68 ID:fFffNKjx 次に言語とは関係ない話 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となる つづく http://mevius.5ch.net/test/read.cgi/tech/1723861080/194
195: デフォルトの名無しさん [sage] 2025/01/20(月) 21:47:00.81 ID:fFffNKjx UTF-16⇔UTF-8は常に可逆に変換できる 前述のWTF-16に対しても同様に可逆となるものとしてWTF-8が考えられる つまりWTF-16⇔WTF-8は常に可逆に変換できる 前述のWTF-16⊃UTF-16と同様に WTF-8⊃UTF-8となる このWTF-8はあくまでもWTF-16との可逆を保証するための内部表現であり外で使われることはない つづく http://mevius.5ch.net/test/read.cgi/tech/1723861080/195
196: デフォルトの名無しさん [sage] 2025/01/20(月) 21:48:06.23 ID:fFffNKjx このWTF-8には以下の利点がある ・WTF-16(＝任意の16bit列)と可逆に1対1に変換できる ・元のWTF-16がUTF-16のみの場合は対応するWTF-8はUTF-8のみとなる ・特に元がアスキー文字のみならば対応するWTF-8は7bitアスキー文字となる 集合関係はWTF-8⊃UTF-8⊃7bitアスキー文字となる つまり内部表現として非常に使い勝手が良いものとなっている つづく http://mevius.5ch.net/test/read.cgi/tech/1723861080/196
197: デフォルトの名無しさん [sage] 2025/01/20(月) 21:49:23.00 ID:fFffNKjx そしてようやく再びRustの話 Rustでは言語の外の世界とをつなぐFFI (Foreign Function Initerface)の一つとして OS環境依存の文字列型としてOsString型とOsStr型がある これはvalidなUTF-8文字列型であるString型とstr型にそれぞれ対応する 集合的にはOsString⊃StringとOsStr⊃strとなりinvalidなUTF-8を含む分だけ大きな集合を表す Windows環境ではこの内部表現として前述のWTF-8が使われている つづく http://mevius.5ch.net/test/read.cgi/tech/1723861080/197
198: デフォルトの名無しさん [sage] 2025/01/20(月) 21:50:56.30 ID:fFffNKjx >>177 >>190 WTF-8を新たに作り出すにはvalidなUTF-8から作るか あるいは16bit列から作るかのどちらかしか手段がない つまり必ずWTF-16(＝任意の16bit列)⇔WTF-8は1対1に対応する したがってあなたが主張する 「別の冗長表現」は生じることはなく危険なことは絶対に起こらない http://mevius.5ch.net/test/read.cgi/tech/1723861080/198
199: デフォルトの名無しさん [sage] 2025/01/20(月) 22:03:03.35 ID:SJIxPBxD Rustスレから出てこないで欲しいなあ http://mevius.5ch.net/test/read.cgi/tech/1723861080/199
200: デフォルトの名無しさん [sage] 2025/01/20(月) 22:15:46.02 ID:fw0guZsp >>198 普通に結合で新しくOsStringを作ってる例がありますやん ttps://doc.rust-lang.org/std/ffi/struct.OsString.html#capacity-of-osstring http://mevius.5ch.net/test/read.cgi/tech/1723861080/200
201: デフォルトの名無しさん [sage] 2025/01/20(月) 22:20:59.93 ID:SnLzVhb4 utf8とutf8を結合しても必ずutf8となるように wtf8とwtf8を結合しても必ずwtf8だね 何を問題視しているのかな http://mevius.5ch.net/test/read.cgi/tech/1723861080/201
202: デフォルトの名無しさん [sage] 2025/01/20(月) 22:26:06.74 ID:fw0guZsp 何度も書いてるじゃないですか サロゲートの片方だけなWTF-8同士を結合するとサロゲートペアが揃ってしまって本来あるべき形の別表現となるでしょ その状態で比較等をすると狂いが生じる話 http://mevius.5ch.net/test/read.cgi/tech/1723861080/202
203: デフォルトの名無しさん [sage] 2025/01/20(月) 22:44:54.83 ID:SnLzVhb4 >>202 wtf16の1文字(16bit値)とwtf8の1文字が可逆対応だよ それぞれ結合してN文字同士になっても可逆対応だよ 別表現なし 何を問題視しているのかな http://mevius.5ch.net/test/read.cgi/tech/1723861080/203
204: デフォルトの名無しさん [sage] 2025/01/20(月) 22:51:08.98 ID:uZ5HVjRv WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない UTF-8 のように単純に結合することできない 両サロゲートが含まれてるものはWTF-8ではない http://mevius.5ch.net/test/read.cgi/tech/1723861080/204
205: デフォルトの名無しさん [sage] 2025/01/20(月) 23:00:53.63 ID:fw0guZsp >>204 そうそうそれそれ。ようやく話が通じそうな人が来てくれた で、現実には？と http://mevius.5ch.net/test/read.cgi/tech/1723861080/205
206: デフォルトの名無しさん [sage] 2025/01/20(月) 23:18:31.29 ID:uZ5HVjRv >>205 片サロゲートはユニコード的には文字コードではないので片サロゲートの結合をどう処理するかは実装依存 捨てる、未定義文字に置き変える、文字だったことにしてUTF-8変換する、なんかのセパレータを挟むとかできるかもしれない でも一般的と思われるのは結合処理自体をエラーで失敗させる WTF-8 にも UTF-8 にも冗長性はない、WTF-8 を UTF-8 と同じように使ってはいけないだけ、両者は別物 http://mevius.5ch.net/test/read.cgi/tech/1723861080/206
207: デフォルトの名無しさん [sage] 2025/01/20(月) 23:19:38.23 ID:fFffNKjx >>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に可逆が保証される 別の冗長表現は生じない http://mevius.5ch.net/test/read.cgi/tech/1723861080/207
208: デフォルトの名無しさん [sage] 2025/01/20(月) 23:26:06.35 ID:uZ5HVjRv >>206 一応補足しておくと、エラーなどの処理するのは結合時点でなくて、それを何か使おうとしたり、他の文字コードに変換しようとした時点とすることもできる Invalid な WTF-8 のチェックをどの時点でするかだけの問題 http://mevius.5ch.net/test/read.cgi/tech/1723861080/208
209: デフォルトの名無しさん [sage] 2025/01/20(月) 23:27:17.08 ID:fw0guZsp >>206 OSがファイル名として扱えるバイナリ列を作れないのはむしろそちらのほうが問題になるので 失敗させるのはナシでは >>206-207 で、今ソースを追いかけていてpushに関しては ttps://stdrs.dev/nightly/x86_64-pc-windows-gnu/src/std/sys_common/wtf8.rs.html#337-359 で>>204の処理がなされてるのを確認しました つまりpushに関しては俺の杞憂でした(もちろん他の処理は別) http://mevius.5ch.net/test/read.cgi/tech/1723861080/209
210: デフォルトの名無しさん [sage] 2025/01/20(月) 23:35:21.19 ID:fw0guZsp >>208 他言語のStringBuilder等ならそうだけど OsStringには直接の比較関数等もあるので結合時点以外に選択肢は無いと思う http://mevius.5ch.net/test/read.cgi/tech/1723861080/210
211: デフォルトの名無しさん [sage] 2025/01/20(月) 23:45:27.35 ID:fFffNKjx >>209 それは任意の16bit列に対応するWTF-8を作れるようになっているのでその場合も対応できて大丈夫 use std::os::windows::ffi::OsStringExt OsString::from_wide(wide: &[u16]) つまりWTF-16⇔WTF-8は必ず1対1に対応するため別の冗長表現は生じず問題は起こらない http://mevius.5ch.net/test/read.cgi/tech/1723861080/211
212: デフォルトの名無しさん [sage] 2025/01/20(月) 23:52:28.98 ID:fFffNKjx つまり話をまとめると WTF-8の新規生成はUTF-8もしくはWTF-16(＝任意の16bit列)からのみ生成できるため常にWTF-16と1対1に対応する WTF-8の結合は個別にWTF-16にしてから結合してWTF-8に戻した処理と同等と定義されているため常にWTF-16と1対1に対応する したがって問題が発生する箇所はない http://mevius.5ch.net/test/read.cgi/tech/1723861080/212
213: デフォルトの名無しさん [sage] 2025/01/21(火) 00:05:41.71 ID:HFAykEjr >>212 異論というわけじゃないが、そもそもWTF-16どうしをそのまま結合して良いかというと必ずしもそうではない WTF-16をそのまま結合して許される条件下まらWTF-8の結合を終端でサロゲートが並んだらUTF-8変換するというのは間違ってないけど まあどっちにしろ正しく処理すれば冗長性はない http://mevius.5ch.net/test/read.cgi/tech/1723861080/213
214: デフォルトの名無しさん [sage] 2025/01/21(火) 00:39:07.85 ID:HFAykEjr ファイル名に文字ではないゴミが含まれている → 実際に含まれているだから仕方ないOSの問題 ゴミとゴミをくっつけると文字になる → OSの問題でも文字コードの問題でもない、許すかどうかはアプリの問題 http://mevius.5ch.net/test/read.cgi/tech/1723861080/214
215: デフォルトの名無しさん [sage] 2025/01/21(火) 00:52:01.60 ID:HFAykEjr ゴミの結合をして文字になることを許すと冗長性とは別のセキュリティホールになることがある 文字のフィルターとかで文字列Aにも文字列Bにも含まれてないことを確認した文字が A+B に含まれるかもしれない これは最近に始まったことではなくて SJIS とか EUC-JP とかでもあった問題で、セキュリティ要件ではゴミの単純な結合は許さないのがベスト・プラクティス http://mevius.5ch.net/test/read.cgi/tech/1723861080/215
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 257 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.014s