Что за хреновая кодировка?

← →
kaif © (2006-10-26 17:47) [0]

Через Microsoft FoxPro OLE DB Provider обращаюсь к некоторой таблице. Даже не одной. Получаю такую хрень:

Edют№ ъюэёхdтшdютрээр

Если преобразовать к win1251 получаю такую хрень:

Edовь консеdвиdованная

Означает это на самом деле:

Кровь консервированная.
Что делать? Часть русских букв приходит в ASCII-кодах английских букв. Причем данные такие, что не исключено применение английских букв тоже.

Кто-нибудь сталкивался с подобным?

← →
Reindeer Moss Eater © (2006-10-26 17:51) [1]

коi8-r?

там как раз похожая история

← →
Anatoly Podgoretsky © (2006-10-26 17:53) [2]

Обрати внимание, что это одна и таже буква <р>, замененая на английскую букву d
А теперь предистория, давно многие драйвера клавиатуры и многие программы, например NortonCommande не могли работать с русской буквой р, видимо это последствия того и "хитрый" программист так обходил проблему, вместо того чтобы написать, нормальный не кривой драйвер клавиатуры!

← →
Reindeer Moss Eater © (2006-10-26 17:54) [3]

Я бы посмотрел внутрь просто фаром

← →
oldman © (2006-10-26 17:55) [4]

> Через Microsoft FoxPro OLE DB Provider обращаюсь к некоторой
> таблице. Даже не одной. Получаю такую хрень:
>
> Edют№ ъюэёхdтшdютрээр
>

Мдя......

← →
Jeer © (2006-10-26 18:01) [5]

> kaif © (26.10.06 17:47)

Умеешь же ты зашифровать известное:)

← →
kaif © (2006-10-26 18:21) [6]

oldman © (26.10.06 17:55) [4]
Мдя......
Jeer © (26.10.06 18:01) [5]
Умеешь же ты зашифровать известное:)

А можно яснее?
FAR-а под рукой нет.
Обычный Notepad открывает нормально и там все нормально читается.

Я подозреваю, что где-то в заголовке какой-то байт сообщает системе OLE DB неверные сведения о кодировке.
Я и сам разберусь, если никто не поможет. Напишу приложение, которое затрет этот байт, если дело в нем. Еще нужно поискать описание заголовка DBF - я не помню, где этот байт там находится. Возможно он даже не там, а в файле DBC (без присутствия этого файла ADO даже не видит эту таблицу). Это может осложнить мне жизнь. И я убью целый день на какую-то глупость,
с которой, возможно, кто-то уже и сталкивался.

Вот и все.

← →
kaif © (2006-10-26 18:31) [7]

Поставил FAR.
В FAR-е тоже нормально читается.
Кодировка DOS, выражаясь согласно FAR-у.
Проблема возникает в самой системе OLE DB.
Поэтому я ничего не зашифровал, а ясно сообщил поблему.

Мне нужно обеспечить доступ именно через Microsoft FoxPro OLE DB Provider, так как у меня написано уже приложение, перегоняющее данные из нескольких десятков таблиц и отходить от этой технологии ради нескольких странных таблиц я не буду.

← →
ANB © (2006-10-26 18:34) [8]

> kaif © (26.10.06 18:31) [7]

Нужно установить правильный байт кодировки в заголовке DBF файла. По всей видимости таблицу создавали в фоксе/клиппере, а им этот байт по барабану.

← →
Anatoly Podgoretsky © (2006-10-26 18:35) [9]

Не поможет, если внимательно посмотреть на оба текста, то видно что везде таже самая латинская буква d

← →
ANB © (2006-10-26 18:36) [10]

> Anatoly Podgoretsky © (26.10.06 18:35) [9]

Двойная перекодировка еще не такие фокусы выкидывает. :)

← →
ANB © (2006-10-26 18:38) [11]

Вообще то я бы на всякий случай фаром глянул на коды букв. Вполне возможна смесь. Однако зачем бы это провайдеру менять английскую p на английскую же d ?

← →
kaif © (2006-10-26 18:42) [12]

29-й байт имеет значение 0x01, что соотвествует:
"кодовая страница 437 DOS USA"

Видимо нужно поменять на 0x26, что соответствовало бы
"кодовая страница 866 DOS Russian"

Щас попробую.

← →
oldman © (2006-10-26 18:45) [13]

> ANB © (26.10.06 18:34) [8]
> Нужно установить правильный байт кодировки в заголовке DBF
> файла. По всей видимости таблицу создавали в фоксе/клиппере,

Клиппер за такими шутками не замечен, а вот Фокс - тот да... Тот любит!!!

← →
Anatoly Podgoretsky © (2006-10-26 18:46) [14]

> Однако зачем бы это провайдеру менять английскую p на английскую
> же d ?

Не английскую р, а русскую р

← →
Anatoly Podgoretsky © (2006-10-26 18:48) [15]

Я уже написал, что это буква особая, она совпадает с началом escape последовательности для клавиатуры, их там несколько таких, но многие не взлюби именно ее, поскольку она была во всех 101 клавиатурах. Я с ней боролся в свое время, для решения прислось написать свой драйвер на Паскале.

← →
ANB © (2006-10-26 18:54) [16]

> Anatoly Podgoretsky © (26.10.06 18:48) [15]

Я находил решение этой проблемы. Достаточно было скэн-код заменить на 0 и все программы начинали эту букву есть. Видел и кривые реализации, где она менялась на английскую р. Сначала боролся своей пришлепкой, потом поставил нормальный русификатор, где эта проблема была решена.
Впрочем - кайф уже увидел неправильный код языка. Скорее всего исправление поможет.

← →
Anatoly Podgoretsky © (2006-10-26 18:57) [17]

Гораздо полезнее было бы увидеть hex коды символов и язык таблицы

← →
kaif © (2006-10-26 18:57) [18]

Нашел неплохую статейку.
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=624

← →
kaif © (2006-10-26 19:17) [19]

Anatoly Podgoretsky © (26.10.06 18:57) [17]
Гораздо полезнее было бы увидеть hex коды символов и язык таблицы

Вот так записано "Кровь цельная"

CA
F0
EE
E2
FC
20
F6
E5
EB
FC
ED
E0
FF

Выдрал с помощью FileStream (написал утилитку).
Полностью соотвествует таблице символов Windows.

← →
kaif © (2006-10-26 19:30) [20]

Да. Проблема была именно в байте кодировки. OLE DB ориентировался на неверное значение кодировки.
Спасибо всем.

← →
Ketmar © (2006-10-26 19:31) [21]

>[20] kaif(c) 26-Oct-2006, 19:30
>Да. Проблема была именно в байте кодировки. OLE DB
>ориентировался на неверное значение кодировки.
учтём на будущее.

← →
Anatoly Podgoretsky © (2006-10-26 20:56) [22]

> Выдрал с помощью FileStream (написал утилитку).
> Полностью соотвествует таблице символов Windows.

Вот это другое дело, сразу видно, что с файлом порядок, значит это проблема драйвера, который перекодировал.
Ну раз нашел причину, то больше говорить не о чем.
Байт 29 - язык таблицы можно менять или с помощью ФоксПро, или простейшей утилитой, например с помощью FileStream, если бы это было не ФокспПро и не 1251 то мог бы посоветовать Database Desktop

Осталось конечно неясным почему менял на символ d но это и не важно.

← →
Ketmar © (2006-10-26 21:22) [23]

>[22] Anatoly Podgoretsky(c) 26-Oct-2006, 20:56
>Осталось конечно неясным почему менял на символ d
спишем на загадки мерзкософта. %-)

← →
kaif © (2006-10-27 15:02) [24]

В общем, сообщаю результаты своих экспериментов по замене байта №29.
Microsoft OLE DB Provider for Visual FoxPro четко ориентируется на байт №29.

Если кодировка 866 DOS, этот байт должен иметь значение 0x26(38)
Если WIN1251, то 0x57(87)
Если 0 - драйвер игнорирует кодовую страницу и выдает ASCII-коды, как есть.

Замену байта №29 можно сделать так:

F := TFileStream.Create(<имя файла>, fmOpenReadWrite); try F.Seek(29, soBeginning); b := 87; //кодовая страница WIN1251 (или 38, если кодировка DOS 866) F.Write(b, 1); finally F.Free; end;

Тот случай, с которым я столкнулся, в байте №29 содержал число 3.

Забыл:

var
b: byte;
F: TFileStream;

В фоксе сменить кодировку таблицы DBF:
do cpzero with "table.dbf", 866 - сменить на 866-ю.
(меняет именно байт заголовка)

Кодировка (3) изменяла не только русскую р на d, но и многие русские большие буквы на какие-то английские большие.
В частности, русскую К на английскую E.

Таким образом, все, кто сталкивается с перекачкой данных из FoxPro, обращайте внимание на байт №29 заголовка DBF и заменяйте его на правильный, иначе ADO будет выдавать кракозябры и не всегда их возможно однозначно вернуть в исходный вид (не всегда спасет ручное перекодирование с помощью OemToChar(), с помощью которой я до сих пор выкручивался в случае таблиц с кодировкой DOS 866).
Если в байте №29 поставить 0, то можно выкручиваться с помощью "ручной обработки" текста в полях TStringField, но если этот байт равен 1 или 3 или еще чему-то не тому, что там должно быть по уму, то легко можно получить ту картину, что я наблюдал. И тогда будет не ясно, это действительные английские E,d или исходные русские К,р.

Почему меняла, понятно, потому что в DOS437 эти коды должны были бы показываться как E с домиком (Ê) и еще в виде такой интересной литеры (ð), которая похожа на букву d. Если на компьютере поставить поддержку соответствующих языков, то их наверно можно будет увидеть, а так компьютер пытается изобразить эти литеры пользуясь доступными наборами.

Если в байте №29 поставить
0, это машинная кодировка (любая - as is).
1 - 437 US ASCII
3 - Windows ANSI (1252)

Официальная информация для ФокПро, у дБейс свои недокументированые коды. Кроме того дБейс не поддеживает 1251 в принципе, даже самые последнии версии, типа дБейс 2000 или дБейс ВЕБ

866 - $65
1251 - $C9

Окончательные рекомендации по перекачскам из FoxPro.

Сразу заменяете нулем (!!!) байт №29 (точнее, тридцатый, если считать первый байт первым).
Обращаетесь через ADO, предварительно установив Microsoft OLE DB Provider for Visual FoxPro.

Наверняка базу данных писали профи.
Иначе вряд ли бы данные дожили до наших дней в такой форме.
А если ее писали профи, то там будут извраты.
В частности, будут строки, в которые запиханы бинарные данные.
А вот такие данные нужно считывать без перекодировок, нарурально, так сказать. Поэтому и байт №29 нужно поставить в 0. ЕА если в строках закорюки (в случае кодировки 866), то уже потом руками с помощью OemToChar() перекодировать в нужный текст (если это текст) или разбирать побайтно, если это бинарная кодировка чисел с хранением в виде строк.

чтобы считать такую строку и не получить нулевой байт в качестве терминатора строки используйте запросы вида:

select cast(<имя поля> as VarBinary(<размер>)) F1, ...

и затем обращайтесь методом AsString к компоненту поля датасета.
Что-то вроде этого (для двухбайтной записи чисел, например):

var s: string; n: smallint; begin s := ADOQuery1.FieldByName("F1").AsString; n := ord(s[1])*255 + ord(s[2]); end;

И только если вы уверены, что авторы не использовали таких приемов кодирования чисел, дат и т.п., можете попробовать заюзать байт №29 и сообщить системе ADO о необходимости конвертировать символы.

В моем случае мне в конечном итоге прилось от этого отказаться и все перекодировать руками, так как данные содержали как строки DOS, так и бинарные числа, записанные в строки и эти числа разрушались, если позволить ADO применить правильтную кодировку.
Здесь был ожесточенный спор об извратах DBF.
Я не изменил своегно мнения - извраты в сочетании с кодировками DOS делают невозможным стандартное использование кодовых страниц для строк.

пардон:

n := ord(s[1])*256 + ord(s[2]);
хотя можно придумать метод и побыстрее, если надо (поигравшись с типизацией указателя на буфер строки).

Присоединяюсь к Ketmar © (26.10.06 19:31) [21]
Сохраню страничку, на всякий пожарный". И буду следить не появятся ли новые данные.

Что за хреновая кодировка? Найти похожие ветки