取得する文字列の文字エンコードを自動で判定するロジックもあるがいくつか問題が。
まず判定精度を高くするためにはサンプルとしての文字列が一定数以上あるという前提、この前提が成り立たないと自動判定も精度を落とすことになる。
つまり十分に判定するための文字数が無いページだと判定に失敗する可能性。そして自動判別にすべて頼り切ってしまうと、この自動判別がもしも間違った場合に異なった文字エンコードを設定してデコードすることになるため、結果として文字が化けて表示される。
自動判定じゃ無い場合の処理を考える
自動判定じゃないなら手動判定だが、CF25 の場合アクションから毎回文字エンコードを指定することでデコード処理を内部的に選択できるようにする、などが方法として考えられるはず。
初心者には「文字エンコード？？なにそれ？」なのだろうが、そんなもん自分で調べてもらえばいいのでこの際キニシナイ。
日本語の場合「Shift-Jis」「Euc-JP」「UTF-8」などがウェブでは利用されているが、いちおう先ほどこれら三つの文字エンコードからのデコード処理にそれぞれ成功。本家の Get Object にはこういう機能がないためこういう機能が欲しかったのである。
日本語ページの表示に関する対応としてはほぼ理想的な実装になってると思う。もちろん英語ページも取れる…はず？試してなかった。
クリックチーム本家フォーラムで試してみた
試す前に文字エンコーディングを事前に調べてみたら「西欧諸語を扱う＝ISO-8859-1」が指定されていた。さすがにこれだったら ANSI で良いっつーか、UTF-8 でも Euc-JP でも間違った指定をしても文字は化けないはず。日本語と違ってオソロク簡単である。
実際化けることはなかった、なんなく成功。しかし…
ここで別の問題発生
これまで文字列を定数で確保していたけど、確保してあった定数よりはるかにでかい相手と戦った場合、メモリ領域不足になる。当たり前である。
CT のフォーラムページは結構な量の情報というか文字数だったため確保してあった定数よりも大きかったからメモリアクセス違反でアプリが落ちた。動的確保に切り替えないとアカンという結論に。