文字コード総合スレ part15 (470ﾚｽ)
文字コード総合スレ part15 http://mevius.5ch.net/test/read.cgi/tech/1723861080/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
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
216: デフォルトの名無しさん [sage] 2025/01/21(火) 01:27:51.08 ID:cx2WozxM いずれにせよRustの文字列処理には何ら問題なくて WTF-8の処理にも何ら問題ないことがわかったのだから 最初の書き込みのこの人が間違っていたな >>177 >>RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな… WTF-8で脆弱性が引き起こされないことも今回はっきりした あとはもし何かあるとすればWindows側の問題のみ http://mevius.5ch.net/test/read.cgi/tech/1723861080/216
217: デフォルトの名無しさん [sage] 2025/01/21(火) 06:06:40.49 ID:/BTcOxxh Rustは何も解決してないのにWTF-8型で解決したかの様な振る舞い勘違いが一番質が悪い その意味で>>177は的を射ている >>216は>いずれにせよ..., で誤魔化さないでまき散らした勘違いを訂正しないとな 例えば>>195 > WTF-8⊃UTF-8となる など http://mevius.5ch.net/test/read.cgi/tech/1723861080/217
218: デフォルトの名無しさん [sage] 2025/01/21(火) 07:33:55.78 ID:CGf2GAkC >>217 ウソはいかんよ Rustは正しく解決している >>177氏は冗長表現ができると勘違いしていた 冗長表現は原理的に不可能だ そして誰もその生成プログラム例を示せなかった WTF-8⊃UTF-8は定義から当たり前の話であるとともに この性質によりUTF-8からWTF-8へはエラーなく常に変換できる http://mevius.5ch.net/test/read.cgi/tech/1723861080/218
219: デフォルトの名無しさん [sage] 2025/01/21(火) 07:42:06.00 ID:4+X4XnDl まあ抽象的なコードポイントの話じゃなくて、エンコーディングの話、例えば > WTF-16(＝任意の16bit列) と言ってるから > WTF-8⊃UTF-8となる も8bit列を意図してるのなら、成り立たないな。 WTF-8に関しては、WTF-8(＝任意の16bit列)ではなくて、 絵文字などをUTF-8エンコードした8bit列は、WTF-8では不正な8bit列となる。 http://mevius.5ch.net/test/read.cgi/tech/1723861080/219
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 251 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.017s