文字コード総合スレ part15 (472ﾚｽ)
上下前次1-新
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>
省7
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解釈が試みられて)
不正なパラメータエラーとかで(ディレクトリスキャン時などの)早期に発見できそうな気がする
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とし結合を+で表すと
省3
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の処理がなされてるのを確認しました
省1
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は定義から当たり前の話であるとともに
省1
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 → ○ （未定義文字などを許す前提）
省3
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の特殊事情なんて考慮してないコードも山ほどあろう
232: 01/21(火)17:20 ID:HFAykEjr(6/7) AAS
>>231
だから最初から WTF-8 は UTF-8 とは別物
混同したら問題、混同しなければ問題はない
UTF-8 ではサロゲート断片は許されない
WTF-8 ではサロゲートの片側だけ許されるがそのせいで追加の処理が必要
冗長性うんぬんを言い出すのはこの違いが分かってないやつという話題だろ
233(1): 01/21(火)17:51 ID:ARY2cBPO(1) AAS
Windowsも対応しているRipGrepの場合、OsStringのまま処理してるけど
ユーザーアプリレベルでWTF-8は必要なのか？
(すぐにpub fn into_string(self) -> Result<String, OsString>してる気がする)
234: 01/21(火)20:27 ID:81VrkBbA(1) AAS
10年以上経ってv0.1.0な時点でネタライブラリでは
235: 01/21(火)20:36 ID:vcWEfek9(1) AAS
>>233
OsStringとWTF-8は別物だと理解できてる？
OsStringは元が正規ユニコードならUTF-8となり、異なるならUTF-8を含む拡大集合になる、という抽象的な型
たまたまWindows環境の時は内部がWTF-8になるかもしれないがそんなことを意識せずに使えるところがカギ
自分の管轄範囲を処理する多くのアプリでは元がユニコードでなければエラーとして無視できる
そのためto_string()で文字列すなわちUTF-8へ変換するがそこで実際に変換する必要がなく変換コストはゼロとなる点が実際の目的
このような特性を備えつつUTF-8にできない場合も元の情報を保つ抽象的な型がOsString
省1
236: 01/21(火)22:03 ID:HFAykEjr(7/7) AAS
Rust の OsString という基準だと Linux とかだと任意のバイト列なんでそっちがもともとの形だな
たまたま Windows 版で効率考えて WTF-8 変換したものを使ってるだけ
237: 01/21(火)22:39 ID:p3RcK7RU(1) AAS
rgは凄く効率を重視してるけどOsStringで扱うしかなくてロスが発生してる
(各ファイルを開くのにWTF-16名に戻す処理が必要)
238: 01/22(水)23:14 ID:qi7PZ6q/(1) AAS
OsStringは異なる環境で統一的に容易にStringと相互変換して扱えるための標準ライブラリ機能
些細なロスすら深刻な影響が出る用途がもし存在するのならば
特定環境に特化した専用のライブラリを用意すればよいだけ
必要な条件を満たすライブラリが既に存在しているかどうかは各自の用途で調べて
239(1): 01/24(金)18:16 ID:3xtC4p+Z(1) AAS
>>209
今の正しいソースはこっちな
githubcom/rust-lang/rust/blob/master/library/std/src/sys_common/wtf8.rs#L357
>>228
結果的にWTF-8でA+B問題は起きるな
240(1): 01/24(金)21:50 ID:VaG4uwwC(1) AAS
>>239
WTF-8自体を自在に改変するインターフェイスが全くないため、WTF-8独自の問題は発生しない。
WTF-8はWTF-16と1対1に可逆なので、WTF-16で起こる問題は当然WTF-8でも起きる。
WTF-16とはWindows OSが許容している拡張UTF-16、すなわち本来のUTF-16とは異なる16bit列も許す。
したがって、WTF-8を用いて起こる問題は、Windows OSが許容してる範囲内の問題のみであり、新たな問題を持ち込むことはない。
241(1): 01/25(土)06:47 ID:IEhZAzOs(1/5) AAS
>>240
なんでもOSのせいにするのは良くないぞ
Windows は片サロゲートどうしを連結することを前提にしてはいない
あくまでも連結してるのはアプリの問題
WTF-8 の連結もアプリの問題OSとは独立
242(1): 01/25(土)07:40 ID:oQSzfWfA(1/5) AAS
>>241
もちろんその通りで
当たり前の三つの同値
WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること
これだけの話だな
それを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた
243(1): 01/25(土)08:02 ID:IEhZAzOs(2/5) AAS
>>242
いや
WTF-8 で起こりうること = WTF-16 で起こりうることは定義上正しいけど
= Windows で起こりうること、は正しくないだろという指摘だぞ
244(1): 01/25(土)08:11 ID:oQSzfWfA(2/5) AAS
>>243
意図的にUTF-16から逸脱したコードを生成するアプリ次第でWindows上で起こりうるから全く同じ
もし違うというならばその差分となる具体例を出してください
245(1): 01/25(土)11:54 ID:IEhZAzOs(3/5) AAS
>>244
Linux とかでも意図的に逸脱したコード書けば起きるだろ
違うってなんら Windows 固有にコード示したら？
246(1): 01/25(土)12:08 ID:oQSzfWfA(3/5) AAS
>>245
それも正しい
WindowsもLinuxも正しいユニコード以外を許容している
だからUTF-16やUTF-8を前提としてはいけない
そのためWTF-16やWTF-8あるいは何らか他の枠組みの導入でようやく対応できる
その時に当たり前の三つの同値
WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること
省2
247(1): 01/25(土)12:36 ID:IEhZAzOs(4/5) AAS
>>246
= Windows で起こりうることに拘るのは何でだ？
UTF-8 と WTF-8 は別物なのに同じように扱ったら問題が起きる可能性がある OS とは独立
248(1): 01/25(土)13:00 ID:oQSzfWfA(4/5) AAS
>>247
どのOSも正しいユニコード以外を許容している
したがってUTF-8/16以外も扱えなければならない
そして非UTF-8/16があった時にそれを認識して区別して扱えなければならない
その区別ができないと既存のUTF-8/16部分にもうっかり混入させて汚染を広げてしまう
この重要性が理解できるかね？
RustではUTF-8とWTF-8(など非ユニコード)は明確に別の型となっているため安全性が保証される
省1
上下前次1-新書関写板覧索設栞歴
あと 224 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s