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

КАК ИМПОРТИРОВАТЬ ТАБЛИЦУ EXCEL ЧЕРЕЗ DBF

Казалось бы, в чем проблема?

Excel понимает формат DBF, должен, во всяком случае. С другой стороны, DBF - это родной формат ArcView, именно в нем хранится атрибутика для шейп-файла. Создавай себе файл в Эксель и передавай в ArcView... Однако на этой "дорожке" масса ям и канав, да таких, что даже опытные пользователи порой спотыкаются. Отчего так просходит и что делать? Создаем таблицу, например, с номерами точек, названиями, координатами.

Да, Эксель способен записать данные сразу в DBF, но... загрузив таблицу в ArcView, вы сразу столкнетесь с тем, что в ней:

1. Утеряны знаки у чисел "после запятой";
2. Перепутаны типы данных в колонках;
3. Искажена кодировка русских букв и т.п.

Повозившись немного, вы поймете, что виноват в этом не ArcView, а именно Эксель. Почему так происходит и как же быть? Первые две проблемы связаны с тем, что Эксель - простой табличный процессор, а не система баз данных, вот он и не умеет заботиться о типах данных. А DBF - это не простая таблица, это файл именно базы данных, и в нем есть строгая структура - она зафиксирована в заголовке DBF. Для баз данных в составе MS Office предназначен Access, и он-то правильно пишет DBF, принимает его почти как родной формат, работать с DBF там "правильнее". Проблемы 1 и 2 там практически отсутствуют. Но многие, тем не менее, любят вычисления в табличном, привольном стиле! Дорожка в Эксель нужна! Как же ее протоптать?

Типы данных

Разберемся сначала с типами данных. Эксель определяет типы данных для каждой колонки по верхним строкам, поэтому, составляя таблицу, делайте так:

- Верхнюю строку отведите под заголовки колонок, как показано на первом рисунке. Лучше если названия будут без пробелов, латинские и не более 10 символов - это требования формата DBF.

- Проверьте, правильно ли написаны ваши данные, особенно в верхних строчках. Если числа имеют неверный десятичный знак-разделитель, или букву "О" вместо нулей, Эксель объявит их текстом, и колонки в DBF приобретут текстовый тип со всеми вытекающими последствиями.

- Если в верхних строчках в некоторых колонках нет данных, или они не показательны для колонок (например, колонка текстовая, а в верхних строчках попались, как назло, одни цифры), то отведите вторую строку специально под образчики значений: так спокон веку хитрили опытные DBF-щики. Эту строку потом ведь несложно будет удалить из DBF, ну, уже в ArcView.

- В последних версиях Экселя этот прием перестал работать, видимо, анализ данных стал более изощренным. Мало того, уже при вводе Эксель, бывает, придает данным свой формат, меняя текст на даты, числа на деньги и т.п., причем по своему усмотрению. В связи с этим рекомендуем явно задавать типы данных. Для этого поочередно обводите колонки мышкой, и меняйте формат клеток с "общего" на более конкретный. Для чисел подойдет "Фиксированный" с нужным количеством десятичных знаков.

Кодовые страницы

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

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

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

Как же быть? Ответ очевиден: нужно восстанавливать указание кодовой страницы сразу после выхода из Эксель. Тут поможет простейшая програмка CPDBF. К программе есть подробная инструкция, для "чайников" в том числе, но и без этого диалог с ней очевиден. Ошибиться сложно - поскольку, как мы уже знаем, Эксель пишет текст в досовской кодировке, именно этот вариант предлагается программой по умолчанию. После этого в ArcView данные, как по волшебству, начинают читаться как надо. Для того, чтобы создать файл с координатами в Эксель, и передать его потом в ArcView это и нужно. Программа обрабатывает файлы любого размера в считанные секунды, так как не перекодирует все данные в таблице, а всего-навсего меняет в заголовке один-единственный байт.

Тем же, кому и этого мало, советуем продвинуться дальше в освоении возможностей ArcView и MS Office. Многочисленные хитрости кодовых страниц изложены в разделе "Продвинутым".

Как решить проблемы файла Excel с типами данных и кодировками через SQL-соединение, рассказано здесь.

ArcMap

Как обстоят дела в ArcMap? А точно так же. Таблицы DBF не читаются без усилий, и все вышеописанные рекомендации актуальны. Точно так же исправление кодовой страницы производит привычно-волшебный эффект:

Однако ArcMap умеет подгружать напрямую таблицы Access, и рекомендуем не увлекаться форматом DBF.

Успешного импорта!

Lalex.