[Ruby] Win32OLEの1.8と1.9の違い(その2)
3. WIN32OLE.codepageの動作が変わった。
Ruby m17n絡みで変わった点です。
まず、WIN32OLE.codepageの初期値は、1.8では、WIN32OLE::CP_ACPでしたが、1.9では、Encoding.default_externalに従って初期値が決まります。
また、1.8では、RubyのStringオブジェクトをOLEサーバー側に渡すときに、WIN32OLE.codepageを参照してUnicode(UTF-16LE)に変換して
渡していましたが、1.9では、StringオブジェクトのEncoding(String#encoding)を参照してUnicode(UTF-16LE)に変換するようになりました。
このため、1.9では、WIN32OLE.codepageの値が意味を持つのは、OLEサーバー側からStringオブジェクトを受け取るときです。
Stringオブジェクトを受けとるときに、WIN32OLE.codepageの値に従って変換されます。
たとえば、
# -*- encodinge:Windows-31J -*-
dict = WIN32OLE.new('Scripting.Dictionary')
dict.add("Windows31J", "あいう") # Windows-31Jの文字列 "あいう"をセット
puts dict["Windows31J"].encoding # => Windows-31
puts("あいう" == dict["Windows31J"]) # => true
WIN32OLE.codepage = WIN32OLE::CP_UTF8
puts dict["Windows31J"].encoding # => UTF-8
puts("あいう" == dict["Windows31J"]) # => false!!!
puts("あいう".encode("UTF-8") == dict["Windows31J"]) # => true
となります。
つまり、WIN32OLE.codepageの設定によっては、OLEサーバー側に渡した文字列のエンコーディングとは異なるエンコーディングの文字列をOLEサーバーから受け取ることになります。
WIN32OLE.codepageのこの動作は、将来、変更される可能性があります。
また、OLEサーバー側から受け取るときだけWIN32OLE.codepageが登場することから、WIN32OLE.codepageという名前が変わる可能性もあります。
| 固定リンク
この記事へのコメントは終了しました。
コメント
2020人気TOPブランドコピー腕時計専門店。
こういうユニークなコピーブランドは貴方の気質に顕現できるだけでなく、個性と魅力に漂います。
もしできれば、ご来店を期待しています。
世界の一流ブランド品N級の専門ショップ
◆在庫情報随時更新!(*^-^*)
◆スタイルが多い、品質がよい、価格が低い、実物写真 .
◆100%品質保証!満足保障!
2020超人気 ブランドコピー時計超美品
投稿: スーパーコピー時計 | 2020年11月 7日 (土) 07時16分