Проблема с кодировкой DBF при подключении через ADO

← →
avn72 © (2009-07-31 16:13) [0]

Всем доброго всемени суток. Доступ к таблице DBase через ADO. Проблема с
правильным отображением русских букв таблицы (открыватся-то открывается,
но "буковки нерусские")
Строка подключения:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Work\Work-TD\;Extended
Properties=DBASE III;Persist Security Info=False;
Если в dbf-файле кодовую страницу ппроставлять принудительно, то все нормально срабатывает. НО!!! DBF может быть с нулевым
29-ым байтом и с CP866 и c CP1251! А открывать их в режиме чтения только можно, для различных выборок (сами понимаете, что байтик)
Кроме Jet.OLEDB.4.0 пробовал еще VFPOLEDB.1 У этого провайдера и явный параметр есть на code page, но при нулевом байте не работает даже явное казание CP
Как решить проблему? Или этот косяк никак не обойти?

← →
Anatoly Podgoretsky © (2009-07-31 16:22) [1]

DBASE III в принципе не поддерживает языка таблиц. У него только один язык MACHINE

← →
sniknik © (2009-07-31 19:08) [2]

у jet-а (вернее у его dBase исама) есть настройка в реестре как он будет открывать таблицы. в дос или вин кодировке. байтик в таблице в принципе влиять не должен... тем более в 3 дибесе его вообще быть не должно (как и такой таблицы с виндовой кодировкой... они устарели задолго до появления виндовс.).

← →
avn72 © (2009-07-31 21:07) [3]

> DBASE III в принципе не поддерживает языка таблиц. У него
> только один язык MACHINE

И что это значит??? Для особо одаренных пожалуйста!

> у jet-а (вернее у его dBase исама) есть настройка в реестре
> как он будет открывать таблицы. в дос или вин кодировке.
> байтик в таблице в принципе влиять не должен.

Но влияет именно байтик CP!
Смотрим ISAM здесь:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\ISAM Formats\dBase III
Ничего про CP, только есть Engine
Смотрим Engine:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Xbase
Вроде должно быть нормально, по умолчанию, в ключе DataCodePage=OEM! (кстати пробовал и ANSI, как кто-то советовал, но результат нулевой) НО-Но-НО!!! Правильное отображение только и только тогда, когда проставлен байтик в таблице! Вот в чем и дело-то! А именно его я менять не могу т.к. базы shared! А если 0-ой байт CP то перкодируется вообще непонятно как. И символы в гриде всякие-есть (есть и до 127 кода), хотя я специально сделал табличку, из одного поля, в которой только русский алфавит. То есть я вообще не понимаю, как перекодируется, ведь если CP866<->CP1251, то коды символов должны быть > 127 (Dec) ???
Где собака порылась?

← →
sniknik © (2009-07-31 21:21) [4]

> И что это значит??? Для особо одаренных пожалуйста!
нету в DBASE III байтика... вообще указания кодовой страницы нет, т.к. когда разрабатывался был только дос без винды.

раз у тебя есть то это НЕ дибейс три. и работать с ним скорее всего нужно по другим правилам. кстати о работе исамов, jet может работать через установленный BDE (там у тебя какие настройки?), а может через "встроенную" (и ограниченную в чем то) версию BDE.

← →
avn72 © (2009-08-03 09:08) [5]

> нету в DBASE III байтика... вообще указания кодовой страницы
> нет, т.к. когда разрабатывался был только дос без винды.

Это понятно, но другие проги, которые цепляются к этой базе, проставляют. И отследить трудно.

Поэкспереремнтировал на чистой машине и с на машине с установленной BDE. Тоже по разному ведут себя таблички с проставленной CP, и без него.
Причем правильно в обоих случаях (для DOS таблицы) только с проставленной CP

Вобщем, как бы не хотелось, а придется сначала проверять байтик! И ставить его!
Спасибо всем! Тему можно закрывать!

← →
sniknik © (2009-08-03 09:20) [6]

блин, да даже если то что пишешь правда (когда то проверял, когда работал, и что помню расходится с твоими словами - никакой разницы у движка у которого жестко проставлено в какой кодировке открывать. если не вмешивается другая настройка конечно... а они так цепочкой друг друга используют, запутаться легко ),
ладно пусть что то с тех пор изменилось, и счас не так, но что мешает найти какой нибудь старый встраиваемый в программу движок, который попросту не знает об этом байте?

← →
Anatoly Podgoretsky © (2009-08-03 10:28) [7]

> avn72 (03.08.2009 09:08:05) [5]

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

А может быть ты лапшу нам насчет DBASE III вешает, может не DBASE III они ждут а другое.

← →
sniknik © (2009-08-03 11:22) [8]

вообще легко проверить, выложи 2 файла, один с "правильным" байтом другой с неправильным, открою сам и посмотрю. только вечером, счас работы много.

← →
Anatoly Podgoretsky © (2009-08-03 12:07) [9]

> sniknik (03.08.2009 11:22:08) [8]

Можно не тратить время, dBase III по определению не поддерживает это поле, по спецификации. Поддержка языка таблицы, а это именно это поле, появилась начиная с dBase for Windows, кроме того для русского только 866 кодовая таблица.

← →
sniknik © (2009-08-03 15:21) [10]

Anatoly Podgoretsky © (03.08.09 12:07) [9]
я это знаю, но как предполагал ранее у него скорее всего не dbase III, и даже в этом случае при указании движку (jet) кодировки он не обращает внимание на байт в файле, ну, насколько помню, вот с парадоксом было обратное.

← →
Anatoly Podgoretsky © (2009-08-03 16:35) [11]

> sniknik (03.08.2009 15:21:10) [10]

Поскольку jet работает с dBase III - dBase IV поэтому кодировка не актуально, в отличии от Борланда они не стали делать извращения, а отнеслись более лояльно к формату, единственно, что они позволили себе так это перекодировку OEM/ANSI

← →
avn72 © (2009-08-18 08:20) [12]

Не думал, что тема продолжилась!

> вообще легко проверить, выложи 2 файла, один с "правильным"
> байтом другой с неправильным, открою сам и посмотрю. только
> вечером, счас работы много.

Если найдешь время проверить, могу выслать и базки и програмульку и исходник, потому что результаты мои что-то уж сильно расходятся с вашими, хотя тестил на двух машинках - w2k3 c BDE и на девственно чистой w2k

← →
sniknik © (2009-08-18 09:18) [13]

> Если найдешь время проверить
только вечером. и не надо лишнего, исходников и всей базы, просто 2 файла "правильный" и "неправильный", с указанием кто из них кто.

> w2k3 c BDE и на девственно чистой w2k
сразу можно сказать результат может быть разный, при использовании jet-ом установленного BDE одни настройки (использование его ты наверняка не отключал) , без установки другие.

← →
avn72 © (2009-08-18 10:08) [14]

> сразу можно сказать результат может быть разный, при использовании
> jet-ом

Так в том то и дело! О чем я и говорил. Результаты разные! Поэтому я и решил байт проверять, потому что проверять на разных машинах настройки Jet и BDE и менять их - это нехорошо. Я решил в данном случае как можно меньше править реестр, неизвестно, как себя поведут другие сторонние проги, которые могут пользоваться этими-же настройками. И гемора у меня будет намного больше.

Так что спасибо! Не стоит проверять.

О каком байте может идти речь, при

> Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Work\Work-TD\;Extended
> Properties=DBASE III;Persist Security Info=False;

Оно в принципе не поддержано, язык таблицы впервые появился в версии dBase for Windows. До этого никаких языков не было, только MACHINE, при этом под этим исключительно понимается OEM, для JET сделано извращение для покрытия извращений других проеkтировщиков - это переключение OEM/ANSI хотя ANSI в принципе быть не может, DBASE III это для ДОС

Дальнейшее извращение это двойная поддержка БДЕ - родного БДЕ и из JET, по JET я уже указал, но когда стоит большой БДЕ, то используются его языковые драйвера, но все равно для DBASE нет ANSI драйверов в принципе.

Третье извращение - это dBase VII тебя правда не касается, то там еще появилась поддрежка шрифтов, языки реализуются через шрифт :-)

> пробовал еще VFPOLEDB.1

Это бы решило проблему, только нет совместимости с dBase по индексам и мемо полям.

И все это не включает извращение над байтом язык таблицы, когда он установлен для тех форматов, где его быть не должно и непредсказуемое поведение большого БДЕ

И резюма, для JET, как правило, достаточно поиграться с параметром OEM/ANSI.

> потому что проверять на разных машинах настройки Jet и BDE
> и менять их - это нехорошо.

Это очень нехорошо, но слава богу, что их можно задать локально в строке подключения, название параметра не помню.

Оказывается, что неправильная кодировка при нулевом байте возникает при стандартных установках BDE (т.е. LangDriver="ascii" ANSI)

> но слава богу, что их можно задать локально в строке подключения,
> название параметра не помню.

Уже все глаза проглядел на:
http://msdn.microsoft.com/en-us/library/aa140022(office.10).aspx#adoproperties_extendedsettings

Не нашел!

← →
kish (2010-05-19 11:49) [19]

> Оказывается, что неправильная кодировка при нулевом байте
> возникает при стандартных установках BDE (т.е. LangDriver="ascii"
> ANSI)

Все что нужно, это добавить в реестр в ветку
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\xBase]
значение BDE типа DWord со значением 2.
Причем это не повлияет на работу остальных приложений.
Вот пруфлинк: http://support.microsoft.com/kb/307455/EN-US/

Автор давно уже умер, а ты только проснулся.

Проблема с кодировкой DBF при подключении через ADO Найти похожие ветки