- Windows 7 x64
- Quantum GIS Lisboa 1.8
- GDAL/OGR 1.9.1
いろいろと思考錯誤していて、GDAL/OGR がどのように多言語に対応しようとしているのか、わかってきました。
QGis Python Plugin と日本語の周辺1 に書いていたコードは、実はベストプラクティスでは無い事が判明いたしました。
まずは、基本的なおさらいから…
Linux, mac 等の環境では、UTF8 で文字コードを取り扱うのが基本になります。それに対して Windows では MBCS がベースで、プログラム内部の文字コードは、MBCS か UNICODE(UCS2) を選択します。Visual C++ のコンパイルオプションで、どちらを選択するか可能なのですが、もう少し中身を説明すると、Windows API には、MBCS 系の文字コードを引数にとる HogeA という大文字 A をサフィックスにとるものと、UNICODEの文字コードを引数にとる HogeW という大文字 W をサフィックスにとるものが対になって存在します。C言語では、単に
#ifdef _UNICODE #define Hoge HogeW #else #define Hoge HogeA #endifというように、マクロで切り替えているだけなのです。 ですので、MBCS系の文字コードでコンパイルをしていても、UNICODE系のAPIをコールする事は可能となっています。
ここから、本題に入ります。QGIS では、GDAL_FILENAME_IS_UTF8 = YES を前提としています。それは、どのようなトリックかというと、ogr2ogr.exe 等の実行ファイルのパスは MBCS でないと実行できません。ところが、コマンドラインのオプション引数は MBCS である必要は、ありません。極端な話、UTF8 の文字コードをコマンドラインのオプション引数に渡しても問題ありません。 GDAL/OGR の shape ドライバでは、Windows 環境かつ、GDAL_FILENAME_IS_UTF8 = YES であれば、UTF8で引き渡された文字コードを内部で UNICODEに変換して、ファイル操作を行うように書かれていました。この手法でいけば、windows 付属の iconv.dll では、UTF8 と UNICODE 間の変換さえ、うまく行けば、IO(入出力回り)の文字化けに対応できる事になります。
では、どうすれば日本語のファイルをコマンドラインから扱う事ができるか?
GDAL_FILENAME_IS_UTF8 = NO というような設定は、実は一切不要でして、サクラエディタなどのUTF8が扱えるエディタを使って、バッチファイルを作成し、ファイルを保存する時に、文字コードを「UTF8」にして保存してやればOKでした。QGISのインストール先を日本語の混じったフォルダ下にしなければ、これで、問題なく動くはずです。
UTF-8で書かれたバッチファイルを実行する事です。
問題は、Python で、どうやって UTF-8 な文字コードを subprocess.call に引き渡す事ができるのか。ここが、わかりませんorz...。
0 件のコメント:
コメントを投稿