| ! | Данная информация предназначена только только для IT-специалистов по системной интеграции модулей БИОСОФТ-М. (см. Руководства пользователя к программным продуктам) |
class unicode
{
public:
// ASCII/RU --> UTF-8
static sbuf GConvertWin1251ToUtf8(
sbuf sbuf1251);
// UTF-8 --> ASCII/RU
static sbuf GConvertUtf8ToWin1251(
sbuf sbufUtf8);
//VL: 2014-07-19 -U3
// UTF-16 --> UTF-8
static sbuf GConvertUtf16ToUtf8(
sbuf sbufUtf16);
// UTF-8 --> UTF-16 (*** Always adds 2 zero bytes for termination ***)
static sbuf GConvertUtf8ToUtf16PlusZeroWord(
sbuf sbufUtf8);
//VL.| ! | Запрещено оперировать устаревшим 16 битным UNICODE (UCS-2, UTF-16) кроме конверсии из/в него когда это неизбежно в коммуникации с легаси внешним миром |
UNICODE/widechar не имеет никаких преимуществ над UTF-8 кроме создания бесчисленных проблем с отклонением от нормального размера char и нулями в str. Его использование в ОС и всяких языках была ошибка, с которой нужно иметь коммуникацию но которую нельзя повторять в нашем коде.
Вся внутренняя обработка текста должна быть ориентирована на 8 битные ASCII или UTF-8. Как весь Web. Хотя конвертеры UTF-16 в/из sbuf реализованы, представить такой юникод в str корректно нельзя из за требования терминации двумя нулями. Нужно всегда добавлять дополнительные Char(0) во избежание очень не очевидных и не всегда сразу проявляющихся коррупций. Не возможно и не целесообразно сделать полноценно эквивалентные str методы обработки текста представленного в char!=8bit. То же касается и извращений типа UTF-32.
| ! | 99.9% парсеров работают в рамках ASCII символов и им безразлична кодировка всего что за пределами 128 первых символов |
Английский язык главный и практически исключительный во всех управляющих ключевых словах. Кроме английских букв для парсеров осмыслены только знаки препинания того же ASCII диапазона. Поэтому практически 100% кода глубоко безразлично как вторичные языки закодированы в str - UTF-8, Win-1251, KOI8R или какие угодно крякозябы. Поэтому весь существующий С/С++ код спокойно работает с 8 битными char не зависимо от кодировок. Вплоть пока не понадобилось буквицы на экране рисовать или EditBox реализовывать. Но это системные задачи специализированных библиотек. Приложением же все равно в каком байте русская буква начинается и где заканчивается.
Приятная особенность UTF-8 что не смотря на переменную длину логического символа сортировка происходит правильно даже если сравнивающий строки код работает побитно/ASCII.
Но эту ситуацию сразу убивает UTF-16, писать парсеры в котором очень глупо, как вообще применять любые кодировки корежащие чисто английскую часть текста.
Эта категория в данный момент пуста.