cstring m_pszdata не соответствует преобразованному char * в UNICODE

Я протестировал преобразование Unicode с помощью диалогового приложения UNICODE MFC, где я могу ввести немного китайского языка в поле редактирования. После прочтения символов с помощью

DDX_Text (pDX, IDC_EDIT1, m_strUnicode) UpdateDate (TRUE)

m_pszdata из m_strUnicode показывает «e0 65 2d 4e 1f 75 09 67». Затем я использовал следующий код, чтобы преобразовать его в char *:

char * psText; psText = новый символ [dwMinSize]; WideCharToMultiByte (CP_OEMCP, NULL, m_strUnicode, -1, psText, dwMinSize, NULL, FALSE);

psText содержит "ce de d6 d0 c9 fa d3 d0", ничего похожего на m_pszdata m_strUnicode. Кто-нибудь, пожалуйста, объясните, почему это так?


unicode cjk cstring
person LSSG    schedule 05.06.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

ce de d6 d0 c9 fa d3 d0 составляет 无中生有 в ГБК. Вы уверены, что манипулируете Unicode?

CP_OEMCP instructs the API to use the currently set default OEM codepage.

Итак, я предполагаю, что вы находитесь на китайском ПК с кодовой страницей по умолчанию GBK.

无中生有 в UTF16LE - это e0 65 2d 4e 1f 75 09 67, поэтому в основном вы конвертируете строку UTF-16-LE в GBK.

person dda    schedule 05.06.2012
comment
Я выбрал Unicode в настройках проекта MFC при запуске проекта и ввел 无中生有 для тестирования, предполагая, что китайские символы находятся в формате Unicode. Я ошибался в этом? - person LSSG; 05.06.2012
comment
Понятно. Спасибо. Я снова протестировал, используя английские буквы abcdef, и все заработало, как ожидалось. Правильно ли я говорю, что какая бы строка я ни вводила, она будет в UTF-16-LE, если используется UNICODE, а после преобразования в многобайтовый формат она будет в строке кодовой страницы по умолчанию? - person LSSG; 06.06.2012