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

Я проверил преобразование Юникода с диалоговым окном UNICODE MFC, где я могу ввести некоторых китайцев в поле редактирования. После считывания символов с помощьюcstring m_pszdata не соответствует преобразованному символу char * в UNICODE

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

в m_pszdata из m_strUnicode шоу "е0 65 2d 4e 1f 75 09 67". Затем я использовал следующий код для преобразования его в char *:

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

The psText содержит "се-де-d6 d0 с9 фа d3 d0", ничего подобного с m_pszdata из m_strUnicode. Кто-нибудь, пожалуйста, объясните, почему это так?

источник

2012-06-05 LSSG

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.

источник

2012-06-05 11:37:32 dda

Я выбрал Юникод в настройках проекта MFC при запуске проекта, и я сделал вход 无中生有 для проверки, считая, что китайские символы находятся в формате Unicode. Был ли я неправ? – LSSG

Получил. Благодарю. Я снова тестировал, используя английские буквы abcdef, и он работал, как ожидалось. Могу ли я сказать, что независимо от строки, которую я вводил, она будет в UTF-16-LE, если используется UNICODE, и после преобразования в многобайтовый он будет в строке кодовой страницы по умолчанию? – LSSG

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

ответ

Смежные вопросы