返信

> >> yuko さん > > > なるほど、それは知りませんでした。Windows側がよしなにやってくれるところなんですね。 > > すみません、「ANSI」というのは、今の環境 (ロケール) で使うべきローカル文字コード、という意味で使っていました。 > > なので、Windows が勝手にいい感じに変換してくれる、というわけではないんです。 > > 今考えているのは、第 3 引数 (UTF8 フラグ) を false にしたときは、Mery 側で OS のロケールを調べて、それぞれの環境に合ったエンコードに変換して返す、という仕組みです。 > > > …が、よくよく考えれば、バイナリをBase64にすること自体は以下の方法でできることに気づきました。これらの方法でBase64にはできるので、わざわざ実装しなくても良さそうですね。すみません😅 > > いえいえ、特に実装が大変というわけではないのですが、検討や検証のために、何かそういったアプリや API があるのかなーと思った次第です。 > > 「外部プログラム側でデコードが必要」とおっしゃっていたので、もしかして自作ツールかな？と😅 > > > リモートファイル to Base64 の場合 → curlの出力を一時ファイルとして保存してから 1 と同じ方法でBase64化 > > `base64`コマンドって標準入力にも対応しているので、一時ファイルに出力しなくても、こんな感じで Base64 化できそうですね。 > > ``` > cmd.exe /C curl https://www.haijin-boys.com/ | base64 > ``` > > > こうやって整理すると、画像生成についてはBase64とかせずに普通にファイルとして保存した方が閲覧など汎用的に使えるのが見えてきてしまいましたね。。。😅 > > 確かに、一度 Base64 にする必要はあまりなさそうな気もします。 > > ただ、たとえばセキュリティ的な理由で`cmd.exe`を使いたくない場面や、`base64`コマンドがない環境だと、`shell.Exec`で直接 Base64 形式を返せると便利なこともありそうな気もします。 > > >> enaka さん、yuko さん > > > Base64に反応して昔のnntpによるnetnewsやmailで使われた「ROT13/47」や「X-Face:」や「Sixel」などのエンコードを思い出しました。 > > 情報ありがとうございます。 > > mail といえば、Mery の [Base64 エンコード] 機能は、もともとメールを想定していたため、76 文字で改行が入る仕様になっています。 > > そこでとりあえず、`shell.Exec`で Base64 対応するかどうかはさておき、仮に対応する場合、やっぱり 76 文字改行ありの方がいい感じでしょうか？ > > 最近では、Base64 はメールよりも Web 系で使われることの方が多い気がしていて、改行なしの方が扱いやすいケースもあるかも、と思いまして。 > > ちなみに、`base64`コマンドのデフォルトは 76 文字改行のようですね🤔 > > > 一目で何が書かれているかわかる人間デコーダーも存在したらしい。 > > 16 進数の羅列を読める逆アセンブラの人たちもいますし、「人間デコーダー」がいてもおかしくないですよね (笑) > > >> barrackdo さん、yuko さん > > 情報ありがとうございます。 > > PowerShell って Base64 文字列を引数として受け取れるんですね。 > > > Base64 表現は、UTF-16 エンコードされた文字列でなければなりません。 > > なるほど、Base64 エンコードされた「バイナリデータ」ではなく、「コマンド文字列」を受け取れる、ってことなんですね。 > > そう考えると、現在検討している`shell.Exec`から Base64 形式で返す機能とは、少し相性が悪いかもしれませんね。 > > しかも UTF-16 が絡んでくるとなると… > > `shell.Exec` → Base64 (バイナリ) → マクロ側で Base64 デコード → マクロ側でバイナリを UTF-16 に変換 → マクロ側で Base64 にエンコード → PowerShell へ渡す。 > > …という、なかなかの回り道になりそうな気がします😅 > > うーん、`shell.Exec` に Base64 で出力する機能を入れるかどうか、方向性さえ定まれば開発に入れるのですが…。具体的な用途が見えてくれば、という段階ですね。

マークダウンを有効にする