НА ГЛАВНУЮ СТРАНИЦУ

КОДОВЫЕ СТРАНИЦЫ В ARCVIEW И ARCMAP

Как известно, из Excel в ArcView не так просто передать данные, тем более с русскими буквами. Записав данные в DBF с помощью Эксель, вы получите вот что:

1) утеряны знаки у чисел после запятой;

2) возможно, перепутаны типы данных в колонках;

3) искажена кодировка русских букв.

Первые две проблемы связаны с тем, что Эксель - простой табличный процессор, соответственно он и не умеет поддерживать структуру базы данных DBF. Для БД есть Access, и он-то понимает DBF как родной формат, работать там "правильнее": проблемы 1 и 2 практически отсутствуют. Однако многие любят вычисления в табличном, привольном стиле! Тогда следите за типами данных сами: первую строку отведите под заголовки колонок. Проверьте, правильно ли написаны ваши данные в верхних строчках. Если в некоторых колонках пробелы, задайте второй строкой образчики значений: так спокон веку хитрили опытные DBF-щики. В последних версиях этот прием перестал работать, мало того, уже при вводе Эксель меняет данным формат по своему усмотрению. В связи с этим рекомендуем явно задавать типы данных через формат клеток. Эта проблема известна, и прямого отношения к ГИС она не имеет. Очень подробно это разбирается здесь, и там же можно найти описание структуры DBF-файла.

Вопрос с русскими буквами сложнее: они "слетают" из-за того, что Эксель упрямо пишет DBF в старинной Dos-кодировке (ASCII). Он считает формат DBF очень древним, чисто Досовским наследием. Они там в Микрософт, похоже, не представляют, насколько DBF разошелся по свету. ArcView же по умолчанию считает DBF виндовсовским форматом, и читает его как будто он в Windows-кодировке (ANSI). Так и стоят эти два бычка, упершись лбами. Эту проблему не решает даже и Access - он ведь тоже детище Билла Гейтса, и те же упрямые мысли заложены и в этой офисной башке :) Как же быть? Знатоки часто советуют не перевоспитыть бычков, а... обойти проблему "огородами": подгрузить таблицу через текстовой файл "с разделителями". Файл, разумеется, должен иметь регулярную структуру, но это как раз Эксель умеет обеспечить. При загрузке ArcView читает такой текст правильно. Детали такого обходного маневра описаны на ГИС-лаб.

Таким образом мы обходим бычков стороной, и... последствия тут же дают себя знать - снова начинаются проблемы с типами данных. Разделители путаются с текстом, с десятичными знаками. К тому же обидно, что стройный DBF (почти база данных!!!) вдруг надо "унижать" до примитивного текста. Это еще и лишний шаг, лишний файл... Между тем избежать этого довольно просто: в ArcView имеется встроенный механизм поддержки кодовых страниц. Однако по умолчанию он выключен, и чтобы включить его, нужно иметь опыт по части настройки программ (об этом ниже). Вместе с тем мало кто в курсе, но ArcView умеет правильно читать любые DBF-файлы и без специальных настроек! Это тем более странно, так как изложено в Help... Потому-то полная поддержка разнообразных кодовых страниц и скрыта от пользователей - в общем случае она не нужна! Хотите убедиться в этом - вот DBF-файл с русским текстом, который ОДИНАКОВО читается в любых Эксель и ArcView!

Секрет кроется в заголовке DBF. В нем спокон веку есть место для указания кодовой страницы, так называемый "29-й байт". ArcView "знает" об этом, и, если DBF-файл "правильный", если кодировка обозначена верно этим самым байтом, то ArcView читает русские буквы как следует. Разработчики Microsoft об этом напрочь забыли, и в Эксель эти лишние кодовые подробности не вошли. Мало того, Эксель обнуляет 29-й байт каждый раз, как только до него доберется. Значит, нужно восстанавливать информацию о кодовой странице после сохранения DBF в Эксель. В этом поможет простейшая програмка CPDBF.

К программе есть подробная инструкция, но и без этого диалог с ней очевиден. Указываете в качестве параметра файл DBF, новую кодовую страницу (RusDos 38), после этого данные как по волшебству, начинают читаться правильно. Програмка обрабатывает файлы любого размера в считанные секунды, так как не перекодирует все данные в таблице, а всего-навсего меняет в заголовке один-единственный байт. При необходимости взглянуть на 29-й байт, впрочем, пользователь может воспользоваться также любым универсальным просмотровщиком: (Far, Total Commander etc). Эти же просмотровщики позволят и определить кодировку содержимого DBF: данные в DBF пишутся открытым текстом, и его легко понять любым невооруженным глазом. Имея желание редактировать 29-й байт вручную, пользователь также может воспользоваться любым универсальным редактором файлов (MultiEdit, EditPad Pro etc.) с бинарными функциями.

Тех же, кто любит MS офис больше ГИС-жизни, и привык уже при каждом удобном случае "гонять" данные туда и обратно, можно лишь пожалеть: Эксель, в добавление к вышеописанным странностям, еще и откровенно глючит при повторной работе с DBF: единожды созданный (даже в нем самом!) DBF он способен в дальнейшем только редактировать, а добавлять ему колонки и даже строки он НЕ МОЖЕТ! Знатоки, наверно, догадаются зачем, и что это не "баг", а "фича", но простым людям-то от этого не легче! Выглядит это уж точно как глюк, когда с трудом напечатанные колонки и строки исчезают :)

Любителям MS офиса можно посоветовать другую разумную дорожку - с использованием Access. Прикрепите DBF к базе данных (link), и редактируйте его. Access тоже отказывается редактировать структуру DBF-таблицы, но, по крайней мере, делает это честно. Зато он может добавлять строки, притом следит за соблюдением типов данных в колонках. Сохраняя данные, он не портит заголовок DBF, и кодовый байт остается на месте. Таким образом, вы можете сыграть в забавную игру - открыть DBF в ArcView и одновременно в Access. Вы увидите, что измененные значения самостоятельно переезжают и в другую программу, они умеют синхронизироваться! К сожалению, игра эта опасная - известны случаи порчи таблиц. Если это случайно произошло в ArcView, не отчаивайтесь - попробуйте "освежить" вид таблицы командой "Refresh", как правило, это помогает. Но лучше, конечно, выключайте ArcView на момент работы с Access и наоборот. От Access, кстати, недалеко и до Excel... Знатоки технологий Microsoft тут же сообразят, как наладить бесперебойную передачу данных по ODBC.

Тем же, кому и этого мало, придется влезть в настройки ArcView, и не полениться прочесть все-таки Help, все разделы касающиеся "Code Page". Механизм Arcview работает чуть ли не с любыми кодовыми страницами, нужно только его умело активировать. Если коротко, то есть вожможность назначить кодовую страницу не отдельному файлу, а любому каталогу: например, пусть "D:\MAPS\866" будет досовским. Тогда шейп-файлы из этого аталога ВСЕГДА будут читаться как RusDos (CP 866), и, мало того, туда они будут сохраняться тоже в той же кодировке. Таким образом, вы получаете вожможность не только работать с любыми кодовыми страницами, но и использовать ArcView как перекодировщик содержимого DBF-файлов! На русском языке этот подход грамотно изложил Е. Стороженко. Это, кстати, уже позволяет с блеском решить и задачу работы одновременно в Эксель и ArcView, минуя промежуточные стадии. Не лишне будет знать кое-что, не упомянутое в документации - этот механизм влияет не только на шейп-файлы. Попробуйте сохранить в каталог проект apr, и вы в этом убедитесь. Он тоже приобретет непривычную кодировку. Иными словами, любые объекты, которые порождены ArcView, могут использовать этот механизм. ArcINFO тоже его поддерживает - таким способом можно "лечить" кодировку и "юниксовых" покрытий тоже.

Как обстоят дела в ArcMap? А точно так же. Точно так же не читается, и точно так же подправка кодового байта волшебным образом снимает проблему.

Также как ArcView, ArcMap можно настроить на определенные кодовые страницы DBF по умолчанию, об этом можно почитать на ESRI support. Однако ArcMap выучилась читать Access напрямую, поэтому рекомендуем увлекаться DBF только в случае приступов острой ностальгии по старым, добрым дос-временам :)

Автор: Geologic