Здравствуйте, gegMOPO4, Вы писали:
MOP>Фактически единственная операция, где std::string недостаточно — обрезка строки по заданному количеству символов.
И ещё вообще везде где надо знать сколько буковок будет выведено.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, okman, Вы писали:
O>Нельзя использовать строки std:(w)string для работы с UTF-8. O>Потому что шаблонный тип для basic_string — это char и wchar_t, длина которого фиксирована. O>В Visual C++ это 1 и 2 байта соответственно. А UTF-8 — многобайтовая кодировка, символ в ней O>может быть представлен как одним байтом, так и четырьмя.
Изначально подразумевалось что char'ами представляются символы в мультибайтовой кодировке, а wchar_t'ы должны вмещать в себя любой символ из доступного набора. На практике это не всегда так, UTF-16 в винде — это ужас и моральный террор. Для пруфа см. соответствующие разделы стандарта, приложение о локализации в Страуструпе и напр. http://www.cplusplus.com/reference/std/locale/codecvt/max_length/ — функция как раз возвращает максимальную длину символа. Так что мультибайтовость сама по себе использованию std::string и набора функций из <cstring> не мешает. Другое дело что, например, результат std::string::operator==() не более чем результат побитового сравнения, такой же как и strcmp(), и если необходимо нечто иное, то следует использовать strcoll(), std::locale::collate, std::lexicographical_compare и надеятся что они правильно работают на данной платформе.
Здравствуйте, Erop, Вы писали:
O>>Выполним std::normalize (гипотетический) и забудем.
E>Э-э-э, зачем? Тем более, что в каком-нибудь тайском этот твой std::normalize будет весьма гипотетическим. E>А ещё есть кроейский, например. Там можно буквы блока (слога) писать, как последовательные юникоды, а можно, как один. И чего?
Суть в том, что хоть какого, — плохого или хорошего, — std::normalize в C++ нету.
E>Нипиши правильный локейл и всё будет...
Какой ? К примеру, на Visual C++ любые конструкторы std::locale, инициализированные строками
вроде "ru_RU.utf-8", обламываются.
E>Да используй [ICU], ради Бога, если тебе это нужно/удобно и всё такое. Но это ни разу не единственное верное решение...
Здравствуйте, gegMOPO4, Вы писали:
MOP>В 90% задач toupper/tolower не нужны.
MOP>В 90% оставшихся достаточно toupper/tolower только с ASCII.
MOP>Оставшийся 1% — где действительно нужно, и UTF-16 или UTF-32 сами по себе не помогут
MOP>в 90% его не используют и работают с регистром неправильно.
MOP>Подавляющее большинство токенайзеров (использующих разделители из ASCII) будут работать правильно.
MOP>Это очень специфичные задачи, где могло бы понадобиться.
MOP>Затем, что в подавляющем числе случаев «жонглировать» не нужно.
Когда возражения приводятся в таком ключе, спорить неинтересно.
Здравствуйте, Erop, Вы писали:
O>>Выполним std::normalize (гипотетический) и забудем.
E>Э-э-э, зачем? Тем более, что в каком-нибудь тайском этот твой std::normalize будет весьма гипотетическим. E>А ещё есть кроейский, например. Там можно буквы блока (слога) писать, как последовательные юникоды, а можно, как один. И чего?
Дык есть же std::locale::collate::transform, ни разу не гипотетический.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, sidorov18, Вы писали:
S>>что значит переводить? M>WinAPI вроде как работает в UCS-2. Как минимум, это ограничивает набор символов 65536-ю символами. Но все равно необходимо перевести из UTF-16 в UCS-2. Некоторые кроссплатформенные либы принимают все-таки UTF-8. Ну и под другие OS UTF-8 нативнее.
хм. а источник есть?
в википедии написано что UCS-2 использовался до 2000 винды.
UTF-16 is used for text used in the OS API in Microsoft Windows 2000/XP/2003/Vista/CE.[8] Older Windows NT systems (prior to Windows 2000) only support UCS-2.[9]
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Erop, Вы писали:
E>>При этом с регисторм есть такая беда, что всё равно надо знать язык, чтобы понять какие маленькие буквы каким большим соответствуют.
PD>LCMapString PD>For a locale specified by identifier, maps one input character string to another using a specified transformation, or generates a sort key for the input string.
PD>int LCMapString( PD> LCID Locale, PD> DWORD dwMapFlags, PD> LPCTSTR lpSrcStr, PD> int cchSrc, PD> LPTSTR lpDestStr, PD> int cchDest PD>);
PD>LCMAP_LOWERCASE For locales and scripts capable of handling uppercase and lowercase, map all characters to lowercase. PD>LCMAP_UPPERCASE For locales and scripts capable of handling uppercase and lowercase, map all characters to uppercase
Ты не то выделил, IMHO...
Как это не печально, но в разных языках РАЗНОЕ соответствие больших букв маленьким. Разное и всё тут, хоть ты тресни.
Так что если язык не знаешь, а знаешь только буквы, например UTF-16, то фиг ты чего сконвертируешь
Примеры "разного"
1) Что делать с SS в немецком.
2) Что делать с диакритикой в язвках, где над большими буквами не пишут диакритических знаков?
3) Буква I бывает с точкой и без точки, как большая, так и маленькая. При этом в некоторых языках, например в турецком, маленькой с точкой соответствуюе большая с точкой, а большой без точки соответствует маленькая, тоже без точки, а вот в некоторых других языках, например в английском, всё перепутано. Большой без точки соответствует маленькая СТОЧКОЙ, и наоборот...
4) И т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Banned by IT, Вы писали: BBI>Здравствуйте, gegMOPO4, Вы писали: MOP>>Фактически единственная операция, где std::string недостаточно — обрезка строки по заданному количеству символов. BBI>И ещё вообще везде где надо знать сколько буковок будет выведено.
…но достаточно u32string…
Нет, для числа буковок строки в UTF-32 недостаточно.
Здравствуйте, gegMOPO4, Вы писали:
MOP>Т.е. нет проблем конвертировать каждый раз для COM?
Нет. но...
В моей практике — в винде я всегда использовал UTF-16. И с этим небыло проблем.
Конвертировать самому в UTF-8 — только для HTTP POST запросов. которые посылались не часто и не несли тонны текста.
Поскольку использовалось много COM-а — в противом случае нужно было бы много конвертировать.
Все таки маленький, но плюс — больше конвертировать или меньше конвертировать..
S>>Расход памяти тоже в большинстве случаев незаметен.
MOP>Это аргумент в основном для англоязычных. Очень много было криков из-за того, что Python3 требует в 2-4 раза больше памяти при работе с текстом, чем Python2 на тех же задачах. Хуже, что и скорость соответственно падала (а как вы думаете, вдвое больше байт перемолотить). Идентификаторы, ключевые слова, числа в десятичной записи, имена файлов, URL-ы — как правило помещаются в ASCII, поэтому это касается не только англоязычных.
Может..
На студия я не жалуюсь. Возможности проверить нет, конечно, но сомневаюсь, что они используют там внутри UTF-8.
S>>И что за проблема 0-го байта?
MOP>Функции, ожидающие ASCIIZ, споткнутся на первом же байте со значением 0. В UTF-16 это скорее всего будет в одном из первых символов.
тю, ну ясен пень. Проблема бабушки в том, что она не дедушка?
А вы запихните UTF-8 строку в wchar_t* и вызовите CreateFile. Интересно, откроется?
Это будет уже проблемой UTF-8?
MOP>>>А вот чем UTF-16 лучше UTF-8? Ничем. Сохраняет недостатки UTF-8 и добавляет свои. S>>в соседней ветке уточняем по поводу доступа по индексу.
MOP>Доступ по индексу — довольно редкая операция (может чуть чаще, чем языкозависимое сравнение строк без учёта регистра). И если нужно — можно и ICU подключить (впрочем, именно для этого есть и полегче библиотеки).
Может. Справедливости ради — сам не сталкивался. Но та же винда внутри этим должна заниматся. при переносе строк и т.п.
S>>Но проблема совместимости так же актуальна и для UTF-8. Здесь вопрос окружения, а не ситуация, если бы S>>везде был UTF-8.
MOP>Это Microsoft создала эту проблему и практически единственная причина для работы с UTF-16 — её обход.
Здравствуйте, okman, Вы писали:
O>Суть в том, что хоть какого, — плохого или хорошего, — std::normalize в C++ нету.
Суть ещё хуже. Его нет не только в С++, но и нигде. Для юникода нельзя задать такое универсальное отображение, увы и ах...
O>Какой ? К примеру, на Visual C++ любые конструкторы std::locale, инициализированные строками O>вроде "ru_RU.utf-8", обламываются.
Ну ты же сам можешь его реализовать, если библа не поддреживает...
O>Возражал не я, возражали мне.
Не-не-не, ты говорил, что типа так и никак иначе... На это и возражали. Иначе тоже можно. Серебрянной пули и правда не бывает
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Banned by IT, Вы писали:
BBI>И ещё вообще везде где надо знать сколько буковок будет выведено.
А что значит "буковок"? Вот, например, Ы -- это скока буковок?.. А арабское слово, какое-нибудь? А арабское слово с огласовками?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, MescalitoPeyot, Вы писали:
MP>Дык есть же std::locale::collate::transform, ни разу не гипотетический.
Беда тут в том, что во многих случаях вообще нет единственно-правильного представления. Поэтому и функцию нормализации фиг-напишешь...
Вот, например, во-французском языке принято (допустимо и широко используется) опускать диакоритику над большими буквами. Но недопустимо сбрасывать регистр букв в именах собственных.
И как будем нормалайз писать?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gegMOPO4, Вы писали:
MOP>А вот с этим категорически не соглашусь. Они все неудобны (или удобны) по-разному!
IMHO, сами по себе они примерно эквивалентны, за исключением регистра букв, но у разных библ и API интерфейс в разных кодировках... Вот и вся разница. Есть какая-то ещё?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gegMOPO4, Вы писали:
MOP>Нет, для числа буковок строки в UTF-32 недостаточно.
Да и само по себе понятие "число буковок" крайне мутное...
Интереснее обсуждать не предрассудки, а задачи. От задачи можно было бы хотя бы понять физ. смысл того "из чисел букв", которое имеется в виду...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, sidorov18, Вы писали:
S>Все таки маленький, но плюс — больше конвертировать или меньше конвертировать..
Ну и распечатать/посмотреть/что-то ещё сделать для отлдаки, например, в винде с UTF-16 строкой проще, чем с UTF-8...
S>>>в соседней ветке уточняем по поводу доступа по индексу.
Доступ по индексу имеет смысл обсуждать, только после того, как поределимся с тем, что такое буква...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, sidorov18, Вы писали: S>Поскольку использовалось много COM-а — в противом случае нужно было бы много конвертировать. S>Все таки маленький, но плюс — больше конвертировать или меньше конвертировать..
Согласен. А если это не надо, то и выбор UTF-16 становится намного менее обоснованным.
S>А вы запихните UTF-8 строку в wchar_t* и вызовите CreateFile. Интересно, откроется? S>Это будет уже проблемой UTF-8?
Какой ещё CreateFile-Shmile? Мы в форуме C++ или где? fopen, fstream скорее заработают с UTF-8, чем с wchar_t.
Здравствуйте, gegMOPO4, Вы писали:
MOP>Здравствуйте, okman, Вы писали: O>>Это значит, что уже только сравнение строк в UTF-8 без учета регистра запросто обломается. O>>Как и всякие toupper/tolower.
MOP>В 90% задач toupper/tolower не нужны. В 90% оставшихся достаточно toupper/tolower только с ASCII. Оставшийся 1% — где действительно нужно, и UTF-16 или UTF-32 сами по себе не помогут, нужно использовать ICU (но в 90% его не используют и работают с регистром неправильно ).
Похоже на то, что спорят тут негры с финами — нужна куртка зимняя или нет.
фины говорят, что нужна, а то замерзнешь. А негры говорят — холод — это очень специфическая температура, встречающаяся раз в 100 лет. И для нее сойдет и 3 свитера, нахрен куртка.
Что касается UTF-16 — в каких языках она не покрывает символ/2 байта?
Здравствуйте, Erop, Вы писали: E>Здравствуйте, gegMOPO4, Вы писали: MOP>>А вот с этим категорически не соглашусь. Они все неудобны (или удобны) по-разному! E>IMHO, сами по себе они примерно эквивалентны, за исключением регистра букв, но у разных библ и API интерфейс в разных кодировках... Вот и вся разница. Есть какая-то ещё?..
Здравствуйте, gegMOPO4, Вы писали:
S>>А вы запихните UTF-8 строку в wchar_t* и вызовите CreateFile. Интересно, откроется? S>>Это будет уже проблемой UTF-8?
MOP>Какой ещё CreateFile-Shmile? Мы в форуме C++ или где? fopen, fstream скорее заработают с UTF-8, чем с wchar_t.
Все правильно. Ну так какой был довод такой и контрдовод.
Не суйте UTF-16 туда, где предполагается ANSI и наоорот.
А арабское слово, какое-нибудь? А арабское слово с огласовками? 
).