文字コード総合スレ part15 (470ﾚｽ)
上下前次1-新
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は定義から当たり前の話であるとともに
この性質によりUTF-8からWTF-8へはエラーなく常に変換できる
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 → ○ （未定義文字などを許す前提）
任意の8bit列 = WTF-8 → ✕
WTF-16 と WTF-8 は冗長性なく1対1対応 → ○
基本が分かってないやつがいるので議論が噛み合ってないだけのようだ
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
そしてWindowsの場合はその内部実装をWTF-8にすると上述の特性群を満たせるというだけの話
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で起こりうること
この事実を理解できるかどうか
これを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた
上下前次1-新書関写板覧索設栞歴
あと 224 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.016s