| Summary: | 1Cv77: Ошибка при формировании полей dbf-файлов | ||
|---|---|---|---|
| Product: | WINE@Etersoft | Reporter: | Vitaly Lipatov <lav> |
| Component: | Общее | Assignee: | Анатолий Лютин <vostok> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P5 | CC: | aae, baraka, edo.rus, vostok |
| Version: | 1.0.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | |||
| Bug Depends on: | |||
| Bug Blocks: | 42, 584, 760 | ||
Принимаю багу, прошёлся трейсами по all, пробовал класть 1с по вызову строчки "uuuuuuuuuu", ничего интересного трайсы не дают. Ставили mfc42.dll из поставки 1с - то же самое. В Вин всё нормально. Проблема только с маленькой буквой u, даже русские символы и то записываются правильно... Не всё так просто. *** Bug 863 has been marked as a duplicate of this bug. *** При указании кодировки windows - ДБФ.КодоваяСтраница(0) все ок, проблема возникает с кодировкой по умолчанию dos - ДБФ.КодоваяСтраница(1) По-английски функция называется AddField. Элементарный toupper из msvcrt используется для поднятия типа поля к верхнему регистру. Так же возможны MakeUpper из Type32 или Lower2Upper из BkEnd. CharUpperA и CharToOemA, CharToOemBuffA (раз проблема только при использовании Кодовой страницы DOS). Lower2Upper из bkend.dll реализована на основе собственной таблицы, по которой символы просто приводятся к верхнему регистру. Таблица формируется на основе CharUpperA, причём Lower2Upper является часто используемой функцией, и проблем от неё ожидать не приходится. MakeUpper из type32.dll является просто обёрткой для CharUpperA, работающей с принятыми в 1С строками. CharToOemBuffA преобразует букву микрон (0xB5) в u (0x75),
в то время как в Windows получается 0xE7.
Поскольку CharToOemBuffA использует
MultiByteToWideChar( CP_ACP, 0, s, len, bufW, len );
WideCharToMultiByte( CP_OEMCP, 0, bufW, len, d, len, NULL, NULL );
нужно серьёзно разобраться, правильно ли они работают.
Причём странно, что символы поступают на сравнение так:
B2
A5
B5 (вредная B5)
4D (злосчастная M!) - причём имеет другой выходной буфер, то есть не в этом цикле вызывается.
A8
AA
Как это получается, не ясно...
А, передаются пары - маленькая-большая, т.е.
a
A
b
B
из этой микрон получается
u
следом за которой её вариант микрона - M.
То есть нельзя, чтобы CharToOemBuff создавал буквы, которые уже были.
Временно приложен патч hack/lstr.c.patch
Написал патч lib-fixoem.patch, который должен решать эту проблему корректно. Хак отложил. |
1. из 1с формируются dbf-файлы, в названии полей "u" меняется на "M" (?!?). то есть в коде написано: Т=СоздатьОбъект("XBase"); Т.ДобавитьПоле("Summa","N",10,2); Т.СоздатьФайл(ИмяКаталога+"DT_Rash"); создается файл с полем "SMMMA" (в dbf названия полей хранятся заглавными буквами). если переписать код на Т=СоздатьОбъект("XBase"); Т.ДобавитьПоле("SUmma","N",10,2); Т.СоздатьФайл(ИмяКаталога+"DT_Rash"); всё отрабатывает нормально.