я должен исключить TCHAR из кода Windows?

Question

Я пересматриваю очень старый (10 лет) C-код. Код компилируется на Unix / Mac с GCC и кросс-компилируется для Windows с MinGW. В настоящее время есть строки TCHAR. Я хотел бы избавиться от TCHAR и использовать вместо этого строку C ++. Нужно ли по-прежнему использовать широкие функции Windows или я могу делать все сейчас с Unicode и UTF-8?

Answer 1

Windows использует UTF16 до сих пор и, скорее всего, всегда будет.Поэтому вам нужно использовать wstring вместо string.Windows API не предлагают поддержку UTF8 напрямую, потому что Windows поддерживала Unicode до изобретения UTF8.

Поэтому довольно сложно писать код Unicode, который будет компилироваться на платформах Windows и Unix.

Answer 2

Нужно ли использовать Широкие функции Windows, или я могу сделать теперь все с Unicode и UTF-8?

Да. К сожалению, в Windows нет встроенной поддержки UTF-8. Если вам нужна надлежащая поддержка Unicode, вам нужно использовать wchar_t версию функций Windows API, а не char версию.

я должен исключить TCHAR из кода Windows?

Да, вы должны. Причина, по которой существует TCHAR, заключается в поддержке как версий Unicode, так и не-Unicode для Windows. Поддержка не Unicode, возможно, была серьезной проблемой еще в 2001 году, когда Windows 98 все еще была популярна, но не сегодня.

И очень маловероятно, что любая библиотека, отличная от Windows, будет иметь такую ​​же перегрузку char / wchar_t, что делает TCHAR пригодной для использования.

Итак, замените все ваши TCHAR s на wchar_t s.

Код компилируется на Unix / Mac с GCC и кросс-компилируется для Windows с MinGW.

Раньше мне приходилось писать кроссплатформенный код C ++. (Сейчас моя работа - написание кроссплатформенного кода на C #.) Кодировка символов довольно болезненна, когда Windows не поддерживает UTF-8, а Un * x не поддерживает UTF-16. В итоге я использовал UTF-8 в качестве основной кодировки и преобразовал по мере необходимости в Windows.

Answer 3

И я предсказываю, что когда-нибудь, хотя, вероятно, не ранее 2020 года, Windows добавит поддержку UTF-8, просто добавив U-версии всех функций API, наряду с A и W, плюс такой же вид хакерских ссылок. 8-битные функции A - это просто слой перевода над собственными функциями W (UTF-16). Могу поспорить, что они могут генерировать U-слой полуавтоматически из A-слоя.

Как только их достаточно долго дразнили по поводу их поддержки Юникода '20-го века' ...

Им все равно удастся сделать неловкое написание, уродливое чтение и непереносимым по умолчанию, используя тщательно выбранные макросы и стандартные настройки Visual Studio.

Answer 4

Чтобы прямо ответить на ваш вопрос:

Нужно ли по-прежнему использовать широкие функции Windows или я могу сделать все сейчас с Unicode и UTF-8?

Нет, (не ASCII) UTF-8 не поддерживается большинством функций Windows API.Вам все еще нужно использовать широкие API.

Можно также оплакивать, что другие ОС по-прежнему не поддерживают wchar_t.Поэтому вам также необходимо поддерживать UTF-8.

В других ответах содержится несколько полезных советов о том, как управлять этим в кроссплатформенной кодовой базе, но звучит так, как будто у вас уже есть реализация, поддерживающая разные типы символов.Желательно, чтобы это прозвучало для упрощения кода.

Answer 5

Да, писать не-юникодные приложения в наше время - это стрелять себе в ногу.Просто используйте широкий API везде, и вам не придется плакать об этом позже.Вы по-прежнему можете использовать UTF8 в UNIX и wchar_t в Windows, если вам не нужна (сетевая) связь между платформами (или конвертировать wchar_t с Win32 API в UTF-8), или пойти трудным путем и везде использовать UTF-8 и конвертироватьк wchar_t, когда вы используете функции Win32 API (это то, что я делаю).