[過去ﾛｸﾞ] Win32API質問箱 Build125 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
648(4): 2019/11/26(火)12:30 ID:4pvDP8OD(1/12) AAS
>>641
こういう流れになってますが
Twitterﾘﾝｸ:unagix
動かなくなるんじゃなくて、破壊されて動かなくなるのが正解なのでは？
Twitterﾘﾝｸ:5chan_nel (5ch newer account)
649: 2019/11/26(火)12:31 ID:Yz+apKYY(1/11) AAS
>>648
破壊されて動かなくなるとは、一体どこにそんな証拠があるのでしょうか？
650: 2019/11/26(火)12:39 ID:Yz+apKYY(2/11) AAS
実際に試した人たち
外部ﾘﾝｸ:qiita.com
外部ﾘﾝｸ[html]:adatarag3.blogspot.com
外部ﾘﾝｸ[html]:chiyosuke.blogspot.com
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」から
「日本語（日本）」に戻して文字化けが直った人
外部ﾘﾝｸ:kuronyankotan.com
651(2): 2019/11/26(火)12:50 ID:4pvDP8OD(2/12) AAS
全てのA系APIがUTF-8をI/Oするんじゃろ？
非対応アプリがテキスト系ファイルI/Oしたら死ぬのでは？
652(1): 2019/11/26(火)13:01 ID:Yz+apKYY(3/11) AAS
>>651
WindowsはUnicode対応なので関係ない話
非対応アプリが動かなくなるだけ
653(1): 2019/11/26(火)13:03 ID:Yz+apKYY(4/11) AAS
だいたい全てのA系APIがUTF-8をI/Oしたからって
何の問題があるんだ？
今までだってそれは、全てのA系APIがSJISとかASCIIとか
韓国や中国のなにかに変更するスイッチだっただろうと
そこにUTF-8が増えただけに過ぎない。
654(1): 2019/11/26(火)13:06 ID:VJ34cQn0(1) AAS
Windows自体は昔からUTF16だと思ってたんだけど、
いつのまにかUTF8になってたの？
655: 2019/11/26(火)13:08 ID:njyF587z(1) AAS
A系
656: 2019/11/26(火)13:12 ID:Yz+apKYY(5/11) AAS
>>654
Windows NTはUTF-16だよ？
この設定はUnicodeに対応してない古いWindows 9xアプリのための
互換モード設定だから
将来的に互換モードとして使っていたこの機能をUTF-8アプリの
移植用に利用しようとか考えてるんでしょ？ Linuxアプリのこともあるし。
WindowsネイティブのUnicode（UTF-16）モードとは別に
UTF-8モードが追加されたってだけの話
657: 2019/11/26(火)13:29 ID:4pvDP8OD(3/12) AAS
>>652-653
>>651
A系アプリの問題の話なのに、なんでWindows自体の話になるの？
てか、>651のみならずリンク元の流れすら読んでない感じ？
まあ実際俺も試したわけじゃないけど、書いてることが事実だとすると
設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
658(2): 2019/11/26(火)13:35 ID:Yz+apKYY(6/11) AAS
> A系アプリの問題の話なのに、なんでWindows自体の話になるの？
A系アプリってなんだ？ A系っていうのはWindows APIのAPIの末尾のAだろ
Windows APIの話なんだからWindowsの話だろ？
Windows自体はWindows APIのW系（Unicode）を原則として使用してるが
古いアプリのためにA系のAPIも提供してる。Windows はW系を使ってるので
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
したところで何の影響もない。影響があるのは古いアプリのみ
> 設定戻してもファイルは戻らんからA系アプリは死んだままになるぞ
それならデータ消せばいいだけだろ。アプリの都合なんか知るか
659: 2019/11/26(火)13:46 ID:dAEqoOXB(1/5) AAS
朝鮮人は息を吐くように嘘を吐く
660(2): 2019/11/26(火)13:47 ID:4pvDP8OD(4/12) AAS
>>658
>それならデータ消せばいいだけだろ。アプリの都合なんか知るか
だからそのアプリの話を一貫してしてるんだけど？
アプリのデータを消す？
大事な既存データでも消したらOK? 馬鹿？ 仕事したことない？
システムプロファイルも全て戻らないということなので、戻したら動く保証はどこにもない
何度も言うけど、A系アプリの話だからな？
例えばCの話をしてるのにJaveや.NETが今は主流だからCなんて知らん
って的外れなこと言ってるだけだお前は
661(1): 2019/11/26(火)13:55 ID:Yz+apKYY(7/11) AAS
>>660
何が言いたいのかわからん。
アプリが動かなくてなってもWindowsは問題なく動くだろ
SJISにしか対応してないアプリのコードページを変えてデータが壊れたって
それはアプリの動作保証外の使い方をしたからってだけで
OSのせいでもアプリのせいでもない。
データ消えたら困るなら保証外の使い方をするなよ。
バックアップぐらい取れ。
662(1): 2019/11/26(火)13:58 ID:dAEqoOXB(2/5) AAS
役に立つ人柱はここか
外部ﾘﾝｸ[html]:chiyosuke.blogspot.com
外部ﾘﾝｸ:srad.jp
663: 2019/11/26(火)14:08 ID:dbvsSdaZ(2/5) AAS
英語圏の人間向けであって、日本人が使うオプションじゃないからな
大手のソフト含めて対応してない（設定変えるとおかしくなる）のは山ほどあるよ
664(1): 2019/11/26(火)14:13 ID:JyI6kWkc(1/5) AAS
>>660
君はちょっと落ち着け
>>648の内容はシステムの設定を元に戻せないという話であって
アプリの話じゃないだろ
そして
>大事な既存データでも消したらOK? 馬鹿？ 仕事したことない？
だったらβの機能なんか使うなよ、で終わりだよ
βじゃなくなるときに、キレイに全部戻せるようになってるか、
SJISアプリは切り捨てますって発表があるかのどっちかだろ
665(1): 2019/11/26(火)14:17 ID:4pvDP8OD(5/12) AAS
>>661
なんでWindowsが動かなくなる（だったりWindowsの問題や責任）話と勘違いしてるの？
単純に設定変えたらA系アプリに問題があるねってだけの話だぞ？
的外れも甚だしいし視野が狭すぎる
過去資産を使ってるクライアントを持ってたら、この手の話には敏感になるわ
バックアップとかそういう次元の話じゃない
お前みたいなのがクライアントのサポートしたらクライアントが居なくなるレベル
666(1): 2019/11/26(火)14:22 ID:Yz+apKYY(8/11) AAS
>>665
だから何が言いたいんだよ。
cp932前提の古いアプリはUTF-8で動きませんって
当たり前の話なだけだろ
667(1): 2019/11/26(火)14:24 ID:Yz+apKYY(9/11) AAS
つーか、最初っから俺が言ってるんだわ
641 自分：デフォルトの名無しさん[sage] 投稿日：2019/11/26(火) 11:36:11.45 ID:fVihpbt7 [1/4]
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。
cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。
Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応
668(1): 2019/11/26(火)14:28 ID:4pvDP8OD(6/12) AAS
>>664
> だったらβの機能なんか使うなよ、で終わりだよ
まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
割を食うのはこっちになったりすると目も当てられんからね
>>666
そんな当たり前の次元の話を一切してないからね
669: 2019/11/26(火)14:29 ID:dAEqoOXB(3/5) AAS
ふ〜ん
Pythonで問題起きるのか
Rubyはどうなんだろ
670: 2019/11/26(火)14:32 ID:dAEqoOXB(4/5) AAS
上の >>662 のPythonの人は
PYTHONENCODING=utf-8の方を気にしてるけど
setdefaultencodingとかはどうしてるのかな
671(1): 2019/11/26(火)14:34 ID:4pvDP8OD(7/12) AAS
>>667
> cp932使ってる古いアプリは、この設定にすると
> 動かなくなるだけ。つまり捨てるしか無い。
この時点で間違ってる
つーかW系A系のAPIの使い分けしたことあれば、A系の動作が変わることでどうなるのか
ってある程度予想できそうなもんだけど、なんでここまで勘違いが続けられるの？
672(1): 2019/11/26(火)14:46 ID:LSm6MssX(2/2) AAS
プロファイル壊されるってゆーてるリンクの連中だけが情報量ゼロなの草
673: 2019/11/26(火)14:53 ID:hqQvrruW(1) AAS
結局W系で作るしかないんだから余計なことは考えなくていいよ
674(1): 2019/11/26(火)14:54 ID:ogXaluX+(1/4) AAS
fopen()の振る舞いで困るかも。Win32のfopen()はutf8を特別扱いするから。
675: 2019/11/26(火)14:56 ID:dAEqoOXB(5/5) AAS
レジストリの読み書きも気になるな
676: 2019/11/26(火)15:01 ID:JyI6kWkc(2/5) AAS
>>671
いわゆるバイナリモードを使うとBOMがついてきちゃうとか、
いろいろトラブルが発生する可能性はあるね
前回のアップデートでもコンソールで文字化けする問題があったし
それをざっくり言えば、古いアプリを捨てるか、設定変えんな、
という話になるだろ
APIオタクと運用を見てる人で視点が違うことを理解しなよ
>>668
>まあそれは正論なんだが、さっきも書いたようにクライアントの責任であっても
それは契約文書にきちんと盛り込むべきだね
677: 蟻人間 ◆T6xkBnTXz7B0 2019/11/26(火)15:25 ID:SWHzOLKZ(1/2) AAS
MultiByteToWideChar/WideCharToMultiByteの第一引数にシフトJISコードページ932を指定しないといけないらしい。CP_ACPだと死ぬ。
678: 2019/11/26(火)15:33 ID:Yz+apKYY(10/11) AAS
>>672
壊されないよ。日本語が化けることはあっても
それは想定とは違うデータが入っただけだし
アプリの問題
679(1): 蟻人間 ◆T6xkBnTXz7B0 2019/11/26(火)15:37 ID:SWHzOLKZ(2/2) AAS
シフトJISテキストファイルにUTF-8テキストが混ざったら、そりゃ文字化けするでしょう。
680: 2019/11/26(火)15:56 ID:9NQ9wJPH(1/10) AAS
>>679
無茶苦茶になるよな
ありえんわ
681: 2019/11/26(火)16:01 ID:Yz+apKYY(11/11) AAS
コードページを変えると文字化けするだろうね
それだけの話。別に動かなくなるわけじゃない。
コードページをもとに戻せば動く
壊れたデータは直せばいいだけ
682(1): 2019/11/26(火)16:02 ID:ogXaluX+(2/4) AAS
main()に渡される引数文字列argvどうなります？
683(1): 2019/11/26(火)16:23 ID:9NQ9wJPH(2/10) AAS
自前で先行バイト検出しながら文字列書き換えるような関数とか如何すんのよ
684(2): 2019/11/26(火)16:23 ID:H048FZbZ(1/11) AAS
>>682
Unicode非対応アプリのmainだとして、
Unicode対応アプリ（からUnicode APIを使って）呼び出せば、引数全てがUTF-16からUTF-8に変換されてから
呼び出される。Unicode非対応アプリから呼び出せば、渡した文字列（バイト列）がそのまま渡される。
そこは今までと変わらない。今までもUnicode対応アプリから呼び出せば、設定されたコードページ（例えばcp932）に
変換されて呼び出される。違いはUTF-16からUTF-8だと変換できない文字がないので文字化けは一切発生しない。
なお、渡されたからと言ってアプリが正しくその文字列を扱えるかどうかは別の話
結局の所cp932専用で作られたアプリは完全に同じようには動かない。（ASCIIの範囲でなら問題ないだろう）
685(1): 2019/11/26(火)16:25 ID:H048FZbZ(2/11) AAS
>>683
実装と場合（データ）によるとしか言えない。
Unicode（UTF-16）非対応の古いアプリは、想定したコードページでしか
まともに動かない。それだけの話だよ。
686: 2019/11/26(火)16:25 ID:H048FZbZ(3/11) AAS
あと、システムプロファイルとか意味不明。
何の話をしてるのかわからないレベル。
687: 2019/11/26(火)16:30 ID:H048FZbZ(4/11) AAS
ちなみにUnicodeから非Unicodeへの変換は変換できない文字があるから一部文字化けするが、
非UnicodeからUnicodeへの変換では文字化けすることはない。
だから、cp932を扱えるアプリがcp932でレジストリ（UTF-16）に書き込んでも
適切に変換が行われるし、そのアプリがUTF-8を使えるなら、それもレジストリに書き込んでも壊れたりしない。
例えばアプリ（cp932）から レジストリ（UTF-16）に書き込んで、
レジストリ（UTF-16）を アプリ（UTF-8）から参照することは問題なくできるということ
688(1): 2019/11/26(火)16:32 ID:9NQ9wJPH(3/10) AAS
>>685
非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
そこにUTF-8とかねじ込まれても困るわ
689: 2019/11/26(火)16:32 ID:H048FZbZ(5/11) AAS
もちろんレジストリ（UTF-16）をアプリ（cp932）で参照したときは扱えない文字列があるが、
それはファイル名（UTF-16）をアプリ（cp932）で扱えない文字があるという程度の話でしか無い。
690(1): 2019/11/26(火)16:35 ID:ogXaluX+(3/4) AAS
マルチバイト文字を含むファイルパスが鬼門でしょ。
691(1): 2019/11/26(火)16:38 ID:H048FZbZ(6/11) AAS
>>688
お前は意味がわかるように書き込め
> 非対応じゃ無くWとAはちゃんと使い分けがなされてるんだよ
どういう使い分けがされてるのか書け
> オーバーロード関数なら引数がWCHAR *がCHAR *で問題なく動く
それって引数がWCHAR *ならW系が使われて、引数がCHAR *ならA系が使われるってだけだろ
> そこにUTF-8とかねじ込まれても困るわ
そこにってどこよ？何が困るんだよ。
UTF-8はCHAR*を使うって理解してるか？
今までA系はASCIIだけでなくSJISや多数の文字コードで使われていたというのに
省1
692: 2019/11/26(火)16:41 ID:H048FZbZ(7/11) AAS
>>690
鬼門っていうか、単にUnicode非対応のアプリは
想定しているコードページに変換できない文字を扱えないってだけだけどな
たったこれだけのことなのに何をグダグダ言ってるのかわからん
693: 2019/11/26(火)16:56 ID:ogXaluX+(4/4) AAS
バッチファイルは厄介。あればだが。
694(1): 2019/11/26(火)16:59 ID:JyI6kWkc(3/5) AAS
>>684
UTF8アプリなんて存在するんだっけ？
695(1): 2019/11/26(火)17:02 ID:9NQ9wJPH(4/10) AAS
>>691
たとえUnicodeに対応しているプログラムであっても何らかの出力ファイルをSJISで出力するような構造だと、
それを勝手にUTF-8に書き換えられたら次読み込んだ時滅茶苦茶になるだろ
一般的なテキストエディタも勝手に文字コード変えるような事はせんからな
696: 2019/11/26(火)17:12 ID:H048FZbZ(8/11) AAS
>>694
まずないだろうね。作れるようになったのは最近だし。
念ために言っておくけど、ないっていうのは
Unicode対応アプリではない（＝A系APIを使う）かつASCII文字としてUTF-8を使うアプリのことね。
UTF-8はUnicodeだろというツッコミはいらん。
WindowsにおいてUnicode対応とはUTF-16アプリのこと
最近Unicode非対応の古いアプリでもUTF-8が使えるようになったから、
古いアプリをUTF-8用として作り直して新しくすることでA系のまま
Unicode対応にできるとかいうジョークのような話ｗ
それするぐらいなら最初からUnicode対応として.NETとかで作りますわ。
省2
697: 2019/11/26(火)17:13 ID:H048FZbZ(9/11) AAS
>>695
だからなんなんだよ？
当たり前の話するな。OSともアプリとも関係ない話だわ
LinuxでもMacでも同じことは起きるわ。だからなんだんだよ
698(2): 2019/11/26(火)17:14 ID:H048FZbZ(10/11) AAS
結論を書け結論を。お前がいいたいこが何かを書け。
699: 2019/11/26(火)17:16 ID:9NQ9wJPH(5/10) AAS
>>698
勝手に文字コードを変えんなってだけやろ
利用者の意思で変えさせろと
700(1): 2019/11/26(火)17:44 ID:H048FZbZ(11/11) AAS
>>698
勝手に変えてない。お前は馬鹿なのか？
701(4): 2019/11/26(火)17:48 ID:FXTOqUMb(2/5) AAS
クッソ伸びてて草
MBSCなソフトがA系APIでデータ読み書きしてたら非対応のUTF8に書き換わってて、
以降データが文字化けしたまま困ることになるんだから、元に戻せばOKとか非対応なんだから
仕方ないとか、こればかりは擁護不可能の的外れ
表示だけの問題じゃなく記録データにも影響があって、こいつばかりは復元ソフトでも組まないと戻せない
MBSCなソフトは使えないだけならば、単純にA系APIを廃止すればいいだけなんだが
MSはお節介にもどうにかして過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
用意したって点だけ見ても、単純に非対応とか元に戻せばいいというような話ではない
年末にお父ちゃんから、古い宛名印刷ソフトのデータが壊れたって連絡が来るかも知れないくらいには、
時と場合によっては取り返しが付かない
省1
702: 2019/11/26(火)17:59 ID:4DbW4sNm(1/15) AAS
>>701
そんな長々と書かなくても、
SJISのファイルにUTF-8で書き込んだら文字化けしたのと同じことでしょ
そんなのLinuxでもmacOSでも起きる問題だって言ってるんだが
703: 2019/11/26(火)18:00 ID:4DbW4sNm(2/15) AAS
>>701
> 過去資産を活かしてやろうってことでA系の挙動を変える選択肢を
意味不。単にUTF-8にも対応したってだけ
コードページを一つ増やしたに過ぎない。
A系の挙動は昔から設定で変更できた。
704: 2019/11/26(火)18:02 ID:4DbW4sNm(3/15) AAS
もしかしてこいつは、ユーザーが設定変更しなくても
アップデートで勝手にUTF-8に変わるとか思ってるのか？
ならものすごくマヌケだｗ
705: 2019/11/26(火)18:12 ID:FXTOqUMb(3/5) AAS
あー、アホが一人混じってるから伸びてるのか
把握
706: 2019/11/26(火)18:18 ID:4DbW4sNm(4/15) AAS
今度はレスしなかったところを見ると図星だったか
707: 2019/11/26(火)18:39 ID:9NQ9wJPH(6/10) AAS
>>700
編集して上書きしたらUTF-8に変るんじゃなく新規での作成がUTF-8になるだけ？
それなら俺の誤解だったわ
勝手に変えるのなら死ねだが
708: 2019/11/26(火)18:49 ID:4DbW4sNm(5/15) AAS
本当にアホだったな。ユーザーが意図的に変えない限り変わらないってのに
709(2): 2019/11/26(火)18:55 ID:FXTOqUMb(4/5) AAS
論旨はは>>638よりは>>648みたらはっきりしてる
”安易に設定変更したらA系使ってるソフトが恐い”ってことだけであって、”問題ない”
と連呼してるアホ一人が理解力0というかマイナスなだけ
710(1): 2019/11/26(火)18:55 ID:4DbW4sNm(6/15) AAS
しかもエアプなんだろうな。
>>638は古い情報で、
そもそも「ベータ: ワールドワイド言語サポートで Unicode UTF-8 を使用」の設定と
『メモ帳の文字コードと全く関係ない』話だってのもわかってないんだろう
『当時』はたまたまそこの設定がデフォルトになっていただけで、
今は常にUTF-8（BOMなし）
メモ帳は古いアプリでもなんでも無いしな
で、メモ帳が保存するテキストファイルの文字コードと
古いアプリの挙動も全く関係ない話。そんなの考えるまでもなくわかること
省3
711: 2019/11/26(火)18:58 ID:9NQ9wJPH(7/10) AAS
>>710
言っとくが俺と>>701は別人だからな
712: 2019/11/26(火)18:58 ID:4DbW4sNm(7/15) AAS
>>709
>”問題ない”と連呼してる
連呼の意味わかってる？ｗ
”問題ない”で >>638以降のレスを探すと
>>684で一回しか書いていない。しかも関係ない話
お前は思い込みが激しいってことがはっきりわかったな
713: 2019/11/26(火)19:05 ID:4pvDP8OD(8/12) AAS
はい、論点誤魔化してきたね
未だに文字化けする程度の認識しかしてないから、話するだけ無駄だと思うよ
メモ帳とか連呼の定義とか持ちだしてきてもう意味不明
そもそもWinAPIのプログラムも組んだことないの丸わかりだから、キチガイに付き合うだけ損
714(1): 2019/11/26(火)19:05 ID:dbvsSdaZ(3/5) AAS
例えば標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
そんなの使ってたら、ファイル前半はシフトJIS、後半はUTF8になって、どっちでも読めなくなる
これは極端な例だけど同じようなことはそこら中で起こりえる
715: 2019/11/26(火)19:05 ID:FXTOqUMb(5/5) AAS
メモ帳・・・・？
ヤベえなこいつ
716: 2019/11/26(火)19:09 ID:s8aO6zrT(1) AAS
だんだん論点ずれてきてるやん
717(1): 2019/11/26(火)19:09 ID:4pvDP8OD(9/12) AAS
>>709
んだ
>>714
そうだね
単純にそういう話になると思ってたんだが、このスレでこのレベルの未経験者が話しに入ってくるとは思わなかった
718(1): 2019/11/26(火)19:11 ID:4DbW4sNm(8/15) AAS
はぁ、リンク先も読んでないのかよ
>>638のリンク先読めよ・・・
Twitterﾘﾝｸ:MurakamiShinyu
> 今までデフォルトでShift JISだったもの（メモ帳をはじめ…）が
> この設定をすると「メモ帳」の「名前を付けて保存」で「文字コード: ANSI」
> （デフォルト）だとBOM無しのUTF-8、「文字コード: UTF-8」だと
> BOM付きのUTF-8のファイルになります。
↑注意 これは古い話で今は当てはまらない
Twitterﾘﾝｸ:5chan_nel (5ch newer account)
719(2): 2019/11/26(火)19:12 ID:4DbW4sNm(9/15) AAS
>>717
> 単純にそういう話になると思ってたんだが、
その話は当たり前で、LinuxでもmacOSでも同じことになると
さんざん言ってる
720(1): 2019/11/26(火)19:17 ID:4DbW4sNm(10/15) AAS
ちなみに
> 標準入力から文字列を受け取ってテキストファイルに追加書き込みする実行ファイル
これはコードページとは何の関係もない。
当たり前だがSJISで出力してるアプリは、
コードページをどう変更しようが、SJISで出力される。
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」に
チェックを入れたところで、SJISで出力してるアプリが
UTF-8で出力するように変わることはない。
721: 2019/11/26(火)19:18 ID:9NQ9wJPH(8/10) AAS
設定変更しなければ良い、ってのは利用者の目線で開発者の発想ではないわな
722(2): ◆QZaw55cn4c 2019/11/26(火)19:19 ID:eitz3RWA(1/5) AAS
>>658
＞A系アプリってなんだ？ A系っていうのはWindows APIのAPIの末尾のAだろ
＞Windows APIの話なんだからWindowsの話だろ？
win32api には同じ api 関数に対して A 系と W 系の二つの異なった関数が準備されているんです
A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います
723: ◆QZaw55cn4c 2019/11/26(火)19:20 ID:eitz3RWA(2/5) AAS
>>674
win32api に fopen は存在しません、CreateHandle ならば存在しますが
724: 2019/11/26(火)19:21 ID:4DbW4sNm(11/15) AAS
もちろん、「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
の設定（コードページ）を見て、アプリ内部でその文字コードに変換して
出力するように作られてるアプリは別な。
あくまでA系APIを使ってるアプリの話
SJIS前提で作られてるアプリは、SJISでしか出力しません。
ただしAPIがUTF-8前提として処理するのでASCII以外だと
出力がおかしくなります。
725(1): 2019/11/26(火)19:22 ID:4DbW4sNm(12/15) AAS
>>722
> A 系の A は ansi の A で、こいつは主にファイルパスに Shift-JIS/cp932 を使うのに対して W 系はファイルパスに utf-16LE を使います
うんしってる。そして新設された「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」
というのは、A系を使ってASCII互換のUTF-8を使えるようになる機能です。
726: ◆QZaw55cn4c 2019/11/26(火)19:22 ID:eitz3RWA(3/5) AAS
問題のオプションが A系 W系に関係するものか、誰か見解を出していただけませんか？
727: ◆QZaw55cn4c 2019/11/26(火)19:24 ID:eitz3RWA(4/5) AAS
>>725
thanks!
728(2): 2019/11/26(火)19:25 ID:4pvDP8OD(10/12) AAS
>>718
>>648読んでる？
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
>>719
> その話は当たり前で、LinuxでもmacOSでも同じことになると
> さんざん言ってる
今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？
>>720
> 当たり前だがSJISで出力してるアプリは、
> コードページをどう変更しようが、SJISで出力される。
省4
729(1): 2019/11/26(火)19:26 ID:4DbW4sNm(13/15) AAS
>>728
> 今回のWinの設定がなんで他のOSを例に挙げるの？しかもWin32APIの話なのに、どういう関係があるのか？
だから他のOSでも起きる、SJISのファイルにUTF-8で書き込むと壊れるという話を
ごちゃまぜにするなと言ってる。
それはWin32APIと関係ない話だと言ってるだけ
730(1): 2019/11/26(火)19:32 ID:4pvDP8OD(11/12) AAS
>>729
> SJISのファイルにUTF-8で書き込むと壊れるという話を
なぜそのようなことが起こるのか、どういうきっかけで起こるのか、影響範囲はどうなっているのか、
A系APIの挙動が変わるからだ
という話なだけでしょうが
他のOSを例に出す意味がない
君の主張は、APIの挙動は変わらないということなんだね？
要点をまとめなよ
731(2): 2019/11/26(火)19:36 ID:4DbW4sNm(14/15) AAS
>>728
> すべての A 系 API が UTF-8 を I/O するようになるスイッチやぞ。半端ねぇぞ。
「ダウト」なのの１つ目は「半端ねぇ」の部分。
A系APIは昔から、コードページの設定をみてそのコードページの文字コードを
前提として処理している。昔から当たり前のことで今更驚くことじゃない。
英語ならASCIIを前提として処理するし、日本語に設定すればSJISを前提として
処理するするようになるし、韓国語や中国語にすれば、その国文字コードを前提して処理する。
20年以上そういう機能だった。
そしてもう一つはI/Oするって所。APIが設定に応じた文字コードを前提とするだけで別にI/Oするわけじゃない。
どの文字コードを使うかはアプリによる。SJIS専用のアプリはSJISしかI/Oしない。
省4
732(2): 2019/11/26(火)19:40 ID:4DbW4sNm(15/15) AAS
>>730
要点 「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」の設定によるAPIの挙動と
アプリが入出力する文字コード（ファイル等を含む）は関係は一切ない
アプリが入出力する文字コードはアプリの実装によって決まる。
（Win32 APIと関係ないから、他のOSも同じという話につながる）
733(2): 2019/11/26(火)20:15 ID:9NQ9wJPH(9/10) AAS
APIの挙動変るのはやっぱヤベーな
iniから文字列を取り出す >UTF-8
今まで通りSJISだと決めてかかって独自関数でパスの分解などをすると滅茶苦茶になるって話やん
これを利用したディレクトリトラバーサルとかも可能なんじゃね？
734(1): 2019/11/26(火)21:07 ID:Qm31cF9G(1) AAS
まずは公式ドキュメントを読め
話はそれからだ
Visual C++ のテキストと文字列
外部ﾘﾝｸ:docs.microsoft.com
735: ◆QZaw55cn4c 2019/11/26(火)21:10 ID:eitz3RWA(5/5) AAS
>>734
VC のドキュメントがなんの役に立つ？
736(1): 2019/11/26(火)22:34 ID:JUtzLycC(1/3) AAS
他のソースはないかな。
βとはいえMSが単なるロケールの追加じゃなくてそんな過激なスイッチを導入しようとする意図がよくわからん。
737(1): 2019/11/26(火)23:00 ID:dbvsSdaZ(4/5) AAS
英語圏だと切り替えても英語入出力だけするなら何も変わらないしメリットの方が多い
日本語圏じゃデメリットしかないがｗ
738(2): 2019/11/26(火)23:01 ID:JyI6kWkc(4/5) AAS
>>719
> その話は当たり前で、
本当？
SJISアプリをUTF-8アプリとして動作させるんだぜ？
printf("あほまぬけ\n"); こんなアプリがあったときに、
設定前と設定後で出てくる文字コードが違うんだぜ？
Linuxでそんなことが起こるかよ。
739: 2019/11/26(火)23:03 ID:JyI6kWkc(5/5) AAS
>>737
シングルバイトアプリがマルチバイトアプリとして動くわけ？
もっと変なことになるだろそれ
740: 2019/11/26(火)23:32 ID:9NQ9wJPH(10/10) AAS
_tcsincなんかマルチバイト前提にしか使わないような関数だろ
どんな挙動になるんだ
741: 2019/11/26(火)23:33 ID:4vHYq+aK(1) AAS
「ワールドワイド言語サポートで Unicode UTF-8 を使用」にチェックを入れ
なければUnicode非対応のアプリは従来通り動くし、これにチェックを入れな
ければ動かない既存のアプリっていうのも現状では無いんでしょう？
非対応アプリを対応させるのに要するコスト以上の利益が今後見込めるなら
アプリ開発元も対応させるだろうけど、そうでないなら放置されるんじゃ
ないかなあ。
MSがUnicode非対応アプリを切り捨てるようなことをすれば、Windows離れ
(＝パソコン離れ)が進むだけでしょ。
742: 2019/11/26(火)23:36 ID:JUtzLycC(2/3) AAS
CP1252のアプリにUTF8突っ込まれてもやっぱり困るだけだよなぁ。
743(1): 2019/11/26(火)23:40 ID:oARfCEQj(1) AAS
いきなりなんとかアプリで括るから話が噛み合ってないのでは？
まず確認すべきなのはAPIの挙動がどう変わるのかで、
次に典型的なsjisアプリでAPIをどう使っているのか
だから影響はこうだみたいな
誰か整理して教えて
744: 2019/11/26(火)23:43 ID:dbvsSdaZ(5/5) AAS
>>738
> printf("あほまぬけ\n"); こんなアプリがあったときに、
設定後は文字化け出力
745: 2019/11/26(火)23:56 ID:4pvDP8OD(12/12) AAS
>>731
こちらの論拠は全てこのツイートにあるしこれベースで話していたわけで、
最初から君の主張がそれなら話が早かったんだけどね
端からAPI関係ないと言われても話が通じず意味不明にしか思わない
しかしはっきり言って、どっちも信用ならんｗ
自分でテストするしかないわもう
746: 2019/11/26(火)23:58 ID:JUtzLycC(3/3) AAS
ググってみて気付いたが一年以上前の話題なのね、これ。
747(1): 2019/11/27(水)03:15 ID:j6pNPBz/(1/8) AAS
>>738
> 設定前と設定後で出てくる文字コードが違うんだぜ？
違うという証拠は？
printf("あほまぬけ\n"); と書いてコンパイルしたとき
\0で終わるSJISのバイト列が格納されてるに過ぎない。
それが設定で変わるわけ無いだろ。
上下前次1-新書関写板覧索設栞歴
あと 255 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.025s