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 が混在している事が判明しました。 　エスパーじゃあるまいし、知るか！