Char To Unicode (C function)

[Mfcer__]

Как преобразовать строку типа char в юникодную строку типа wchar_t, причем функцией самого Си.
WinAPI функции WideCharToMultiByte не подходят.

[RXL]

Что понимать под "функцией самого Си"?

Unicode имеет размер 2 байта - в старшем хранится номер страницы, а в младшем код символа из этой страницы.
ASCII коды (32..126) конвертятся добавлением нуля (т.е. страница 0). Управляющие ASCII - не помню. Остальные (для некой кодовой страницы - напр. cp1251) можно конвертить табличным способом: создай таблицу wchar_t tab[128] для символов 128..255 и используй так tab[c&0x7f].

[Mfcer__]

я только что нашкел вот такую функцию mbstowcs
size_t mbstowcs(
   wchar_t *wcstr,
   const char *mbstr,
   size_t count
);
И она вроде работает...  

RXL

Спасибо за ответ, как предложил ты сделать куда интересней, но готовая функция уже есть.

[RXL]

Mfcer__, действительно есть  
Для интересующихся ссылочка:
http://www.linuxdoc.ru/manpages/man3/mbstowcs.3.html

[Mfcer__]

А не подскажет кто-нибудь еще - есть ли функция которая из ANSII кодировке в ANSI кодировку переводит строку и обратно.  Спасибо.

[RXL]

Немножко подробнее, пожалуйста: что есть "ANSI" кодировка?

[Mfcer__]

:arrow: ANSI Char - представляет собой так наызваемые Ansi-символы. Эти символы, которые используются в операционных системах семейства Windows. Каждому символу соответствует число либо иначе говоря код ANSI , что расшифровывается как American National Standard Institute - американский национальный институт стандартизации, в котором разработан этот код.

Всего в таблице 256 символов, которые кодируются числами от 0 до 255.
Перые символы ASCII и ANSI с кодами 0-127 совпадают, а другие символы различны.

[RXL]

Ни когда не слышал о ASCII с кодами 128-255...

Не проще ли отдать все на растерзание библиотечным ф-иям? Не знаю, как это в win, а в *nix используется библиотека iconv (входит в glibc).

[Sashok]

Ни когда не слышал о ASCII с кодами 128-255...

Ну как же, она называется "Extended ASCII". Там еще всякие умляуты, энье, и прочие добавочные буквы латинского алфавита прописаны.

[Джон]

Ага, точно, по умолчанию там-же псевдографика была. А ещё под ДОСом можно было с codepage устанавливать. Если не соврать русская была 866.

Mfcer__, Перевод из ASCII в ANSI и наоборот сводится к табличке соответствия, которая зависит от конкретных условий. Тк ANSI тоже загружаемая.
Например немецкая отличается от русской (ессно речь идёт о символах от 0x80 до 0xFF).

Работать с такой табличкой можно так:

Код:

pszCodePage - буфер с табличкой 
pszSrc - исходный массив символов

for)int i=0; i<strlen)pszSrc:; i++: pszSrc[i( = )byte:)pszCodePage[)byte:pszSrc[i((:;

зы. Вот ещё забыл - посмотри функции CharToOem и OemToChar.

[Mfcer__]

зы. Вот ещё забыл - посмотри функции CharToOem и OemToChar

Как я понял это функции колторые находятся в user32.dll. А есть ли такие функции, которые предусмотрены в си.
И можно еще поподробней рассказать о "codepage"

[Джон]

Как я понял это функции колторые находятся в user32.dll. А есть ли такие функции, которые предусмотрены в си.

Да это API-шные функции.
Хм... не думаю, чтоб стандарт такое поддерживал. С языком это напрямую не связано. Char-у например вообще до символов дела нет, он их как целые знаковые числа видит.

И можно еще поподробней рассказать о "codepage"

Ну представь себе табличку, вернее массив целых незнаковых чисел:

unsigned char ucCodePage[256];

первые элементы от 0 до 127 совпадают с порядковым номер, ты и сам это знаешь ASCII и ANSI - совпадают. А вот потом начинается "подгружаемая" часть. Которая под ДОС зависила например от драйверов клавы. А под виндой от выбранного языка, или кодировки.

Твоя задача сопоставить коды символов одной кодировки с кодами другой. Начиная со 128го. Например, ты хочешь, чтоб при вводе символа с кодом 192 на печать (на экран) отправился бы символ с кодом 121. Тогда:

ucCodePage[192] = 121;

и тд.

Отображение же символов зависит целиком и полностью от выбранного шрифта. Или например как принтер воспримет этот код.

[Джон]

в FAQ (в связи участившимся в последнее время вопросами по теме) ИМХО должна быть ещё пара тем про это, но я их не нашёл (сильно не искал)

[Malaja]

Люди,

вопрос из той же серии - просьба ногами не бить :

есть старый си-шный проект, соответственно все строки представлены как char.
Теперь это все надо сделать unicode-восприимчивым (кроме немецкого и прочих стандартных текстов они хотят обрабатывать и другие, напр. русский).
Вопрос - как бы это провести наиболее безболезненно и с мин. временными и прочими затратами? (ибо как всегда сроки поджимают, клиенты кусают за выступающие части тела...)
Т.е. я пока понимаю только один путь: все char заменить на wchar_t, все функции для обработки char типа strcpy заменить соответствующими аналогами для unicode (в данном примере - wcscpy).
Возможно есть и другие, но я их не знаю... Может, кто-то уже такой кульбит на ушах выполнял? Заранее спасибо за терпение!

[Джон]

- char заменить на TCHAR (и вообще лучше им всегда пользоваться, кто его знает?)
- все константные строки взять в макрос: "Hallo"  -> _T("Hallo")
- использовать ф-ции не w*, а _t: strcpy -> _tcscpy - все ф-ции указаны в MSDN
- использовать CString где только возможно - он прекрасно управляется с юникодом и без него
- размер (при побайтной работе, например обнуление, или запись в файл) обязательно! умножать на размер типа

char *p = new char[nLen];
memset(p,0,nLen);
...
TCHAR *p = new TCHAR[nLen];
memset(p,0,nLen*sizeof(TCHAR));

Если следовать этим правилам ВСЕГДА, то переход на юникод займёт одну минуту - установка параметров проекта.

При этом следует заметить, что юникодная компиляция работает только на NT-платформах. Для поддержки всех вин-систем необходимо использовать MSLU (см. MSDN) - это конечно в том случае, если жизнь лёгкой кажется и тоскуешь по геморрою.

зы Другого пути нет.

[Malaja]

Джон,

во-первых, CString использовать не могу - проект должен быть си-шным и с майкрософтом никак не связанным...
Далее - насколько я понимаю, TCHAR является майкрософтовским типом (а у меня все это должно летать и под линуксом), посему я и сказала о wchar_t и функциях с w***. Если я неправа, поправь меня, пожалуйста.
Насчет компиляции - по твоему описанию похоже на трагедию в моем исполнении... Компилировать надо с помощью makefile-а, который надо будет, судя по всему, как-то изменить для уникода (только мне пока не совсем ясно как). Так что геморроя мне не избежать ;-( Насчет  MSLU я сейчас поищу, что это такое.

кстати, попыталась тебе вчера вечером с работы позвонить (пока ты в поезде ехал), но твой телефон послал меня на фиг Не любит он меня ,-)

[Джон]

Ну дык "Предупреждать надо" (с)  Короче всё, сливай воду, туши свет. Мои советы были для студии - так можно и юникод и ANSI компилировать. По сути за _T() _tc и тд скрывается опрос типа

#ifdef _UNICODE
    void FunctionW()
#else
    void FunctionA()
#endif

Вот и всё. MSLU - мелкософтовская прослойка для юникода. Требует установки доп. библиотек и компиляции всего и вся (runtime, MFC и тд и тп) с этой прослойкой.
В общем тебе тоже не поможет.

Тут лучше спроси у юниксоидов, может под никсом чего бывает.

зы А тебе позавчера звонил... А мой хэнди дурит. Мы ж во время переезда без телефона сидели (и без интернета!) - пользовались только хэндиками. Потом получилось так, что я поменялся с женой аку, а она его постоянно в экстриме гоняет и заряжает каждые 5 минут. Короче он у меня вырубается когда хочет. А мой отдавать она не хочет.

[Malaja]

Эгеж, то-то я и смотрю, что вся инфа про MSLU явно не про меня
Ща буду дальше искать... Тем более у меня еще с другой стороны виселица стоит - это все должно работать с SAP-программой, т.е. я еще должна выяснить, что мне надо для того, чтобы они жили вместе и дальше (как до сих пор и было - без уникода, тихо, полюбовно )

Судя по всему, мне надо в makefile-е вводить опцию UNICODE... Короче, я ищу дальше

Ну я ж не знала, что вы переехали! Я увидела, что ты звонил, но было уже слишком поздно - в 10 вечера я не рискнула звонить,чтобы никого не беспокоить.
А у меня с телефоном вечная проблема - я на работе ставлю его на вибрацию, а потом после работы забываю переставлять на звонок, в результате не слышу, когда мне вечером кто-то звонит на сотовый -) Родители меня скоро за это убьют
А с акку - так я вечно ловлю его, когда он уже умер или почти не дышит Ну что поделаешь, женщина и техника - это ж классика Хотя бывают исключения, но ооочень редко

[Антон (LogRus)]

обычно так делаем.
#ifdef UNICODE
typedef std::wstring tstring;
#define _T(s) L##s
#else
typedef std::string tstring;
#define T(s)
#endif

далее почти не где не используется Cи функции ибо зло
костантные строки обёрнуты в T("ddd");
вместо std::string везде tstring
для конвертации кодировок, обычно UTF8(char)<-->UTF32(wchar_t)// вообще размер wchat_t в gcc задаётся
используем ibm icu

ну и далее как было предложено Джоном с поправками на изоляцию от MS
рекомендую сделать маленький проектик в котором опробуется работа этих макросов и typedef'ов

[Malaja]

LogRus,

мда, а жизнь-то не налаживается ;-(

1) Почему "далее почти не где не используется Cи функции ибо зло"? А как же проводить операции со строками?
2) как  использовать UTF8(char)<-->UTF32(wchar_t) и для чего?
3) почему нельзя просто ввести wchar_t?

[Джон]

1. Это объекты стандартной библиотеки те должны работать на всех платформах.

2. Использовать тебе это придётся для коммуникации с НЕюникодными приложениями, например,  если "твоя" SAP - ANSI, то тогда все строчки из юникодной будут обрываться на первом же нуле, наприпер 'A' - 0x0041. Поэтому тебе надо будет конвертить.

3. Ну в принципе можно, и вот когда спустя многие тяжёлые месяцы ты, облегчённо вздохнув, созерцаешь результаты титанической работы, приходит некто и говорит, что ему нужна точно такая же программа, только с перламутровыми пуговицами - в НЕ юникоде, тк он её под Win9x запустить хочет, тут ты меееедленно выпадаешь в осадок и начинаешь себе говорить: "А ведь говорил мне LogRus, по-хорошему, по-доброму, так говорил - используй дефайны."

Offtopic:

Всё-таки умно поступил Nixdorf, что от Siemens отколупнулся. Они уже почти полностью на Win2000 перешли. Красссота! А ведь каких-нибудь пару лет назад было тяжело с поддержкой всяких 9х, NT3.5, NT4.0 А так, глядишь, лет через 10, и на ХР перейдут

Поставлю в угол.

[Dimka]

1. Это объекты стандартной библиотеки те должны работать на всех платформах.

Но вроде говорили о старом C-шном проекте, а объекты имеются лишь в C++.

[Malaja]

Джон,

1) я согласна с Димой - насколько я знаю, все это существует только для C++, а у меня чистый си... Или я ошибаюсь?
2) я никак не найду пример применения этих функций (в мсдн-не не нашла вообще...)

[Антон (LogRus)]

LogRus,

мда, а жизнь-то не налаживается ;-(

1) Почему "далее почти не где не используется Cи функции ибо зло"? А как же проводить операции со строками?
2) как  использовать UTF8(char)<-->UTF32(wchar_t) и для чего?
3) почему нельзя просто ввести wchar_t?

1) ну это если у тебя C++ то std::string всё умеет
2) у нас оракловый клиент а оракл имеет привычку возращать исключения в UTF8
3) потомучто если что можно выключить поддержку юникода за пару секунд.

что касается примеров использования функция то я обчно использую google codesearce прекрасный ресурс

[Джон]

Ну вы буквоеды. А что мешает сделать это для С?

#ifdef UNICODE
    typedef wchar_t TCHAR;
#else
   typedef char TCHAR;
#endif

[Dimka]

Джон, ну вот, например, отсутствие класса std::string, о котором LogRus говорит. Ведь мало типы переменных поменять - ещё C-шные стандартные функции есть типа strcpy.

P.S. Те ещё буквоеды

[Malaja]

Согласная я!
Просто когда на чем-то сосредоточен, а тут еще начальство за спиной притаилось с коварным вопросом типа :"НУ так как оно?", извилины перестают работать с выдумкой и начинают работать тупо и прямо

Я уже загрузила ICU-библиотеку, посмотрю, зачем она нам
А с этими смешными функциями завтра разбираться буду
Тут для начала надо выяснить элементарные вещи типа будет ли скелет проги стартовать и соединятъся с сапом, а если да, то еще и выяснить, получу ли я данные от них и смогу ли им что-то отправить. Короче, бред сивой кобылы в 3 часа ночи

[Джон]

Джон, ну вот, например, отсутствие класса std::string, о котором LogRus говорит. Ведь мало типы переменных поменять - ещё C-шные стандартные функции есть типа strcpy.

Насчёт STL согласен, без объектов ваще тяжко.

[не в тему]Хотя с другой стороны - кто мешает перейти на С++?[/не в тему]

 Я про пример определения ф-ций:

char *strcpy( char *strDestination, const char *strSource );
wchar_t *wcscpy( wchar_t *strDestination, const wchar_t *strSource );

Их тоже можно определить через макрос управляемый ключом UNICODE. Я вот только не знаю, может по никсом уже есть нечто подобное? Наверняка. Так их сразу и использовать.

[npak]

Функции операции со строками можно переопределить при помощи макросов переносимым образом.  Проблемы с переносимостью возникнут при вводе/выводе.

Именно, в Windows начиная с VS 2005 у потока ввода-вывода есть параметр, определяющий размер символов: ANSI (8 бит) и Unicode (UTF-16 или UTF-8).  Соответственно, результат вывода в поток функцией fwprintf на винде зависит от режима потока - при печати в ANSI поток широкие символы будут трактоваться как UTF-16 и конвертироваться в текущую кодовую страницу.  Печать в поток Unicode функцией fprintf не поддерживается совсем, поэтому предсказать, что напечатает функция ftprintf на винде - не тривиальная задача.
Поддержка Unix (POSIX) версии добавит ещё сложностей:
1. в POSIX не понятно, что именно сбрасывают функции вывода в поток - то ли wide char как они есть (16 бит), то ли производят конверсию в текущую локаль. Для каждой ОС и каждой версии библиотеки LIBC необходимо проводить эксперименты, что именно они делают.
2. в POSIX (и ISO C) и Windows по-разному интерпретируется спецификатор %s в строке формата fwprintf.  В windows %s означает, что соответствующий аргумент есть строка широких символов wchar_t, а в POSIX (ISO C) %с означает, что аргумент есть строка многобайтовых символов, которые перед печатью необходимо сконвертировать вызовами mbrtowc.  Для того, чтобы получить одинаковый результат, в Windows надо писать формат %s, а в линуксе %ls.

[Malaja]

Ой мама, а оптимизму-то у меня постепенно все меньше и меньше...
С fprintf, судя по всему, мне еще предстоит развлечься, но это потом

Пока более идиотский вопрос:

Сначала инфа к пониманию:
1)я наконец-то нашла инфу о том, в каком виде ожидаются данные на стороне SAP-а при использовании unicode: wchar_t или unsigned short.
2) программа стартует из окна cmd.exe с и имеет набор параметров для запуска:
saprfcsr.exe  -a DLG_TEST -g sap1 -x sapgw00

Сама проблема:
есть стандартная функция main(int argc, char** argv1).
В argv1 после старта лежат все данные, описанные в п.2). И этот список параметров должен быть послан дальше к RFC-проге с помощью функции RfcAccept(), которая проверит их на вшивость и при положительном решении разрешает соединение. В соответствующей RFC-функции этот параметр ожидаетя при unicode-запуске соответственно как wchar_t.
Если параметр argv1 сделать как wchar_t сразу в main(), то данные нечитабельны уже на входе в мою прогу. Значит, надо оставить argv1 как char**, а затем преобразовать данные в wchar_t.
Делаю:

Код:

    //  SAP_UC - typedef, определяющий тип wchar_t/char в зависимости от 
    // #ifdef UNICODE (поставляется с unicode-вариантом RFC-проги)
    // функции с окончанием ..U также определены в этой поставке для возможности 
    //переключения из одного состояния в другое:
/*
#define sizeofR(par)         sizeof(par)

#ifndef SAPwithUNICODE
  #define sizeofU(par)       sizeof(par)
#else
  #define sizeofU(par)       (sizeofR(par)/sizeofR(SAP_UC))
#endif

#define memsetU(  s,  wc, len )  wmemset(  s,  wc, len )
typedef size_t          size_tU;
*/
    int count;
    SAP_UC **argv = NULL;

    argv = (SAP_UC**)mallocU(argc * sizeofU(SAP_UC*));
    argv = (SAP_UC**)mallocU(argc * sizeofU(SAP_UC*));
    if (argv)
    {
        memset( argv, 0, argc * sizeofU(SAP_UC*) );
        for (count=0;count<argc;count++)
        {
            argv[count] = (SAP_UC*)mallocU(CHAR_COUNT * sizeofU(SAP_UC));

            if (argv[count])
            {
                memsetU( argv[count], 0, CHAR_COUNT * sizeofU(SAP_UC) );

                mbstowcs (argv[count], argv1[count], (size_tU)CHAR_COUNT);
            }
        }
    }

В результате я ожидаю argv - здоровую копию нашего argv1, но в виде wchar_t! Фигушки!!! При вызове RfcAccept() прога корчится от боли из-за проблем с доступом к памяти...
Вопрос: что я сделала неверно??? Что не так преобразовано?...
Я также попробовала поубирать все эти "U" и использовать обычные функции, но это не спасло тоже