GDAL 1.9, unicode и сопутствующие проблемы

GDAL постепенно движется в сторону полной поддержки unicode: уже реализован RFC 23, продолжаются работы по реализации RFC 5.

Еще одним шагом стала реализация перекодирования атрибутов shape-файла в UTF-8 при чтении, и из UTF-8 при записи. Только вот… кодировка определяется путем считывания LDID (Language Driver ID) из заголовка DBF. Вобщем-то это правильный подход, только что-то я не припомню когда в последний раз видел шейпы с корректно указанной кодировкой. В основном попадаются файлы, у которых LDID установлен в 87, что соответствует значению default.

Здесь начинается самое интересное. Понятно, что этот самый default у всех разный. А в текущей реализации значение LDID/87 трактуется как ISO8859_1 (Latin-1). Чем это грозит, думаю, понятно всем. В качестве решения предлагается либо отредактировать имеющиеся файлы и задать нужную кодировку DBF, либо переопределить трактовку значения LDID, путем установки переменной окружения. Первый способ затратен (нужно выяснить кодировку каждого shape-файла и прописать ее в заголовке DBF), но в то же время является наиболее правильным. Второй — костыль в чистом виде, ведь при таком подходе нормально будут читаться файлы только в одной, переопределенной, кодировке. Все остальные по-прежнему будут отображаться загогулинками, что при использовании данных в разных кодировках неприемлемо.