Win32API質問箱 Build125

**デフォルトの名無しさん** · 2019/02/27(水) 15:09:08.64

Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build124
http://mevius.5ch.net/test/read.cgi/tech/1510395780/
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2019
http://mevius.5ch.net/test/read.cgi/tech/1548765663/
Visual Studio 2017 Part6
http://mevius.5ch.net/test/read.cgi/tech/1528645068/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】
http://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2019/11/26(火) 14:46:41.11

プロファイル壊されるってゆーてるリンクの連中だけが情報量ゼロなの草

**デフォルトの名無しさん** · 2019/11/26(火) 14:53:48.35

結局W系で作るしかないんだから余計なことは考えなくていいよ

**デフォルトの名無しさん** · 2019/11/26(火) 14:54:37.98

fopen()の振る舞いで困るかも。Win32のfopen()はutf8を特別扱いするから。

**デフォルトの名無しさん** · 2019/11/26(火) 14:56:55.82

レジストリの読み書きも気になるな

**デフォルトの名無しさん** · 2019/11/26(火) 15:01:36.94

>>671
いわゆるバイナリモードを使うとBOMがついてきちゃうとか、
いろいろトラブルが発生する可能性はあるね
前回のアップデートでもコンソールで文字化けする問題があったし

それをざっくり言えば、古いアプリを捨てるか、設定変えんな、
という話になるだろ
APIオタクと運用を見てる人で視点が違うことを理解しなよ

>>668
>まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても

それは契約文書にきちんと盛り込むべきだね

**蟻人間** ◆T6xkBnTXz7B0 · 2019/11/26(火) 15:25:37.49

MultiByteToWideChar/WideCharToMultiByteの第一引数にシフトJISコードページ932を指定しないといけないらしい。CP_ACPだと死ぬ。

**デフォルトの名無しさん** · 2019/11/26(火) 15:33:53.01

>>672
壊されないよ。日本語が化けることはあっても
それは想定とは違うデータが入っただけだし
アプリの問題

**蟻人間** ◆T6xkBnTXz7B0 · 2019/11/26(火) 15:37:00.29

シフトJISテキストファイルにUTF-8テキストが混ざったら、そりゃ文字化けするでしょう。

**デフォルトの名無しさん** · 2019/11/26(火) 15:56:07.44

>>679
無茶苦茶になるよな
ありえんわ

**デフォルトの名無しさん** · 2019/11/26(火) 16:01:44.16

コードページを変えると文字化けするだろうね
それだけの話。別に動かなくなるわけじゃない。
コードページをもとに戻せば動く
壊れたデータは直せばいいだけ

**デフォルトの名無しさん** · 2019/11/26(火) 16:02:07.57

main()に渡される引数文字列argvどうなります？

**デフォルトの名無しさん** · 2019/11/26(火) 16:23:03.19

自前で先行バイト検出しながら文字列書き換えるような関数とか如何すんのよ

**デフォルトの名無しさん** · 2019/11/26(火) 16:23:44.61

>>682
Unicode非対応アプリのmainだとして、

Unicode対応アプリ（からUnicode APIを使って）呼び出せば、引数全てがUTF-16からUTF-8に変換されてから
呼び出される。Unicode非対応アプリから呼び出せば、渡した文字列（バイト列）がそのまま渡される。

そこは今までと変わらない。今までもUnicode対応アプリから呼び出せば、設定されたコードページ（例えばcp932）に
変換されて呼び出される。違いはUTF-16からUTF-8だと変換できない文字がないので文字化けは一切発生しない。

なお、渡されたからと言ってアプリが正しくその文字列を扱えるかどうかは別の話
結局の所cp932専用で作られたアプリは完全に同じようには動かない。（ASCIIの範囲でなら問題ないだろう）

**デフォルトの名無しさん** · 2019/11/26(火) 16:25:08.09

>>683
実装と場合（データ）によるとしか言えない。
Unicode（UTF-16）非対応の古いアプリは、想定したコードページでしか
まともに動かない。それだけの話だよ。

**デフォルトの名無しさん** · 2019/11/26(火) 16:25:51.97

あと、システムプロファイルとか意味不明。
何の話をしてるのかわからないレベル。

**デフォルトの名無しさん** · 2019/11/26(火) 16:30:59.10

ちなみにUnicodeから非Unicodeへの変換は変換できない文字があるから一部文字化けするが、
非UnicodeからUnicodeへの変換では文字化けすることはない。

だから、cp932を扱えるアプリがcp932でレジストリ（UTF-16）に書き込んでも
適切に変換が行われるし、そのアプリがUTF-8を使えるなら、それもレジストリに書き込んでも壊れたりしない。

例えばアプリ（cp932）からレジストリ（UTF-16）に書き込んで、
レジストリ（UTF-16）をアプリ（UTF-8）から参照することは問題なくできるということ

**デフォルトの名無しさん** · 2019/11/26(火) 16:32:48.14

>>685
非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
そこにUTF-8とかねじ込まれても困るわ

**デフォルトの名無しさん** · 2019/11/26(火) 16:32:49.98

もちろんレジストリ（UTF-16）をアプリ（cp932）で参照したときは扱えない文字列があるが、
それはファイル名（UTF-16）をアプリ（cp932）で扱えない文字があるという程度の話でしか無い。

**デフォルトの名無しさん** · 2019/11/26(火) 16:35:04.40

マルチバイト文字を含むファイルパスが鬼門でしょ。

**デフォルトの名無しさん** · 2019/11/26(火) 16:38:45.15

>>688
お前は意味がわかるように書き込め

> 非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
どういう使い分けがされてるのか書け

> オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
それって引数がWCHAR *ならW系が使われて、引数がCHAR *ならA系が使われるってだけだろ

> そこにUTF-8とかねじ込まれても困るわ
そこにってどこよ？何が困るんだよ。
UTF-8はCHAR*を使うって理解してるか？
今までA系はASCIIだけでなくSJISや多数の文字コードで使われていたというのに
UTF-8が増えたごときで何も困らんだろ

**デフォルトの名無しさん** · 2019/11/26(火) 16:41:18.53

>>690
鬼門っていうか、単にUnicode非対応のアプリは
想定しているコードページに変換できない文字を扱えないってだけだけどな
たったこれだけのことなのに何をグダグダ言ってるのかわからん

**デフォルトの名無しさん** · 2019/11/26(火) 16:56:51.07

バッチファイルは厄介。あればだが。

**デフォルトの名無しさん** · 2019/11/26(火) 16:59:13.07

>>684
UTF8アプリなんて存在するんだっけ？

**デフォルトの名無しさん** · 2019/11/26(火) 17:02:23.79

>>691
たとえUnicodeに対応しているプログラムであっても何らかの出力ファイルをSJISで出力するような構造だと、
それを勝手にUTF-8に書き換えられたら次読み込んだ時滅茶苦茶になるだろ
一般的なテキストエディタも勝手に文字コード変えるような事はせんからな

**デフォルトの名無しさん** · 2019/11/26(火) 17:12:43.83

>>694
まずないだろうね。作れるようになったのは最近だし。
念ために言っておくけど、ないっていうのは
Unicode対応アプリではない（＝A系APIを使う）かつASCII文字としてUTF-8を使うアプリのことね。

UTF-8はUnicodeだろというツッコミはいらん。
WindowsにおいてUnicode対応とはUTF-16アプリのこと

最近Unicode非対応の古いアプリでもUTF-8が使えるようになったから、
古いアプリをUTF-8用として作り直して新しくすることでA系のまま
Unicode対応にできるとかいうジョークのような話ｗ

それするぐらいなら最初からUnicode対応として.NETとかで作りますわ。
完全に将来のLinuxアプリなどの移植用。多分最終的にマニフェストとかで
このアプリはUTF-8アプリですって指定できるようになるんじゃない？

**デフォルトの名無しさん** · 2019/11/26(火) 17:13:45.02

>>695
だからなんなんだよ？
当たり前の話するな。OSともアプリとも関係ない話だわ
LinuxでもMacでも同じことは起きるわ。だからなんだんだよ

**デフォルトの名無しさん** · 2019/11/26(火) 17:14:18.74

結論を書け結論を。お前がいいたいこが何かを書け。

**デフォルトの名無しさん** · 2019/11/26(火) 17:16:25.46

>>698
勝手に文字コードを変えんなってだけやろ
利用者の意思で変えさせろと

**デフォルトの名無しさん** · 2019/11/26(火) 17:44:52.60

>>698
勝手に変えてない。お前は馬鹿なのか？

**デフォルトの名無しさん** · 2019/11/26(火) 17:48:56.90

クッソ伸びてて草

MBSCなソフトがA系APIでデータ読み書きしてたら非対応のUTF8に書き換わってて、
以降データが文字化けしたまま困ることになるんだから、元に戻せばOKとか非対応なんだから
仕方ないとか、こればかりは擁護不可能の的外れ
表示だけの問題じゃなく記録データにも影響があって、こいつばかりは復元ソフトでも組まないと戻せない

MBSCなソフトは使えないだけならば、単純にA系APIを廃止すればいいだけなんだが
MSはお節介にもどうにかして過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
用意したって点だけ見ても、単純に非対応とか元に戻せばいいというような話ではない

年末にお父ちゃんから、古い宛名印刷ソフトのデータが壊れたって連絡が来るかも知れないくらいには、
時と場合によっては取り返しが付かない

今のところデフォでこの切り替えは無効だが、将来もしかしたら～というのが現時点でのキモだろう

**デフォルトの名無しさん** · 2019/11/26(火) 17:59:10.05

>>701
そんな長々と書かなくても、
SJISのファイルにUTF-8で書き込んだら文字化けしたのと同じことでしょ
そんなのLinuxでもmacOSでも起きる問題だって言ってるんだが

**デフォルトの名無しさん** · 2019/11/26(火) 18:00:34.44

>>701
> 過去資産を活かしてやろうってことでA系の挙動を変える選択肢を

意味不。単にUTF-8にも対応したってだけ
コードページを一つ増やしたに過ぎない。
A系の挙動は昔から設定で変更できた。

**デフォルトの名無しさん** · 2019/11/26(火) 18:02:42.72

もしかしてこいつは、ユーザーが設定変更しなくても
アップデートで勝手にUTF-8に変わるとか思ってるのか？
ならものすごくマヌケだｗ

**デフォルトの名無しさん** · 2019/11/26(火) 18:12:52.84

あー、アホが一人混じってるから伸びてるのか
把握

**デフォルトの名無しさん** · 2019/11/26(火) 18:18:38.91

今度はレスしなかったところを見ると図星だったか

**デフォルトの名無しさん** · 2019/11/26(火) 18:39:40.59

>>700
編集して上書きしたらUTF-8に変るんじゃなく新規での作成がUTF-8になるだけ？
それなら俺の誤解だったわ

勝手に変えるのなら死ねだが

**デフォルトの名無しさん** · 2019/11/26(火) 18:49:29.78

本当にアホだったな。ユーザーが意図的に変えない限り変わらないってのに

**デフォルトの名無しさん** · 2019/11/26(火) 18:55:32.97

論旨はは>>638よりは>>648みたらはっきりしてる

”安易に設定変更したらA系使ってるソフトが恐い”ってことだけであって、”問題ない”
と連呼してるアホ一人が理解力0というかマイナスなだけ

**デフォルトの名無しさん** · 2019/11/26(火) 18:55:56.87

しかもエアプなんだろうな。

>>638は古い情報で、

そもそも「ベータ: ワールドワイド言語サポートで Unicode UTF-8 を使用」の設定と
『メモ帳の文字コードと全く関係ない』話だってのもわかってないんだろう

『当時』はたまたまそこの設定がデフォルトになっていただけで、
今は常にUTF-8（BOMなし）

メモ帳は古いアプリでもなんでも無いしな
で、メモ帳が保存するテキストファイルの文字コードと
古いアプリの挙動も全く関係ない話。そんなの考えるまでもなくわかること

こいつずっとテキストファイルのデフォルトの文字コードと
APIの話をごっちゃにしてたのかよ

完全に素人だ

**デフォルトの名無しさん** · 2019/11/26(火) 18:58:15.43

>>710
言っとくが俺と>>701は別人だからな

**デフォルトの名無しさん** · 2019/11/26(火) 18:58:43.20

>>709
>”問題ない”と連呼してる

連呼の意味わかってる？ｗ

”問題ない”で >>638以降のレスを探すと
>>684で一回しか書いていない。しかも関係ない話

お前は思い込みが激しいってことがはっきりわかったな

**デフォルトの名無しさん** · 2019/11/26(火) 19:05:03.16

はい、論点誤魔化してきたね
未だに文字化けする程度の認識しかしてないから、話するだけ無駄だと思うよ
メモ帳とか連呼の定義とか持ちだしてきてもう意味不明

そもそもWinAPIのプログラムも組んだことないの丸わかりだから、キチガイに付き合うだけ損

**デフォルトの名無しさん** · 2019/11/26(火) 19:05:29.42

例えば標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
そんなの使ってたら、ファイル前半はシフトJIS、後半はUTF8になって、どっちでも読めなくなる
これは極端な例だけど同じようなことはそこら中で起こりえる

**デフォルトの名無しさん** · 2019/11/26(火) 19:05:45.18

メモ帳・・・・？
ヤベえなこいつ

**デフォルトの名無しさん** · 2019/11/26(火) 19:09:39.48

だんだん論点ずれてきてるやん

**デフォルトの名無しさん** · 2019/11/26(火) 19:09:52.88

>>709
んだ

>>714
そうだね
単純にそういう話になると思ってたんだが、このスレでこのレベルの未経験者が話しに入ってくるとは思わなかった

**デフォルトの名無しさん** · 2019/11/26(火) 19:11:27.01

はぁ、リンク先も読んでないのかよ

>>638のリンク先読めよ・・・

https://twitter.com/MurakamiShinyu/status/994781934407553024
> 今までデフォルトでShift JISだったもの（メモ帳をはじめ…）が
> この設定をすると「メモ帳」の「名前を付けて保存」で「文字コード: ANSI」
> （デフォルト）だとBOM無しのUTF-8、「文字コード: UTF-8」だと
> BOM付きのUTF-8のファイルになります。

↑注意これは古い話で今は当てはまらない
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2019/11/26(火) 19:12:17.71

>>717
> 単純にそういう話になると思ってたんだが、

その話は当たり前で、LinuxでもmacOSでも同じことになると
さんざん言ってる

**デフォルトの名無しさん** · 2019/11/26(火) 19:17:08.27

ちなみに
> 標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
これはコードページとは何の関係もない。

当たり前だがSJISで出力してるアプリは、
コードページをどう変更しようが、SJISで出力される。

「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
チェックを入れたところで、SJISで出力してるアプリが
UTF-8で出力するように変わることはない。

**デフォルトの名無しさん** · 2019/11/26(火) 19:18:48.31

設定変更しなければ良い、ってのは利用者の目線で開発者の発想ではないわな

◆QZaw55cn4c · 2019/11/26(火) 19:19:13.34

>>658
＞A系アプリってなんだ？ A系っていうのはWindows APIのAPIの末尾のAだろ
＞Windows APIの話なんだからWindowsの話だろ？

win32api には同じ api 関数に対して A 系と W 系の二つの異なった関数が準備されているんです
A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います

◆QZaw55cn4c · 2019/11/26(火) 19:20:16.92

>>674
win32api に fopen は存在しません、CreateHandle ならば存在しますが

**デフォルトの名無しさん** · 2019/11/26(火) 19:21:22.69

もちろん、「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
の設定（コードページ）を見て、アプリ内部でその文字コードに変換して
出力するように作られてるアプリは別な。
あくまでA系APIを使ってるアプリの話

SJIS前提で作られてるアプリは、SJISでしか出力しません。
ただしAPIがUTF-8前提として処理するのでASCII以外だと
出力がおかしくなります。

**デフォルトの名無しさん** · 2019/11/26(火) 19:22:46.52

>>722
> A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います

うんしってる。そして新設された「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
というのは、A系を使ってASCII互換のUTF-8を使えるようになる機能です。

◆QZaw55cn4c · 2019/11/26(火) 19:22:59.57

問題のオプションが A系 W系に関係するものか、誰か見解を出していただけませんか？

◆QZaw55cn4c · 2019/11/26(火) 19:24:22.44

>>725
thanks!

**デフォルトの名無しさん** · 2019/11/26(火) 19:25:39.71

>>718
>>648読んでる？
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。

>>719
> その話は当たり前で、LinuxでもmacOSでも同じことになると
> さんざん言ってる
今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？

>>720
> 当たり前だがSJISで出力してるアプリは、
> コードページをどう変更しようが、SJISで出力される。
君は、
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
これ自体がウソだって言ってるんだね？
ダラダラ連投せずに、そう書けば？

**デフォルトの名無しさん** · 2019/11/26(火) 19:26:51.40

>>728
> 今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？

だから他のOSでも起きる、SJISのファイルにUTF-8で書き込むと壊れるという話を
ごちゃまぜにするなと言ってる。

それはWin32APIと関係ない話だと言ってるだけ

**デフォルトの名無しさん** · 2019/11/26(火) 19:32:03.78

>>729
> SJISのファイルにUTF-8で書き込むと壊れるという話を
なぜそのようなことが起こるのか、どういうきっかけで起こるのか、影響範囲はどうなっているのか、
A系APIの挙動が変わるからだ

という話なだけでしょうが
他のOSを例に出す意味がない

君の主張は、APIの挙動は変わらないということなんだね？
要点をまとめなよ

**デフォルトの名無しさん** · 2019/11/26(火) 19:36:44.09

>>728
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
「ダウト」なのの１つ目は「半端ねぇ」の部分。

A系APIは昔から、コードページの設定をみてそのコードページの文字コードを
前提として処理している。昔から当たり前のことで今更驚くことじゃない。

英語ならASCIIを前提として処理するし、日本語に設定すればSJISを前提として
処理するするようになるし、韓国語や中国語にすれば、その国文字コードを前提して処理する。
20年以上そういう機能だった。

そしてもう一つはI/Oするって所。APIが設定に応じた文字コードを前提とするだけで別にI/Oするわけじゃない。
どの文字コードを使うかはアプリによる。SJIS専用のアプリはSJISしかI/Oしない。
UTF-8を前提としてる状態でSJISを流すとおかしくなるというだけで、
それらのAPIがUTF-8でI/Oするように変わるわけじゃない。

（エラーメッセージとかはSJISのリソースを使うようになるが、
これはAPIが変換してるわけじゃなくコードページに応じたリソースに変えてるだけ）

**デフォルトの名無しさん** · 2019/11/26(火) 19:40:06.72

>>730
要点　「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」の設定によるAPIの挙動と
アプリが入出力する文字コード（ファイル等を含む）は関係は一切ない
アプリが入出力する文字コードはアプリの実装によって決まる。
（Win32 APIと関係ないから、他のOSも同じという話につながる）

**デフォルトの名無しさん** · 2019/11/26(火) 20:15:32.91

APIの挙動変るのはやっぱヤベーな
iniから文字列を取り出す >UTF-8
今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
これを利用したディレクトリトラバーサルとかも可能なんじゃね？

**デフォルトの名無しさん** · 2019/11/26(火) 21:07:20.59

まずは公式ドキュメントを読め
話はそれからだ

Visual C++ のテキストと文字列
https://docs.microsoft.com/ja-jp/cpp/text/text-and-strings-in-visual-cpp

◆QZaw55cn4c · 2019/11/26(火) 21:10:43.31

>>734
VC のドキュメントがなんの役に立つ？

**デフォルトの名無しさん** · 2019/11/26(火) 22:34:01.39

他のソースはないかな。
βとはいえMSが単なるロケールの追加じゃなくてそんな過激なスイッチを導入しようとする意図がよくわからん。

**デフォルトの名無しさん** · 2019/11/26(火) 23:00:16.55

英語圏だと切り替えても英語入出力だけするなら何も変わらないしメリットの方が多い
日本語圏じゃデメリットしかないがｗ

**デフォルトの名無しさん** · 2019/11/26(火) 23:01:00.12

>>719
> その話は当たり前で、

本当？
SJISアプリをUTF-8アプリとして動作させるんだぜ？
printf("あほまぬけ\n"); こんなアプリがあったときに、
設定前と設定後で出てくる文字コードが違うんだぜ？
Linuxでそんなことが起こるかよ。

**デフォルトの名無しさん** · 2019/11/26(火) 23:03:08.88

>>737
シングルバイトアプリがマルチバイトアプリとして動くわけ？
もっと変なことになるだろそれ

**デフォルトの名無しさん** · 2019/11/26(火) 23:32:37.50

_tcsincなんかマルチバイト前提にしか使わないような関数だろ
どんな挙動になるんだ

**デフォルトの名無しさん** · 2019/11/26(火) 23:33:44.60

「ワールドワイド言語サポートで Unicode UTF-8 を使用」にチェックを入れ
なければUnicode非対応のアプリは従来通り動くし、これにチェックを入れな
ければ動かない既存のアプリっていうのも現状では無いんでしょう？

非対応アプリを対応させるのに要するコスト以上の利益が今後見込めるなら
アプリ開発元も対応させるだろうけど、そうでないなら放置されるんじゃ
ないかなあ。

MSがUnicode非対応アプリを切り捨てるようなことをすれば、Windows離れ
(＝パソコン離れ)が進むだけでしょ。

**デフォルトの名無しさん** · 2019/11/26(火) 23:36:26.55

CP1252のアプリにUTF8突っ込まれてもやっぱり困るだけだよなぁ。

**デフォルトの名無しさん** · 2019/11/26(火) 23:40:34.75

いきなりなんとかアプリで括るから話が噛み合ってないのでは？
まず確認すべきなのはAPIの挙動がどう変わるのかで、
次に典型的なsjisアプリでAPIをどう使っているのか
だから影響はこうだみたいな

誰か整理して教えて

**デフォルトの名無しさん** · 2019/11/26(火) 23:43:29.50

>>738
> printf("あほまぬけ\n"); こんなアプリがあったときに、
設定後は文字化け出力

**デフォルトの名無しさん** · 2019/11/26(火) 23:56:56.29

>>731
こちらの論拠は全てこのツイートにあるしこれベースで話していたわけで、
最初から君の主張がそれなら話が早かったんだけどね
端からAPI関係ないと言われても話が通じず意味不明にしか思わない

しかしはっきり言って、どっちも信用ならんｗ
自分でテストするしかないわもう

**デフォルトの名無しさん** · 2019/11/26(火) 23:58:07.39

ググってみて気付いたが一年以上前の話題なのね、これ。

**デフォルトの名無しさん** · 2019/11/27(水) 03:15:27.83

>>738
> 設定前と設定後で出てくる文字コードが違うんだぜ？
違うという証拠は？

printf("あほまぬけ\n"); と書いてコンパイルしたとき
\0で終わるSJISのバイト列が格納されてるに過ぎない。
それが設定で変わるわけ無いだろ。

**デフォルトの名無しさん** · 2019/11/27(水) 03:32:29.18

>>733
> APIの挙動変るのはやっぱヤベーな

それは英語圏のASCII前提で作られているアプリでSJISを使うと
\（0x5c）が含まれる「表」などで誤動作するって話と同じこと
http://www.kent-web.com/pubc/garble.html

> 今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
> これを利用したディレクトリトラバーサルとかも可能なんじゃね？

UTF-8は文字の一部にASCIIコードが含まれることはないのでそのようなことは発生しない。
というかそもそもが「英語圏で作られた日本語などを扱えないUnixアプリ」でこのような問題が
起きないように考慮されて作られたのがUTF-8だから

**デフォルトの名無しさん** · 2019/11/27(水) 03:36:29.35

>>747
A系のAPIがUTF-8に変換されるってのは、そういうことだろう？

**デフォルトの名無しさん** · 2019/11/27(水) 03:37:49.05

>>748
>UTF-8は文字の一部にASCIIコードが含まれることはないのでそのようなことは発生しない。

ねぇねぇ？
大丈夫？

**デフォルトの名無しさん** · 2019/11/27(水) 03:56:45.13

>>743
> まず確認すべきなのはAPIの挙動がどう変わるのかで、
WindowsはUTF-16。ファイル名などOSから文字列を受け取るときに
A系APIを使うとシステムロケールの設定で設定された文字コードに変換されて渡される。
またOSに渡すときはUTF-16に変換される。

これは標準入出力やファイルに出力するときには全く関係ない。
SJIS前提のアプリがSJISで出力するとき（つまりA系APIのみを使ってる）
変換は一切されない。SJISで出力される。

Unicodeに変換されるのはアプリが_setmode等を使ってファイルハンドルを
Unicode出力モードに意図的に変更した場合。（OSのシステムロケールの設定で勝手に変わるのではない）
そしてこの話はUnicode出力する話で、今はSJISで出力するアプリの話をしてるのだから関係ない。

SJISで出力するアプリはシステムロケールの設定が英語だろうがUTF-8だろうが常にSJISで出力される。
だから英語モードのコマンドプロンプトはSJISを理解できないから文字化けする。
chcpでコードページを932にすると「Unicode出力モードではない出力」は、SJISとして扱うので
出力を "受け取った側" の ”コマンドプロンプトが” Unicodeに変換して画面に出力する。
出力側でAPIが勝手に変換しているのではない。

**デフォルトの名無しさん** · 2019/11/27(水) 03:57:05.53

>>750
大丈夫だからなにか言い返せ

**デフォルトの名無しさん** · 2019/11/27(水) 04:00:06.35

>>749
> A系のAPIがUTF-8に変換されるってのは、そういうことだろう？
違う。WindowsネイティブのUTF-16が、A系APIを使ったときにUTF-8で渡ってくるというのは
APIの引数の話であって、printfなどの標準入出力やファイル入出力とは関係ない。

**デフォルトの名無しさん** · 2019/11/27(水) 04:41:20.28

>>753
printfは内部でWriteFileを呼んでるよ？

**デフォルトの名無しさん** · 2019/11/27(水) 04:46:25.68

そこまで調べたなら、WriteFile、ReadFleには
AやWという区別がないところまで調べようか？
これはバイナリで読み書きする。必然的に文字コードの変換など起きない。

**デフォルトの名無しさん** · 2019/11/27(水) 07:11:33.58

ところがコンソールに書くときはどうなると思う？

**デフォルトの名無しさん** · 2019/11/27(水) 07:34:16.89

dirコマンドはUnicodeでコンソールに書いている例
cp932でもUnicode文字のファイル名を表示している・

これを踏まえて>>756お前がどうなるのか書けや
実は知らんのだろ？

**デフォルトの名無しさん** · 2019/11/27(水) 09:00:23.34

UTF-8は文字の一部にASCIIコードが含まれることはない
とか言っちゃう人に説明しても無駄だと思うからやめとく

**デフォルトの名無しさん** · 2019/11/27(水) 09:13:15.33

そこは単なる表現ミスだろｗｗ
ID:j6pNPBz/ は言ってること基本的にあってる
こいつはどうか知らんが、このタイプのやつってやたら自信と知識あるのにプログラミングできないことが多い

**デフォルトの名無しさん** · 2019/11/27(水) 09:29:28.95

Code Pages
https://docs.microsoft.com/en-us/windows/win32/intl/code-pages

Many Windows API functions have "A" (ANSI) and "W" (wide, Unicode) versions.
The "A" version handles text based on Windows code pages, while the "W" version handles Unicode text.

Windows code pages are also sometimes referred to as "active code pages" or "system active code pages".
A Windows operating system always has one currently active Windows code page.
All ANSI versions of API functions use the currently active code page.

**デフォルトの名無しさん** · 2019/11/27(水) 09:33:42.45

頭でっかちって奴？
装備は良くてもと実力が・・・的な

**デフォルトの名無しさん** · 2019/11/27(水) 10:18:57.48

>>758
SJISは「表」のように文字の一部に「\」が含まれることがある。
UTF-8では文字の一部にASCIIコードが含まれることはない。
反例があるならどうぞ

**デフォルトの名無しさん** · 2019/11/27(水) 10:54:33.13

素人ですまんが"a"の文字コードはUTF8ではどうなるの?

**デフォルトの名無しさん** · 2019/11/27(水) 10:57:33.93

ASCIIと全く同じ。そして他の文字の一部に含まれることはない。

**デフォルトの名無しさん** · 2019/11/27(水) 11:01:09.01

>>762
\に拘らなくてもダメ文字でよくない？

**デフォルトの名無しさん** · 2019/11/27(水) 11:04:56.74

>>733が
> 今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
と書いてるから\にしただけの話
ダメ文字の定義なんて無いし

**デフォルトの名無しさん** · 2019/11/27(水) 11:19:42.60

>>762
マルチバイトの文字の2バイト目以降にASCII文字が含まれることはない、とか言えば相手に誤解されないんじゃないか？
相手が理解してない、間違ってると決めつけるのでなく、自分の意図が正しく相手に伝わってない可能性があることに想像が至らないのかな。
いつも他人と衝突してばかりで(主に周囲の方が)苦労してそう。

**デフォルトの名無しさん** · 2019/11/27(水) 11:38:22.80

APIの挙動は変わらないから問題ないっていうのなら、本件のスイッチはなんの意味が？
実際に、表示に問題が出たりpythonで問題が出たりしてるけど、原因は何？
このスイッチで何が起こっている？
本当にロケールの変更だけなのか？問題ないならスイッチなんか付けずに勝手に処理変えていいのでは？

この説明をして初めて問題がないという事に説得力が出るんじゃないの？

**デフォルトの名無しさん** · 2019/11/27(水) 11:45:34.42

> APIの挙動は変わらないから問題ないっていうのなら、
誰もそんなこと言ってない。スレ読み返してお前がどれにレスしてるのか言ってみろよ。

**デフォルトの名無しさん** · 2019/11/27(水) 11:48:33.36

>>768
アプリの話だから関係ない。ｷﾘｯ

**デフォルトの名無しさん** · 2019/11/27(水) 12:07:01.06

>>764
つまり、UTF-8にASCIIコードが含まれるんだよね。