[過去ﾛｸﾞ] Win32API質問箱 Build125 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
596: 2019/11/08(金)13:27 ID:D1bzmSlR(2/2) AAS
あんまり不人気だと
供給側も撤退を考える要素が色々出てくるだろ
597: 2019/11/08(金)13:56 ID:1R79qYgq(1) AAS
ワイの中では永遠の大人気、comctl32.dllをずっとverupして欲しいと願います
1803でも修正するくらいだしさ
598: 2019/11/08(金)21:00 ID:lpVjWTGo(1) AAS
TOPMOST ウィンドウがほかのウィンドウの背後に移動してしまう
外部ﾘﾝｸ:social.msdn.microsoft.com
599: 2019/11/08(金)21:14 ID:sQQR9KNr(1) AAS
TOPMOST同士があるからな
600: 2019/11/09(土)13:55 ID:hHKZwsDl(1/2) AAS
タスクマネージャもよく後ろに移動する時あるけど何なのあれ
601: 2019/11/09(土)14:13 ID:BZG37V3w(1) AAS
API設計が糞だから
皆がみんなTOPを取りたがって
奪い合いになる
602: 2019/11/09(土)15:42 ID:01iIJK4d(1) AAS
タスクバーより手前にくる時もある
別件だが
タスクマネージャのCPU使用率が高くなってグラフが高速になるのもある
603: 2019/11/09(土)17:34 ID:GyhiHYRD(1/2) AAS
もう記憶の彼方ですがディスプレイメモリのアドレスって直で取れましたっけ？
毎回メモリ確保してDIB作って画面のHDCからコピーしてっやらないと駄目すかね
それなら諦めてGetPixel使いますが
604(1): 2019/11/09(土)17:44 ID:HanEs9+F(1/2) AAS
アドレスを直で、の正確な意味がわからんが基本あれGPUにあるからね
Direc3Dテクスチャで良いならIDXGIOutputDuplicationから取れるけど
605: 2019/11/09(土)17:56 ID:HyuDdIlK(1/2) AAS
TOPMOSTなんて思い上がった言葉ですぐ気がつけよ
スレッドの優先度でさえ最優先ではなくタイムクリティカルだろうが
606(1): 2019/11/09(土)18:03 ID:GyhiHYRD(2/2) AAS
>>604
こりゃ失礼、ありがとうございます
なんか昔いじった気がしたんですが、あれはオフスクリーンバッファだったか……
PC98じゃあるまいし、言われて見りゃ無理くさいすね
画面上の変化を監視して作業自動化する様なのを頼まれたのですが、
監視するべきは数ピクセルなので、おとなしくGetDC(nullptr)からGetPixelします
607: 2019/11/09(土)21:35 ID:hHKZwsDl(2/2) AAS
GetPixelって内部でどうやってるのかな
毎回呼び出すと遅いんだよね
608: 2019/11/09(土)22:19 ID:HyuDdIlK(2/2) AAS
故意に減速してるようだね
ビットマップオブジェクトにキャッシュしといて
そこから取ると普通の速度になる
609: 2019/11/09(土)22:41 ID:e6n/6jzv(1) AAS
gnsk
610: 2019/11/09(土)23:25 ID:HanEs9+F(2/2) AAS
仮にVRAMから1ピクセルだけ毎度読み戻してたらそらクソ重いやろとは思うが
今のDWMってGDI周りの扱いがどうなってんのかよくわかんねえからな
611(1): 2019/11/10(日)06:21 ID:nWjdF62e(1/2) AAS
XPでは爆速だったのがVistaから突然遅くなった
612: 2019/11/10(日)09:02 ID:R9o6dqtJ(1/2) AAS
TOPMOSTの競合の話ではない
"ごく稀に TOPMOST ウィンドウが通常のウィンドウの背面に移動してしまう現象が発生するとお問い合わせいただいています。"
"•Windows 8.1 以降、Windows 10 でも数十回に 1 回程度この現象が発生します。"
613(1): 2019/11/10(日)09:11 ID:IRh+3wYd(1/2) AAS
>>611
メモリー積め
ってかPC買い替えろ
614(1): 2019/11/10(日)09:22 ID:nWjdF62e(2/2) AAS
>>613
GetPixelの話だよ？
615(2): 2019/11/10(日)10:13 ID:2HW6YGp5(1/2) AAS
それはAeroのせいかも知れない。
色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやって
いかないので、Windowが重なっている場合、その内の一つでも色が変化した場合、
その場所に重なっている全ての Window の色が分からないと、画面に表示される
色が計算できない。Windowsは、昔はメモリが少なかったので、伝統的には、
各Windowが仮想VRAMを持たない設計になっていた。それと絡んで、Windowの
ピクセルの色を取得するには、そのWindowにWM_PAINTメッセージを送って、
アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
再描画をさせるのが伝統的やり方。
このやり方に従っているなら、ディスプレイ上の最終的な色を取得したい場合、
省2
616: 2019/11/10(日)10:14 ID:2HW6YGp5(2/2) AAS
>>615
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないので、
誤：色々なアルゴリズムがあるが、特に「半」透明の処理は、後ろから順にやっていかないといけないので、
617: 2019/11/10(日)10:48 ID:IRh+3wYd(2/2) AAS
>>614
ああすまん、それはVistaから導入されたDesktop Window Managerのせいやね
Windows 7から改良されたからマシになってるはず
618(1): 2019/11/10(日)11:26 ID:GjrjejsC(1/3) AAS
aeroで半透明になるから描画に時間かかる←わかる
だからgetpixelに時間かかる←う〜ん
呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
619: 2019/11/10(日)11:30 ID:42Oft6n8(1) AAS
getdc(0)だと全部の合成してからビデオメモリからとってくるから遅い
個別ウィンドウ指定だとウィンドウ下のとかからも取れる上に早い
個別の描画内容は多分システムメモリ上にある
大体そんなような動作っぽい
getpixel使わないからbitbltの挙動だけど多分おんなじじゃないかな
620: 2019/11/10(日)12:37 ID:R9o6dqtJ(2/2) AAS
> 呼ばれるたびにDCに対して描画させてピクセル取り出してるのならわかるけどさ
1x1のビットマップに転送して取得しているのでxpでも遅かった
621: 2019/11/10(日)13:55 ID:fP398yW4(1/3) AAS
>>615
> そのWindowにWM_PAINTメッセージを送って、
> アプリプログラマが作成したOnDraw()などの関数に本質的にはそのWindow全体の
> 再描画をさせるのが伝統的やり方。
> このやり方に従っているなら
もうやってないというか「重なり」なんて概念がないよ。
動画再生して、他のウインドウの後ろに隠して、
その状態でタスクバーにマウス乗せてみ
画面に表示されてなくても、ウインドウの中身は更新されてるからさ。
最小化したときはアプリ側で描画止めてるソフトが多いけど
省3
622: 2019/11/10(日)13:57 ID:fP398yW4(2/3) AAS
>>618
× aeroで半透明になるから描画に時間かかる←わかる
○ 半透明処理はCPUで行っていて時間がかかる処理だったがああ
GPU処理をするようになって軽くなったから、Aeroで半透明が採用された
623: 2019/11/10(日)14:11 ID:hRll0rFL(1) AAS
>>606
GetDC GetPixel で取れない場合
外部ﾘﾝｸ:maverickproj.web.あれ.com/d3d11_04.html
外部ﾘﾝｸ:ka-ka-xyz.はて？.com/entry/20101209/1291890231
外部ﾘﾝｸ[html]:codeday.me
624: 2019/11/10(日)14:11 ID:O4L9SaaX(1) AAS
GPUを使うようになった時点で、GetPixelのような処理はGPU側に問い合わせを送って
その結果を返してもらうという形になったから、遅くなるというのはあり得る話。
625: 2019/11/10(日)14:17 ID:fP398yW4(3/3) AAS
昔はVRAMにあったものがGPUのメモリにあるわけだからね。
通常の描画処理は、CPUからは命令だけ投げてあとはGPUが処理するので
GPU内で完結するから速いんだよ。でもデータを取ってきたりするのは負荷が高い。
だからピクセル単位でとってくるよりも、一定の範囲をごっそり取るほうが
GPUに出す命令は減るから結果として速くなる。
626: 2019/11/10(日)15:48 ID:GjrjejsC(2/3) AAS
でもaero切ると描画速いよｗ
GPU使おうが何しようが処理が多いのは変わらないし時間かかるのも変わらない
627: 2019/11/10(日)15:51 ID:u8+xJCBj(1) AAS
同じことをするならGPUを使ったほうが速いんだよ。
Aeroを切るとバックグラウンドウインドウの描画をしなくなるから速く感じる。
それは、それまでのOSの設計の正しさ、GPU性能が低い場合の正しさを証明してるわけ
628: 2019/11/10(日)16:09 ID:GjrjejsC(3/3) AAS
もう滅茶苦茶だなｗ
そりゃ同じことをするなら一般的にはGPUが速いよ
でも半透明処理の有無の話をしてるんだから、同じ処理での比較じゃない
半透明処理をしなければそれだけ処理が減るんだから一般的には速くなる。体感の話じゃない
昔と比べて処理が速くなっただなんて歴史はどうでもいいんだよ
で、getpixel使うときはメモリ確保してそこにsrccopyするだろ。この時点で描画なんかは終わってる
getpixelはコピーされたメモリ内容を読みだして過去のピクセルを返す処理のはず
リアルタイムのピクセル情報返すってなら半透明で遅くなるのもうなづけるけどそうじゃないだろ
629: 2019/11/10(日)16:51 ID:invbJGJm(1) AAS
Vistaから7でウィンドウ毎のシステムメモリのバッファを削減した時も
トレードオフとしてリードバックが頻発するシナリオでは従来よりペナルティがあると言ってたな
10でもDXGIのフリップモデルが増えたりFCUでGetPixelがさらに重くなる現象もあったりと今でも色々弄ってそう
ウィンドウからGetPixelする時とデスクトップからGetPixelするのではなんか事情が違うのかも知らんけど
630(3): 2019/11/12(火)19:29 ID:fqP05o8Z(1) AAS
HBITMAPの画像を上下反転や左右反転や90度単位の回転をする場合、やはりPlgBltでしょうか。
それとも、それらに特化したAPIでもありますでしょうか。
631: 2019/11/12(火)19:33 ID:R9AMJEW8(1) AAS
>>630
確か、BitBlt系の関数は選択肢が沢山あって、PlgBltだけではなかったはず。
632: 2019/11/12(火)20:44 ID:mKGma296(1) AAS
>>630
SetWorldTransform
633: 2019/11/13(水)10:09 ID:OceCV+VL(1) AAS
DirectX使えば自由
634: 2019/11/19(火)11:11 ID:NEogfZFa(1) AAS
いいかい学生さん、
「令和元年12月2n日」をな、「令和元年12月2n日」をはみ出さずに表示できるくらいになりなよ。
それが、人間えら過ぎもしない貧乏過ぎもしない、ちょうどいいくらいってとこなんだ。
635: 2019/11/25(月)20:46 ID:0q+n1Hac(1) AAS
Windows10 での symlink
外部ﾘﾝｸ:social.msdn.microsoft.com
636: 49 2019/11/25(月)22:38 ID:dg2mzwJY(1) AAS
>>630
GDIPlusは駄目なん?
637: 蟻人間 ◆T6xkBnTXz7B0 2019/11/25(月)22:53 ID:S0HuE7/3(1) AAS
StretchBltでマイナスの値を指定するとミラーリングできるらしい。
外部ﾘﾝｸ[php]:forums.codeguru.com
638(4): 2019/11/26(火)00:15 ID:FXTOqUMb(1/5) AAS
どっかで阿鼻叫喚が始まる予感
Twitterﾘﾝｸ:MurakamiShinyu
Twitterﾘﾝｸ:5chan_nel (5ch newer account)
639(2): 2019/11/26(火)09:59 ID:c3SEnPpX(1) AAS
お
いよいよcp932ともおさらばか
試行錯誤はあっても良い流れは認めよう
問題が出たら出たで治せば良いんだから
治す範囲がどんだけあっても諦めるな
なにもやらないよりまし
640: 2019/11/26(火)10:49 ID:LSm6MssX(1/2) AAS
一年前以上からあるオプトイン設定の話だが
641(1): 2019/11/26(火)11:36 ID:fVihpbt7(1/4) AAS
>>639
cp932使ってる古いアプリは、この設定にすると
動かなくなるだけ。つまり捨てるしか無い。
cp932を使ってる古いアプリを捨てるって話なら、
ずっと前から捨てられる。
Windows自体はコマンドプロンプトも含めて
ずっと前から完全にUnicode対応
642: 2019/11/26(火)11:45 ID:fVihpbt7(2/4) AAS
「ワールドワイド言語サポートで Unicode UTF-8 を使用」をするとどうなるか？
Unicode対応のアプリ・・・設定とはとは無関係にUnicode対応
Unicode非対応のアプリ・・・
日本語アプリはcp932でないと動かない。
ASCIIしか使えないアプリはcp932でもUTF-8でも動く。
UTF-8に対応したアプリは現時点ではまず存在しない。
この設定は今後UTF-8に対応したアプリが作られたときのための設定
この設定はデフォルト値でしかないのでUTF-8にしてもchcp932相当のことをすればcp932アプリは動く
互換モードの設定でコードページを指定できるようになるかもしれないね
643(1): 2019/11/26(火)11:55 ID:sOexhNbU(1/2) AAS
コマンドプロンプトは怪しいな
644: 2019/11/26(火)11:55 ID:dbvsSdaZ(1/5) AAS
いまだにファイルパスがユニコード対応してないアプリあるからな。氏ねと言いたくなる
645: 2019/11/26(火)11:57 ID:fVihpbt7(3/4) AAS
>>643
コマンドプロンプトはUnicode対応だよ
cp932の状態でもdirでUnicodeのファイル名表示できてるじゃん
646(1): 2019/11/26(火)12:05 ID:sOexhNbU(2/2) AAS
chcp 65001
でバグバグになるのいつ治るの
647: 2019/11/26(火)12:08 ID:fVihpbt7(4/4) AAS
>>646
表示が崩れる問題なら直ってる。
動作自体なら以前から問題なく動いている。
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に書き換えられたら次読み込んだ時滅茶苦茶になるだろ
一般的なテキストエディタも勝手に文字コード変えるような事はせんからな
上下前次1-新書関写板覧索設栞歴
あと 307 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.041s