240(1): デフォルトの名無しさん [sage] 2025/01/24(金) 21:50:18.47 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が許容してる範囲内の問題のみであり、新たな問題を持ち込むことはない。

242(1): デフォルトの名無しさん [sage] 2025/01/25(土) 07:40:49.86 ID:oQSzfWfA(1/5) AAS
>>241
もちろんその通りで
当たり前の三つの同値
WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること
これだけの話だな
それを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた

244(1): デフォルトの名無しさん [sage] 2025/01/25(土) 08:11:11.01 ID:oQSzfWfA(2/5) AAS
>>243
意図的にUTF-16から逸脱したコードを生成するアプリ次第でWindows上で起こりうるから全く同じ
もし違うというならばその差分となる具体例を出してください

246(1): デフォルトの名無しさん [sage] 2025/01/25(土) 12:08:02.89 ID:oQSzfWfA(3/5) AAS
>>245
それも正しい
WindowsもLinuxも正しいユニコード以外を許容している
だからUTF-16やUTF-8を前提としてはいけない
そのためWTF-16やWTF-8あるいは何らか他の枠組みの導入でようやく対応できる

その時に当たり前の三つの同値
WTF-8で起こりうること ＝ WTF-16で起こりうること ＝ Windowsで起こりうること
この事実を理解できるかどうか

これを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた

248(1): デフォルトの名無しさん [sage] 2025/01/25(土) 13:00:31.67 ID:oQSzfWfA(4/5) AAS
>>247
どのOSも正しいユニコード以外を許容している
したがってUTF-8/16以外も扱えなければならない
そして非UTF-8/16があった時にそれを認識して区別して扱えなければならない
その区別ができないと既存のUTF-8/16部分にもうっかり混入させて汚染を広げてしまう
この重要性が理解できるかね？

RustではUTF-8とWTF-8(など非ユニコード)は明確に別の型となっているため安全性が保証される
両者を扱えつつ型システムにより必ず区別できる