文字コード総合スレ part15

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

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

**デフォルトの名無しさん** · 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文字同士になっても可逆対応だよ
別表現なし
何を問題視しているのかな