URL エンコードの仕組み自体は把握して変換もできたけど、数字とアルファベットと一部記号まではトラブル無し。しかし日本語の扱いで困っている。
エクステ内部でワイド文字列として扱われている文字列を、マルチバイト文字列に変換するロジックを間に挟まないといけないっぽい。ってことは、Shift-jis へ一律変換するのはまずいので UTF-8 をデフォルトにするのが無難だし妥当。しかし可変長マルチバイトなので UTF-8 の方が長ったらしい変換結果になる。
”日本語表現”＝（Shift-jis としてエンコ）＝ %93%FA%96%7B%8C%EA%95%5C%8C%BB ”日本語表現”＝（ UTF-8 としてエンコ）＝ E6%97%A5%E6%9C%AC%E8%AA%9E%E8%A1%A8%E7%8F%BE
受け取る側＝サーバサイドのスクリプトで文字列を受け取る場合、文字コード指定は必要になるだろうから GET の時と同じように文字エンコード方式を選択させるようなオプションをつける必要があるかもしれない。
エクスプレッションの引数を考える
関数は URLEncode$(TCHAR string, int param1);
これで第二引数の int pram1 に 0 〜 3 で指定をしてもらう。
- 0 ＝ ANSI (マルチバイトへの変換不要）
- 1 ＝ UTF-8
- 2 ＝ Shift-Jis
- 3 ＝ Euc-JP
１ 〜 ３ のオプションを指定した場合は日本語を使っている（あるいは ANSI では表現できない符号化された文字列を使っている）という前提で、エクステ内部ではワイド文字列としてこれまで扱ってきた文字列を指定されたエンコード方式のマルチバイト文字列へ一度変換する処理を挟む。
この変換された文字列を URLエンコードして、もう一度マルチバイトからワイド文字列へ変換する。
新しく作られたワイド文字列としてエクステから CF25 本体へ送信。
やばい、なんだこれめんどくさいすぎる。
しかもこのエクスプレッションに引数２つ与えるのは効率悪い。POST データは複数登録される場合もあるからその都度エンコード指定をさせることになる。
こうするしかないか…ということはアクションをひとつ増やす方向で
エクスプレッションは「URLEncode$」
まだ未定義のアクションは
Encode setting (POST)
結局受け取るときはデコードで苦しみ、送信する時はエンコードで苦しむ二重構造の苦しみが待っていた。文字コード変換は難易度高いは…。