2014年7月25日金曜日

GDAL-1.10.1 の日本語環境ではまった

 たまーに、お客さんから DBF ファイルにエンコーディング(文字コード)の設定をしていない Shape ファイルを貰うんですわ。 そしたら、ogr2ogr にかけると、文字化けするんです。
set SHAPE_ENCODING=LDID/19 
って、やっても文字化けは直らないんで、調べました。 DBF をバイナリエディタで見ると、もらった Shape ファイルは、DBFファイル中のヘッダーパートの29バイト目の値(エンコーディング)が 0 のままで、データに使用されている文字コードはCP932(Shift_JIS)でした。 GDALのコード中の処理順序は、こんな感じです。

  1.  DBF ファイルの codepage が設定されているかどうかで処理
  2. CPGファイルに codepage が設定されているかどうかで処理
  3. 環境変数 SHAPE_ENCODING の値が設定されているかどうかで処理
  4. プログラム・オプションに codepage が指定されているかどうかで処理
  5. 文字コードは変換しないで、そのまま利用する
これ、SHAPE_ENCODING を設定してても、DBFファイルにエンコーディングが設定されていれば、正しい変換を行ってくれるので、素晴らしいです。
調査していると、1.10.1 のバージョンでは
set SHAPE_ENCODING=CP932
としないと、ちゃんとSJISとして扱ってくれないようでした。いつから LDID/19 じゃなくなった? こんな調査に半日以上費やしました・・・(`;ω;´) 2014/09/04 追記: 環境によって、SHAPE_ENCODING=LDID/19 にしないと変換してくれない場合があったりして混乱中。  ソースを修正しすぎた?  なんと、UTF-8 コードで書かれた shape と、CP932 コードで書かれた shape が混在している事が判明しました。  エスパーじゃあるまいし、知るか!