Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gegMOPO4, Вы писали:
MOP>>Искать ASCII-пробел и ASCII-запятую это не помешает. А насчёт китайского пробела — так в ASCII с ним вообще никак (как и с прочей китайщиной).
E>А у китайцев есть свои точки, скобки, запятые, так что текст, набраный в КНР по-английски, всё равно может содержать "не те" пунктуаторы...

А у русских и греков свои буквы A и B, так что программа, набранная в России или Греции, может не скомпилироваться.

Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gegMOPO4, Вы писали:
MOP>>А чем сравнение строк без учёта регистра на русском в UTF-8 труднее, чем в UTF-16?
E>Тем что в UTF-16 русский -- это один код -- одна буква, если не лезть в маргинальщину, вроде й как и с диакритикой.

В UTF-16 для русского одна буква — два байта, а в UTF-8 одна буква — два байта. Хм…

Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gegMOPO4, Вы писали:
MOP>>Что? Посимвольно? Немецкий эсцет?
E>Эсцет можно нормализовать о того.

Как вы «посимвольно» будет сравнивать без учёта регистра, например, слова с эсцетом? Если в верхнем и нижнем регистре длина строки в UTF-16 различается.

E>В любом случае, у тех знаков, которые находятся на доп. плоскостях, нет большинства аттриутов. Ну там регистра, диакритики и т. д.
E>Ну и вообще многие алгоритмы будут таки работать, в общем.

Много какой код будет работать с UTF-8 вообще без изменений, как с ASCII. А вот для UTF-16 или UTF-32 придётся реализовать отдельную от ASCII версию.

Здравствуйте, Pzz, Вы писали:

Pzz>Китайцы стерпят, что этот пробел не удастся использовать в качестве разделителя аргументов в командной строке и т.п.

А при поиске?

Здравствуйте, Erop, Вы писали:

Pzz>>Китайцы стерпят, что этот пробел не удастся использовать в качестве разделителя аргументов в командной строке и т.п.

E>А при поиске?

А при поиске все равно надо локаль понимать, из-за [не]чувствительности к регистру.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Повторю еще раз, раз ты не понял — переменное число байт в представлении символа это наименьшая из проблем, которые возникают при не-побайтном сравнении срок. Настолько мелкая, что и упоминать о ней смысла нет. Просто потому, что одна и та же строка в разных регистрах может содержать разное число символов. И даже побайтно разные строки в одном регистре могут быть одинаковые с точки зрения пользователя — независимо от кодировки. И как только ты переходишь от побайтного сравнения строк к ориентированному на пользователя, все эти проблемы на тебя сваливаются.

Ну есть много мест, где можно сравнить не правильно, а "почти правильно".
Ну в нечётком поиске, например.
Но я согласен, если ты реально "по честному" хочешь делать, то кодировка пофигу.
Но если тебя и "почти правильно" устроит, то UTF-16 чуть-чуть лучше, IMHO, потому, что больше языков и сценариев, на которых работа программы не "почти верная", а просто верная получается...

ТКС>Пиши модератору, если что-то не устраивает
Ну та и я не обязан отвечать в струет твоего офтопика...

Здравствуйте, B0FEE664, Вы писали:

E>>Это всё неудбно, а отчасти, невозможно...
BFE>Почему невозможно? И чем не удобно?
BFE>>>Уникальное число задаёт уникальный символ.
BFE>>>Если графическое представление двух символов различно, то и коды этих символов различны (но не наоборот).
Что такое "уникальный символ"? Что такое "граф. представление различно"? Скажем алеф и алеф-италик -- это разные символы или нет? "A" с засечкой и без -- разные или нет? И т. д...

BFE>>>Символы сгруппированы по языковым группам.
Нет никаких языковых групп. Все границы прозрачные и шаткие. Или тебе прийдётся всё мегадублировать, или групп нет. Юникод и так на поддиапазоны разбит, но это мало помогает, на самом деле.

BFE>>>Два разных символа могут иметь одинаковый графический вид.
Это и сейчас так. Зачем ещё усугублять --

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

BFE>>>отдельный подстандарт, который описывает графическое представление символа на формальном языке.
TTF? Постскрипт? Всё не смогло, однако. Я, тебе, как спец в теме говорю -- фиг ты такой стандарт родишь + потом описания сами по себе дорого очень написать будет... Особенно, если они ещё и человекомчитабельные должны быть. (типа смотришь на описание и рисуешь все возможные варианты буквы)

E>>Скажем русская "а" бывает двух видов, это должны быть разные буквы?
BFE>Да. А почему нет? (И, кстати, если учесть ударение — то четырёх видов)

Потому, что работать с таким текстом неудобно. Оформление и аттрибуты, типа болда, например, удобно отделять от самих букв, вообще-то...

BFE>Допустим в слове "Порекомендуйте" символ 'й' представлен с помощью диакритического знака. Насколько просто отрезать от этого слова три последних символа?
В чём проблема? Сложно написать функцию, которая отступает на одну букву влево? Так это потому, что понятие "на одну букву влево" мутное крайне. А так ничего сложного. Есть множество жёстких разделителей + множество символов, которые могут быть началом буквы только после начала строки или жсткого разделителя. Ну и вперёд...


BFE>>>+ относительно легко подсчитать графический размер для представления строки.
E>>Это легко в любой кодировке.Был бы шрифт...
BFE>Да ну? С учётом кернинга?
Да с учётом чего угодно. Если умеешь рисовать -- умеешь и считать. Кодировка тут вообще ниак не поможет и не помешает...

E>>Главное, что графемные кодировки плохи, для передачи СОДЕРЖАНИЯ текста. А обычно тескт имеют в виде букв РАДИ СОДЕРЖАНИЯ, а не ради картинки...
BFE>Если так, то диакритические знаки надо выкинуть из кодировок, так как это всего лишь графическое представление
Нет. Не правда. Слова "Королева" и "Королёва" отличаются. Или, например "все" и "всё". Не говоря уже о "и" — "й" и о других языках...

E>>То есть такое решение нагнуло бы или усложнило поиски замены, спеллеры, граммеры, аннотаторы и т. д...
BFE>Как будто сейчас все они поддерживают диакритические знаки.

Чего? Ты знаешь спеллер, который не поддерживает?

Здравствуйте, gegMOPO4, Вы писали:

MOP>Вообще-то, если код в основной плоскости, то он в основной плоскости, — это не зависит от представления.

В UTF-8, тем не менее, даже код с основной плоскости одним байтом фиг представишь...

Здравствуйте, gegMOPO4, Вы писали:

MOP>А у русских и греков свои буквы A и B, так что программа, набранная в России или Греции, может не скомпилироваться.

Может, но не на современно С++

Здравствуйте, gegMOPO4, Вы писали:

MOP>В UTF-16 для русского одна буква — два байта, а в UTF-8 одна буква — два байта. Хм…

Нет, не так. Скажем буква -- два байта, а пробел или запятая -- один.
И это даже если китайские пунктуаторы не в игре А то и больше может оказаться...

Здравствуйте, gegMOPO4, Вы писали:

MOP>Как вы «посимвольно» будет сравнивать без учёта регистра, например, слова с эсцетом? Если в верхнем и нижнем регистре длина строки в UTF-16 различается.

Ну операции "снять диакритику" и "снять/установить капиталлизацию" можно делать последовательно, например...

MOP>Много какой код будет работать с UTF-8 вообще без изменений, как с ASCII. А вот для UTF-16 или UTF-32 придётся реализовать отдельную от ASCII версию.

Это уже очень сложный вопрос, на самом деле.
В целом подход с отдельной версией надёжнее. Во всякмо случае, при некоторой культуре разработки...

Здравствуйте, Pzz, Вы писали:

Pzz>А при поиске все равно надо локаль понимать, из-за [не]чувствительности к регистру.

Какой такой регистр у китайцев, извините...

Здравствуйте, Mystic, Вы писали:

M>В UTF-16 в начале строки должна идти последовательность 0xFEFF по которой определяется кодировка.

Все-таки не в начале (каждой) строки, а только в начале текста/файла, и в общем случае не должна.

Здравствуйте, Кодт, Вы писали:

К>На 32 битах может быть ещё и pdp-endian (старшим байтом младшего слова вперёд: 1 0 3 2). Для полного щастя.

Для совсем полного счастья нужен еще порядок 1 0 2 3.

On 11/18/2011 11:54 AM, 777777w wrote:

Модыратыры, плиз, отделите этого пасынка от нормальной темы про "С++" и вообще.

Здравствуйте, Erop, Вы писали:

Pzz>>А при поиске все равно надо локаль понимать, из-за [не]чувствительности к регистру.

E>Какой такой регистр у китайцев, извините...

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

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Mystic, Вы писали:

M>>В UTF-16 в начале строки должна идти последовательность 0xFEFF по которой определяется кодировка.

I>Все-таки не в начале (каждой) строки, а только в начале текста/файла, и в общем случае не должна.

Мы же работаем не только с файлами, но и с отдельными строками. Ну и если не должна, то как узнать, как читать файл? Во всяком случае, клиент и сервер должны договориться вначале о том, какой из UTF-16 использовать.

Здравствуйте, B0FEE664, Вы писали:

BFE>Ошибаетесь! В винде есть ещё мультибайтовая кодировка — альтернатива юникоду. Поэтому нельзя однозначно сказать, что char* это ANSI.
Блин, понапридумывали кодировок. =))
Конкретно этот MBCS уже устарел, и проиграл юникоду, я так понял?

Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gegMOPO4, Вы писали:
MOP>>Как вы «посимвольно» будет сравнивать без учёта регистра, например, слова с эсцетом? Если в верхнем и нижнем регистре длина строки в UTF-16 различается.
E>Ну операции "снять диакритику" и "снять/установить капиталлизацию" можно делать последовательно, например...

И преимущество UTF-16 как-то уходит.

MOP>>Много какой код будет работать с UTF-8 вообще без изменений, как с ASCII. А вот для UTF-16 или UTF-32 придётся реализовать отдельную от ASCII версию.
E>Это уже очень сложный вопрос, на самом деле.
E>В целом подход с отдельной версией надёжнее. Во всякмо случае, при некоторой культуре разработки...

И возникает проблема многочисленных перекодировок.

Здравствуйте, gegMOPO4, Вы писали:

E>>В целом подход с отдельной версией надёжнее. Во всякмо случае, при некоторой культуре разработки...
MOP>И возникает проблема многочисленных перекодировок.

Не понял. Что за проблема? UTF-8 это же тоже не ASCII, как бы...

А так я согласен, что если всё честно делать, то пофиг какая кодировка. Но если делать "почти честно", то у UTF-16 есть небольшое преимущество перед UTF-8, IMHO, хотя это, конечно, от типичных задач зависит...