Испанские символы в C ++ Windows / Mac / iOS

Question

У меня проблемы с отображением испанских символов в приложении для iOS. Весь рассматриваемый код написан на C ++ и используется как приложением Windows, так и приложением iOS. Скомпилировано в Windows с использованием Visual Studio 2010 (набор символов многобайтовый). И скомпилировано с использованием Xcode 4.2 на Mac.

В настоящее время в коде используются указатели на символы, и моей первой мыслью было переключение на указатели wchar_t. Тем не менее, я заметил, что испанские символы, которые я хочу вывести, отображаются в Windows очень хорошо, используя только указатели символов Это заставило меня думать, что эти символы являются частью многобайтового набора символов, и мне не нужно прилагать все усилия, чтобы обновить все до wchar_t, пока я не буду готов сделать некоторые переводы на японский, русский, арабский и т. Д. .

К сожалению, хотя испанские символы отображают свойства в приложении Windows, они не отображаются правильно, когда попадают в Mac / iOS. Экспериментируя с wchar_t, я вижу, что они будут отображаться правильно, если я все переконвертирую. Но чего я не понимаю, и надеюсь, что кто-то может просветить меня относительно причины ... почему символы совершенно допустимы на машине с Windows, тот же код и отображаются как бред (требующий вместо wchar_t) в среде Mac?

Visual Studio что-то делает с моими указателями на символы за кулисами, чего не делает Mac? Другими словами, является ли среда Microsoft более щадящей для моего архитектурного надзора, когда я использовал указатели на символы вместо wchar_t?

Поскольку я уже знаю, что мой ответ - преобразовать указатели на символы в указатели wchar_t, то мой реальный вопрос: «Почему Mac требует wchar_t, но в Windows я могу использовать char для тех же символов?»

Спасибо.

Answer 1

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

Лучший способ справиться с локализацией в кроссплатформенной кодовой базе - это UTF8.UTF8 изначально поддерживается в NSString -stringWithUTF8String: и в приложениях Windows Unicode, вызывая MultiByteToWideChar с CP_UTF8.Фактически, поскольку это Unicode, вы даже можете использовать ту же технику для обработки более сложных языков, таких как китайский.

Не используйте широкие символы в кросс-платформенном коде, если можете помочь.Это усложняется тем, что на OS X ширина wchar_t на самом деле составляет 32 бита. Фактически, по этой же причине она растрачивает память.

http://en.wikipedia.org/wiki/UTF-8

Answer 2

Ни одна из char, wchar_t, string или wstring не имеет прикрепленной к ним кодировки.Они просто содержат бинарный суп, который ваш компилятор решит интерпретировать как исходные файлы.У вас есть три переменные, которые могут быть отключены:

1. Что содержит ваш код (в реальном файле, между символами '' ', на двоичном уровне).
2. Какой ваш компилятордумает, что это так. Например, у вас может быть исходный файл UTF-8, но компилятор может преобразовать литералы wchar_t[] в надлежащий UCS-4. (Я бы хотел, чтобы MSVC 2010 мог это делать, но, насколько я знаю, он делаетвообще не поддерживает UTF-8.)
3. Что ожидает ваш API рендеринга. В Windows это обычно Little-Endian UTF-16 (как указатель LPWCHAR). Для старых API LPCHAR,насколько я знаю, обычно это «текущая кодовая страница», которая может быть что угодно * 1016. * Я думаю, что iOS и Mac OS используют UTF-16 для внутреннего использования, но они очень четко говорят о том, что они принимают и возвращают.

Никакой класс или кодировка не могут помочь вам, если между ними есть несоответствие.

В IDE, такой как Xcode или Eclipse, вы можете увидеть кодировку файла в его свойствелист. В Xcode 4 это самая правая панель, поднимите ееith cmd + alt + 0, если он скрыт.Если символы выглядят правильно в редакторе кода, кодировка правильная.Первый шаг - убедиться, что Xcode и MSVC интерпретируют одни и те же исходные файлы одинаково.Затем вам нужно выяснить, что они превращаются в память прямо перед рендерингом.И затем вам нужно убедиться, что оба API рендеринга ожидают одинакового набора символов вообще.

Или просто переместите строки в текстовые файлы отдельно от исходного кода и в четко определенной кодировке.UTF-8 отлично подходит для этого, но все будет работать, что может закодировать все необходимые символы.Затем только переводите ваши строки для рендеринга (при необходимости).

Я только что видел этот ответ, который дает еще больше причин для последнего варианта: https://stackoverflow.com/a/1866668/401925