> > Ну так вот. Переходим к сути моего, так сказать, спича - тип CHAR в > > плане приема-передачи UTF8 данных - отстой полный. > > Позвольте мне вам не позволить. В чем проблема с UTF-8 в CHAR? > Максимальный размер строки (которая, к тому же ограничена нулем) в > байтах тебе известен. Подсчет количества символов делается в один > проход.
Смотри. Мы подключаемся к базе win1251 с использованием UNICODE_FSS. Соответственно все наши буферы будут увеличины в трое. При загрузке данных - все нормально. Сервер видит, что буфер достаточного размера и туда все запихивает. Что там на клиенте - это уже наши проблемы. Обратная передача. Пишем в тройной CHAR-буфер однобайтные символы. Ровно N сиволов. Чем хвост (2*N байт) будем забивать? Для текстовых CHAR-ов забиваем пробелами. Для OCTETS-CHAR-ов забиваем нулями. С обычными колонками не эксперементировал, а вот с CHAR-массивами при записи такая фигня: сервер пытается отконвертировать все 3*N байт (UNIСODE_FSS) в N-байт (win1251). Получаем анус с переполнением. А почему? Потому что как ему сказать, что в этом огромном (3*N) буфере у нас только N байт c данными? Никак - и это у CHAR-ов на конструктивном уровне. > Ну с уникодом никто легкой жизни не обещал. Да нет там ни каких проблем. С Юникодом. Вот с NONE - это оказывается реальная засада. > З.Ы. А в плане того, что оно криво передается в массиве - раз это > обнаружили только сейчас, то наверняка НИКТО это не использовал. Был > такой фараон - Ибо Нех. Наверняка птицеводы думают - оставить багу как > есть или вообще массивы похерить нах? ;-) Там эту багу поправить и заменить strlen для CSTRING элементов на нечто более надежное - и можно еще на 8 лет забыть :)) Коваленко Дмитрий.
