VFoxPro и кириллица

Добрый вечер ув.форумчанам!
Не может ли кто-нибудь из знатоков подсказать, как подружить VFoxPro v.7 с кириллицей?
Дело с том, что последний раз я работал с кириллицей в базах данных в FoxPro и MS-DOS 6.22 лет 15 назад. И так получилось, что до последнего времени ни с тем, ни с другим работать не приходилось. А вот теперь нуна попробовать обрабатывать данные в кириллице на вышеупомянутом VFoxPro.
Исходные данные:
- место действия - Германия, WinXP, Office и VFP соот-но локализованы;
- есть возможность установки русской раскладки и шрифтов;
- данные поступают в текстовом виде UTF-16;
- их нужно так импортировать в DBF, так чтобы не крокозябы на экране отображались, а исходный текст;
- затем проделывать элементарные манипуляции в интерктиве: сортировка, удаление мусора, корректировка ручками или отдельными командами;
- в заключение - выводить в текст UTF-16

Я совершенно не в курсе, как и на чем работают сейчас в России при обработке текстов на кириллице, поэтому буду очень признателен, если кто-нибудь поделится своим опытом, мыслями по поводу или просто покажет пальцем в Инете, куда смотреть...

если есть office может через access сделать проще? а есиче потом можно и в фокспро экспортировать то что получилось.

Я не совсем понял, что тут первично, а что вторично и от чего можно отказаться, а от чего нет. Например, можно ли отказаться от DBF и Visual FoxPro 7? Ведь, вроде бы, написано, что изначально данные откуда-то поступают в виде текста! Тогда зачем их далее загонять обязательно в DBF? Это потому, что уже есть какая-то программа, которая берёт текст и загоняет его обязательно в DBF? Я просто не уверен, что VFP7 сможет загрузить (и правильно отобразить!) кириллицу в UTF-16. Скорее всего, придётся эти данные перед загрузкой чем-то конвертировать в кодировку "windows-1251".

Если же программы пока никакой нет, то, может быть, сразу выбрать приложение, которое дружит с юникодом? Например, как вот и Kuznets пишет выше, Microsoft Access 2007. И начинать писать всё под ним?

Я тоже не знаю, может ли лиса работать с UTF16, но все большие СУБД имеют специальное тип полей для прямой работы с ним — тот же Оракл использует nchar и nvarchar. Если есть такая возможность, то делать по преобразованию инфы перед тем как её ложить, или как её доставать, не надо. Винда корректно работает с UTF-16 до до UNICODE версии 3, если я не ошибаюсь. 2003 должен поддерживать и более позднии версии UNICODE. Про версии UNICODE можно посмотреть здесь — Unicode Consortium — текущая 5, а работают над 5.1, вроде.

Спасибо всем ответившим, и извиняюсь за задержку с ответом - могу отвечать только из дома поздно вечером.
Дело в том, что я уже пару лет работаю в небольшой фирмочке, специализирующейся на обработке почтовых адресов в интересах заказчиков - издательств, рекламных агентств и фирм, продающих товары по почте. Как правило, заказчик предоставляет нам адреса своих клиентов/абонентов, а также купленные или взятые в аренду у др.фирм. Мы конвертируем адреса из TXT или XLS в DBF, выполняем визуальный контроль и предварительную обработку в интерактивном режиме в VFoxPro - удаляем "мусор", меняем структуру данных на б/м удобоваримую, при необх. селектируем по опр.критериям (пол, индекс, регион), корректируем опечатки/ошибки etc. А дальше различные списки адресов в DBF-формате запускаются в спец.программу, которая их фонетически кодирует и на основе нечеткой логики находит и выкидывает дубли адресов. Т.о. можно вычистить свои базы данных от неплательщиков, от "робинзонов" (не желающих получать рекламу), выделить из покупных/арендованых адресов только те, которых в собственной базе не имеешь, ну и т.д. Clean-адреса и дубли снова интерактивно контролируются в VFP, при необходимости повторяется с др.настройками. Дальше они либо уходят к заказчику, либо проходят дальнейшую обработку - выявляются переехавшие и умершие, оптимизируются для почтовой логистики и идут в типографию для печати/рассылки каталогов и/или рекламы.
Все работает беспроблемно, пока CP=1252 или 850. А тут один наш постоянный заказчик, видимо имеющий хорошую почву в России (или пытающийся создать таковую), запросил у нас, сможем ли мы провести подобную сверку адресов на кириллице, и прислал для пробы пару сотен адр. на UTF-8 (оказывается).
Программа сверки кириллицу не переваривает в принципе, есть мысля сделать транслитерацию РУС-->ЛАТ и попробовать. Имеются слухи :-), что VFP v.9 безпроблемно работает если не с UTF, то хотя бы с CP-1251. Так шта будем думать. Должны быть уже готовые конверторы UTF<->1251 (EditPad), 1251<->LAT (RusFon и т.п.), накрайняк сами напишем кодировшик.
15 лет назад я беспроблемно работал с FoxPro в России. Тогда это была одна из наиболее массовых DB-программ. Я просто уверен, что и сейчас сотни тысяч пользователей и программеров в России по-прежнему пользуют его последние (и не очень) версии. Должны быть и программы для сверок адресов, ну не верю я, что нету такого в России...

С UNICODE программкам с fuzzy logic будет работать значительно труднее.

Насколько я помню - в фокспро при создании таблицы можно указать кодовую страницу
ну и - http://www.west-wind.com/presentations/foxunicode/foxunicode.asp

Спасибо,очень полезная ссылка. Будем изучать.
Mishka> С UNICODE программкам с fuzzy logic будет работать значительно труднее.
В том то и дело, что программа сверки покупная, разработик не видит смысла добавлять UTF или CYR (или не может/не хочет возится с чужой фонетикой), и единственно, что можно попробовать, прежде чем бросить - это сл.цепочка:
UTF -> 1251 -> контроль/зачистка в VFP -> LAT -> сверка адресов -> LAT -> 1251 -> контроль/обработка в VFP -> UTF

Наверно проще хранить исходный вариант параллельно с преобразованным
|
V
UTF -> 1251 -> контроль/зачистка в VFP
|
V
UTF -> LAT -> сверка адресов
|
V
UTF -> 1251 -> контроль/обработка в VFP
|
V

На письмо.рф былинный отказ. Страница, заточенная на кириллицу, даже пароль требуют кириллический. А вот капча — латинская :D А, да, забил по приколу балансер@письмо.рф :)

// Транслировано с juick.com