Наборы символов Visual Studio "не задано" vs "Многобайтовый набор символов"

я работаю с устаревшим приложением, и я пытаюсь выяснить разницу между приложениями, скомпилированными с Multi byte character set и Not Set под .

я понимаю, что компиляция с Multi byte character set определяет _MBCS что позволяет использовать многобайтовые кодовые страницы набора символов и использовать Not set не определяет _MBCS, в этом случае допускаются только однобайтовые кодовые страницы набора символов.

в случае, если это, я полагаю, тогда мы можем использовать только однобайтовые кодовые страницы набора символов, найденные на этой странице:http://msdn.microsoft.com/en-gb/goglobal/bb964654.aspx

поэтому я прав, думая, что это Not Set используется, приложение не сможет кодировать и писать или читать дальневосточные языки, поскольку они определены в двухбайтовых кодовых страницах набора символов (и, конечно, Unicode)?

после этого, если Multi byte character set определен, оба одиночные и многобайтовую кодировку на страницах кодекса, или только многобайтовую кодировку страниц кода? Я предполагаю, что это должно быть как для европейских языков, которые будут поддерживаться.

спасибо,

Энди

Более Дальнеишее Чтение

ответы на этих страницах не ответили на мой вопрос, но помогло в моем понимании: о опции "набор символов" в visual studio 2010

исследования

Итак, так же, как рабочие исследования... С мой язык, японский

влияние на жестко закодированные строки

char *foo = "Jap text: テスト";
wchar_t *bar = L"Jap text: テスト";

компиляция с Unicode

*foo = 4a 61 70 20 74 65 78 74 3a 20 83 65 83 58 83 67 == Shift-Jis (кодовая страница 932)
* bar = 4a 00 61 00 70 00 20 00 74 00 65 00 78 00 74 00 3a 00 20 00 c6 30 b9 30 c8 30 == UTF-16 или UCS-2

компиляция с Multi byte character set

*foo = 4a 61 70 20 74 65 78 74 3a 20 83 65 83 58 83 67 == Shift-Jis (кодовая страница 932)
* bar = 4a 00 61 00 70 00 20 00 74 00 65 00 78 00 74 00 3a 00 20 00 c6 30 b9 30 c8 30 ==UTF-16 или UCS-2

компиляция с Not Set

* foo = 4a 61 70 20 74 65 78 74 3a 20 83 65 83 58 83 67 == Shift-Jis (кодовая страница 932)
* bar = 4a 00 61 00 70 00 20 00 74 00 65 00 78 00 74 00 3a 00 20 00 c6 30 b9 30 c8 30 ==UTF-16 или UCS-2

вывод: Кодировка символов не оказывает никакого влияния на жестко закодированные строки. Хотя определение символов, как указано выше, похоже, использует кодовую страницу, определенную языковым стандартом, а wchar_t, похоже, использует UCS-2 или UTF-16.

использование закодированных строк в версиях W/A из API-интерфейсы Win32

Итак, используя следующий код:

char *foo = "C:Tempテストテa.txt";
wchar_t *bar = L"C:Tempテストテw.txt";

CreateFileA(bar, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
CreateFileW(foo, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

компиляция с Unicode

результат: оба файла создаются

компиляция с Multi byte character set

результат: оба файла создаются

компиляция с Not set

результат: оба файла создаются

вывод: Оба A и W версия API ожидает ту же кодировку независимо от выбранного набора символов. Из этого, возможно, можно предположить, что все Character Set опция делает это переключение между версией API. Так что A версия всегда ожидает строки в кодировке текущей кодовой страницы и W версия всегда ожидает UTF-16 или UCS-2.

открытие файлов с помощью W и Win32 APIs

Итак, используя следующий код:

char filea[MAX_PATH] = {0};
OPENFILENAMEA ofna = {0};
ofna.lStructSize = sizeof ( ofna );
ofna.hwndOwner = NULL  ;
ofna.lpstrFile = filea ;
ofna.nMaxFile = MAX_PATH;
ofna.lpstrFilter = "All*.*Text*.TXT";
ofna.nFilterIndex =1;
ofna.lpstrFileTitle = NULL ;
ofna.nMaxFileTitle = 0 ;
ofna.lpstrInitialDir=NULL ;
ofna.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST ;  

wchar_t filew[MAX_PATH] = {0};
OPENFILENAMEW ofnw = {0};
ofnw.lStructSize = sizeof ( ofnw );
ofnw.hwndOwner = NULL  ;
ofnw.lpstrFile = filew ;
ofnw.nMaxFile = MAX_PATH;
ofnw.lpstrFilter = L"All*.*Text*.TXT";
ofnw.nFilterIndex =1;
ofnw.lpstrFileTitle = NULL;
ofnw.nMaxFileTitle = 0 ;
ofnw.lpstrInitialDir=NULL ;
ofnw.Flags = OFN_PATHMUSTEXIST|OFN_FILEMUSTEXIST ;

GetOpenFileNameA(&ofna);
GetOpenFileNameW(&ofnw);

и выбрать либо:

• C:Tempテストテopenw.txt
• C:Tempテストテopenw.txt

выходы:

при компиляции с Unicode

*filea = 43 3a 5c 54 65 6d 70 5c 83 65 83 58 83 67 5c 83 65 6f 70 65 6e 61 2e 74 78 74 ==Shift-Jis (кодовая страница 932)
* filew = 43 00 3a 00 5c 00 54 00 65 00 6d 00 70 00 5c 00 c6 30 b9 30 c8 30 5c 00 c6 30 6f 00 70 00 65 00 6e 00 77 00 2e 00 74 00 78 00 74 00 == UTF-16 или UCS-2

при компиляции с Multi byte character set

*filea = 43 3a 5c 54 65 6d 70 5c 83 65 83 58 83 67 5c 83 65 6f 70 65 6e 61 2e 74 78 74 ==Shift-Jis (кодовая страница 932)
* filew = 43 00 3a 00 5c 00 54 00 65 00 6d 00 70 00 5c 00 c6 30 b9 30 c8 30 5c 00 c6 30 6f 00 70 00 65 00 6e 00 77 00 2e 00 74 00 78 00 74 00 == UTF-16 или UCS-2

когда скомпилировано с Not Set

*filea = 43 3a 5c 54 65 6d 70 5c 83 65 83 58 83 67 5c 83 65 6f 70 65 6e 61 2e 74 78 74 ==Shift-Jis (кодовая страница 932)
* filew = 43 00 3a 00 5c 00 54 00 65 00 6d 00 70 00 5c 00 c6 30 b9 30 c8 30 5c 00 c6 30 6f 00 70 00 65 00 6e 00 77 00 2e 00 74 00 78 00 74 00 == UTF-16 или UCS-2

вывод: Опять же,Character Set настройка не имеет отношения к поведение Win32 API. The A версия всегда возвращает строку с кодировкой активной кодовой страницы и W one всегда возвращает UTF-16 или UCS-2. Я прямо вижу, как это объяснил в этот великий ответ: https://stackoverflow.com/a/3299860/187100.

Окончательное Заключение

Ханс кажется правильным, когда он говорит, что определение на самом деле не имеет никакой магии, кроме изменения Win32 API для использования либо W или A. Поэтому я не вижу никакой разницы между Not Set и Multi byte character set.