Lazarus 1.6(FPC3.0)の文字列自動変換は使用しないのが吉

僕は以前、FPC 3.0 では、コードページが異なる文字列の代入時に FPC が文字コードの変換を自動的に行うようになり、便利だよというようなことを記事にしました。

しかし、結論からいえば、この「自動変換機能」は使用しないほうがよいです。いろいろテストしてみたのですが、理解しにくい現象が発生することがあり、現時点ではとてもおすすめできる機能ではありません。
とはいってもこの機能が使えないからといって何も悲観的になる必要はありません。よく考えて見れば、自動変換ってそれほど便利なものなのでしょうか。以前の記事で僕は「Decode や Encode という、どっちがどっちかよくわからない命名に悩まなくてよくなるだけでなく、ソースファイルのコードページが UTF8 でない場合にも対応できるようになります。」と書きました。これは結局「文字コードが何かをプログラマーが気にする必要はない」という夢の様な話をしているのですが、経験のある方ならご存知のとおり、使用している文字コードが何かすら把握できていないようなソースコードほど保守が厄介なものはありません。特に、昔から色々な文字コードを使用してきた僕達日本のエンジニアはそのことをよく分かっています。
今までどおり、文字コードの変換には UTF8Decode() や UTF8Encode() などを使いましょう。そうです何も変える必要はないのです。むしろ、Lazarus のバージョンによってソースコードを変えるという厄介な事態が回避できて嬉しいくらいです。

話が長くなるのであまり多くは書きませんが、「自動変換機能」が使えない諸悪の根源は、簡単にいってしまえばコンパイル時の文字コードと実行時の文字コードがこちらの意図とは異なるものになってしまう場合があるからです。

さて、繰り返しますが、我々は、Lazarus 1.4 で書いたソースコードをわざわざ Lazarus 1.6 の新しいコードページ文字列のために書き換える必要はありません。具体的なまとめとしては次のことを守れば、「自動変換機能」によって生じうる異常現象を回避できます。

1. UTF8文字列とUTF16文字列の相互変換には、今までどおり UTF8Decode() や UTF8Encode() などを明示的に使う。
   例えば、間違っても、次のようなコードは書かないでください。
   
   var s: UnicodeString;
   s:='あいうえお';
   
   UnicodeString 型(および WideString 型)の文字コードは UTF16 で、'あいうえお' の文字コードは UTF8 ですから、今までどおり、
   
   s:=UTF8Decode('あいうえお');
   
   と、してください。
   
2.  UTF8String 型は使用しない。
   UTF8String 型を使うと異常現象に悩まされることがあります。現時点では UTF8String 型を使用するメリットは何もありません。素直に string 型を使用してください。
   Lazarus 1.4 では string 型と UTF8String 型は完全に同じものでしたが、Lazarus 1.6 では両者は異なるものになりました。あまりいないとは思いますが、Lazarus 1.4 で UTF8String 型を使っていた方は string 型に変更したほうが良いです。