4d-class-powershellについて

スレッド分けました。

miyako wrote:追伸

結論から述べるとShift_JISにする必要があるようです。

BLOB入出力，BOMありなし，試しましたが，いずれも同じように化けました。

なおmacOSはUTF-8でも化けませんでした。

リポジトリのほうはWindowsでShift_JISを使用するように更新してあります。

P.S.

chcp 65001もダメでした・・・

これってpowershell側の問題でしょうかそれともSystemWorkerの問題でしょうか。
LAUNCH EXTERNAL PROCESSの時もこんな問題があった様な気がします。

現象は開発部に伝えましたが「PowerShellそれともSystemWorkerの問題」は現時点で断定できない状況です。

"を:を:を:を:を:"

が

"めEめEめEめEめE"

として返されるわけですが「を」単体なら化けないなど，不可解な側面があります。

文字コードは

を:

utf-8: E382924A
utf-16: 3092004A
SJIS: 82F04A

めE

utf-8:E3828145
utf-16: 30810045
SJIS: 82DF45

となっており，何がどうして化けるのが謎です。

miyako wrote:現象は開発部に伝えましたが「PowerShellそれともSystemWorkerの問題」は現時点で断定できない状況です。

日本語文字化けの件はまだ未解決でしょうか。

はい。

本件は2022年10月17日に開発部へ報告済みですが，原因がわからず，調査が難航しています。ずっと後に報告された不具合はつぎつぎと修正され，本件だけ取り残されている状況です（現在のプライオリティー1位）。

申し訳ございません。

ありがとうございます。
現状SystemWorkerは日本語環境では使えない可能性があるということですね。

SystemWorkerではなくPowerShell特有の問題かもしれません。

miyako wrote:SystemWorkerではなくPowerShell特有の問題かもしれません。

pwsh.exe単体での実行では文字化けしないですよ。念の為に最新のR8を使って確認しました。

Mac Ventura 13.2（22D49）でためそうとおもったのですが色々なファイルがセキュリティにひっかかって実行できないですね。

はい。プロンプトで化けないことは把握しています。



ただ，PSがANSI/UTFをBOM等で判定している場合，文字コードが入力と出力で二重に化けているのかもしれない，と考えました。

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding?view=powershell-7.2

当方，Venturaで実行できていますが，zip圧縮したり，OneDriveなどの共有フォルダーを経由してしまうと，検疫フラグがついたりするかもしれません。

Macの場合，.dmg形式にしたり，Gitなどのツールでファイルをダウンロードするといった工夫が必要かと思います。

githubで'最新の可能性のあるエンコードの問題’バージョンで再テストしてみました。
なんか動かなくなっているものが複数でてきました。

Code:

//CSV読込→JSON変換
$csv_file:=Folder(fk resources folder).folder("CSV").file("CsvSample1.csv")
$command_t:=New collection("Import-CSV"; $csv_file.platformPath; "-Encoding Default | ConvertTo-Json").join(" ")
$response:=<>instance.command($command_t)

powershellのプロンプトにコピペすると動作するので$command_tの内容が原因ではないようです。

追加情報

英語版のWindowsでは問題ないことを確認しました

参考　

https://stackoverflow.com/questions/49476326/displaying-unicode-in-powershell/49481797#49481797

$OutputEncoding や [Console]::OutputEncoding を変更すると，返される文字列も変化する（別の化け方）ので，やはり，PowerShell側の問題のように思います。

なお，上記リンクによると，PSはキーボード入力と標準入出力ストリームではエンコーディングの設定が違う（一部は共通）ようです。またBOMなしをANSIとするかUTF-8とするかもコマンドレットによって違う，という話もあります。それにオープソース版のPowerShell CoreなのにANSIとかコードページといった設定を継承することからすると，Windows版のCoreは従来のPowerShellと内部的につながっている可能性があります。

https://github.com/PowerShell/PowerShell

SystemWorkerを使用する場合，Windowsの言語に左右されるPowerShellではなく，別の言語で開発された実行ファイルをコールしたほうが無難かもしれません。

miyako wrote:SystemWorkerを使用する場合，Windowsの言語に左右されるPowerShellではなく，別の言語で開発された実行ファイルをコールしたほうが無難かもしれません。

結局のところ日本語環境で利用するSystemWorkerではPowerShellは使えないという事ですね。結論が出てよかったです。

ちなみにSystemWorkerはwindowsではどの OSAPIをコールしているのでしょうか。

確認が取れました。

macOSはPOSIX APIの<spawn.h>

Windowsはprocessthreadsapi.h

miyako wrote:確認が取れました。

macOSはPOSIX APIの<spawn.h>

Windowsはprocessthreadsapi.h

これってLEPと一緒じゃないでしょうか。

これはちゃんと結果がかえってくるのですが

Code:

var $exec_t; $in_t; $out_t; $error_t : Text
$line_t:="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe \"[String]::Format(\\\"数値を16進表示: {0:x}\\\", 1234)\""
LAUNCH EXTERNAL PROCESS($line_t; $in_t; $out_t; $error_t)

こちらはダメですね。単純にLEPの後継というわけでは無い様です。

Code:

$line_t:="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe \"[String]::Format(\\\"数値を16進表示: {0:x}\\\", 1234)\""
$myWinWorker:=4D.SystemWorker.new($line_t)

LAUNCH EXTERNAL PROCESSは，入出力ストリームにテキスト型を使用した場合，ANSI（いわゆるSJIS）でやりとりする点に留意してください。

SystemWorkerとPowerShellの例題も，デフォルトはUTF-8ですが，エンコーディングをWindows-31Jに設定すれば問題ありませんでした。

miyako wrote:LAUNCH EXTERNAL PROCESSは，入出力ストリームにテキスト型を使用した場合，ANSI（いわゆるSJIS）でやりとりする点に留意してください。

SystemWorkerとPowerShellの例題も，デフォルトはUTF-8ですが，エンコーディングをWindows-31Jに設定すれば問題ありませんでした。

SystemWorkerのoptionを追加しました。

Code:

$option:=New object()
$option.hideWindow:=True
$option.encoding:="Windows-31J"

にして実行しましたが結果が返ってきませんでした。
試しに$myWinWorker.wait(1)の行を追加したらちゃんと返ってきました。

まとめるとSystemWorkerをwindowsで使う場合
1.encodingはあるけれど実質window-31J前提
2.レスポンスを受け取る場合wait()は必須

まとめていただいてありがとうございます。

相手プログラムが入力ストリームの「待ち受け」をしている場合，

$myWorker:=4D.SystemWorker.new($text; $param)
$myWorker.closeInput()
$myWorker.wait(10)

のように記述して，こちらの入力を終了した上で，答えを待つ必要があるかもしれません。

wait()

は相手プログラムの終了まで待つ命令，タイムアウト付きのwait(x)は事実上の同期処理となります。

Windowsであっても，PowerShell以外のプログラムであれば，大概，UTF-8でやりとりできるはずです。

https://qiita.com/zawazawa5809/items/d6f84cf92a56f47229ed

こちらに書いてあった
'ワールドワイド言語サポートでunicode utf-8を使用'
にチェックをいれたら文字化けがなおりました。

miyako wrote:
を:
utf-8: E382924A
...
めE
utf-8:E3828145
...
となっており，何がどうして化けるのが謎です。

なんとなく原因がわかったので書いておきます。
WindowsAPIでの文字コード変換でShiftJISで表示できないと判断した文字は8145（ShiftJISで「・」らしい）に置き換えられるみたいです。
UTF-8の文字コードを見比べるとわかるのですが、上位２バイトはSjiftJISで表示できる文字としてそのままになっているのですが、下位2バイトは表示できない文字として8145に置き換えられている様に思われます。