206(2): デフォルトの名無しさん [sage] 2025/01/20(月) 23:18:31.29 ID:uZ5HVjRv(2/3) AAS
>>205
片サロゲートはユニコード的には文字コードではないので片サロゲートの結合をどう処理するかは実装依存
捨てる、未定義文字に置き変える、文字だったことにしてUTF-8変換する、なんかのセパレータを挟むとかできるかもしれない
でも一般的と思われるのは結合処理自体をエラーで失敗させる
WTF-8 にも UTF-8 にも冗長性はない、WTF-8 を UTF-8 と同じように使ってはいけないだけ、両者は別物

204(3): デフォルトの名無しさん [sage] 2025/01/20(月) 22:51:08.98 ID:uZ5HVjRv(1/3) AAS
WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない
UTF-8 のように単純に結合することできない
両サロゲートが含まれてるものはWTF-8ではない

224(1): デフォルトの名無しさん [sage] 2025/01/21(火) 08:59:02.25 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対応 → ○

基本が分かってないやつがいるので議論が噛み合ってないだけのようだ

228(2): デフォルトの名無しさん [sage] 2025/01/21(火) 11:37:21.93 ID:q2HQSFd2(1) AAS
>>215の言うAにもBにも含まれない「文字」がA+Bに含まれるかもしれない問題、
処理の正しさの観点では(脆弱性の話は置いておいて)
NFC/NFDやIVS/IVD/ZWJ絡みで(well formed UTF-8同士の範囲でも)発生する気がするけど
実際にA+Bを作ってからチェックするのが鉄則なのか？

「文字」じゃなくて「文字列」ならA+Bを作るのが普通と思う
(それと正規表現なら部分マッチが出来たりする)