PDA

Просмотр полной версии : Багрепорт по OWEN-библиотеке ASCII_TO_UNICOD(3.5.3.40).compiled-library-ge33



porada
17.07.2017, 16:27
1. Символ 0x8D кодируется на выходе нулем вместо 0x040C
(Пруф из файла ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT:
..
0x8D 0x040C #CYRILLIC CAPITAL LETTER KJE
.. )

2. Перекодируется максимум 81 символ, но об этом нигде не упоминается. (Даже не 80, что как-то объяснялось бы длиной типов STRING и WSTRING по умолчанию). Если в функцию передать ссылку на WSTRING(10) то оставшиеся 142 байта затрут чего-нибудь в области данных с непредсказуемыми последствиями. Или даже если на WSTRING, то ноль в конце уже не поместится и что-то затрет.
А лучше переделать вызов на явное указание длины:
ASCII_TO_UNICOD2(p_STR_IN:=ADR(strAscii) , p_STR_OUT:=ADR(wstrUnicode), size:=SIZEOF(wstrUnicode));

3. Функция всегда возвращает FALSE. Это можно считать feature. Но лучше бы возвращать что-то полезное, например ошибку если входная строка длиннее выходного буфера, или просто длину выходной строки.

4. Символ 0x98 не определен в кодовой странице CP-1251 и сейчас кодируется нулем, что принудительно завершает строку, хотя последующие за ним символы все равно заносятся в выходную строку. Традиционно в Unicode для таких случаев используется:
U+FFFD � replacement character

Евгений Кислов
17.07.2017, 17:46
Добрый день. Актуальным средством конвертации кодировок сейчас является библиотека OwenStringUtils:
http://www.owen.ru/forum/showthread.php?t=25981

Мы протестируем на ней ваши замечания, и если они повторятся - внесем исправления.

Евгений Кислов
18.07.2017, 13:54
Проверил - п. 1 и 2 в OwenStringUtils не воспроизводятся.
П. 4 - 0x98 конвертируется в Unicode как 0x0098 ("˜"). Постараемся исправить в следующей версии.

Осинский Алексей
04.08.2017, 17:03
Проверил - п. 1 и 2 в OwenStringUtils не воспроизводятся.
П. 4 - 0x98 конвертируется в Unicode как 0x0098 ("˜"). Постараемся исправить в следующей версии.

Устранено в версии 3.5.4.2 OwenStringUtils