Опасность использования юникода

Вот и сиди на жопе ровно, а не высовывайся с «мудрыми» суждениями.

А я и сижу и не парюсь. А вы можете мучиться со своим юникодом.

А вот и фанбои подтянулись. Пример с жабой показателен только тем, что в этом языке проблему индусов, у которых обновление 1-й дырки в какой-нибудь librdp.dll зависит от локализации всей операционки, решили кардинально и жестко. Не всем угодили, да. Какие-нибудь китайцы или рубисты, которым 2 байта для азбуки мало, не прочувствуют всю силу и мощь l10n/i18n, но они в общем-то и без этого срать хотели на унифицированные кодировки. Им бы все шифт-жс и подобные использовать. Об этом, кстати, тоже по приведенной ссылке сказано.

Кстати в глибцах кошерный чар

Нормальных восьмибитных не бывает по очевидной причине.

Немного подумав, склонен согласиться: US-ASCII таки семибитная

Пока есть поддержка такой локали, буду пользоваться ею

Но зачем?

Он непрограммист на чистосях, ему так проще.

За шкафом.

Я уже неоднократно повторял: во-первых, man «бритва Оккама»; во-вторых, писать всякие программки на сишечке в КОИ8 намного проще; в-третьих, нет никаких проблем с латеховскими пакетами…

++

man «бритва Оккама»

Исправлено в порядке демонстрации полезности Юникода

писать всякие программки на сишечке в КОИ8 намного проще

GNU gettext спасет отца, нет?

нет никаких проблем с латеховскими пакетами

У LaTeX еще остались какие-то проблемы с UTF-8?

GNU gettext спасет отца, нет?

Спасет только если нужна многоязычная локализация. Для только русскоязычных приложений gettext не нужен.

У LaTeX еще остались какие-то проблемы с UTF-8?

Может быть - не знаю, лет 5 назад были.

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

Вот как раз лет 5 назад проблемы точно были: с bibtex'ом и rumkindex'ом.

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

Ты учти, какую часть объема занимают:

• разметка
• CSS
• Javascript (в т.ч. всякие счетчики, G+, twitter, жуйка)
• картинки (да хотя бы аватарки)

Могу спорить, что на фоне всего этого оверхед от UTF-8 - мизерный.

А «нормальная восьмибитная кодировка» - это что-то из области фантастики.

Т.е. то, что всякие CGI проще писать, тебя не смущает?

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

Шёл 2012 год...

http://xkcd.ru/742/

Поэтому многие хранят юникодные строчки в памяти в виде мультибайта фиксированной длины. Тогда никакого замедления нет.

За счет чего проще?

обработкой utf-8

Если необходимо много обрабатывать, что мешает перевести в UCS-2 для внутреннего использования?

Хотя бы за счет того, что 1символ == 1 байт. И никаких проблем в обработке строк.

Да и просто комментарии пишем: printf(«Тралала») вместо всяких извратов.

Хотя бы за счет того, что 1символ == 1 байт.

Профита от этого мало, антипрофита - много. Ну и можно 1 символ == 4 байта в оперативке хранить и будет точно то же самое.

printf(«Тралала») вместо всяких извратов.

Кто тебе мешает printf(«Тралала») в UTF-8?

PS. Что это за мода - писать обработку текста на языке, для этого не предназначенном?

Ну и вообще: к чему спорить? Всякому инструменту есть свое применение. Пихать юникод куда попало - это как прилаживать корове седло: вроде бы и сидит, но выглядит как-то хреновато...

Ну и можно 1 символ == 4 байта в оперативке хранить

Ну и какой дурак будет в 4 раза больше памяти на текстовую информацию тратить?

Вот из-за такого подхода мы и имеем то, что современные ОСи на (аж!!!) 2ГБ оперативки тормозят!!!

Ну и какой дурак будет в 4 раза больше памяти на текстовую информацию тратить?

Именно поэтому придумали utf8.

Пихать не-юникод куда попало - это как в 21 веке писать прикладные приложения в хекс-редакторе - такая же некрофилия. Зачем заново разводить проблемы с кодировками, которые, казалось бы, давно в прошлом?

казалось бы, давно в прошлом?

Ага, особенно в мрзтегах, куда ушлёпки с русской windows вместо ОС пихают текст в cp1251. Даже если там символы из cp1252 (первые 256 символов utf8 в чистом виде), когда Marléne превращается в Marlцne.

Что это за мода - писать обработку текста на языке, для этого не предназначенном?

???

Русский язык не предназначен для работы с текстами?

Ну и какой дурак будет в 4 раза больше памяти на текстовую информацию тратить?

Для этого и придумали UTF-8.

Вот из-за такого подхода мы и имеем то, что современные ОСи на (аж!!!) 2ГБ оперативки тормозят!!!

У знакомого есть компьютер с 384 Мб памяти, 434 Мгц Celeron и некая интеграшка с 8 Мб памяти. И ничего - Debian Lenny работает субъективно быстрее, чем венда хр, даже с файрфоксом, OOo 3 и довольно тяжелым DE (KDE 3.5.10). Так, что про прожорливость современных ОС - 4.2.

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

Нет. Я про язык программирования. Судя по всему, ты пишешь на C, который в плане обработки текста так и остался в каменном веке.

Windows - заповедник некрофилии, но все равно подобного все меньше и меньше, даже там.

А есть живые тулкиты, не хранящие внутри себя строки исключительно в юникоде?

даже с файрфоксом

4.2: современный огнелис жрет память, как свинья помои:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                           
 1945 eddy       1   0  745m 577m  11m S    1 28.8  12:09.30 freeciv-gtk2                                                                                                                      
 1868 eddy       1   0  805m 243m  25m S    0 12.1   1:52.39 firefox 

Тулкитами я практически не пользуюсь.

Мне сишечка нравится. И все в ней отлично.

Ещё не подохшая примитивщина вроде С и С++ (да и питона 2, к примеру) всё ещё в некотором смысле поощряет восьмибитных содомитов.

4.2: современный огнелис жрет память, как свинья помои:

И в этом виноват utf8, а не кривой web, допускающий ошибки в html, который и без того неоднороден?

Судя по всему, ты пишешь на C, который в плане обработки текста так и остался в каменном веке.

NAME wcscat - concatenate two wide-character strings

SYNOPSIS #include <wchar.h>

wchar_t *wcscat(wchar_t *dest, const wchar_t *src);

DESCRIPTION The wcscat() function is the wide-character equivalent of the strcat(3) function. It copies the wide-character string pointed to by src, including the terminating null wide character (L'\0'), to the end of the wide-character string pointed to by dest.

4.2, Firefox 3.6 без дополнений влезаем в сотню, если не меньше. На своем старом ноуте с 384 Мб юзал Firefox 7.

А в том что к примеру вычисление длины строки в UTF-8 намного медленнее чем ASCII строки

4.2, кстати. Если это нуль-терминированная C-строка, то вычисление и той, и другой - O(N), если же это нормальная строка, то там длина поддерживается отдельно и в обеих случаях - O(1).

Знаю про это. ЕМНИП, wcslen считает символы по принципу «1 символ == 2 байта» - плохо. Так, что таки каменный век.

C++ не поощряет восьмибитных содомитов.

Я говорю о современном дистрибутиве с современным набором софта. Т.е. 11-й огнелис и т.д., и т.п.

Причем, что интересно, html5 поддерживать огнелиса так и не научили, а вот жрет он, скотина, как будто бы на html10 рассчитан...

C++ не поощряет восьмибитных содомитов.

Своим хорошим уровнем совместимости с plain C вполне поощряет.

В линуксе wchar_t - 4 байта.

Он жрёт столько потому что рассчитан на html4. Убери поддержку всех исторических костылей, всё будет влезать и в калькулятор с 128 мб памяти. А если ещё всех обязать использовать один лишь xhtml, а при непрохождении страницы через xml-парсер и при невозможности отрендерить полученное дерево выдавать юзеру фигу, то вообще лепота будет. Но это уже мечты.

Если выбросить плагины, 10-й фокс на 32-битной системе с несколькими вкладками ЛОРа и гугла занимает около 150 Мб.

Мечтаю о том, что когда-нибудь W3C и производители бровзеров образумятся и будут открывать только сайты, являющиеся валидным XHTML...

калькулятор

128 мб памяти

:D