文字コード総合スレ part15

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

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

**デフォルトの名無しさん** · 2024/12/07(土) 14:01:25.11

>他の方法が駆逐されるわけじゃなく新たなバリエーションを増やすだけ

ほんそれ

**デフォルトの名無しさん** · 2024/12/07(土) 14:17:40.72

まずはMacを駆逐しよう

**デフォルトの名無しさん** · 2024/12/07(土) 16:00:13.39

Mac で日本語を駆逐でいいんじゃね？

**デフォルトの名無しさん** · 2024/12/07(土) 21:42:37.76

ファイル名にはASCIIにある文字しか使わないようにすれば解決

**デフォルトの名無しさん** · 2024/12/07(土) 21:44:45.68

>>136
ASCII のバックスラッシュが円記号になってしまう OS がるらしい

**デフォルトの名無しさん** · 2024/12/08(日) 03:07:43.02

>>136
じゃあまずはASCII以外でここに書き込むのやめろよ

**デフォルトの名無しさん** · 2024/12/08(日) 04:05:29.89

>>138
ここにファイル名を書いてる人あまりいないと思うんだけど？

**デフォルトの名無しさん** · 2024/12/09(月) 11:25:01.55

波ダッシュ（〜）と全角チルダ（～）は違う文字

**デフォルトの名無しさん** · 2024/12/09(月) 12:17:56.89

JISで全角チルダ定義したのがアレだよな
全角しか表示できない場面のためだろうけど

**デフォルトの名無しさん** · 2024/12/09(月) 14:00:31.58

>>141
JIS は全角と半角とか定義してない（定期

**デフォルトの名無しさん** · 2024/12/09(月) 14:37:46.18

>>142
えー、をMSIMEで変換したら
全角チルダ(U+FF5E)でした

抑揚のある伸ばし棒はこれが正解ですか？

**デフォルトの名無しさん** · 2024/12/09(月) 15:02:44.75

>>143
知らん
MS が決めたことは MS に聞け
全角とか半角とか関係ない

**デフォルトの名無しさん** · 2024/12/09(月) 17:46:32.24

この板には表層的にMSを持ち出すだけで思考停止する若干一名がいるね

**デフォルトの名無しさん** · 2024/12/09(月) 18:34:12.95

>>145
シフトJISの「波ダーシ」を unicode の「全角チルダ」にマッピングする CP932 を規定したのはマイクロソフト
マイクロソフト以外の Linux とか MacOS とかその他の各社OSではそうなっていない

マイクロソフトが何でこんなマッピングにしたのかは専門家でも分かんない謎
unicode がまだドラフトの時代にあわてて作業したのでミスっただけの可能性も指摘されてるが、一度決めたものは互換性のために変えられないのだろう点は理解できる

**デフォルトの名無しさん** · 2024/12/09(月) 23:51:59.27

マイクロソフト憎しにも程がある
デマだめ絶対

**デフォルトの名無しさん** · 2024/12/13(金) 01:50:01.54

マイクロソフトの場合親の敵の可能性があるから俺は許すね
気の済むまでじゃんじゃんやっといてくれ

**デフォルトの名無しさん** · 2024/12/13(金) 02:14:20.18

unicode 規格が最初に作られた時サイトに参考情報として JIS と unicode のマッピング表が置いてあった
Linux も Mac も商用Unixもこの表に従ってJISの波ダーシを unicode の wave dash にマッピングした。さらに JISの規格書にもこのマッピングで記載された
ただ Microsoft 1社だけは JIS の波ダーシを unicode の fullwidth tilde にマッピングした

こんなんマイクロソフトの中の人以外に理由が分かるわけねーだろ

**デフォルトの名無しさん** · 2024/12/13(金) 11:09:50.07

初期のUnicode仕様書の文字の形がおかしかったのがそもそもの原因なんだけどね

いまの仕様書では、〜（U+301C、波ダッシュ）は、～（U+FF5E、全角チルダ）と同じ字形だけど、
古いものは、上下反転した存在しない文字の形だったので、どちらに合わせるかを決める時点で、
MSは形の相似した全角チルダのU+FF5Eを、その他は仕様どおりの波ダッシュのU+301Cを割り当てた
更にMacは仕様書を無視して字形を変更し、現在の仕様書と同じようにU+301Cに本来の波ダッシュの形を割り当てた

ただ、上下反転した字形は、縦書きの際の全角チルダ（左右の順）文字を横書きにしたために紛れ込んだとも言われているので、
仕様書制定の段階で縦書きのある日本語を理解した人が加わっていなかったのだろうな

まぁ、仕様書の字形がおかしかったことがそもそもの原因ではあるけれど、
これの対応を話し合いをすることなく各社で独自に行なってしまったというのが一番大きいな
結局、日本語が軽んじられていたんだろうけど、なんとも間抜けな話

**デフォルトの名無しさん** · 2024/12/13(金) 11:39:54.50

>>150
仕様書も文字の形がおかしかったはネットの素人が勝手に推測した迷信、文字形は規定していない
文字コード的にはフォントで変わる文字の形は意味がない

unicode の wave dash は JIS 第一水準の波ダージなどに対応する文字として準備された
unicode の互換領域の fullwidth tilde は EUC-JP とかで使用されいたJIS補助漢字のチルダをマッピングするために準備された
EUC-JP では ASCII の1バイト文字のチルダと補助漢字の2倍と文字のチルダに両方が使われていたので互換領域が必要だった

**デフォルトの名無しさん** · 2025/01/11(土) 13:26:51.55

なんか文字コード絡みでWindowsに特大級のセキュリティホールが見つかったぽい
https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/

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

CP65001で緩和可能ってことであってるよね?

超ヤバげなんでageるよ

**デフォルトの名無しさん** · 2025/01/11(土) 13:52:24.87

>>153
あってる
MSYS2を使ってれば2,3ヶ月前には対策の副作用があったから知ってたよ
メディアはもっとこれを大きく報じてユーザー環境にもUTF8ロケールが広まって欲しい

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

やべーやつだこれ
終わったな...

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

とうとう Windows の Best-Fit-Conversion が槍玉にあげられたか
これって多数の個別アプリの問題に矮小化されてきたけどどう考えてもOSの設計ミスにしかみえない

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

件のBestFit機能のせいで、
windowsバッチでフルパスが半角スペースなし全角スペースありだと、
どのようにクォーティングをしようともまともに動かなくなったわけか

**デフォルトの名無しさん** · 2025/01/11(土) 16:17:43.05

システム設定でUTF8にするとメモ帳でSJISテキストファイルが文字化けする訳だけど
この特需で伸ばす代替エディタは何か？

**デフォルトの名無しさん** · 2025/01/11(土) 16:20:20.66

場合によっては情シスがSJISテキストファイルリストアップツールを用意する事になりそう

**デフォルトの名無しさん** · 2025/01/11(土) 16:29:41.49

UTF-8に設定すると、JaneStyleは今度こそ本当に使えなくなるんだよな

**デフォルトの名無しさん** · 2025/01/11(土) 16:37:08.97

ファイル名に禁則文字を増やしても避けられないのだろうか？

**デフォルトの名無しさん** · 2025/01/11(土) 16:50:18.36

これを機に932以外では文字化けするレガシーアプリは駆逐されれば良い

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

>>161
ファイル名の禁則レベルでは無理
Unicode の一部の文字がバックスラッシュとか空白とかクォートとかの区切り文字や特殊処理する文字に化けるので、これを利用して入力を誤魔化せるという技
どう化けるかはコードページ次第

全部のアプリがユニコード対応になるか Windows が BestFit やめない限りは多くのアプリで同様の問題が量産される（オープンソース系のアプリはこれはOSの仕様のせいでアプリのバグじゃないので直すつもりはないとか言ってる）

UTF-8だとBestFit使われないので Windows 12 とかで SJIS とか Win-1521 とか捨ててデフォルトが UTF-8 になれば解決するけど

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

システムをUTF-8に設定した上で、
CP932なアプリについて、個別のマニフェストの"activeCodePage"を"CP932"することで使えるようにならないんだろうか？

**デフォルトの名無しさん** · 2025/01/11(土) 17:23:40.51

>>164
今のところできないし、できたとしてもその cp932 に設定したプログラムで BestFit による抜け穴が使われるリスクがある

**デフォルトの名無しさん** · 2025/01/11(土) 17:41:24.43

ファイル名に英数字以外禁止したら何とかなりそうな気はした

**デフォルトの名無しさん** · 2025/01/11(土) 17:49:38.65

>>166
ファイル名だけじゃないから
コマンドのオプションスイッチとか、URL とか、環境変数とか、レジストリとか、とにかくプログラムの入力全部

**デフォルトの名無しさん** · 2025/01/11(土) 22:53:43.82

Windows全然詳しくないんだけど、Windows APIのANSI APIとUnicode APIとの違いって
標準Cライブラリの文字出力で言えばprintfとwprintfとの違いってことだよね?

世の中のOSSのほとんどはwprintf等のワイド文字関数なんて使っていないんだから
OSSをWindowsで動かした場合ほぼ全部WorstFitの影響を受けることになるはず

今後基本的にワイド文字関数で書くべきってなると、Hello Worldは

#include <stdio.h>
#include <locale.h>
#include <wchar.h>

int main(int argc, char **argv)
{
setlocale(LC_ALL, "");
wprintf(L"こんにちは世界\n");
}

こうすべきってこと?

**デフォルトの名無しさん** · 2025/01/11(土) 23:28:05.92

あ、
int main(int argc, char **argv)
エントリーポイントの時点で引数がワイド文字じゃないから脆弱性の影響を受ける可能性があるのか
wmainがあるのはそういう理由なのね

**デフォルトの名無しさん** · 2025/01/12(日) 08:20:59.76

MS的には「いまだにワイド文字列使ってないアプリが悪い」なんだよな

**デフォルトの名無しさん** · 2025/01/12(日) 11:43:06.44

>>170
最近は ANSI は UTF-8 に固定しろとか言い出してる

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

>>160
Jane大好きマウイ君がウォームアップしてそう
ああ見えてフッ軽だから今度はflutterで作ったりしてなw

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

UTF-8に一本化されるなら嬉しいな

**デフォルトの名無しさん** · 2025/01/13(月) 21:19:29.06

Windows アプリで UTF-8 コードページを使用する
https://learn.microsoft.com/ja-jp/windows/apps/design/globalizing/use-utf8-code-page

**デフォルトの名無しさん** · 2025/01/13(月) 23:50:34.22

初めから文字列はUTF-8と言語仕様＆標準ライブラリで決めてあるRustが楽でいいね
もちろん必要ならUTF-8以外も読み書き可

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

pythonも楽ちんちん

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

RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう

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

>>177
気のせいじゃない？
規格どおり実装されてればUTF-8にサロゲートなんて概念は存在しない
最短表記のみが正式なので冗長性はないよ

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

>>178
UTF-8では違反なサロゲートの片方だけを許すのがWTF-8なので
正常なサロゲートペアをUTF-8に変換したときの4～6バイト表現に対して
WTF-8ではペアの片割れを別々に変換して結合した3バイトのサロゲート片☓2な別表現が存在できてしまうでしょ
これらはUTF-16に戻したら同じ文字列になってしまうので
WTF-8で比較等の処理をしてUTF-16に戻すと脆弱性になっちゃう

**デフォルトの名無しさん** · 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>してる気がする)