Комментарии 6
Разве нельзя .cpp файл сохранить в utf-8 в Visual Studio?
Увы, это не так просто, как например в Eclipse CDT или CodeBlocks, там просто указываешь UTF-8 в workspace. Мало того, на логику того что в коде именно строки файловой системы по умолчанию уже может быть заложено много кода. В частности во взаимодействии с БД или веб-клиентом. Если просто перекодировать код большого проекта в UTF-8 и закоммитить, то:
1) получишь тонну проблем в массе стыковых мест, которые не так легко отловить, т.к. код изначально подразумевал переход от локализованной части к интернациональной;
2) к тебе придут все разработчики на MS Visual C++, если ты работаешь в команде больше одного человека, и спросят, с какого у них всё теперь так отображается в виде кракозябр и не работает.
Максимально безболезненно перенести все стыковые проблемы с перекодировкой на Boost.Python.
Если код на C++ пишется с нуля, разумеется лучше будет писать его сразу весь в UTF-8 (без BOM).
Но! Транспорт уменьшится по трафику вдвое, если перекодировать строку в cp1251 перед отправкой. Вспомните на досуге ваши проблемы с укороченными СМС кириллицей. Это всё благодаря транспортному уровню в UTF-8, кириллически символ идёт за два байта и не помещается в один стандартный пакет отправки.
1) получишь тонну проблем в массе стыковых мест, которые не так легко отловить, т.к. код изначально подразумевал переход от локализованной части к интернациональной;
2) к тебе придут все разработчики на MS Visual C++, если ты работаешь в команде больше одного человека, и спросят, с какого у них всё теперь так отображается в виде кракозябр и не работает.
Максимально безболезненно перенести все стыковые проблемы с перекодировкой на Boost.Python.
Если код на C++ пишется с нуля, разумеется лучше будет писать его сразу весь в UTF-8 (без BOM).
Но! Транспорт уменьшится по трафику вдвое, если перекодировать строку в cp1251 перед отправкой. Вспомните на досуге ваши проблемы с укороченными СМС кириллицей. Это всё благодаря транспортному уровню в UTF-8, кириллически символ идёт за два байта и не помещается в один стандартный пакет отправки.
По-моему, все с ног на голову. Не надо больше работать с кодированным текстом, не только в python, но и в C, а уж тем более в базах! Об этом и как раз революция Гвидо намекает. Вы отстали от жизни, базы уже давно распухли на строках и позволяют хранить нормальный тест на любом языке.
UCS — это бинарное представление строк в памяти и далеко не только в Windows. Кодировки используются только для записи в файлы, (и я бы рекомендовал забыть обо всех, кроме utf-8). При чем тут у вас кодировка файловой системы по отношению к строке «Это Я!» тоже непонятно, на имя файла это совсем не смахивает.
Ненавистный MS предложил это в лохматом 1996 ввиде Unicode API в WinNT 4, программистский мир дозрел только сейчас.
UCS — это бинарное представление строк в памяти и далеко не только в Windows. Кодировки используются только для записи в файлы, (и я бы рекомендовал забыть обо всех, кроме utf-8). При чем тут у вас кодировка файловой системы по отношению к строке «Это Я!» тоже непонятно, на имя файла это совсем не смахивает.
Ненавистный MS предложил это в лохматом 1996 ввиде Unicode API в WinNT 4, программистский мир дозрел только сейчас.
Эм, это как мне не работать с кодированным текстом в C++? Стандартная строка на языке C++ подразумевает char*=byte*, то есть базовый как бы намекает один символ=один байт, что ещё на заре C++ было далеко не всегда так. Уже используя UTF-8 мы получаем для Windows массу символов в 2 и 3 байта.
Я понимаю, что есть UCS-2 (обрезок UTF-16) которым Microsoft заткнула большинство дыр с Юникодом. Но подавляющее большинство библиотек на С++ работают с
Ну и в конце концов вы правда хотите работать на C++ с wide-strings?
Кроме того, с «широкими строками» в Windows мы получаем три основные проблемы.
1. Нет поддержки суррогатных пар из UTF-16, это дословно означает, что Юникода в Windows нет. Вы рано или поздно огребёте от наших китайских или индийских друзей. То что до сих пор не огребли, значит что либо применение вашего кода локализовано, либо эти ребята тоже пользуются Windows и их алфавиты сильно порезаны применением «основного».
2. Ваше API будет подразумевать постоянный переход от char* к wchar_t*. Как ни крути а большинство использует однобайтовые строки, нужно поддержать сигнатуру стандартных строк на C++.
3. Ваши строки в виде Wide-string сильно распухнут по сравнению с UTF-8 (наиболее компактным представлением Юникода), просто потому что ваш код изобилует пунктуацией, служебными символами и латиницей примерно наполовину минимум. Это очень сильно скажется на траффике и объемах данных на жёстком диске.
Исходя из вышесказанного проще использовать однобайтовую кодировку UTF-8.
Я понимаю, что есть UCS-2 (обрезок UTF-16) которым Microsoft заткнула большинство дыр с Юникодом. Но подавляющее большинство библиотек на С++ работают с
char* и std::string, причём не только сторонних, но и стандартных. Большинство функций уже дублировано через wchar_t* и std::wstring, но не все даже стандартные, даже в WinAPI.Ну и в конце концов вы правда хотите работать на C++ с wide-strings?
Кроме того, с «широкими строками» в Windows мы получаем три основные проблемы.
1. Нет поддержки суррогатных пар из UTF-16, это дословно означает, что Юникода в Windows нет. Вы рано или поздно огребёте от наших китайских или индийских друзей. То что до сих пор не огребли, значит что либо применение вашего кода локализовано, либо эти ребята тоже пользуются Windows и их алфавиты сильно порезаны применением «основного».
2. Ваше API будет подразумевать постоянный переход от char* к wchar_t*. Как ни крути а большинство использует однобайтовые строки, нужно поддержать сигнатуру стандартных строк на C++.
3. Ваши строки в виде Wide-string сильно распухнут по сравнению с UTF-8 (наиболее компактным представлением Юникода), просто потому что ваш код изобилует пунктуацией, служебными символами и латиницей примерно наполовину минимум. Это очень сильно скажется на траффике и объемах данных на жёстком диске.
Исходя из вышесказанного проще использовать однобайтовую кодировку UTF-8.
Я не понял, вы предлагаете не работать с wchar*, а работать с char* на utf-8? И что для этого есть стандартные функции?
Стандартные функции работают с UTF-8 в виде std::string или char* просто замечательно, за исключением operator[], поскольку он ссылается именно на элемент данных, а не на символ. Если Вы скажете, что wchar_t и std::wstring лучший выбор, я пожалуй не соглашусь, потому как с UTF-16 также operator[] не обязательно вернёт ссылку на символ. Если в тексте UTF-16 встречается суррогатная пара, то об индексации по символам можно забыть.
Если говорить только об UCS-2, то это настолько малая часть Юникода, по сути вы отказываетесь от 0x10FF0000 символов, то есть около 285 миллионов, в пользу 65,5 тысяч. В UCS-2 не входят даже все основные алфавиты, но кириллица там конечно же есть.
Можете обманывать себя, но по сути использование UCS-2 для кириллицы не сильно отличается от использования кодовой страницы. Проблем с другой кодовой страницей Вы конечно не получите, но интернационализации кодировки также не будет. Первый же выход крупного проекта ударит по вам незнакомыми доселе проблемами с хинди и, возможно, каким-нибудь кантонским, для избежания которых и существует общепринятый Юникод.
Используйте пожалуйста UTF-16, но также помните, что operator[] от i-го элемента не обязательно ссылается на i-й символ.
Если говорить только об UCS-2, то это настолько малая часть Юникода, по сути вы отказываетесь от 0x10FF0000 символов, то есть около 285 миллионов, в пользу 65,5 тысяч. В UCS-2 не входят даже все основные алфавиты, но кириллица там конечно же есть.
Можете обманывать себя, но по сути использование UCS-2 для кириллицы не сильно отличается от использования кодовой страницы. Проблем с другой кодовой страницей Вы конечно не получите, но интернационализации кодировки также не будет. Первый же выход крупного проекта ударит по вам незнакомыми доселе проблемами с хинди и, возможно, каким-нибудь кантонским, для избежания которых и существует общепринятый Юникод.
Используйте пожалуйста UTF-16, но также помните, что operator[] от i-го элемента не обязательно ссылается на i-й символ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дружим Python 3 с MS Visual C++. Строим мост в Boost.Python с автоматической перекодировкой