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 型に変更したほうが良いです。

ユニコード文字列の取り扱い (訂正版)

以前の記事の訂正版です。Lazarus 1.6 の完成により事情もだいぶ変化したので、内容を少し改め分かりやすくしたほうがよいと思い、訂正しました。

Lazarusの標準文字コードはUTF8です。したがって、森鷗外の「鷗」のように、ユニコードにはあるがシフトJISにはない文字もあっさり使用できます。例えば、Label.Caption := '森鷗外'; のように。
そして、Lazarus には Delphi と同じく、ユニコード文字列を取り扱うためのルーチンが豊富に用意されています。したがって、自分でコーディングしてユニコード文字列を処理する場面では困ることはないと思います。

Lazarus 1.4 には次のような問題がありました。 

それは、LCLやRTLなどにある既存のルーチンでのユニコード文字列の取り扱いです。代表的なものはファイルのパスで、例えば 多くのオブジェクトに搭載されている LoadFromFile メソッドには、パスをシフトJIS(ANSI)で渡さなければいけません。 したがって、 LoadFromFile(UTF8ToSys(filename)) のようにして、UTF8をシフトJISに変換して渡す必要があります。当然、ファイル名に、"森鷗外.txt"のようなユニコードにはあるがシフトJIS にはない文字が含まれていた場合はエラーになります。これは、内部で Windows API をコールする際に、シフトJISしか使えないAPI、いわゆるA系のAPIを使っていることが主たる原因です。
この問題を解決するため、lazutf8classes や FileUtil ユニットなどに、ユニコード文字列に対応したルーチンが準備されています。その多くは、ParamStrUTF8やFileExistsUTF8、 TFileStreamUTF8、TStringListUTF8 など、標準名＋"UTF8"という名前がつけられています。これらが Windows API を使用する場合は、ユニコード文字列に対応したいわゆるW系のAPIを呼び出してくれます。
しかし、これで問題が全て解決するわけではありません。先程の例である LoadFromFile メソッドのほとんどでは内部でTFileStreamUT8ではなくTFileStreamを使用しているため、結局ユニコードのパスは使用できません。 また、UTF8対応の関数を使う必要があるかという判断には、その関数がどういう処理をするのか、シフトJISとUTF8の違いはなんなのか、という知識 が求められることになります。

繰り返しますが、以上は Lazarus 1.4 でのお話です。 Lazarus 1.4 は、FPC(=Free Pascal Compiler) 2.6 をコンパイラとして使用するのですが、FPC 2.6 の基本ルーチンがANSIしか処理できないため上記のようになってしまっています。FPCに依存せずに Lazarus側が全て自前でユニコード処理をしてしまえばよいわけですが現実的ではないので、lazutf8classes や FileUtil ユニットなど最低限のものを苦肉の策としてLazarus側で準備しているわけです。
これに対し、FPC 3.0 では、ユニコード標準対応を謳っています。誤解をおそれずに簡単にいってしまえば、多くの基本ルーチンで、引数がANSI文字列型の場合はA系APIを、ユ ニコード文字列型の場合はW系APIを適切にコールしてくれるようになります。これによって、上記の問題は完全に解決されます。そして、Lazarus 1.6 では、FPC 3.0が Lazarus の標準コンパイラに採用されました。

Lazarus 1.4 で作成した自前のソースを Lazarus 1.6 でビルドすると、UTF8ToSys関数、 lazutf8classes や FileUtil ユニットなどのUTF8対応ルーチンを使用している箇所でWarningが出るので修正すべき場所がすぐ分かります。UTF8ToSys関数はもはや不要 になりますし、TFileStreamUTF8などはUTF8を取ってTFileStreamを使えば良いことになります。

三項演算子です

C++では、三項演算子（ternary operator）が使えます。次のようなものです。

x = a ? b : c;

解り難いとかの批判もあるみたいですが、それは条件等が複雑な場合だけで、そうでない場合は逆に if 文よりも解りやすいと思うのですがいかがでしょう。

果たして Lua でこれを実現できるのでしょうか？

Lua のリファレンスマニュアルには次のように書かれています。

論理積演算子 and は最初の引数が false か nil であればその値を返し、そうでなければ2番目の引数を返します。 論理和演算子 or は最初の引数が nil でも false でもなければその値を返し、そうでなければ2番目の引数を返します。 and と or は両方とも短絡評価を行います。 つまり2番目の引数は必要な場合にだけ評価されます。
　～　Lua 5.3 リファレンスマニュアル - 論理演算子

The conjunction operator and returns its first argument if this value is false or nil; otherwise, and returns its second argument. The disjunction operator or returns its first argument if this value is different from nil and false; otherwise, or returns its second argument. Both and and or use short-circuit evaluation; that is, the second operand is evaluated only if necessary.
　～　Lua 5.3 Reference Manual – Logical Operators

よって、

x = a and b or c

これで三項演算子が実現できます。ただ、慣れないうちは三項演算であることが分かり難いかもですね。
なお、C++ では数値の 0 は false と判定されますが、Lua では true と判定される点には注意してください。