文字コード総合スレ part15 (472ﾚｽ)
上下前次1-新
117: 2024/12/05(木)23:11 ID:+y5lu+gF(1) AAS
見苦しいぞ
118(2): 2024/12/06(金)10:53 ID:zw4qy2EX(1) AAS
ﾊﾝｶｸｶﾀｶﾅ.txtと
ハンカクカタカナ.txtは
区別されると困るか区別して欲しいかは個人の好みだな
119: 2024/12/06(金)11:15 ID:kzR0LSsc(1) AAS
>>111,118
主観と好みの問題だから、現状がそれを孕んでいるかどうか心配ならNKFCで突合チェックしたら良いだけかな
120: 2024/12/06(金)13:01 ID:tlsLperd(1) AAS
>>118
自分はまったく別物だろうという考えだが、逆にそれを同じと思う人がいるというのに驚きだ
121(2): 2024/12/06(金)14:57 ID:PqgirqmV(1/4) AAS
MacOS/iOS だと OS 的にファイル名はNFD強制なのでその2つ区別できないのが普通だな
Macユーザーは「半角カナはファイル名には使えない」という言い方してることが多いけど
122(1): 2024/12/06(金)15:08 ID:teqNcVuG(1) AAS
Windowsは大文字小文字の区別を付けないのがデフォルトなんだけど、
WSL内からアクセスする兼ね合いで区別設定できる(fsutil)
>>121
Macにも同様の理由でNFD強制解除の設定があるのでは？
123: 2024/12/06(金)17:09 ID:PqgirqmV(2/4) AAS
>>122
強制解除とかはなかったと思うが古い HFS+ と違って新しい APFS では論理的には書き込み可能なはず
一方でライブラリで、ファイルオープンする時にファイル名が強制的にNFD変換されるので通常のプログラムでは全部NFDになるのは避けられない
124(1): 2024/12/06(金)20:10 ID:77CvoLMD(1) AAS
Macが一番遅れているのは意外だな
> Mac で NAS (SMB) のファイルが見えない問題を Unicode 正規化方式を変えて解決
> Unicode 正規化方式として NFD を採用しているのは Mac なのに，SMB (NAS) を介してみると当の Mac だけがそういったファイルを認識できない（ことがある）というのはなんとも皮肉な結果ですね...。
125: 2024/12/06(金)21:07 ID:PqgirqmV(3/4) AAS
>>124
Mac はローカルファイルは NFD (っぽい独自仕様）で正規化されてる前提で、リモートのSMBの先は NFC （っぽい独自仕様）で正規化されている前提で動作するという謎仕様なので
Lunux は基本的に正規化されずに全部別の文字扱いで unicode の全文字が使える
Windows も基本的には正規化を前提にしていないが独自仕様の使えない文字がある
126: 2024/12/06(金)21:22 ID:XSDLieo6(1) AAS
わかりやすいようにたとえで説明するとさ、
オマエんちに人を招待したら、土足のまま上がってきた
オマエはイラっとするんじゃね? はいオマエ遅れてる〜
127: 2024/12/06(金)21:35 ID:PqgirqmV(4/4) AAS
服装カジュアルな場所でも常にスーツ着てきてスーツ着てないやつは家族だろうと友人だろうと全員無視するのが Mac 仕草
その上、自宅用と訪問用に別の種類のスーツを使い分けてて同じ種類のスーツ着てないと相手してくれない
128(1): 2024/12/07(土)10:53 ID:+zec5U9G(1) AAS
UnicodeはUnicodeで様々な言語の様々な表現ができるようにするなかで一意性についても
用途や目的によって方法は異なるとしているわけで、そもそもファイルをファイル名で特定するという
昔ながらのやり方との齟齬が出てきているのかもね。
使うなら使うでファイルシステムに用いる正規化ルールなどを定めなければならないんだろう。
129: 2024/12/07(土)11:21 ID:RCmjilK5(1) AAS
同一性やコロケーション問題として
path-win-ntfs、path-linux-ext4のようにunicodeでpath-localeを定めてicu実装されたら良いのにと思った事はあったけど、
それで他の方法が駆逐されるわけじゃなく新たなバリエーションを増やすだけだから、今は余計な事するなと思うよ
130: 2024/12/07(土)11:21 ID:prVW7qhX(1/3) AAS
>>128
ファイル名はOS的には単なる識別子なのでバイト列一致で良い
それを文字コードと絡めて正規化しようとするのがそもそもの間違い
バイト列をどのように解釈するかは別のレイヤーの問題
131(1): 2024/12/07(土)11:44 ID:3wlpERVS(1) AAS
FSとしてならそれでいい
OSをどの層までとするかでも変わってくるけど
マウント時に変換かけてOS間の相互運用気にしてほしい
ネットワーク透過考えるとパスはURIで扱いたいしね
132: 2024/12/07(土)13:08 ID:prVW7qhX(2/3) AAS
>>131
基本的にはアプリ側のライブラリ層でやるべきこと
OS標準ライブラリかユーザ追加ライブラリかはOSの思想によるし Linux とかだとOS標準ライブラリという考え方は縁遠いけど
マウントの時にファイルシステムで文字コード変換するのも否定しないけど、あくまで代替手段なので、固定ではなくオプションや設定で利用者で任意に変更できるべきもの
133: 2024/12/07(土)14:01 ID:8ekNK8XT(1) AAS
>他の方法が駆逐されるわけじゃなく新たなバリエーションを増やすだけ
ほんそれ
134: 2024/12/07(土)14:17 ID:Zwl6oBBL(1) AAS
まずはMacを駆逐しよう
135: 2024/12/07(土)16:00 ID:2Ddhf3xH(1) AAS
Mac で日本語を駆逐でいいんじゃね？
136(2): 2024/12/07(土)21:42 ID:1sWZyE4C(1) AAS
ファイル名にはASCIIにある文字しか使わないようにすれば解決
137: 2024/12/07(土)21:44 ID:prVW7qhX(3/3) AAS
>>136
ASCII のバックスラッシュが円記号になってしまう OS がるらしい
138(1): 2024/12/08(日)03:07 ID:h9KuPnHR(1) AAS
>>136
じゃあまずはASCII以外でここに書き込むのやめろよ
139: 2024/12/08(日)04:05 ID:Xxla/ZnP(1) AAS
>>138
ここにファイル名を書いてる人あまりいないと思うんだけど？
140: 2024/12/09(月)11:25 ID:uh4vUAM3(1) AAS
波ダッシュ（〜）と全角チルダ（〜）は違う文字
141(1): 2024/12/09(月)12:17 ID:Ne3E3UJU(1) AAS
JISで全角チルダ定義したのがアレだよな
全角しか表示できない場面のためだろうけど
142(1): 2024/12/09(月)14:00 ID:4HU/GnaT(1/3) AAS
>>141
JIS は全角と半角とか定義してない（定期
143(1): 2024/12/09(月)14:37 ID:+G8yezOA(1) AAS
>>142
えー、をMSIMEで変換したら
全角チルダ(U+FF5E)でした
抑揚のある伸ばし棒はこれが正解ですか？
144: 2024/12/09(月)15:02 ID:4HU/GnaT(2/3) AAS
>>143
知らん
MS が決めたことは MS に聞け
全角とか半角とか関係ない
145(1): 2024/12/09(月)17:46 ID:bX1qj24S(1) AAS
この板には表層的にMSを持ち出すだけで思考停止する若干一名がいるね
146: 2024/12/09(月)18:34 ID:4HU/GnaT(3/3) AAS
>>145
シフトJISの「波ダーシ」を unicode の「全角チルダ」にマッピングする CP932 を規定したのはマイクロソフト
マイクロソフト以外の Linux とか MacOS とかその他の各社OSではそうなっていない
マイクロソフトが何でこんなマッピングにしたのかは専門家でも分かんない謎
unicode がまだドラフトの時代にあわてて作業したのでミスっただけの可能性も指摘されてるが、一度決めたものは互換性のために変えられないのだろう点は理解できる
147: 2024/12/09(月)23:51 ID:TvtcjS7H(1) AAS
マイクロソフト憎しにも程がある
デマだめ絶対
148: 2024/12/13(金)01:50 ID:XDI5kMlm(1) AAS
マイクロソフトの場合親の敵の可能性があるから俺は許すね
気の済むまでじゃんじゃんやっといてくれ
149: 2024/12/13(金)02:14 ID:OiDxg/7M(1/2) AAS
unicode 規格が最初に作られた時サイトに参考情報として JIS と unicode のマッピング表が置いてあった
Linux も Mac も商用Unixもこの表に従ってJISの波ダーシを unicode の wave dash にマッピングした。さらに JISの規格書にもこのマッピングで記載された
ただ Microsoft 1社だけは JIS の波ダーシを unicode の fullwidth tilde にマッピングした
こんなんマイクロソフトの中の人以外に理由が分かるわけねーだろ
150(1): 2024/12/13(金)11:09 ID:ncXjn+FF(1) AAS
初期のUnicode仕様書の文字の形がおかしかったのがそもそもの原因なんだけどね
いまの仕様書では、〜（U+301C、波ダッシュ）は、～（U+FF5E、全角チルダ）と同じ字形だけど、
古いものは、上下反転した存在しない文字の形だったので、どちらに合わせるかを決める時点で、
MSは形の相似した全角チルダのU+FF5Eを、その他は仕様どおりの波ダッシュのU+301Cを割り当てた
更にMacは仕様書を無視して字形を変更し、現在の仕様書と同じようにU+301Cに本来の波ダッシュの形を割り当てた
ただ、上下反転した字形は、縦書きの際の全角チルダ（左右の順）文字を横書きにしたために紛れ込んだとも言われているので、
仕様書制定の段階で縦書きのある日本語を理解した人が加わっていなかったのだろうな
省3
151: 2024/12/13(金)11:39 ID:OiDxg/7M(2/2) AAS
>>150
仕様書も文字の形がおかしかったはネットの素人が勝手に推測した迷信、文字形は規定していない
文字コード的にはフォントで変わる文字の形は意味がない
unicode の wave dash は JIS 第一水準の波ダージなどに対応する文字として準備された
unicode の互換領域の fullwidth tilde は EUC-JP とかで使用されいたJIS補助漢字のチルダをマッピングするために準備された
EUC-JP では ASCII の1バイト文字のチルダと補助漢字の2倍と文字のチルダに両方が使われていたので互換領域が必要だった
152: 01/11(土)13:26 ID:ftPdDy1W(1/4) AAS
なんか文字コード絡みでWindowsに特大級のセキュリティホールが見つかったぽい
外部ﾘﾝｸ:blog.orange.tw
153(1): 01/11(土)13:36 ID:ftPdDy1W(2/4) AAS
CP65001で緩和可能ってことであってるよね?
超ヤバげなんでageるよ
154: 01/11(土)13:52 ID:wkEhpAnW(1) AAS
>>153
あってる
MSYS2を使ってれば2,3ヶ月前には対策の副作用があったから知ってたよ
メディアはもっとこれを大きく報じてユーザー環境にもUTF8ロケールが広まって欲しい
155: 01/11(土)15:04 ID:mk8LdH4O(1) AAS
やべーやつだこれ
終わったな...
156: 01/11(土)15:07 ID:MN266Dik(1/4) AAS
とうとう Windows の Best-Fit-Conversion が槍玉にあげられたか
これって多数の個別アプリの問題に矮小化されてきたけどどう考えてもOSの設計ミスにしかみえない
157: 01/11(土)16:08 ID:IZON3iKr(1/3) AAS
件のBestFit機能のせいで、
windowsバッチでフルパスが半角スペースなし全角スペースありだと、
どのようにクォーティングをしようともまともに動かなくなったわけか
158: 01/11(土)16:17 ID:PjVvqmiz(1/2) AAS
システム設定でUTF8にするとメモ帳でSJISテキストファイルが文字化けする訳だけど
この特需で伸ばす代替エディタは何か？
159: 01/11(土)16:20 ID:PjVvqmiz(2/2) AAS
場合によっては情シスがSJISテキストファイルリストアップツールを用意する事になりそう
160(1): 01/11(土)16:29 ID:IZON3iKr(2/3) AAS
UTF-8に設定すると、JaneStyleは今度こそ本当に使えなくなるんだよな
161(1): 01/11(土)16:37 ID:8GlegYBS(1/2) AAS
ファイル名に禁則文字を増やしても避けられないのだろうか？
162: 01/11(土)16:50 ID:SJ4Pziuh(1) AAS
これを機に932以外では文字化けするレガシーアプリは駆逐されれば良い
163: 01/11(土)17:11 ID:MN266Dik(2/4) AAS
>>161
ファイル名の禁則レベルでは無理
Unicode の一部の文字がバックスラッシュとか空白とかクォートとかの区切り文字や特殊処理する文字に化けるので、これを利用して入力を誤魔化せるという技
どう化けるかはコードページ次第
全部のアプリがユニコード対応になるか Windows が BestFit やめない限りは多くのアプリで同様の問題が量産される（オープンソース系のアプリはこれはOSの仕様のせいでアプリのバグじゃないので直すつもりはないとか言ってる）
UTF-8だとBestFit使われないので Windows 12 とかで SJIS とか Win-1521 とか捨ててデフォルトが UTF-8 になれば解決するけど
164(1): 01/11(土)17:17 ID:IZON3iKr(3/3) AAS
システムをUTF-8に設定した上で、
CP932なアプリについて、個別のマニフェストの"activeCodePage"を"CP932"することで使えるようにならないんだろうか？
165: 01/11(土)17:23 ID:MN266Dik(3/4) AAS
>>164
今のところできないし、できたとしてもその cp932 に設定したプログラムで BestFit による抜け穴が使われるリスクがある
166(1): 01/11(土)17:41 ID:8GlegYBS(2/2) AAS
ファイル名に英数字以外禁止したら何とかなりそうな気はした
167: 01/11(土)17:49 ID:MN266Dik(4/4) AAS
>>166
ファイル名だけじゃないから
コマンドのオプションスイッチとか、URL とか、環境変数とか、レジストリとか、とにかくプログラムの入力全部
168: 01/11(土)22:53 ID:ftPdDy1W(3/4) AAS
Windows全然詳しくないんだけど、Windows APIのANSI APIとUnicode APIとの違いって
標準Cライブラリの文字出力で言えばprintfとwprintfとの違いってことだよね?
世の中のOSSのほとんどはwprintf等のワイド文字関数なんて使っていないんだから
OSSをWindowsで動かした場合ほぼ全部WorstFitの影響を受けることになるはず
今後基本的にワイド文字関数で書くべきってなると、Hello Worldは
#include <stdio.h>
#include <locale.h>
省7
169: 01/11(土)23:28 ID:ftPdDy1W(4/4) AAS
あ、
int main(int argc, char **argv)
エントリーポイントの時点で引数がワイド文字じゃないから脆弱性の影響を受ける可能性があるのか
wmainがあるのはそういう理由なのね
170(1): 01/12(日)08:20 ID:xo4UH4ro(1) AAS
MS的には「いまだにワイド文字列使ってないアプリが悪い」なんだよな
171: 01/12(日)11:43 ID:2Lg/ICMd(1) AAS
>>170
最近は ANSI は UTF-8 に固定しろとか言い出してる
172: 01/12(日)12:45 ID:/g6mpPgl(1) AAS
>>160
Jane大好きマウイ君がウォームアップしてそう
ああ見えてフッ軽だから今度はflutterで作ったりしてなw
173: 01/13(月)13:47 ID:g4/CTboD(1) AAS
UTF-8に一本化されるなら嬉しいな
174: 01/13(月)21:19 ID:5zeCvv1K(1) AAS
Windows アプリで UTF-8 コード ページを使用する
外部ﾘﾝｸ:learn.microsoft.com
175: 01/13(月)23:50 ID:ux79df1f(1) AAS
初めから文字列はUTF-8と言語仕様＆標準ライブラリで決めてあるRustが楽でいいね
もちろん必要ならUTF-8以外も読み書き可
176: 01/17(金)17:07 ID:GO6/DX25(1) AAS
pythonも楽ちんちん
177(5): 01/18(土)03:52 ID:CaguG0TX(1/7) AAS
RustがWindowsでファイル名を扱う時のWTF-8、あれ脆弱性の元な気がするんだよな…
WTF-8状態でサロゲートペアの前後を結合してしまうとUTF-8のとはまた別の冗長表現が導入されてしまう
178(1): 01/18(土)09:40 ID:ryxfYm1H(1/5) AAS
>>177
気のせいじゃない？
規格どおり実装されてればUTF-8にサロゲートなんて概念は存在しない
最短表記のみが正式なので冗長性はないよ
179(1): 01/18(土)10:15 ID:CaguG0TX(2/7) AAS
>>178
UTF-8では違反なサロゲートの片方だけを許すのがWTF-8なので
正常なサロゲートペアをUTF-8に変換したときの4〜6バイト表現に対して
WTF-8ではペアの片割れを別々に変換して結合した3バイトのサロゲート片☓2な別表現が存在できてしまうでしょ
これらはUTF-16に戻したら同じ文字列になってしまうので
WTF-8で比較等の処理をしてUTF-16に戻すと脆弱性になっちゃう
180(1): 01/18(土)10:40 ID:ryxfYm1H(2/5) AAS
>>179
色々間違えてる
UTF-8では片側だろうと両方だろうとサロゲート領域のコードは許されてない。あったらUTF-8じゃない
サロゲート導入前の古いUTF-8規格を参照してるアホがいるだけ
UTF-8は最大長で1文字4バイト、それ以上長いのは今のUTF-8では許されない
ましてWTF-8とか名前変えてもユニコード規格の対象外、UTF-8ではない
181: 01/18(土)10:44 ID:CaguG0TX(3/7) AAS
>>180
最初っからWTF-8って言ってるじゃん
182: 01/18(土)10:49 ID:CaguG0TX(4/7) AAS
Windowsのファイルシステムでは文字コードとしては不正なバイト列がファイル名として存在できる
それを8バイト文字列で無理やり扱うためRustではWTF-8という本来エラーになる表現も許容した規格違反UTF-8を使っている
OK？
183: 01/18(土)11:09 ID:ryxfYm1H(3/5) AAS
だから WTF-8 は UTF-8 とは違う
別物なんだから混同しなければ脆弱性にはならない
184: 01/18(土)11:15 ID:CaguG0TX(5/7) AAS
Rustではファイル名をWTF-8で扱うけどWTF-8で文字列処理すると危なくね？ってそれだけの話だよ
UTF-8の話と混同して絡んできたのはあんたじゃね
185: 01/18(土)11:27 ID:7Jaib8zo(1) AAS
m1Hは馬鹿ちんちん
186: 01/18(土)11:33 ID:ryxfYm1H(4/5) AAS
WTF-8 の文字列を UTF-8 の比較関数とかで処理しようとしてもうまくいかない → 当たり前
これは脆弱性ではないし、冗長性も関係ない
ここまでは理解できてるんだよな？
WTF-8 が別規格なんだからそれ専用の処理コードが必要ってだけだろ
UTF-8ではないので混同するなって話
187: 01/18(土)11:36 ID:CaguG0TX(6/7) AAS
もう自分が何書いてるかもわかってなさそう
もう一度読んで？
188(1): 01/18(土)11:44 ID:rGNNXTeE(1/2) AAS
横通ります
Rustではディレクトリを開いてスキャンしたら各ファイル名はWTF-8とやらのスライスなのか？
189(1): 01/18(土)11:46 ID:rGNNXTeE(2/2) AAS
それとLinuxのファイルシステム自体もUTF-8文字コードを外れてもOKだから、Windowsに限った話ではないかと
LTF-8もあるのか？
190(2): 01/18(土)12:03 ID:CaguG0TX(7/7) AAS
>>188-189
型としてはOsStringとしてラップされてて、中身を取り出したらWindowsではWTF-8
不正な文字コードが入りうるのはどのOSでも同じだけどバイト列そのままな他OSと異なりWindowsだとUTF-16との変換も挟まって危なそうだなあって
(ちなmacOSやあとBSDのzfsなんかだと不正な文字コードは最初から入らないらしい？)
191: 188-189 01/18(土)12:30 ID:ZXpOcGU5(1) AAS
>>190
なるほどね納得
不正な文字コードに遭遇したら処理を進めないで即座にエラーにするが良さそう
問題は処理系がちゃんと不正な文字コードを感知するかどうかだけど、
WindowsでA系APIを使っていれば(RawワイドストリングのUTF-16解釈が試みられて)
不正なパラメータエラーとかで(ディレクトリスキャン時などの)早期に発見できそうな気がする
192: 01/18(土)12:32 ID:ryxfYm1H(5/5) AAS
なんだろうな？
UTF-8: 片サロゲートも両サロゲートも不可
WTF-8: 片サロゲートのみ可、両サロゲートは不可
CESU-8: サロゲート展開必須
という区別がちゃんとついてるんだろうかという疑問、これら混ぜれば冗長だが…
単独で冗長と言われても具体性がない
193: 01/20(月)21:45 ID:fFffNKjx(1/9) AAS
勘違いしてる人がいるため正しい情報
まずRustの文字列つまりstr型とString型はvalidなUTF-8のみであることが必ず保証されている
そこには当然サロゲートもなければinvalidなUTF-8もないため問題は一切起きない
そこにWTF-8など他のものが混ざることも絶対にない
つまりどんな文字列操作をしても冗長表現のない
validなUTF-8となる安全が保証されている
つづく
194: 01/20(月)21:46 ID:fFffNKjx(2/9) AAS
次に言語とは関係ない話
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となる
つづく
195(1): 01/20(月)21:47 ID:fFffNKjx(3/9) AAS
UTF-16⇔UTF-8は常に可逆に変換できる
前述のWTF-16に対しても同様に可逆となるものとしてWTF-8が考えられる
つまりWTF-16⇔WTF-8は常に可逆に変換できる
前述のWTF-16⊃UTF-16と同様に
WTF-8⊃UTF-8となる
このWTF-8はあくまでもWTF-16との可逆を保証するための内部表現であり外で使われることはない
つづく
196: 01/20(月)21:48 ID:fFffNKjx(4/9) AAS
このWTF-8には以下の利点がある
・WTF-16(＝任意の16bit列)と可逆に1対1に変換できる
・元のWTF-16がUTF-16のみの場合は対応するWTF-8はUTF-8のみとなる
・特に元がアスキー文字のみならば対応するWTF-8は7bitアスキー文字となる
集合関係はWTF-8⊃UTF-8⊃7bitアスキー文字となる
つまり内部表現として非常に使い勝手が良いものとなっている
つづく
197: 01/20(月)21:49 ID:fFffNKjx(5/9) AAS
そしてようやく再びRustの話
Rustでは言語の外の世界とをつなぐFFI (Foreign Function Initerface)の一つとして
OS環境依存の文字列型としてOsString型とOsStr型がある
これはvalidなUTF-8文字列型であるString型とstr型にそれぞれ対応する
集合的にはOsString⊃StringとOsStr⊃strとなりinvalidなUTF-8を含む分だけ大きな集合を表す
Windows環境ではこの内部表現として前述のWTF-8が使われている
つづく
上下前次1-新書関写板覧索設栞歴
あと 275 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.019s