文字コード総合スレ part15

**デフォルトの名無しさん** · 2024/11/15(金) 23:15:52.91

>>73
コードはユニコード
それをどうエンコーディングするかでUTF8やUTF16やUTF32などがある
ネットの標準がUTF8に統一されてなって
ファイルシステムでもUTF8に統一されつつあり
プログラム内部でもほとんどの用途はそのまま透過的にUTF8が有利に

固定長で扱うUTF32はムダすぎで
可変長のUTF8は後ろからでも切れ目を間違えことなく
表示幅問題はUTF8/UTF32関係なく発生するため

**デフォルトの名無しさん** · 2024/11/17(日) 17:51:56.38

>>92
>ファイルシステムでもUTF8に統一されつつあり
例を挙げてもらえますか?

**デフォルトの名無しさん** · 2024/11/17(日) 18:35:05.90

>>93
Linux distro, MacOS, android, iOS,...
挙げ始めたが最近のリリースだと Windows 以外のメジャーどころは全部じゃね？

**デフォルトの名無しさん** · 2024/11/18(月) 23:18:52.19

UTF-8は世界の誰もが好むわけではない。
どの民族もUTF-8の良いところと悪いところで悩んでいる

**デフォルトの名無しさん** · 2024/11/18(月) 23:20:18.92

>>94
勘違いしているけど、それらの製品でも区別して使う分けている。

**デフォルトの名無しさん** · 2024/11/20(水) 15:38:36.45

>>94
Linux (ext4) は、ファイルシステムとしてはエンコーディングは規定されてないのでは?
ディストロやユーザーがUTF-8を使ったりするのは自由だが
よってAndroidも同様

なんだAppleだけじゃんw

**デフォルトの名無しさん** · 2024/11/20(水) 16:37:13.78

>>97
そんなこと言いだしたら APFS も NTFS も単にバイト列を記録してるのに過ぎない。
それをOSやライブラリとしてどう解釈するかがファイルシステムの文字列。
だから linux kernel でなくて linux distro の問題。
（もっとも最近の Linux kernel はデフォルトで UTF-8 を指定するABIとかあって文字コードの変換したりするけど。別問題）

**デフォルトの名無しさん** · 2024/11/21(木) 12:47:55.86

UTF-8も完璧じゃないからな

**デフォルトの名無しさん** · 2024/11/21(木) 14:20:22.35

>>99
キミの言う「完璧」とは一体...

**デフォルトの名無しさん** · 2024/11/21(木) 15:46:00.53

>>98
>そんなこと言いだしたら APFS も NTFS も単にバイト列を記録してるのに過ぎない。
いいえ

**デフォルトの名無しさん** · 2024/12/01(日) 10:32:32.38

UTF8を推しているのは形を変えたASCII信者の老害。

**デフォルトの名無しさん** · 2024/12/01(日) 11:15:01.77

刷新できていない古いシステムを除くと
文字コードはユニコードになったね

エンコーディングはネット上がUTF8なので
それをそのまま扱うのが一般的となったね

**デフォルトの名無しさん** · 2024/12/01(日) 12:39:57.84

UTF-8 より完璧な文字コードって何だい？
ASCII と SJIS と UTF-8 はいいねしたい

**デフォルトの名無しさん** · 2024/12/01(日) 20:40:24.45

なんか色々ごっちゃだな

**デフォルトの名無しさん** · 2024/12/02(月) 03:35:11.02

元のユニコードがクソだからなあ
結局どうにもならなくなって異体字セレクタとか出てくるし

**デフォルトの名無しさん** · 2024/12/02(月) 13:49:05.08

ishの出力ってSJISが標準？
utf-8板のish欲しいと思ったけど
-Dutf8付けてコンパイルしても結局SJIS出力だった

**デフォルトの名無しさん** · 2024/12/02(月) 14:10:00.90

バイトデータで出力してるだけでエンコーディング関係ないような
UTF-8対応してもバイト単位でみたら7ビットしか情報持てないから損
効率気にしないならコード変換したらいい
半角カナが3バイトになるけどエラー訂正なんかは使える

**デフォルトの名無しさん** · 2024/12/03(火) 12:52:43.59

たまたまSJISでデコードしたら人間に読める(かもしれない)ってだけで
只のバイナリデータだよね

**デフォルトの名無しさん** · 2024/12/04(水) 23:36:37.56

SJISとして不正なバイト列は含まれないはず

**デフォルトの名無しさん** · 2024/12/05(木) 16:18:11.64

ファイル名がユニコードだと、
例えば2つのファイル名が同一かどうかの判定は、２つのユニコード列が同一かどうかの
判定をしなくてはならない。この場合の同一とはなんだろう。めんどくさい

**デフォルトの名無しさん** · 2024/12/05(木) 16:59:22.16

>>111
「ユニコード列」みたいな曖昧な用語で考えると曖昧な結果にしかならなんわな

**デフォルトの名無しさん** · 2024/12/05(木) 17:16:36.01

「ファイル名」という用語に限ってもOSごとに異なる意味をもち、「バイト列/コードポイント表現」(Linux/Windows)と「 unicode 正規化表現」(MacOS)のどっちのやり方もあるし unicode の正規化には複数の種類がある

**デフォルトの名無しさん** · 2024/12/05(木) 19:21:14.57

>>103
ネットはJISもあるから、そう簡単な話ではない。

EメールだとまだJISが主流。

**デフォルトの名無しさん** · 2024/12/05(木) 19:22:28.03

>>113
Macのせいで記号や改行コードの解釈がめちゃくちゃになった。

**デフォルトの名無しさん** · 2024/12/05(木) 22:25:20.82

>>111はあえて雑に書いてあるんだが（めんどくさいからw）
>>113は「曖昧じゃない」んだ?

**デフォルトの名無しさん** · 2024/12/05(木) 23:11:23.50

見苦しいぞ

**デフォルトの名無しさん** · 2024/12/06(金) 10:53:27.12

ﾊﾝｶｸｶﾀｶﾅ.txtと
ハンカクカタカナ.txtは
区別されると困るか区別して欲しいかは個人の好みだな

**デフォルトの名無しさん** · 2024/12/06(金) 11:15:10.72

>>111,118
主観と好みの問題だから、現状がそれを孕んでいるかどうか心配ならNKFCで突合チェックしたら良いだけかな

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

>>118
自分はまったく別物だろうという考えだが、逆にそれを同じと思う人がいるというのに驚きだ

**デフォルトの名無しさん** · 2024/12/06(金) 14:57:12.37

MacOS/iOS だと OS 的にファイル名はNFD強制なのでその2つ区別できないのが普通だな
Macユーザーは「半角カナはファイル名には使えない」という言い方してることが多いけど

**デフォルトの名無しさん** · 2024/12/06(金) 15:08:33.92

Windowsは大文字小文字の区別を付けないのがデフォルトなんだけど、
WSL内からアクセスする兼ね合いで区別設定できる(fsutil)

>>121
Macにも同様の理由でNFD強制解除の設定があるのでは？

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

>>122
強制解除とかはなかったと思うが古い HFS+ と違って新しい APFS では論理的には書き込み可能なはず
一方でライブラリで、ファイルオープンする時にファイル名が強制的にNFD変換されるので通常のプログラムでは全部NFDになるのは避けられない

**デフォルトの名無しさん** · 2024/12/06(金) 20:10:41.64

Macが一番遅れているのは意外だな

> Mac で NAS (SMB) のファイルが見えない問題を Unicode 正規化方式を変えて解決
> Unicode 正規化方式として NFD を採用しているのは Mac なのに，SMB (NAS) を介してみると当の Mac だけがそういったファイルを認識できない（ことがある）というのはなんとも皮肉な結果ですね...。

**デフォルトの名無しさん** · 2024/12/06(金) 21:07:04.96

>>124
Mac はローカルファイルは NFD (っぽい独自仕様）で正規化されてる前提で、リモートのSMBの先は NFC （っぽい独自仕様）で正規化されている前提で動作するという謎仕様なので
Lunux は基本的に正規化されずに全部別の文字扱いで unicode の全文字が使える
Windows も基本的には正規化を前提にしていないが独自仕様の使えない文字がある

**デフォルトの名無しさん** · 2024/12/06(金) 21:22:50.16

わかりやすいようにたとえで説明するとさ、
オマエんちに人を招待したら、土足のまま上がってきた
オマエはイラっとするんじゃね? はいオマエ遅れてる～

**デフォルトの名無しさん** · 2024/12/06(金) 21:35:56.15

服装カジュアルな場所でも常にスーツ着てきてスーツ着てないやつは家族だろうと友人だろうと全員無視するのが Mac 仕草
その上、自宅用と訪問用に別の種類のスーツを使い分けてて同じ種類のスーツ着てないと相手してくれない

**デフォルトの名無しさん** · 2024/12/07(土) 10:53:50.76

UnicodeはUnicodeで様々な言語の様々な表現ができるようにするなかで一意性についても
用途や目的によって方法は異なるとしているわけで、そもそもファイルをファイル名で特定するという
昔ながらのやり方との齟齬が出てきているのかもね。
使うなら使うでファイルシステムに用いる正規化ルールなどを定めなければならないんだろう。

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

同一性やコロケーション問題として
path-win-ntfs、path-linux-ext4のようにunicodeでpath-localeを定めてicu実装されたら良いのにと思った事はあったけど、
それで他の方法が駆逐されるわけじゃなく新たなバリエーションを増やすだけだから、今は余計な事するなと思うよ

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

>>128
ファイル名はOS的には単なる識別子なのでバイト列一致で良い
それを文字コードと絡めて正規化しようとするのがそもそもの間違い
バイト列をどのように解釈するかは別のレイヤーの問題

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

FSとしてならそれでいい
OSをどの層までとするかでも変わってくるけど
マウント時に変換かけてOS間の相互運用気にしてほしい
ネットワーク透過考えるとパスはURIで扱いたいしね

**デフォルトの名無しさん** · 2024/12/07(土) 13:08:36.00

>>131
基本的にはアプリ側のライブラリ層でやるべきこと
OS標準ライブラリかユーザ追加ライブラリかはOSの思想によるし Linux とかだとOS標準ライブラリという考え方は縁遠いけど
マウントの時にファイルシステムで文字コード変換するのも否定しないけど、あくまで代替手段なので、固定ではなくオプションや設定で利用者で任意に変更できるべきもの

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

**デフォルトの名無しさん** · 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

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

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

>>278
どこで見たんだ？
技術的に変な提案したら通らないだろうが、それが規格を無視して良い理由にはならない
それを理由に脱退したんなら一理あるけど

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

規格があるのにそれを使わない分野なんて沢山ありそうだが
実際のところ金を出せて声がでかければ規格なんていくらでも通せるんだから

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

>>280
俺が見た記事は残ってないだろうけど検索したら出てきたunicode.org内の議事録はたぶんこれ
ttps://www.unicode.org/review/resolved-pri.html#pri7

**デフォルトの名無しさん** · 2025/01/31(金) 21:26:16.69

>>281
ヒデェ

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

>>282
ｗｗｗ
一部除外したら一貫性が無くなって正規化が正規化じゃなくなるから勝手な除外は駄目って明確に指摘されてるな
なんで実装したんだろう？いやVFとか使いたくなかったんだろうけど、

どうしてもやりたければ任意の除外ではなく VF のみ除外みたいなので再提案すべきだったのでは

**デフォルトの名無しさん** · 2025/02/16(日) 22:21:14.00

https://gigazine.net/news/20250214-unicode-hidden-message/
Unicodeでは一見すると普通の文字の中に「秘密のメッセージ」を埋め込むことが可能だという指摘

**デフォルトの名無しさん** · 2025/02/16(日) 23:51:54.49

>>285
なるほどね
https://i.gzn.jp/img/2025/02/14/unicode-hidden-message/03.png

**デフォルトの名無しさん** · 2025/02/17(月) 16:59:47.72

Unicodeはそのうちオーディオブック用やa11yで読み上げ音声用のVSが定義されそう

**デフォルトの名無しさん** · 2025/02/17(月) 17:34:45.48

漢字みたいな複数の読み方があるのは難しいだろうね

**デフォルトの名無しさん** · 2025/02/17(月) 18:36:11.68

MSOfiiceでIME入力がphoneticsとして保存されてて読み仮名表示出来るのは、他に広まっても良いのにな

**デフォルトの名無しさん** · 2025/02/18(火) 12:25:03.72

>>286
なるほどね
fn byte_to_variation_selector(byte: u8) -> char {
if byte < 16 {
char::from_u32(0xFE00 + byte as u32).unwrap()
} else {
char::from_u32(0xE0110 + (byte - 16) as u32).unwrap()
}
}

**デフォルトの名無しさん** · 2025/02/28(金) 17:04:23.70

fn byte_to_variation_selector(byte: u8) -> Option<char> {
if byte < 16 {
char::from_u32(0xFE00 + byte as u32)
} else {
char::from_u32(0xE0110 + (byte - 16) as u32)
}
}