文字コード総合スレ part15

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

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

**デフォルトの名無しさん** · 2024/11/09(土) 23:59:10.46

0xBEEFとBEEFは表現は違うけどどちらも16進表記で指してる値は同じ
10進表記の48879も同じ値を指す
Unicodeのコードポイントってのは値を指してる
だからなんやねんだけど

**デフォルトの名無しさん** · 2024/11/10(日) 02:50:29.80

>>70
「U+」の部分はUTF-8だという意味

**デフォルトの名無しさん** · 2024/11/10(日) 03:16:28.77

>>73
コードポイントとエンコードの区別が付かない男の人って

**デフォルトの名無しさん** · 2024/11/10(日) 12:29:54.80

>>68 ≒ >>73
これはひどい

**デフォルトの名無しさん** · 2024/11/10(日) 16:10:50.24

Cスレの通りにやって文字出力したら化けるんだけど、文字コード民的な正しい対処法は？
ちゃんとソースファイルがUTF-8なのは確認した

https://mevius.5ch.net/test/read.cgi/tech/1721137434/350

#include <windows.h>

int main(void)
{
LPTSTR lptStr = TEXT("テスト😊");
printf("%s\n", lptStr);
}

**デフォルトの名無しさん** · 2024/11/10(日) 16:20:39.17

win32でのAやW、charとwchar_tの事は分かっていて
Linux他でのクロスコンパイルを考えてwchar_tは使わずにUTF-8 everywhereで通しつつ

puts("テスト😊");

が文字化けしない様にしたい
特定システムロケールは仮定せず
ターミナルではchcp 65001してある
場合です

**デフォルトの名無しさん** · 2024/11/10(日) 16:47:24.57

端末がUTF-8非対応なのはないとして
出力をファイルへリダイレクトするかダンプして
想定どおりのバイト列か確認してみては？

**デフォルトの名無しさん** · 2024/11/10(日) 16:48:25.69

C詳しくないんで、正しい対処法は知らんけど、どこの通りで手元で出力できた。

https://www.reddit.com/r/C_Programming/comments/1adv86p/how_do_i_print_a_penguin_emoji_in_c_language/?rdt=48269

**デフォルトの名無しさん** · 2024/11/10(日) 16:48:33.88

分かってるならなんでLPTSTRから変換せずに使ってんの

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

具体的な回答のリンクにできてなかったんで張り直し
これの前半のほうやね
https://www.reddit.com/r/C_Programming/comments/1adv86p/comment/kk5vdm1/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

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

>>78-81
ありがとうございます

putsで文字化けしていたのは、コマンドラインでソースutf-8指定したら文字化けは直りました
だけど、引数が受け取れないですね

#include <stdio.h>

int main(int argc, char **argv) {
puts("テスト0😊");
for (int i = 1; i < argc; i++)
puts(argv[i]);
}

$ cl -utf-8 ConsoleApplication1.c
$ ./ConsoleApplication1.exe テスト1😊 テスト2😊
テスト0😊
???1??
???2??

$ ./ConsoleApplication1.exe テスト1😊 テスト2😊 > out.txt
$ cat out.txt
テスト0😊
???1??
???2??

(システムロケールEnglishでの環境です)

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

デバッグで確認したところ、引数のテスト1😊 テスト2😊は受け取りの時点(argv[i])でアルファベット以外の各コードポイントが?になってます

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

WindowsTerminal
MSYSTEM=UCRT64のMSYS2 bashです

$ echo テスト1😊 テスト2😊
テスト1😊 テスト2😊

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

$ gcc ConsoleApplication1.c
$ ./a.exe
テスト0😊

$ ./a.exe テスト1😊 テスト2😊
Error: Command line contains characters that are not supported
in the active code page (1252).

UTF8 everywhereは厳しいですかね?

**デフォルトの名無しさん** · 2024/11/10(日) 19:10:18.70

WindowsでワイドキャラクタってのはUTF16LEのことだよ？

**デフォルトの名無しさん** · 2024/11/10(日) 20:20:44.02

UTF-8 everywhere行けました

$ cat utf8.rc
#include "winuser.h"
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "utf8.manifest"

$ cat utf8.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings";>
<activeCodePage>UTF-8</activeCodePage>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>

$ cl -utf-8 ConsoleApplication1.c
$ mt.exe -nologo -manifest "utf8.manifest" -outputresource:"ConsoleApplication1.exe;#1"
$ ./ConsoleApplication1.exe テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

$ windres --input utf8.rc --output utf8.res --output-format=coff
$ gcc ConsoleApplication1.c utf8.res
$ ./a.exe テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

**デフォルトの名無しさん** · 2024/11/10(日) 22:05:14.87

>>87
下記の手続きを適用したってことなのかな？

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

**デフォルトの名無しさん** · 2024/11/11(月) 06:32:20.07

はい、検索して適当に拾ってきたのでxmlnsが微妙に違いますが同じことですね

MinGW64ツールチェーンではutf8.rcを経由してマニフェスト埋め込みしてますが
MSVCツールチェーンではその経路だとこうなります

$ rc utf8.rc
$ cl -utf-8 ConsoleApplication1.c utf8.res

ついでにPythonでもやってみました

$ cat ConsoleApplication1.py
import sys
print("テスト0😊")
for s in sys.argv[1:]:
print(s)

$ python313.exe ConsoleApplication1.py テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

環境変数がセットされてたので強制的に空にしても問題ないようです
$ PYTHONIOENCODING= PYTHONUTF8= python313.exe ConsoleApplication1.py テスト1😊 テスト2😊
テスト0😊
テスト1😊
テスト2😊

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

スレ汚しでしかない

**デフォルトの名無しさん** · 2024/11/11(月) 13:27:25.94

>>90
まあ、あの荒れそうな言語がユニコード引数でエラー出すからな

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