文字コード総合スレ part15

**デフォルトの名無しさん** · 2024/08/17(土) 11:18:00.01

文字コードについて語り合うスレです

**デフォルトの名無しさん** · 2025/01/18(土) 10:40:31.12

>>179
色々間違えてる
UTF-8では片側だろうと両方だろうとサロゲート領域のコードは許されてない。あったらUTF-8じゃない
サロゲート導入前の古いUTF-8規格を参照してるアホがいるだけ
UTF-8は最大長で1文字4バイト、それ以上長いのは今のUTF-8では許されない
ましてWTF-8とか名前変えてもユニコード規格の対象外、UTF-8ではない

**デフォルトの名無しさん** · 2025/01/18(土) 10:44:27.05

>>180
最初っからWTF-8って言ってるじゃん

**デフォルトの名無しさん** · 2025/01/18(土) 10:49:44.07

Windowsのファイルシステムでは文字コードとしては不正なバイト列がファイル名として存在できる
それを8バイト文字列で無理やり扱うためRustではWTF-8という本来エラーになる表現も許容した規格違反UTF-8を使っている
OK？

**デフォルトの名無しさん** · 2025/01/18(土) 11:09:46.05

だから WTF-8 は UTF-8 とは違う
別物なんだから混同しなければ脆弱性にはならない

**デフォルトの名無しさん** · 2025/01/18(土) 11:15:32.70

Rustではファイル名をWTF-8で扱うけどWTF-8で文字列処理すると危なくね？ってそれだけの話だよ
UTF-8の話と混同して絡んできたのはあんたじゃね

**デフォルトの名無しさん** · 2025/01/18(土) 11:27:52.60

m1Hは馬鹿ちんちん

**デフォルトの名無しさん** · 2025/01/18(土) 11:33:32.09

WTF-8 の文字列を UTF-8 の比較関数とかで処理しようとしてもうまくいかない → 当たり前
これは脆弱性ではないし、冗長性も関係ない
ここまでは理解できてるんだよな？

WTF-8 が別規格なんだからそれ専用の処理コードが必要ってだけだろ
UTF-8ではないので混同するなって話

**デフォルトの名無しさん** · 2025/01/18(土) 11:36:02.21

もう自分が何書いてるかもわかってなさそう
もう一度読んで？

**デフォルトの名無しさん** · 2025/01/18(土) 11:44:30.94

横通ります

Rustではディレクトリを開いてスキャンしたら各ファイル名はWTF-8とやらのスライスなのか？

**デフォルトの名無しさん** · 2025/01/18(土) 11:46:24.96

それとLinuxのファイルシステム自体もUTF-8文字コードを外れてもOKだから、Windowsに限った話ではないかと
LTF-8もあるのか？

**デフォルトの名無しさん** · 2025/01/18(土) 12:03:49.92

>>188-189
型としてはOsStringとしてラップされてて、中身を取り出したらWindowsではWTF-8
不正な文字コードが入りうるのはどのOSでも同じだけどバイト列そのままな他OSと異なりWindowsだとUTF-16との変換も挟まって危なそうだなあって

(ちなmacOSやあとBSDのzfsなんかだと不正な文字コードは最初から入らないらしい？)

**188-189** · 2025/01/18(土) 12:30:08.19

>>190
なるほどね納得

不正な文字コードに遭遇したら処理を進めないで即座にエラーにするが良さそう

問題は処理系がちゃんと不正な文字コードを感知するかどうかだけど、
WindowsでA系APIを使っていれば(RawワイドストリングのUTF-16解釈が試みられて)
不正なパラメータエラーとかで(ディレクトリスキャン時などの)早期に発見できそうな気がする

**デフォルトの名無しさん** · 2025/01/18(土) 12:32:48.77

なんだろうな？
UTF-8: 片サロゲートも両サロゲートも不可
WTF-8: 片サロゲートのみ可、両サロゲートは不可
CESU-8: サロゲート展開必須
という区別がちゃんとついてるんだろうかという疑問、これら混ぜれば冗長だが…
単独で冗長と言われても具体性がない

**デフォルトの名無しさん** · 2025/01/20(月) 21:45:49.79

勘違いしてる人がいるため正しい情報

まずRustの文字列つまりstr型とString型はvalidなUTF-8のみであることが必ず保証されている
そこには当然サロゲートもなければinvalidなUTF-8もないため問題は一切起きない
そこにWTF-8など他のものが混ざることも絶対にない
つまりどんな文字列操作をしても冗長表現のない
validなUTF-8となる安全が保証されている

つづく

**デフォルトの名無しさん** · 2025/01/20(月) 21:46:25.68

次に言語とは関係ない話
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となる

つづく

**デフォルトの名無しさん** · 2025/01/20(月) 21:47:00.81

UTF-16⇔UTF-8は常に可逆に変換できる
前述のWTF-16に対しても同様に可逆となるものとしてWTF-8が考えられる
つまりWTF-16⇔WTF-8は常に可逆に変換できる
前述のWTF-16⊃UTF-16と同様に
WTF-8⊃UTF-8となる
このWTF-8はあくまでもWTF-16との可逆を保証するための内部表現であり外で使われることはない

つづく

**デフォルトの名無しさん** · 2025/01/20(月) 21:48:06.23

このWTF-8には以下の利点がある
・WTF-16(＝任意の16bit列)と可逆に1対1に変換できる
・元のWTF-16がUTF-16のみの場合は対応するWTF-8はUTF-8のみとなる
・特に元がアスキー文字のみならば対応するWTF-8は7bitアスキー文字となる

集合関係はWTF-8⊃UTF-8⊃7bitアスキー文字となる
つまり内部表現として非常に使い勝手が良いものとなっている

つづく

**デフォルトの名無しさん** · 2025/01/20(月) 21:49:23.00

そしてようやく再びRustの話
Rustでは言語の外の世界とをつなぐFFI (Foreign Function Initerface)の一つとして
OS環境依存の文字列型としてOsString型とOsStr型がある
これはvalidなUTF-8文字列型であるString型とstr型にそれぞれ対応する
集合的にはOsString⊃StringとOsStr⊃strとなりinvalidなUTF-8を含む分だけ大きな集合を表す
Windows環境ではこの内部表現として前述のWTF-8が使われている

つづく

**デフォルトの名無しさん** · 2025/01/20(月) 21:50:56.30

>>177 >>190
WTF-8を新たに作り出すにはvalidなUTF-8から作るか
あるいは16bit列から作るかのどちらかしか手段がない
つまり必ずWTF-16(＝任意の16bit列)⇔WTF-8は1対1に対応する
したがってあなたが主張する
「別の冗長表現」は生じることはなく危険なことは絶対に起こらない

**デフォルトの名無しさん** · 2025/01/20(月) 22:03:03.35

Rustスレから出てこないで欲しいなあ

**デフォルトの名無しさん** · 2025/01/20(月) 22:15:46.02

>>198
普通に結合で新しくOsStringを作ってる例がありますやん
ttps://doc.rust-lang.org/std/ffi/struct.OsString.html#capacity-of-osstring

**デフォルトの名無しさん** · 2025/01/20(月) 22:20:59.93

utf8とutf8を結合しても必ずutf8となるように
wtf8とwtf8を結合しても必ずwtf8だね
何を問題視しているのかな

**デフォルトの名無しさん** · 2025/01/20(月) 22:26:06.74

何度も書いてるじゃないですか
サロゲートの片方だけなWTF-8同士を結合するとサロゲートペアが揃ってしまって本来あるべき形の別表現となるでしょ
その状態で比較等をすると狂いが生じる話

**デフォルトの名無しさん** · 2025/01/20(月) 22:44:54.83

>>202
wtf16の1文字(16bit値)とwtf8の1文字が可逆対応だよ
それぞれ結合してN文字同士になっても可逆対応だよ
別表現なし
何を問題視しているのかな

**デフォルトの名無しさん** · 2025/01/20(月) 22:51:08.98

WTF-8 どうしを結合するときは終端処理をしてサロゲートの変換をしないといけない
UTF-8 のように単純に結合することできない
両サロゲートが含まれてるものはWTF-8ではない

**デフォルトの名無しさん** · 2025/01/20(月) 23:00:53.63

>>204
そうそうそれそれ。ようやく話が通じそうな人が来てくれた
で、現実には？と

**デフォルトの名無しさん** · 2025/01/20(月) 23:18:31.29

>>205
片サロゲートはユニコード的には文字コードではないので片サロゲートの結合をどう処理するかは実装依存
捨てる、未定義文字に置き変える、文字だったことにしてUTF-8変換する、なんかのセパレータを挟むとかできるかもしれない
でも一般的と思われるのは結合処理自体をエラーで失敗させる
WTF-8 にも UTF-8 にも冗長性はない、WTF-8 を UTF-8 と同じように使ってはいけないだけ、両者は別物

**デフォルトの名無しさん** · 2025/01/20(月) 23:19:38.23

>>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に可逆が保証される
別の冗長表現は生じない

**デフォルトの名無しさん** · 2025/01/20(月) 23:26:06.35

>>206
一応補足しておくと、エラーなどの処理するのは結合時点でなくて、それを何か使おうとしたり、他の文字コードに変換しようとした時点とすることもできる
Invalid な WTF-8 のチェックをどの時点でするかだけの問題

**デフォルトの名無しさん** · 2025/01/20(月) 23:27:17.08

>>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に関しては俺の杞憂でした(もちろん他の処理は別)

**デフォルトの名無しさん** · 2025/01/20(月) 23:35:21.19

>>208
他言語のStringBuilder等ならそうだけど
OsStringには直接の比較関数等もあるので結合時点以外に選択肢は無いと思う

**デフォルトの名無しさん** · 2025/01/20(月) 23:45:27.35

>>209
それは任意の16bit列に対応するWTF-8を作れるようになっているのでその場合も対応できて大丈夫
use std::os::windows::ffi::OsStringExt
OsString::from_wide(wide: &[u16])
つまりWTF-16⇔WTF-8は必ず1対1に対応するため別の冗長表現は生じず問題は起こらない

**デフォルトの名無しさん** · 2025/01/20(月) 23:52:28.98

つまり話をまとめると
WTF-8の新規生成はUTF-8もしくはWTF-16(＝任意の16bit列)からのみ生成できるため常にWTF-16と1対1に対応する
WTF-8の結合は個別にWTF-16にしてから結合してWTF-8に戻した処理と同等と定義されているため常にWTF-16と1対1に対応する
したがって問題が発生する箇所はない

**デフォルトの名無しさん** · 2025/01/21(火) 00:05:41.71

>>212
異論というわけじゃないが、そもそもWTF-16どうしをそのまま結合して良いかというと必ずしもそうではない
WTF-16をそのまま結合して許される条件下まらWTF-8の結合を終端でサロゲートが並んだらUTF-8変換するというのは間違ってないけど
まあどっちにしろ正しく処理すれば冗長性はない

**デフォルトの名無しさん** · 2025/01/21(火) 00:39:07.85

ファイル名に文字ではないゴミが含まれている → 実際に含まれているだから仕方ないOSの問題
ゴミとゴミをくっつけると文字になる → OSの問題でも文字コードの問題でもない、許すかどうかはアプリの問題

**デフォルトの名無しさん** · 2025/01/21(火) 00:52:01.60

ゴミの結合をして文字になることを許すと冗長性とは別のセキュリティホールになることがある
文字のフィルターとかで文字列Aにも文字列Bにも含まれてないことを確認した文字が A+B に含まれるかもしれない
これは最近に始まったことではなくて SJIS
とか EUC-JP とかでもあった問題で、セキュリティ要件ではゴミの単純な結合は許さないのがベスト・プラクティス

**デフォルトの名無しさん** · 2025/01/21(火) 01:27:51.08

いずれにせよRustの文字列処理には何ら問題なくて
WTF-8の処理にも何ら問題ないことがわかったのだから
最初の書き込みのこの人が間違っていたな

>>177
>>RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…

WTF-8で脆弱性が引き起こされないことも今回はっきりした
あとはもし何かあるとすればWindows側の問題のみ

**デフォルトの名無しさん** · 2025/01/21(火) 06:06:40.49

Rustは何も解決してないのにWTF-8型で解決したかの様な振る舞い勘違いが一番質が悪い
その意味で>>177は的を射ている

>>216は>いずれにせよ..., で誤魔化さないでまき散らした勘違いを訂正しないとな

例えば>>195
> WTF-8⊃UTF-8となる
など

**デフォルトの名無しさん** · 2025/01/21(火) 07:33:55.78

>>217
ウソはいかんよ
Rustは正しく解決している

>>177氏は冗長表現ができると勘違いしていた
冗長表現は原理的に不可能だ
そして誰もその生成プログラム例を示せなかった

WTF-8⊃UTF-8は定義から当たり前の話であるとともに
この性質によりUTF-8からWTF-8へはエラーなく常に変換できる

**デフォルトの名無しさん** · 2025/01/21(火) 07:42:06.00

まあ抽象的なコードポイントの話じゃなくて、エンコーディングの話、例えば
> WTF-16(＝任意の16bit列)
と言ってるから
> WTF-8⊃UTF-8となる
も8bit列を意図してるのなら、成り立たないな。

WTF-8に関しては、WTF-8(＝任意の16bit列)ではなくて、
絵文字などをUTF-8エンコードした8bit列は、WTF-8では不正な8bit列となる。

**デフォルトの名無しさん** · 2025/01/21(火) 07:43:40.53

訂正
WTF-8に関しては、WTF-8(＝任意の8bit列)ではなくて、

**デフォルトの名無しさん** · 2025/01/21(火) 08:02:21.62

>>219
>>絵文字などをUTF-8エンコードした8bit列は、WTF-8では不正な8bit列となる。

それは君が勘違いしてるよ
UTF-8エンコードした8bit列は必ず有効なWTF-8になるが正しい
反論があるならUTF-8がWTF-8とならない場合のプログラム例を出そう

**デフォルトの名無しさん** · 2025/01/21(火) 08:06:50.62

>>221
それを含めた時が冗長性誕生の瞬間である

**デフォルトの名無しさん** · 2025/01/21(火) 08:11:27.09

>>222
冗長表現となる事例とその生成プログラム例を出そうよ
世界中で誰も示せていないよ

**デフォルトの名無しさん** · 2025/01/21(火) 08:59:02.25

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対応 → ○

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

**デフォルトの名無しさん** · 2025/01/21(火) 09:11:27.73

>>224
> 基本が分かってないやつ
ごめんごめんWTF-8の定義見て来た。
あと>>209見て明らかな脆弱性はないと納得した。
pushでsurrogate pairになってもself.is_known_utf8 = falseにしてるんだな。

**デフォルトの名無しさん** · 2025/01/21(火) 09:23:46.18

WTF-8に冗長表現は起きず脆弱性はないね
冗長が起きると書き込んでる人は、理解できずに間違った思い込みをしているのか、悔しくてデマを繰り返してるのか、わからんけどさ
冗長表現を生成する具体例を一つ示せば済むのに、ここまで来ても一つも示せていない

**デフォルトの名無しさん** · 2025/01/21(火) 10:25:40.02

帰れ

**デフォルトの名無しさん** · 2025/01/21(火) 11:37:21.93

>>215の言うAにもBにも含まれない「文字」がA+Bに含まれるかもしれない問題、
処理の正しさの観点では(脆弱性の話は置いておいて)
NFC/NFDやIVS/IVD/ZWJ絡みで(well formed UTF-8同士の範囲でも)発生する気がするけど
実際にA+Bを作ってからチェックするのが鉄則なのか？

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

**デフォルトの名無しさん** · 2025/01/21(火) 12:16:20.66

>>228
結合文字とか変種指定は機能性の問題なのでさらに一段回上のレイヤーの要件だな
「が」と「か＋結合濁点」を同じとみなすか別とみなすかは目的による（文字コード的にはどちらもありえる

**デフォルトの名無しさん** · 2025/01/21(火) 12:47:14.29

そんなの要件定義考慮漏れで溢れかえってる
何かあったら現状を仕様にする

**デフォルトの名無しさん** · 2025/01/21(火) 16:35:46.77

ライブラリ側に問題がないとはいえ過信はよろしくない
OsStringでは機能が足りず中身を取り出しての直接処理はよくやられてるし
余計な変換をかましてるせいで考慮することが増えてしまってる一方でアプリ側にはWindowsの特殊事情なんて考慮してないコードも山ほどあろう

**デフォルトの名無しさん** · 2025/01/21(火) 17:20:43.69

>>231
だから最初から WTF-8 は UTF-8 とは別物
混同したら問題、混同しなければ問題はない

UTF-8 ではサロゲート断片は許されない
WTF-8 ではサロゲートの片側だけ許されるがそのせいで追加の処理が必要

冗長性うんぬんを言い出すのはこの違いが分かってないやつという話題だろ

**デフォルトの名無しさん** · 2025/01/21(火) 17:51:44.82

Windowsも対応しているRipGrepの場合、OsStringのまま処理してるけど
ユーザーアプリレベルでWTF-8は必要なのか？
(すぐにpub fn into_string(self) -> Result<String, OsString>してる気がする)

**デフォルトの名無しさん** · 2025/01/21(火) 20:27:12.14

10年以上経ってv0.1.0な時点でネタライブラリでは

**デフォルトの名無しさん** · 2025/01/21(火) 20:36:26.03

>>233
OsStringとWTF-8は別物だと理解できてる？
OsStringは元が正規ユニコードならUTF-8となり、異なるならUTF-8を含む拡大集合になる、という抽象的な型
たまたまWindows環境の時は内部がWTF-8になるかもしれないがそんなことを意識せずに使えるところがカギ

自分の管轄範囲を処理する多くのアプリでは元がユニコードでなければエラーとして無視できる
そのためto_string()で文字列すなわちUTF-8へ変換するがそこで実際に変換する必要がなく変換コストはゼロとなる点が実際の目的

このような特性を備えつつUTF-8にできない場合も元の情報を保つ抽象的な型がOsString
そしてWindowsの場合はその内部実装をWTF-8にすると上述の特性群を満たせるというだけの話

**デフォルトの名無しさん** · 2025/01/21(火) 22:03:34.94

Rust の OsString という基準だと Linux とかだと任意のバイト列なんでそっちがもともとの形だな
たまたま Windows 版で効率考えて WTF-8 変換したものを使ってるだけ

**デフォルトの名無しさん** · 2025/01/21(火) 22:39:07.66

rgは凄く効率を重視してるけどOsStringで扱うしかなくてロスが発生してる
(各ファイルを開くのにWTF-16名に戻す処理が必要)

**デフォルトの名無しさん** · 2025/01/22(水) 23:14:48.82

OsStringは異なる環境で統一的に容易にStringと相互変換して扱えるための標準ライブラリ機能
些細なロスすら深刻な影響が出る用途がもし存在するのならば
特定環境に特化した専用のライブラリを用意すればよいだけ
必要な条件を満たすライブラリが既に存在しているかどうかは各自の用途で調べて

**デフォルトの名無しさん** · 2025/01/24(金) 18:16:24.35

>>209
今の正しいソースはこっちな
githubcom/rust-lang/rust/blob/master/library/std/src/sys_common/wtf8.rs#L357

>>228
結果的にWTF-8でA+B問題は起きるな

**デフォルトの名無しさん** · 2025/01/24(金) 21:50:18.47

>>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が許容してる範囲内の問題のみであり、新たな問題を持ち込むことはない。

**デフォルトの名無しさん** · 2025/01/25(土) 06:47:37.99

>>240
なんでもOSのせいにするのは良くないぞ
Windows は片サロゲートどうしを連結することを前提にしてはいない
あくまでも連結してるのはアプリの問題
WTF-8 の連結もアプリの問題OSとは独立

**デフォルトの名無しさん** · 2025/01/25(土) 07:40:49.86

>>241
もちろんその通りで
当たり前の三つの同値
WTF-8で起こりうること＝ WTF-16で起こりうること＝ Windowsで起こりうること
これだけの話だな
それを理解できずにWTF-8で新たな問題が生じると勘違いしているバカがWTF-8を批判していた

**デフォルトの名無しさん** · 2025/01/25(土) 08:02:54.69

>>242
いや
WTF-8 で起こりうること = WTF-16 で起こりうることは定義上正しいけど
= Windows で起こりうること、は正しくないだろという指摘だぞ

**デフォルトの名無しさん** · 2025/01/25(土) 08:11:11.01

>>243
意図的にUTF-16から逸脱したコードを生成するアプリ次第でWindows上で起こりうるから全く同じ
もし違うというならばその差分となる具体例を出してください

**デフォルトの名無しさん** · 2025/01/25(土) 11:54:33.53

>>244
Linux とかでも意図的に逸脱したコード書けば起きるだろ
違うってなんら Windows 固有にコード示したら？

**デフォルトの名無しさん** · 2025/01/25(土) 12:08:02.89

>>245
それも正しい
WindowsもLinuxも正しいユニコード以外を許容している
だからUTF-16やUTF-8を前提としてはいけない
そのためWTF-16やWTF-8あるいは何らか他の枠組みの導入でようやく対応できる

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

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

**デフォルトの名無しさん** · 2025/01/25(土) 12:36:14.63

>>246
= Windows で起こりうることに拘るのは何でだ？
UTF-8 と WTF-8 は別物なのに同じように扱ったら問題が起きる可能性がある OS とは独立

**デフォルトの名無しさん** · 2025/01/25(土) 13:00:31.67

>>247
どのOSも正しいユニコード以外を許容している
したがってUTF-8/16以外も扱えなければならない
そして非UTF-8/16があった時にそれを認識して区別して扱えなければならない
その区別ができないと既存のUTF-8/16部分にもうっかり混入させて汚染を広げてしまう
この重要性が理解できるかね？

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

**デフォルトの名無しさん** · 2025/01/25(土) 13:07:40.11

>>248
だからOSとは独立の文字コードの扱いの問題
もっといえば文字コードを正しく扱えないアプリの問題
OSのせいにするな

**デフォルトの名無しさん** · 2025/01/25(土) 13:31:18.17

>>249
どちらのOSも自由を許容している
そのため非ユニコードが混入しうる
OSは歯止めにならない

だからRustのように型で明確に区別できる言語を用いてアプリを作ればよい
非ユニコードが他へ波及することを防ぎつつ安全に扱うことができる

**デフォルトの名無しさん** · 2025/01/25(土) 14:44:40.60

from_encoded_bytes_uncheckedにoverlong UTF-8をブチ込んでinto_stringしたらOk返ってきちゃった

StringまたはWTF-16から変換されること以外は無い前提でチェックは最低限にされてるみたい
unsafe contractを破った俺が悪いのはそうなんだが、これを「WTF-8文字列コンテナ型」だと思ってたらまあまあ死にそう
バイト列からの変換にcheckedな版が無いのも、一応エンコーディング未規定なんだから好き勝手なバイト列から作るもんじゃねーよバーカってことだな

同じことをLinuxでもやったらこっちはinto_stringの時点でErrが返ってくる
OsStringの内部のバッファの不変条件としても違いがあって、Windows以外では任意のバイト列でいいけど、Windowsでは常にWTF-8でなくてはならないようだ

WTF-8それ自体が脆弱性の根源になることはなくても、こうしたややこしさが誤った使い方、ひいては脆弱性を生むことはあるかもしれないとは思った

**デフォルトの名無しさん** · 2025/01/25(土) 15:20:14.12

>>251
そのunsafe fn from_encoded_bytes_unchecked(byres: Vec<u8>)は安全性の対象外と明示されているね
unsafeとはC言語と同じようにプログラマーの責任で安全性を保証しなければならない
それを理解しない者や扱う技術を持たない者がunsafeを使ってはいけない
それ以前にRustは今回の件も自動的に安全性が保証されるコードを(unsafeを使わずに)書くことができる

**デフォルトの名無しさん** · 2025/01/25(土) 15:40:07.61

>>252
その通り、だからunsafe contractを破った俺が悪いと書いた
しかしぶっ壊すことで得られる学びは多い

**デフォルトの名無しさん** · 2025/01/25(土) 15:45:28.44

というかもうWTF-8の話じゃなくてRustの話になりつつあるしこの辺で終わっとこうぜ
続きがやりたければRust本スレで

**デフォルトの名無しさん** · 2025/01/25(土) 21:10:55.94

Rustスレから出てこないで欲しい

**デフォルトの名無しさん** · 2025/01/25(土) 22:20:25.13

構うから居座り続けるんだよ
学習しろ

**デフォルトの名無しさん** · 2025/01/26(日) 10:07:42.23

Macの濁点半濁点問題ってUTF-8の正規化とやらの範疇に入るのかな
文字構成の解釈の仕方の問題だから正規化を実装する人の思想に強く依存してしまうと思うけど

**デフォルトの名無しさん** · 2025/01/26(日) 10:56:58.06

日本人からすると濁点半濁点の違うMacうぜーとなるけど
欧州でもdiacriticsがあるから同じくMacうぜーだろうな

**デフォルトの名無しさん** · 2025/01/26(日) 11:31:33.02

>>257
このスレにいるなら文字コードとエンコーディングの区別を理解しよう
UTF-8はエンコーディング方法なので
そこでの正規化は冗長表現の排除やサロゲートペアの排除を指す
一方濁点半濁点の話は文字コードであるUnicodeの正規化の話であってUTF-8は一切関係がない

**デフォルトの名無しさん** · 2025/01/26(日) 11:52:28.72

>>257
Unicode の正規化は規格で決まっている
基本的に実装者の自由にやってはいけない
・複数の正規化が規定されてるのでそのうちの1つに過ぎない
・MacOSの正規化は一部規格から外れてる
という問題はある

**デフォルトの名無しさん** · 2025/01/26(日) 12:03:07.52

Macの濁点半濁点問題はEBCDICのカナ（半角カタカナ）をきれいに表示する努力をした結果なのだろうか？

**デフォルトの名無しさん** · 2025/01/27(月) 11:38:12.00

ファイル名は正規化するべきなのかするべきでないのか、という問題があり
Macは正規化する派
正規化するとした場合、どういう正規化がいいか、それが次の問題

**デフォルトの名無しさん** · 2025/01/27(月) 18:51:09.07

日本語のフォントを外国人が作っているせいで日本語の記号の見た目がおかしくなった

**デフォルトの名無しさん** · 2025/01/27(月) 18:52:15.56

>>262
Macのアップル社もGoogle社も改行コードに対しては意地悪すぎだろ

**デフォルトの名無しさん** · 2025/01/27(月) 22:05:41.27

Apple の改行コードはCRだったものがMac OS X でLFになったのを意地悪と言っているのだろうか？

**デフォルトの名無しさん** · 2025/01/27(月) 23:31:59.65

>>265
WindowsのCRLFをどちらも改行と見做すところ

どう考えても1つの改行なのにEメールなどでは2つの改行として送り返してくる

**デフォルトの名無しさん** · 2025/01/28(火) 10:08:29.84

CR=改行(Macのみ)
CRLF=改行(WindowsやRFC)
LF=改行(Unix)

>>266
それはアプリのバグ

**デフォルトの名無しさん** · 2025/01/28(火) 11:39:24.54

>>267
いろいろ間違えてるぞ
正確さが足りない

**デフォルトの名無しさん** · 2025/01/30(木) 07:10:47.96

ワシの霊感では、
CR LF → LF 変換　は無理
CR LF → CR 変換　も無理
その逆、は可能、スナワチ
LF → CR LF 変換等は、可能

なんでかって❓　霊感的には、
それが可能と仮定すれば、そのような問題は解決済
しかし未だに未解決の模様なので、

では、霊感的にではなく、数学的にはどうなのか
吟味しようかな。てか不可能が証明されても
その証明は、闇に葬る必要があるよな
by 💃🥳🤔

とにかく、アプリの改行バグなくせぇーー
by 👤🤡

**デフォルトの名無しさん** · 2025/01/30(木) 10:13:34.95

RFCもいまどき入力は寛容にとは書いてないんだっけか

**デフォルトの名無しさん** · 2025/01/30(木) 23:31:56.82

改行の話をするならこのTRには目を通しているよね?
https://www.unicode.org/reports/tr14/tr14-32.html#BreakingRules

**デフォルトの名無しさん** · 2025/01/31(金) 19:55:09.44

CRの直後にLFが現れたなら、改行2つではないとわかる。
それなのに改行2つと解釈するのは悪意でしかないり

**デフォルトの名無しさん** · 2025/01/31(金) 20:06:45.58

CR や LF より前に CRLF を処理しないのは悪意でしか無いな

**デフォルトの名無しさん** · 2025/01/31(金) 20:07:21.09

>>260
NFD、NFC等を名乗るならそうだが最初からmodified NFD言ってるしなあ
当時は異体字セレクタなどなく、ただのNFDで字形まで変えるUnicodeの定義のほうがおかしかった

**デフォルトの名無しさん** · 2025/01/31(金) 20:25:32.29

>>274
みんながみんな勝手に modified NFD とか作り始めたら互換性とか規格とか何の意味もなくなる
勝手なオレオレ基準は非難されるべき
単に古い規格準拠というだけなら許されるが Apple のはそうじゃない

**デフォルトの名無しさん** · 2025/01/31(金) 20:45:51.19

そもそも正規化自体は都合に合わせて勝手にやるもんだぜ？
Windowsの.で終わるファイル名を拡張子なしと同一視するのも正規化だし
掲示板への書き込みで行頭のスペースが消えるのも正規化だ
Unicodeで定義されたやつだけが正規化ではないというのは大前提として

字形を変えない範囲で厄介な合成分解で別ファイル扱いになるのを避けたい
というのは他の文字コードからUnicodeへの過渡期では当然の要求だろう
他のOSとのやりとりでトラブルが起きるようになったのはもっと考えるべきだったとは思うが

**デフォルトの名無しさん** · 2025/01/31(金) 20:53:12.36

>>276
それは違う
Apple はユニコード・コンソーシアムの設立からのメンバー
技術的に規格に問題があるののならそれを変えればいい、それをやらなければいけない立場
中核メンバーが自分たちが作った規格を勝手に無視してたら、規格の意味なんてない
この件はどう言い訳しても Apple はクソという結論にしかならない

**デフォルトの名無しさん** · 2025/01/31(金) 20:55:58.32

>>277
Appleは提案したが通らなかったってどっかで見たぞ

**デフォルトの名無しさん** · 2025/01/31(金) 20:57:03.60

技術的に無理な仕様作ったん？