ここ数年、ソフトウェア自体やソフトウェア開発の国際化が急速に進んでいますね。国際化に対応するために、開発ツールもいろいろな対応が必要になってきています。一方で、開発ツールが高機能化し、多くのコードを自動生成するようになったことで、プログラムの要素と目に見えるもの（ユーザーインターフェースなど）の境目がなくなってきました。結果として、開発効率を向上するためには、プログラム中でも日本語が使用できることが必要になってきています。今回は、こういった国際化と日本における開発効率を両立するための重要なポイントでありながら、意外と語られていない文字のエンコーディング（符号化）について思いつくまま書くつもりです。
今までエンコーディングなんてあまり気にしていなかったという方にも読んでいただきたいので、最初にちょっとだけ、これまでの流れについて触れておきたいと思います。
PCの世界ではMS-DOSの時代から長い間shift-jisが使用されてきました。２０年くらい前は、shift-jis で全く問題ありませんでした。ソフトウェアの国際化は進んでいなかったですし、大半の開発者がプログラムは英語であたりまえと考えていたからです。しかし、ご存知の通り、shift-jis で保存されたテキストファイルは他言語のオペレーティングシステムでは正しく表示できませんし、一つのファイルに多言語のテキストを含めることもできません。これでは、国際化にも対応できませんし、プログラム要素に日本語を使うといったこともできません。そこで、Unicodeの登場です。Unicodeに対しては賛否両論いろいろご意見があるかもしれませんが、認知度や採用実績を考えるとUnicode以上のものは存在しないという点ではおおかたの合意が得られるのではないでしょうか。Microsoftも１０年以上前からオペレーティングシステムでUnicode採用してきていますし、今後もUnicodeを全面的に採用していくことになるでしょう。
そういえば、予断ですが、先日（といってもだいぶ前になりますが）開発環境展に行ってきました。そこでも比較的日本に特化していると思われる帳票のコーナーでさえ、頻繁にUnicode という単語を目にしたような気がします（気がするだけかも）。
さて、開発ツールの話に戻しますと、以前からVisual C++でUnicodeライブラリを使ってUnicodeアプリケーションが開発出来る他、Visual Basicも内部的Unicodeを使用していました。しかし、言語仕様や統合開発環境における本格的なUnicodeサポートとなると意外にも３年前のVisual Studio.NETが最初になります。Visual Studio.NETに含まれる、Visual Basic.NET、Visual C#やVisual J++といった開発言語（以下、まとめて .NET開発言語と呼びます）では、言語仕様を見ていただければ分かるように、言語文法中の文字の定義自体がUnicodeをベースにしています。もちろん、.NET開発言語のベースとなる共通言語ランタイムにおいても、名前や文字列はすべてUnicodeであり、内部的もUnicodeを使用するよう規定されています。
このことによって、クラスやメソッドなどの名前に日本語を使用することができるようになり、しかも日本語のメソッドは他言語（ここでは、英語、中国語など普通の言語、以下、「自然言語）として区別します）のオペレーティングシステム上で正しくコンパイル、実行できるようになりました。例えば、以前はデータベースのフィールド名が英語の場合には、「CustomerField」「RegistrationNumberField」のように分かりやすい名前をつけられても、日本語であった場合には、Field1、Field2というように単に番号を付けただけの名前になってしまっていましたが、.NET開発言語では、英語の場合と同様に「顧客Field」「登録番号Field」といった直感的に分かる名前を付けることができるようになりました。実際、Visual Studio.NETでは、このような分かりやすい名前を自動生成します。同様にMenuItemなども名前に日本語が使用できると、分かりやすい名前が生成できるようになりますね。ここで、国際化という観点では他国の開発者がソースコードを参照する場合のことも考えなければいけませんが、Field1というような名前のまま他の開発者にソースコードを渡すことはないでしょうから、どのみち名前の変更が必要になるのなら、元の名前が分かりやすいに越したことはありませんね。ただし、課題もあります。現状では、日本語の名前はIMEで確定しないとインテリセンスで選択されません。将来的には確定前であってもインテリセンスが動作するようにしたいものです。
ところで、「Unicodeでなくても日本語をクラス名に使用できるようにすることはできるのでは？」という疑問を持つ方もあるかもしれませんが、文字の検証や型安全性、さらにはセキュリティを考えたとき、どの言語のオペレーティングシステム上であっても一意に決まる文字でなければ、クラス名などに使用することはできません。
また、Unicodeの本来の目的を忘れてはいけません。当然ながら、日本語が使えるというだけでなく、今までshift-jisでは使用できなかった文字も使用できるようになります。「ゥ」もとい「©」もきちんと表示できるようになりますね。
ここまでコンパイラにはUnicodeで渡っているという前提で書いてきたので、完全に（ライブラリも含めて）内部的な話でした。エンコーディングは渡す側－受け取る側、書き出す側－読み込む側の間の決め事なので、この決め事がしっかり決められている内部では、すんなりUnicodeへ移行できました。さて、問題はソースファイルなど、外の世界とのやり取りです。過去との互換性、他のツールとの互換性などなど考えなければならないことがいっぱい。
本当に書きたかったのは、これからなのですが、ん～、なにやら上司が呼んでいます。という訳で、今週はここまで。続きは近いうちに（できるだけ、来週書けるように頑張ります）。