1. из 1с формируются dbf-файлы, в названии полей "u" меняется на "M" (?!?). то есть в коде написано: Т=СоздатьОбъект("XBase"); Т.ДобавитьПоле("Summa","N",10,2); Т.СоздатьФайл(ИмяКаталога+"DT_Rash"); создается файл с полем "SMMMA" (в dbf названия полей хранятся заглавными буквами). если переписать код на Т=СоздатьОбъект("XBase"); Т.ДобавитьПоле("SUmma","N",10,2); Т.СоздатьФайл(ИмяКаталога+"DT_Rash"); всё отрабатывает нормально.
Принимаю багу, прошёлся трейсами по 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, который должен решать эту проблему корректно. Хак отложил.
