Unicode и C++ без wchar

подумай, и ты поймёшь почему говоришь глупость

Объясни, не понимаю. Как в одномерной структуре найти десятый отображаемый символ без перебора всех символов юникода один за другим?

Это - исключительный случай. А обычному русскому хватит любой восьмибитной кодировки по уши. Кстати, для всех европейских алфавитов хватит одной восьмибитной кодировки: достаточно псевдографику и всякие ненужные значки повыкидывать.

Над ē точки не нужны. И вообще эта буква - лишняя.

Запихнуть туда контрольный восьмой бит?

>ē
Перечисли кодировки, в которых есть либо можно представить этот символ.

-

— же. И вообще, преимуществ у восьмибитного legacy нет, а недостатков — полно.

Вы что, против смеси языков в одном тексте? Открою страшную тайну: короме русского и английского языка есть и другие языки, которые могут встречаться в одном тексте вместе с русским языком. И в 8 бит их не затолкаешь.

Перечисли кодировки, в которых есть либо можно представить этот символ.

Мне он не нужен. На клавиатуре у меня его нет, поэтому набираю, как привык писать (в случае, если нужно написать что-то вроде Шрēдингер).

преимуществ у восьмибитного legacy нет, а недостатков — полно.

Пока ни одного недостатка не заметил. Разве что, стоило бы остановиться на первоначальной кодировке, а не плодить всякие там ненужные cpXXXX.

Это - редкие случаи. Для них можно и юникод использовать. Но не постоянно же им пользоваться!

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

Объясни, не понимаю. Как в одномерной структуре найти десятый отображаемый символ без перебора всех символов юникода один за другим?

1) ровно так же как и двумерный массив хранить в одномерном :) просто смещаться на кратное количество байт
2) типичный алгоритм на строках занимается последовательным перебором символов, начиная с начала строки

Спор о том, нужен ли юникод — это вообще как спор на тему нужны ли компьютеры. Можно в существовании компов найти недостатки, но в целом это скорее польза, чем вред.

обычному русскому хватит любой восьмибитной кодировки по уши

увы, мне не хватит, ибо много чего на английском в программировании

кстати, даже виндовозники осознали и внедрили юникод, ну, по-своему конечно, своеобразненько так, но всё же

Над ē точки не нужны. И вообще эта буква - лишняя.

то не тебе решать

Ладно, спорить об этом можно бесконечно долго. Я же перейду на юникод лишь когда для поддержки КОИ-8 мне придется убивать больше, чем полчаса-час.

>Разве что, стоило бы остановиться на первоначальной кодировке, а не плодить всякие там ненужные cpXXXX.

Слишком толсто, проигнорировал.

много чего на английском в программировании

Как бы, первая половина любой 8-битной кодировки - ASCII =)

Вы что, не понимаете, что 1 ОТОБРАЖАЕМЫЙ символ занимает переменное число символов юникода, а каждый символ юникода в кодировке UTF8 занимает переменное число байт?

Понятие «кратное количество байт» отсутствует в принципе.

продолжая: а комментарии требуют на русском писать, ибо потом из них doxygen собирает маны, и?

> Спор о том, нужен ли юникод — это вообще как спор на тему нужны ли компьютеры.

Не нужны. Но раз уж есть, пусть лучше в них будет юникод :)

Вы что, не понимаете, что 1 ОТОБРАЖАЕМЫЙ символ занимает переменное число символов юникода, а каждый символ юникода в кодировке UTF8 занимает переменное число байт?

не-а, не понимаю, приведите ссылку на стандарт, где написано, что это именно так

вам сюда, читать до полного просветвления.

http://www.unicode.org/standard/WhatIsUnicode.html

Пишу комментарии в КОИ-8, doxygen отлично справляется. И?

>Мне
Nuff said.

Пока ни одного недостатка не заметил.

Даже для английского языка нехватает семибитной кодировки. Когда верхняя половина ещё и занята непонятной фигнёй — становиится совсем плохо. Впрочем, некоторые naïveные люди считают, что это не нужно всем, а не только им.
Ну и ад начинается когда софт хочет использовать иностранец. Например, японец или китаец. Собственно, софт идиотов, не желающий слышать о i18n, тупо ломается, они теряют пользователей и обычно уходят с конкурентного рынка. К сожалению, в опенсорсе конкуренции как таковой нет, поэтому никто никуда не уходит. Впрочем, японцы и китайцы относятся к типичному опенсорсу точно так же, как опенсорс относится к ним (а среди японцев опытных разработчиков заметно больше, чем, например, среди русских, и это не говоря о пользователях).

Вообще, юникод не идеален. Те же японцы и китайцы не в восторге от некоторых его особенностей. Но поддерживать юникод на порядки проще, чем поддерживать сотни (!) региональных кодировок и прочих особенностей локали (хотя кому я рассказываю о локалях, млин).

латех с юникодом только недавно начал дружить

Вообще-то, это проблемы говнокодеров и латеха.

Пишу комментарии в КОИ-8, doxygen отлично справляется. И?

И?звращенец :)

Ага. Жалкая попытка бедных людей с неполноценным алфавитом унифицировать кодировки...

а среди японцев опытных разработчиков заметно больше, чем, например, среди русских, и это не говоря о пользователях

ну-ну, давайте без голословщины, plz

google unicode combining marks

Те же японцы и китайцы не в восторге от некоторых его особенностей.

ога, вот только те же «иппонцэ» прутся от shift-js (до 70%), по сравнению с которой даже рисунки детей-дегенератов - вершина творчества

то есть не можете?

Эм. В Японии тупо выше процент компьютеризации при сравнимом населении.
Опенсорса, кстати, там тоже немало, но своеобразного.

>вот только те же «иппонцэ» прутся от shift-js (до 70%), по сравнению с которой даже рисунки детей-дегенератов - вершина творчества
В shift-jis нет юнификации иероглифов (т.е. можно отличить японский текст от китайского без магии). Уже этого хватает, чтобы оно + любая китайская кодировка было лучше юникода. О том, что оно из себя представляет, я в курсе.
Кстати, под shift-jis большинство понимает не её саму, а cp932, но это уже мелочи.

забанили в гугле? тогда помогу http://www.unicode.org/faq/char_combmark.html

особенно рекомендую к чтению
http://www.unicode.org/faq/char_combmark.html#7

ты сам то читал?

ты просто начал издеваться и троллить. Каждый отображаемый символ (grapheme) соостоит из переменного числа символово юникода (codepoint). Я больше не будут с тобой это обсуждать.

Это самый распространенный способ передавать текст на разных языках при неизменном алгоритме обработки.

Кроме того, юникод поддерживают все современные средства разработки и языки программирования, не вижу смысла отказываться от готового решения (целесообразность применения юникода на стороне сервера-то очевидна?).

целесообразность применения юникода на стороне сервера-то очевидна?

Отнюдь. Если это html-сервер, кодировка может быть любой, браузеру наплевать. Если ftp/ssh, то универсального решения не существует: у пользователя А юникод, у пользователя Б cp866, у пользователя В - КОИ8-Р. В любом случае именование файлов в кириллице на сервере кому-то обернется «крякозябрами». Так что, для имен файлов на любом сервере единственная удовлетворительная кодировка - ASCII. Для содержимого - плевать.

Я под серверной стороной имею ввиду все-таки специфичный для проекта софт.

И что мешает пользовательские имена переводить в юникод и хранить на сервере в этом виде имена файлов? Если кому-то нужна сецифическая кодировка, то переводить в неё перед отдачей пользователю.

>кодировка - ASCII

Надо уже забывать этот век динозавров с его ASCII и переходить на кодировку UTF-8, которая должна стать наконец-то новой ASCII и заменить весь остальной доисторический зоопарк кодировок.

> Так что, для имен файлов на любом сервере единственная удовлетворительная кодировка - ASCII. Для содержимого - плевать.

Не в век динозавров живем. Хватит думать о строке, как о наборе байт в какой-то кодировке

В современых способах кодирования символов некоторые кодовые последовательности контекстно-зависимы

и да, я не помню, но вроде в юникоде есть отдельный символ для ff (когда они слиты). Тогда их надо обрабатывтаь раздельно

ff
U+FB00
LATIN SMALL LIGATURE FF

Это 1 неразделяемый символ и её не надо обрабатывать раздельно и делить на 2 буквы f, за исключением режима совместимости (<compat> U+0066 U+0066).

А как о ней думать, если испокон веков строка и есть - набор байт в определенной кодировке.

С чего вы это взяли. С точки зрения текста это 2 символа, с точки зрения отображения один глиф

Испокон веков один байт - один символ. А здесь не так

Ну, кому-то и кактусы нравится жевать... А вообще, если использовать какой-нибудь utf32, то все символы просматривать в поисках нужного по порядку не придется - идешь себе с шагом в 4 байта и проверяешь... Правда, текстовые файлы в 4 раза «тяжелее» будут.

LATIN SMALL LIGATURE FF

При обработке текста ее надо рассматривать как 2 символа ff, при выводе - как один глиф

И шо, вы таки будете набирать лигатурой, или двумя f? Нормальные программы (тот же латех) лигатуры обрабатывает правильно и на выходе выплевывает нужный текст, хоть в ps, хоть в dvi, хоть в pdf формате. Но итоговый текст уже не является редактируемым. Все-таки, pdf не предусматривает полноценного редактирования и переформатирования.