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/10(日) 15:48:36.60

でもaero切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない

**デフォルトの名無しさん** · 2019/11/10(日) 15:51:41.38

同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ

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

もう滅茶苦茶だなｗ

そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ

で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ

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

Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど

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

HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。

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

>>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。

**デフォルトの名無しさん** · 2019/11/12(火) 20:44:06.06

>>630
SetWorldTransform

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

DirectX使えば自由

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

いいかい学生さん、
「令和元年12月2n日」をな、「令和元年12月2n日」をはみ出さずに表示できるくらいになりなよ。
それが、人間えら過ぎもしない貧乏過ぎもしない、ちょうどいいくらいってとこなんだ。

**デフォルトの名無しさん** · 2019/11/25(月) 20:46:42.81

Windows10 での symlink
https://social.msdn.microsoft.com/forums/ja-jp/c6141e7e-0327-4b27-a1b8-d453a169a57b/windows10-1239112398-symlink

49 · 2019/11/25(月) 22:38:11.66

>>630
GDIPlusは駄目なん?

**蟻人間** ◆T6xkBnTXz7B0 · 2019/11/25(月) 22:53:59.71

StretchBltでマイナスの値を指定するとミラーリングできるらしい。
http://forums.codeguru.com/showthread.php?524692-BitBlt-with-mirroring

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

どっかで阿鼻叫喚が始まる予感
ttps://twitter.com/MurakamiShinyu/status/994781934407553024
https://twitter.com/5chan_nel (5ch newer account)

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

お

いよいよcp932ともおさらばか
試行錯誤はあっても良い流れは認めよう
問題が出たら出たで治せば良いんだから
治す範囲がどんだけあっても諦めるな
なにもやらないよりまし

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

一年前以上からあるオプトイン設定の話だが

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

>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。

cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。

Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応

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

「ワールドワイド言語サポートで Unicode UTF-8 を使用」をするとどうなるか？

Unicode対応のアプリ・・・設定とはとは無関係にUnicode対応

Unicode非対応のアプリ・・・
　　日本語アプリはcp932でないと動かない。
　　ASCIIしか使えないアプリはcp932でもUTF-8でも動く。
　　UTF-8に対応したアプリは現時点ではまず存在しない。
　　この設定は今後UTF-8に対応したアプリが作られたときのための設定
　　この設定はデフォルト値でしかないのでUTF-8にしてもchcp932相当のことをすればcp932アプリは動く
　　互換モードの設定でコードページを指定できるようになるかもしれないね

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

コマンドプロンプトは怪しいな

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

いまだにファイルパスがユニコード対応してないアプリあるからな。氏ねと言いたくなる

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

>>643
コマンドプロンプトはUnicode対応だよ
cp932の状態でもdirでUnicodeのファイル名表示できてるじゃん

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

chcp 65001
でバグバグになるのいつ治るの

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

>>646
表示が崩れる問題なら直ってる。
動作自体なら以前から問題なく動いている。

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

>>641
こういう流れになってますが
ttps://twitter.com/unagix/status/1198150980317016065

動かなくなるんじゃなくて、破壊されて動かなくなるのが正解なのでは？
https://twitter.com/5chan_nel (5ch newer account)

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

>>648
破壊されて動かなくなるとは、一体どこにそんな証拠があるのでしょうか？

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

実際に試した人たち
https://qiita.com/obaba/items/c88c6ef833cac23bb01e
https://adatarag3.blogspot.com/2019/03/pcwindows10utf-8.html
https://chiyosuke.blogspot.com/2019/05/windowsutf-8.html

「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」から
「日本語（日本）」に戻して文字化けが直った人
https://kuronyankotan.com/?p=1596

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

全てのA系APIがUTF-8をI/Oするんじゃろ？
非対応アプリがテキスト系ファイルI/Oしたら死ぬのでは？

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

>>651
WindowsはUnicode対応なので関係ない話
非対応アプリが動かなくなるだけ

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

だいたい全てのA系APIがUTF-8をI/Oしたからって
何の問題があるんだ？

今までだってそれは、全てのA系APIがSJISとかASCIIとか
韓国や中国のなにかに変更するスイッチだっただろうと
そこにUTF-8が増えただけに過ぎない。

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

Windows自体は昔からUTF16だと思ってたんだけど、
いつのまにかUTF8になってたの？

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

A系

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

>>654
Windows NTはUTF-16だよ？

この設定はUnicodeに対応してない古いWindows 9xアプリのための
互換モード設定だから

将来的に互換モードとして使っていたこの機能をUTF-8アプリの
移植用に利用しようとか考えてるんでしょ？ Linuxアプリのこともあるし。

WindowsネイティブのUnicode（UTF-16）モードとは別に
UTF-8モードが追加されたってだけの話

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

>>652-653
>>651

A系アプリの問題の話なのに、なんでWindows自体の話になるの？
てか、>651のみならずリンク元の流れすら読んでない感じ？
まあ実際俺も試したわけじゃないけど、書いてることが事実だとすると
設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ

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

> A系アプリの問題の話なのに、なんでWindows自体の話になるの？

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

Windows自体はWindows APIのW系（Unicode）を原則として使用してるが
古いアプリのためにA系のAPIも提供してる。Windows はW系を使ってるので
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
したところで何の影響もない。影響があるのは古いアプリのみ

> 設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
それならデータ消せばいいだけだろ。アプリの都合なんか知るか

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

朝鮮人は息を吐くように嘘を吐く

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

>>658
>それならデータ消せばいいだけだろ。アプリの都合なんか知るか

だからそのアプリの話を一貫してしてるんだけど？
アプリのデータを消す？
大事な既存データでも消したらOK?　馬鹿？仕事したことない？
システムプロファイルも全て戻らないということなので、戻したら動く保証はどこにもない

何度も言うけど、A系アプリの話だからな？

例えばCの話をしてるのにJaveや.NETが今は主流だからCなんて知らん
って的外れなこと言ってるだけだお前は

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

>>660
何が言いたいのかわからん。
アプリが動かなくてなってもWindowsは問題なく動くだろ

SJISにしか対応してないアプリのコードページを変えてデータが壊れたって
それはアプリの動作保証外の使い方をしたからってだけで
OSのせいでもアプリのせいでもない。

データ消えたら困るなら保証外の使い方をするなよ。
バックアップぐらい取れ。

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

役に立つ人柱はここか
https://chiyosuke.blogspot.com/2019/05/windowsutf-8.html
https://srad.jp/story/17/11/14/0640253/

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

英語圏の人間向けであって、日本人が使うオプションじゃないからな
大手のソフト含めて対応してない（設定変えるとおかしくなる）のは山ほどあるよ

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

>>660
君はちょっと落ち着け

>>648の内容はシステムの設定を元に戻せないという話であって
アプリの話じゃないだろ

そして
>大事な既存データでも消したらOK?　馬鹿？仕事したことない？
だったらβの機能なんか使うなよ、で終わりだよ

βじゃなくなるときに、キレイに全部戻せるようになってるか、
SJISアプリは切り捨てますって発表があるかのどっちかだろ

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

>>661
なんでWindowsが動かなくなる（だったりWindowsの問題や責任）話と勘違いしてるの？
単純に設定変えたらA系アプリに問題があるねってだけの話だぞ？
的外れも甚だしいし視野が狭すぎる

過去資産を使ってるクライアントを持ってたら、この手の話には敏感になるわ
バックアップとかそういう次元の話じゃない
お前みたいなのがクライアントのサポートしたらクライアントが居なくなるレベル

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

>>665
だから何が言いたいんだよ。
cp932前提の古いアプリはUTF-8で動きませんって
当たり前の話なだけだろ

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

つーか、最初っから俺が言ってるんだわ

641 自分：デフォルトの名無しさん[sage] 投稿日：2019/11/26(火) 11:36:11.45 ID:fVihpbt7 [1/4]
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。

cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。

Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応

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

>>664
> だったらβの機能なんか使うなよ、で終わりだよ
まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
割を食うのはこっちになったりすると目も当てられんからね

>>666
そんな当たり前の次元の話を一切してないからね

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

ふ～ん
Pythonで問題起きるのか

Rubyはどうなんだろ

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

上の >>662 のPythonの人は
PYTHONENCODING=utf-8の方を気にしてるけど
setdefaultencodingとかはどうしてるのかな

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

>>667
> cp932使ってる古いアプリは、この設定にすると
> 動かなくなるだけ。つまり捨てるしか無い。

この時点で間違ってる
つーかW系A系のAPIの使い分けしたことあれば、A系の動作が変わることでどうなるのか
ってある程度予想できそうなもんだけど、なんでここまで勘違いが続けられるの？

**デフォルトの名無しさん** · 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系に関係するものか、誰か見解を出していただけませんか？