Comments 123
Где же искать корень зла? Взглянем на протокол HTTP.
Тем не менее, корень зла не в HTTP, который был создан в 1990 году.
Собственно, и зла никакого нет, кроме разработчиков сайтов, которые не указывают в заголовках, в какой именно кодировке отдается контент.
Я считаю, разработчикам лучше дать больше подумать о логике скрипта, чем о какой-то мистической кодировке.
+ разработчикам приходится самим иногда забирать контент с других ресурсов, и тут бы гораздо проще было обходиться без магической функции iconv()...
+ разработчикам приходится самим иногда забирать контент с других ресурсов, и тут бы гораздо проще было обходиться без магической функции iconv()...
Вообще, конечно, проблема кодировок распространяется широко за пределы веб-сайтов, и не всегда легко решается.
Тем не менее постепенный переход на UTF происходит, так что процесс идет в нужном направлении :)
Тем не менее постепенный переход на UTF происходит, так что процесс идет в нужном направлении :)
Разработчикам при развертывании сайта нужно правильно написать одну строчку в .htaccess и усё.
Честно говоря, если сейчас в 2007 году я сталкиваюсь с софтом или сайтом, не умеющим работать с UTF-8 или другим уникодом, я обычно отказываюсь от его использования.
Честно говоря, если сейчас в 2007 году я сталкиваюсь с софтом или сайтом, не умеющим работать с UTF-8 или другим уникодом, я обычно отказываюсь от его использования.
мое мнение, что эту проблему должны были решить разработчики ОС, а все остальные должны были про нее забыть или вобще никогда не сталкиваться!
Автор не указал, на то, из-за чего родилось вобще такое разнообразие кодировок?
Автор не указал, на то, из-за чего родилось вобще такое разнообразие кодировок?
А при чём тут ОС? Есть HTTP-сервер, есть HTTP-клиент. Большинство известных мне представителей и того, и другого работает с Content-Type корректно.
А гвозди забивать, пардон, тоже надо учиться. Разработчики стены и стремянки тут не при чём.
А гвозди забивать, пардон, тоже надо учиться. Разработчики стены и стремянки тут не при чём.
Я говорил не о Content-Type, о существовании которого знаю прекрасно, а в основном о проблемах с параметрами, передаваемыми, например, методом GET. Просто не указал на это явно.
Кажется, я понял, Вашу идею. Вы говорите, что в строках запроса GET при передаче не-ASCII символов, они кодируются:
и хотите, чтобы они показывались пользователю красиво:
Если проблема в этом, то это опять таки не к разработчикам ОС, а к разработчикам браузера. Так, в FF и иже с ним у меня пишется в строке адреса http://ru.wikipedia.org/wiki/%D0%9C%D0%B…, а в Konqueror вполне по-русски
http://ru.wikipedia.org/wiki/Москва. В IE, если мне не изменяет память, тоже URL в раскодированном виде показан в строке адреса...
Или речь идёт о самом формировании URL-строки? Так ясно сказано: 1) перекодировать URL в UTF-8, 2) все не-ASCII байты представить в виде %HH. Не вижу, в чём проблема.
Взглянем на протокол HTTP. Итак, что мы видим? Заголовки, строка запроса GET и данные POST кодируются в формате "url-encoded", который, в свою очередь, базируется на символах US-ASCII.
и хотите, чтобы они показывались пользователю красиво:
Легко представить, насколько приятнее было бы видеть адреса страниц вида http://habrahabr.ru/blog/Хабраблог, закодированные в UTF-8.
Если проблема в этом, то это опять таки не к разработчикам ОС, а к разработчикам браузера. Так, в FF и иже с ним у меня пишется в строке адреса http://ru.wikipedia.org/wiki/%D0%9C%D0%B…, а в Konqueror вполне по-русски
http://ru.wikipedia.org/wiki/Москва. В IE, если мне не изменяет память, тоже URL в раскодированном виде показан в строке адреса...
Или речь идёт о самом формировании URL-строки? Так ясно сказано: 1) перекодировать URL в UTF-8, 2) все не-ASCII байты представить в виде %HH. Не вижу, в чём проблема.
FF-расширение под названием «Human Url» вам поможет.
У меня пишет "Несовместимо с 2.0.0.3"
Попробуйте расширение Locationbar2
Оно выполняет схожие функции + немного других
Оно выполняет схожие функции + немного других
Его можно заставить работать в 2.0.0.3, если поправить в install.rdf строчку в секции :
2.0.*
2.0.*
На самом деле совместимо.
Opera показывает по-русски, даже при copy'n'paste адрес остаётся первоначальным
С этим понятно... но все же... источник проблемы не ясен... естественно неясно, кому ее надо решать было...
Я так понимаю просто вовремя utf-8 не разработали, отсюда и проблемы.
Я так понимаю просто вовремя utf-8 не разработали, отсюда и проблемы.
ну и борьба браузеров за рынок в самом начале развития наверное тоже дал о себе знать.
Каюсь, не указал, ибо не копал. Но могу предположить, что КОИ7, а затем и КОИ8 была разработана еще в Советском Союзе, названия Windows-1251, MacCyrillic, ISO-8859-5 тоже сами за себя говорят. Странно, что такой картины не наблюдается с другими языками...
Думаю Вы правы. Кодировки остаются либо как историческое наследие (были государственным стандартом или корпоративным стандартом де-факто в прошлом), либо в результате политики успешного вендора по продвижению конкретной кодировки.
В остальных языках, в которых это не наблюдается, используется один и тот же латинский алфавит, только диакритика разная, но опять же, повторяется. Кстати, "у них", по моему опыту, веб-сервера гораздо реже настроены правильно.
А вот где алфавит нелатинский, то кодировок тоже пруд пруди. Мой браузер предлагает: 4 корейских, 3 тайских, 8 китайских, 3 японских кодировок (и это не предел). Как правило, более одной кодировки имеется везде, где компьютеры широко применялись ещё до пришествия Microsoft на местный рынок.
В остальных языках, в которых это не наблюдается, используется один и тот же латинский алфавит, только диакритика разная, но опять же, повторяется. Кстати, "у них", по моему опыту, веб-сервера гораздо реже настроены правильно.
А вот где алфавит нелатинский, то кодировок тоже пруд пруди. Мой браузер предлагает: 4 корейских, 3 тайских, 8 китайских, 3 японских кодировок (и это не предел). Как правило, более одной кодировки имеется везде, где компьютеры широко применялись ещё до пришествия Microsoft на местный рынок.
UFO just landed and posted this here
Кстати странно гуглевая реклама реагирует на смену кодировки :)
Поменял на этой странице в koi8, затем в utf-8, а затем обратно в 1251 и кодировка в этой рекламе слетела :)
Поменял на этой странице в koi8, затем в utf-8, а затем обратно в 1251 и кодировка в этой рекламе слетела :)
К сожалению, UTF-8 не покрывает все потребности человечества в кодировании. И покуда есть большие споры с носителями юго-восточных языков, часть символов которых не имеет способа кодирования с помощью UTF-8, полному распространению будут препятствия.
UTF-8 (а вернее, кодировка UTF-8 знаконабора Unicode) с точки зрения пользователя европейских алфавитов это верх совершенства.
Однако не всё столь гладко с юникодом. Не стоит забывать, что в процессе разработки стандарта было принято неоднозначное прешение, известное как <a href="http://en.wikipedia.org/wiki/Han_unification"Han" unification, приведшее к тому, что юникод отрицатся большим количеством людей, например, японцами.
Ханификация в юникоде привела к тому, что китайские, японские, корейские, старовьетнамские иероглифы были закодированы одним символом, при том что они, несмотря на общее происхождение, несколько разошлись в семантике и написании за прошедшие столетия. Кроме того, ряд специфически японских знаков просто не были закодированы.
Однако не всё столь гладко с юникодом. Не стоит забывать, что в процессе разработки стандарта было принято неоднозначное прешение, известное как <a href="http://en.wikipedia.org/wiki/Han_unification"Han" unification, приведшее к тому, что юникод отрицатся большим количеством людей, например, японцами.
Ханификация в юникоде привела к тому, что китайские, японские, корейские, старовьетнамские иероглифы были закодированы одним символом, при том что они, несмотря на общее происхождение, несколько разошлись в семантике и написании за прошедшие столетия. Кроме того, ряд специфически японских знаков просто не были закодированы.
То есть, если у меня сайт содержит китайский перевод, который закодирован в utf-8, китайцы вряд ли будут его читать?
Китайцы как раз будут, потому что нормативные унифицированные идеограммы как раз китайские (ханьцзы). Юникод обвиняют в евро-сино-центричности.
А вот японцы не то что не будут, а скорее всего не смогут. Представьте себе японский текст, содержащий цитаты китайских авторов на китайском. Правильно отобразить такой текст с унифицированным ханом нельзя, поскольку китайский текст, записанный японскими каньчжи выглядит довольно странно и неестественно, и в ряде случаев неверно.
Могу написать более обширный хабратопик на эту тему, если есть общий интерес.
А вот японцы не то что не будут, а скорее всего не смогут. Представьте себе японский текст, содержащий цитаты китайских авторов на китайском. Правильно отобразить такой текст с унифицированным ханом нельзя, поскольку китайский текст, записанный японскими каньчжи выглядит довольно странно и неестественно, и в ряде случаев неверно.
Могу написать более обширный хабратопик на эту тему, если есть общий интерес.
Спасибо. Интерес есть. Если будет что сказать об арабских кодировках, также буду рад :)
Вот интересный ресурс на тему представления разных арабских шрифтов http://www.wazu.jp/gallery/Fonts_Arabic.… Ниже в Related Links есть много полезных ссылок про интепретацию арабских языков в юникоде.
есть большие споры с носителями юго-восточных языков, часть символов которых не имеет способа кодирования с помощью UTF-8
Можете рассказать об этом поподробнее? Интересно все-таки.
Можете рассказать об этом поподробнее? Интересно все-таки.
Японцы/китайцы/корейцы продвигают свою кодировку Shift JIS. В принципе не безосновательно.
Думаю, что по Shift JIS должно найтись что-то более развернутое.
Думаю, что по Shift JIS должно найтись что-то более развернутое.
Чуть выше bubuq несколько прояснил ситуацию. Подробно про ханификацию можно прочитать на всезнающей википедии: http://en.wikipedia.org/wiki/Han_unifica…. Там отдельно есть раздел Controversy посвященный разногласию с носителями CJK языков
UTF-8 - одназначно рулит!
Редактор кода Textmate ВСЕГДА сохраняет в UTF-8. Открывает все.
Не надо пытаться изменить весь мир сразу. Начните с малого, с себя: делайте все свои сайты в UTF-8.
При использовании уникода объем страницы возрастает в 2 раза. Я понимаю, что в Москве почти везде уже анлим, но в России это не так.
да ладно вам, графика весит куда больше, не будем экономить на спичках )
именно! зайдите на тот же самый mail.ru
WebDeveloperToolbar для FF показал вес страницы 87 кб, из которых 63 кб картинки.
переход на utf-8 увеличит вес документов примерно в 2 раза, итого конечная страничка потяжелеет всего на 24КБ, а вся страница будет весить всего 111КБ
WebDeveloperToolbar для FF показал вес страницы 87 кб, из которых 63 кб картинки.
переход на utf-8 увеличит вес документов примерно в 2 раза, итого конечная страничка потяжелеет всего на 24КБ, а вся страница будет весить всего 111КБ
откройте код того же mail.ru, и посмотрите, какая часть документа содержит русские буквы. Большая часть документа - тэгопомойка.
Примерно в два раза увеличиваться вес документа будет тогда, когда начнут писать грамотно.
Примерно в два раза увеличиваться вес документа будет тогда, когда начнут писать грамотно.
нууу... думаю не стоит переходить на полемику о верстке, к тому же - верстке конкретного сайта. тут мы про кодировки общаемся.
я собственно о том, что разговоры об увеличении объёма из-за кодировки несостоятельны. Увеличение несущественно на фоне остальных факторов.
А если уж экономить, то можно на другом - та же вёрстка, та же графика. А ещё веб-страницы могут передаваться в сжатом виде, если кто не знал. Экономия от любого из этих методов будет ощутимее, чем от устаревших восьмибитных кодировок.
Проблем с кодировками море, а разницу в весе комментом ниже показал Lynn на конкретном примере с конкретными цифрами. На мой взгляд, утф8 - на сегодняшний день правильное решение.
А если уж экономить, то можно на другом - та же вёрстка, та же графика. А ещё веб-страницы могут передаваться в сжатом виде, если кто не знал. Экономия от любого из этих методов будет ощутимее, чем от устаревших восьмибитных кодировок.
Проблем с кодировками море, а разницу в весе комментом ниже показал Lynn на конкретном примере с конкретными цифрами. На мой взгляд, утф8 - на сегодняшний день правильное решение.
# wget http://mail.ru/ -O mail.html
...
15:28:50 (59.92 KB/s) - `mail.html' saved [45339]
# cat mail.html | wc -c
45339
# iconv -f cp1251 -t utf-8 mail.html | wc -c
48507Итого, при смене кодировки размер главной страницы увеличился на 3кб. Смешно…
это как три маленьких хабровских аватара! :-D
Да, так правильнее. В html-е больше латнинских символов, а раздувание веса файла идет за счет кодирования нелатинских символов. но! кодировать в юникоде придется и CSS и наверняка JavaScript.
Только IE сделал такое, что хоть стой хоть падай: ладно бы он не подхватил ASCII CSS-ку совсем! Он подхватил ее только частично!
Только IE сделал такое, что хоть стой хоть падай: ладно бы он не подхватил ASCII CSS-ку совсем! Он подхватил ее только частично!
И много у вас в CSS и JS нелатинских символов?
ха! прикольно но НИ ОДНОГО!
не буду врать про JavaScript - это моя догадка, но то что обычный IE6 творил необычные вещи у меня на глазах, и из-за которых я убил два часа, - это факт! Почему только после двух часов хождений вокруг до около этого браузерного убожества я просто открыл блокнот и сохранил css-ку в UFT-8 (только после этого все стили подхватились), так то, что я даже не мог предположить, что одна единственная программа как будто намеренно портит жизнь своими, мягко говоря, выходками: два отдельных файла! xhtml и css! один в UTF-8, другой в ASCIIи что в этом такого!!??
Мое предположение, почему IE так себя повел: я видел как в юникоде буква русская буква 'Т' кодировалась вот так 'Т' В css используется символ # например так
#headerdiv {float:left;}. Может, встретив в css-ке решетку, он подумал, что это начало символа?? ну и соответственно стиль не подхватился браузером. как думаете?
не буду врать про JavaScript - это моя догадка, но то что обычный IE6 творил необычные вещи у меня на глазах, и из-за которых я убил два часа, - это факт! Почему только после двух часов хождений вокруг до около этого браузерного убожества я просто открыл блокнот и сохранил css-ку в UFT-8 (только после этого все стили подхватились), так то, что я даже не мог предположить, что одна единственная программа как будто намеренно портит жизнь своими, мягко говоря, выходками: два отдельных файла! xhtml и css! один в UTF-8, другой в ASCIIи что в этом такого!!??
Мое предположение, почему IE так себя повел: я видел как в юникоде буква русская буква 'Т' кодировалась вот так 'Т' В css используется символ # например так
#headerdiv {float:left;}. Может, встретив в css-ке решетку, он подумал, что это начало символа?? ну и соответственно стиль не подхватился браузером. как думаете?
супер!
глюки осла можно коллекционировать и показывать за деньги!
глюки осла можно коллекционировать и показывать за деньги!
С малого - это когда все наконец станут писать charset в заголовке. До Unicode ещё как до Луны.
Сразу после полного перехода на UTF-8 начнется новая революция - "Долой кодировку utf-8 с ее переменной длиной символов! Даешь правильные кодировки - UC16, UC32! Сэкономим на strlen'ах! Облегчим регекспы! Терминировать нулевую терминацию!", ну и так далее.
У меня есть один знакомый товарищь который готов убить разработчиков UTF-8, и, надо сказать что я с ним в чем-то согласен. UTF-8 - это очень странный метод кодирования символьной информации, он подходит только там где надо апельсины бочками грузить :)
ну Википедия же работает с такими урлами.
http://ru.wikipedia.org/wiki/Заглавная_с…
причём она понимает и utf-8, и url-encoded
т.е. http://ru.wikipedia.org/wiki/Заглавная_с… и http://ru.wikipedia.org/wiki/%D0%97%D0%B… - для неё одно и то же (см. исходники mediawiki).
http://ru.wikipedia.org/wiki/Заглавная_с…
причём она понимает и utf-8, и url-encoded
т.е. http://ru.wikipedia.org/wiki/Заглавная_с… и http://ru.wikipedia.org/wiki/%D0%97%D0%B… - для неё одно и то же (см. исходники mediawiki).
http://habrahabr.ru/blog/Хабраблог , а американцы как будут такой URL набирать? Может все-таки стоит оставить url на английском?
грамотные люди всё равно ещё долгое время будут писать урлы по-старинке.
Многие грамотные люди стараются и файлам имена давать только маленькими латинскими буквами и цифрами, всё по той же причине.
Многие грамотные люди стараются и файлам имена давать только маленькими латинскими буквами и цифрами, всё по той же причине.
да, приментильно к урлам есть еще известная проблема двойников, например
http://habrahabr.ru/blog/Хабраблог
и
http://hаbrаhаbr.ru/blоg/Xaбpaблог
в юникоде будут выглядеть по-разному только для тех у кого глифы русского заменяются из другого шрифта (я заменил некоторые английские буквы русскими и наоборот), а для DNS (или обработчика запроса) это абсолютно разные адреса. В вики и проч. это работает потому, что мы ходим на разные виртуальные хосты ru, en, cs и т. п.
Избавление возможно только при переходе людей на один универсальный язык (пусть как второй, не родной). Английский не идеален (в силу многих недостатков, как и другие натуральные языки), но похоже универсальным останется все-таки он или его производная.
http://habrahabr.ru/blog/Хабраблог
и
http://hаbrаhаbr.ru/blоg/Xaбpaблог
в юникоде будут выглядеть по-разному только для тех у кого глифы русского заменяются из другого шрифта (я заменил некоторые английские буквы русскими и наоборот), а для DNS (или обработчика запроса) это абсолютно разные адреса. В вики и проч. это работает потому, что мы ходим на разные виртуальные хосты ru, en, cs и т. п.
Избавление возможно только при переходе людей на один универсальный язык (пусть как второй, не родной). Английский не идеален (в силу многих недостатков, как и другие натуральные языки), но похоже универсальным останется все-таки он или его производная.
Часто у вас американцы, не говорящие по-русски *вручную* набирают урлы полностью русскоязычных страниц? Поделитесь секретом успеха, мне б ваш трафик ;-)
мне один коллега по работе, PHP-программист говорил, что хранить данные в UTF - зло! а БД в Unicode это маразм, правда ли это? и есть ли UTF-8(7) - ЮНИКОД?
Попроси его сохранить в неюникодной базе строку «Шла Саша по Straße».
UTF-8, так же как и UTF-16/32, UCS-2/4 — это распособы кодирования UNICODE.
UTF-8, так же как и UTF-16/32, UCS-2/4 — это распособы кодирования UNICODE.
UTF-8 — это ужасно. БД в Unicode не маразм. UTF-7, UTF-8 — есть и это Unicode.
пасиб за разъяснение
Чем ужасен UTF-8?
Выше уже писали, что UTF-8 был придуман ленивыми англоязычными программистами, чтобы не переделывать существующие приложения. Отсюда я бы убрал слово "ленивыми", а так — всё верно. Это и есть плюс UTF-8.
Минусы существенны — кодировка имеет нефиксированную длину символа, поэтому все strlen, получение символа по номеру и прочее имеют низкую производительность, так как приходится проходить всю строку или нужно хранить метаинформацию, которую нужно расчитывать в момент записи. Т.е. куда не кинь — всюду расход ресурсов.
Минусы существенны — кодировка имеет нефиксированную длину символа, поэтому все strlen, получение символа по номеру и прочее имеют низкую производительность, так как приходится проходить всю строку или нужно хранить метаинформацию, которую нужно расчитывать в момент записи. Т.е. куда не кинь — всюду расход ресурсов.
А какая религия не позволяет программистам внутри программы использовать UCS-2/4, т.е. оставить UTF-8 только для общения с внешним миров? Более того, мне казалось, что так и делают…
> кодировка имеет нефиксированную длину символа
Для сети это плюс, т.к. процессорное время дешёво, а трафик дорог.
> поэтому все strlen, получение символа по номеру и прочее
> имеют низкую производительность, или нужно хранить метаинформацию,
Несущественно, т.к. эти функции не будут применятся к строке в UTF-8, а для UCS-4 доступ к символу по номеру работает быстро, а информацию о длине строки всё равно придётся хранить.
Для сети это плюс, т.к. процессорное время дешёво, а трафик дорог.
> поэтому все strlen, получение символа по номеру и прочее
> имеют низкую производительность, или нужно хранить метаинформацию,
Несущественно, т.к. эти функции не будут применятся к строке в UTF-8, а для UCS-4 доступ к символу по номеру работает быстро, а информацию о длине строки всё равно придётся хранить.
Для сети это не плюс. Так как трафик дешевеет со страшной силой. Выделенки по цене обеда — вполне себе реальность.
по поводу сравнения UTF-8/USC спрошу ещё раз: это как-то противоречит моему утверждению, что UTF-8 ужасная кодировка?
по поводу сравнения UTF-8/USC спрошу ещё раз: это как-то противоречит моему утверждению, что UTF-8 ужасная кодировка?
"Минусы существенны — кодировка имеет нефиксированную длину символа, поэтому..."
Вроде по-русски написали, что внутреннее представление строк обычно не utf-8, а UCS в которой длинна символа фиксированна.
"...приходится проходить всю строку или нужно хранить метаинформацию..."
Избыточность при хранении длинны строки вместе со строкой не значительна. Посколько cstrings должны заканчиваться \0x0 символом, то разница в 1-3 байта на строку для хранения размера - не столь существенна.
UTF-8 ужасен? С тем же успехом, можно утверждать что данные по ethernet следует передавать азбукой морзе. А трафик дешевеет во многом благодоря именно новым методам кодирования информации.
Вроде по-русски написали, что внутреннее представление строк обычно не utf-8, а UCS в которой длинна символа фиксированна.
"...приходится проходить всю строку или нужно хранить метаинформацию..."
Избыточность при хранении длинны строки вместе со строкой не значительна. Посколько cstrings должны заканчиваться \0x0 символом, то разница в 1-3 байта на строку для хранения размера - не столь существенна.
UTF-8 ужасен? С тем же успехом, можно утверждать что данные по ethernet следует передавать азбукой морзе. А трафик дешевеет во многом благодоря именно новым методам кодирования информации.
Каким бы не был внутренний способ кодирования, это никак не влияет на тот факт, что UTF-8 ужасная кодировка. Кстати, спросите у программистов на PHP как там строки хранятся.
Метаинформация - это не только длина строки, это ещё и положение символа для substr и прочего.
UTF-8 ужасен. Я вам привёл аргумент почему. Опровергающих аргументов я не вижу. На всё вы пишите или "и что с того" или "это не аргумент, потому что, когда мы работаем с USC-2...".
Удачных выходных.
Метаинформация - это не только длина строки, это ещё и положение символа для substr и прочего.
UTF-8 ужасен. Я вам привёл аргумент почему. Опровергающих аргументов я не вижу. На всё вы пишите или "и что с того" или "это не аргумент, потому что, когда мы работаем с USC-2...".
Удачных выходных.
Покажите тесты для strlen, substr, и тогда ваши "аргументы" станут Аргументами. Так же, вы могли бы предложить более оптимальный вариант кодировки. А на данный момент все ваши утверждения просто голословны и не несут под собой ни каких фактов.
Странный вы человек. Вы знаете как устроена кодировка? Думаю, знаете. Разницу в алгоритме получения символа по номеру в UCS-2 и UTF-8 представляете? Какие ещё вам тесты нужны?
Мне нужны практические тесты, и практическое доказательство того, что "utf-8 — это ужасно". Давайте посмотрим как сильно изменятся алгоритмы strlen и substr если мы возмем utf-8.
strlen для utf-8 будет работать так же быстро, т.к. маркер конца строки такой же как и в c-string — 0x00.
substr будет немного медленнее т.к. надо будет вычислять количество единиц в первых 4 битах для определения длинны закодированого кодпоинта и двигать указатель на это значение. Ну да, пара дополнительных тактов процессора. Сложность "алгоритма получения символа по номеру" не меняется. Ну и если вы попробуете максимально быстро посчитать количество предложений/строк/слов/букв в 10Гб текста то упретесь в производительность носителя (hdd, сеть, память), а не производительность процессора. На объемах до 100кб разница будет не большой, и беспокоиться тут не о чем. Но, если вдруг, в вашей задаче необходимо много раз вычислять длинну слов/строк/предложений, то вариант с перекодированием в fixed-width, и/или хранением мета-информации, и/или precalculated values будет оптимальнее (в большинстве случаев в не зависимости от кодировки)...
Variable width удобнее передавать по сети, а fixed width удобнее обрабатывать. И если вы забиваете гвозди микроскопом - то это ваша проблема, а не микроскопа. Не надо использовать utf-8 там, где оптимальнее использовать другой вариант кодирования.
Мне кажется, что utf-8 решает гараздо больше проблем чем создает. И благодаря именно этой кодировке мы все медленно, но верно переходим на юникод. Поэтому ваше утверждение о том, что "utf-8 – это ужасно" – не совсем корректно.
p.s. кажется увлеклись ,-)
strlen для utf-8 будет работать так же быстро, т.к. маркер конца строки такой же как и в c-string — 0x00.
substr будет немного медленнее т.к. надо будет вычислять количество единиц в первых 4 битах для определения длинны закодированого кодпоинта и двигать указатель на это значение. Ну да, пара дополнительных тактов процессора. Сложность "алгоритма получения символа по номеру" не меняется. Ну и если вы попробуете максимально быстро посчитать количество предложений/строк/слов/букв в 10Гб текста то упретесь в производительность носителя (hdd, сеть, память), а не производительность процессора. На объемах до 100кб разница будет не большой, и беспокоиться тут не о чем. Но, если вдруг, в вашей задаче необходимо много раз вычислять длинну слов/строк/предложений, то вариант с перекодированием в fixed-width, и/или хранением мета-информации, и/или precalculated values будет оптимальнее (в большинстве случаев в не зависимости от кодировки)...
Variable width удобнее передавать по сети, а fixed width удобнее обрабатывать. И если вы забиваете гвозди микроскопом - то это ваша проблема, а не микроскопа. Не надо использовать utf-8 там, где оптимальнее использовать другой вариант кодирования.
Мне кажется, что utf-8 решает гараздо больше проблем чем создает. И благодаря именно этой кодировке мы все медленно, но верно переходим на юникод. Поэтому ваше утверждение о том, что "utf-8 – это ужасно" – не совсем корректно.
p.s. кажется увлеклись ,-)
strlen не будет работать так же быстро. Потому что в strlen мы не ищем признак конца, а считаем сколько символовов, а они переменной длины. Т.е. строку нужно будет парсить.
Посчёт количества единиц в первых битах — это далеко не "несколько тактов", вы, видимо, в Ассемблере никогда не программировали. Сложность алгоритма получения символа по номеру, конечно же, сильно возрастёт. Вы, видимо, совершенно не представляете как это всё работает. В UCS-2 взять символ по номеру — это взять два байта из позиции N*2, где N — позиция, а 2 — размерность символа.
Идём дальше, вы неверно себе представляете процесс поиска N-нного символа в 10Гб тексте. В случае UCS-2 его не нужно зачитывать полностью, fopen, fseek(.., N*2) и читаем два байта. В случае с UTF-8 его придётся читать целиком до нужной позиции.
Вы тут всё говорите про "несущественную разницу", давайте же поговорим и про неё. БОльшая часть объёма страницы — графика, так что я утверждаю, что разница между объёмом страницы в UCS-2 и UTF-8 несущественна при существующих скоростях и gzip.
Задам вам конкретный вопрос: какие проблемы решает UTF-8, что их не может решить UCS-2?
Посчёт количества единиц в первых битах — это далеко не "несколько тактов", вы, видимо, в Ассемблере никогда не программировали. Сложность алгоритма получения символа по номеру, конечно же, сильно возрастёт. Вы, видимо, совершенно не представляете как это всё работает. В UCS-2 взять символ по номеру — это взять два байта из позиции N*2, где N — позиция, а 2 — размерность символа.
Идём дальше, вы неверно себе представляете процесс поиска N-нного символа в 10Гб тексте. В случае UCS-2 его не нужно зачитывать полностью, fopen, fseek(.., N*2) и читаем два байта. В случае с UTF-8 его придётся читать целиком до нужной позиции.
Вы тут всё говорите про "несущественную разницу", давайте же поговорим и про неё. БОльшая часть объёма страницы — графика, так что я утверждаю, что разница между объёмом страницы в UCS-2 и UTF-8 несущественна при существующих скоростях и gzip.
Задам вам конкретный вопрос: какие проблемы решает UTF-8, что их не может решить UCS-2?
Ну тогда strlen для юникода - это вообще один большой вопрос. Банальный U-умляут может быть закодирован как минимум двумя разными способами, что в таком случае считать длинной? Так что "парсить" придется в любом случае...
Речь не шла о поиске N-ного символа в 10Гб текста. Будте внимательнее.
В отличии от ucs-2:
- utf-8 решает проблему перехода на Unicode (совместимость с ASCII)
- В utf-8 влезает весь unicode range (U+10FFFF), в то время как в ucs-2 только U+FFFF
- В utf-8 не возможно распространение ошибки более чем на 1 кодпоинт. (Если в ucs-2 первый байт потеряется, то обнаружить ошибку невозможно и все последующие последовательности будут декодированны неверно, в utf-8 сразу будет обнаружена ошибка).
А теперь встречный конкретный вопрос: какие же проблемы не может решить utf-8, но их решает ucs-2?
Речь не шла о поиске N-ного символа в 10Гб текста. Будте внимательнее.
В отличии от ucs-2:
- utf-8 решает проблему перехода на Unicode (совместимость с ASCII)
- В utf-8 влезает весь unicode range (U+10FFFF), в то время как в ucs-2 только U+FFFF
- В utf-8 не возможно распространение ошибки более чем на 1 кодпоинт. (Если в ucs-2 первый байт потеряется, то обнаружить ошибку невозможно и все последующие последовательности будут декодированны неверно, в utf-8 сразу будет обнаружена ошибка).
А теперь встречный конкретный вопрос: какие же проблемы не может решить utf-8, но их решает ucs-2?
Вот! Перед измерением длины недурно ещё и нормализацию сделать :)
1) А зачем нам совместимость с ASCII? Что это даёт в нормальных условиях (а не когда надо быстро сделать совместимость)
2) зачем нам весь range? сейчас там занято около 100 000.
3) о каких потерях вы говорите? у нас тема — веб. какие там потери?
на встречный вопрос такой вот ответ: UCS-2 позволяет создавать производительные Unicode-приложения. UTF-8 — нет. UTF-8 — это своеобразная компрессия, по сути.
1) А зачем нам совместимость с ASCII? Что это даёт в нормальных условиях (а не когда надо быстро сделать совместимость)
2) зачем нам весь range? сейчас там занято около 100 000.
3) о каких потерях вы говорите? у нас тема — веб. какие там потери?
на встречный вопрос такой вот ответ: UCS-2 позволяет создавать производительные Unicode-приложения. UTF-8 — нет. UTF-8 — это своеобразная компрессия, по сути.
Нормализация = последовательный просмотр всей строки = можно смело забыть про производительность.
1 - обратная совместимость
2 - 100тыс vs 65535 (0xFFFF)
Производительные Unicode-приложения в Web позволяет создавать horizontal scalability а не кодировка. Производительность - это правильные алгоритмы и кеширование, а не кодировка. Производительность - это выбор в пользу компилируемых языков, а не utf vs ucs. Производительность это грамотная архитекрура...
(похоже каждый при своем остался мнении ,-) )
1 - обратная совместимость
2 - 100тыс vs 65535 (0xFFFF)
Производительные Unicode-приложения в Web позволяет создавать horizontal scalability а не кодировка. Производительность - это правильные алгоритмы и кеширование, а не кодировка. Производительность - это выбор в пользу компилируемых языков, а не utf vs ucs. Производительность это грамотная архитекрура...
(похоже каждый при своем остался мнении ,-) )
про нормализацию я говорил в ключе utf-8 :)
1) обратная совместимость на латинских буквам нам всем не впилась :)
2) да, позабыл, что там два байта всего. что ж... UCS-4? :) тут я крепко проигрываю.
а по поводу производительности — есть масса мест, где можно оптимизировать, то, что вы перечислили — верно, но это не значит, что низкая производительность utf-8 не важный фактор.
1) обратная совместимость на латинских буквам нам всем не впилась :)
2) да, позабыл, что там два байта всего. что ж... UCS-4? :) тут я крепко проигрываю.
а по поводу производительности — есть масса мест, где можно оптимизировать, то, что вы перечислили — верно, но это не значит, что низкая производительность utf-8 не важный фактор.
Вы тест про перекодирование 45кб головы mail.ru в utf-8 видели? В ucs-4 это будет 180кб. В utf-8 = 48кб.
Говорю ж — проигрываю я тут. Хотя, при нынешних каналах это скоро будет совсем несущественно. Но в обработке UTF-8 всё равно кошмар.
Вот вам strlen для utf8:
http://insa.pp.ru/files/strlen_utf.c
Можете скомпилировать и посмотреть на сколько больше стал код по сравнению с стандартным strlen'ом.
Бенчмарки там всякие провести, алгоритмы поанализировать ,-)
http://insa.pp.ru/files/strlen_utf.c
Можете скомпилировать и посмотреть на сколько больше стал код по сравнению с стандартным strlen'ом.
Бенчмарки там всякие провести, алгоритмы поанализировать ,-)
Вы, кажется, невнимательно читали, что я писал. Разве я говорил, что он будет больше, я говорил, что он будет сложнее. Причём, налегаю я не на strlen, который медленее несущественно, а на substr
Простите, забыл что сложность кода уже давно не измеряют в ассемблерных инструкциях. Если потрудитесь скомпилировать и дизассемблировать, то увидете те самые "пару лишних тактов процессора" про которые я писал выше.
substr - это из пэхапэ который?
в Unix Си strcpy и strncpy бегут по source строке и проверяют каждый символ на 0x0. По сути тот же алгоритм что в strlen. Только в случае с utf-8 искать надо будет 0x0 или начало следующего символа (условие из if) минус 1 байт. По вашему это сложно?
Ну что, я пошел рисовать звездочку на крышке ноута? ,-)
substr - это из пэхапэ который?
в Unix Си strcpy и strncpy бегут по source строке и проверяют каждый символ на 0x0. По сути тот же алгоритм что в strlen. Только в случае с utf-8 искать надо будет 0x0 или начало следующего символа (условие из if) минус 1 байт. По вашему это сложно?
Ну что, я пошел рисовать звездочку на крышке ноута? ,-)
substr — это PHP, Perl, куча других языков. Но именно в PHP всё работает несколько иначе (смотрю исходник в данный момент). И длина, конечно же, не ищется поиском \0, она хранится — в PHP-строке могут встречаться эти символы.
Так что, если говорить о Си, то это будет тормозить чуть, для PHP/Perl/Ruby/Python и прочих языков, где \0 — обычный символ тормоза будут серьёзнее.
А так — думаю, нам каждому по звезде :)
Так что, если говорить о Си, то это будет тормозить чуть, для PHP/Perl/Ruby/Python и прочих языков, где \0 — обычный символ тормоза будут серьёзнее.
А так — думаю, нам каждому по звезде :)
Я под ценой имел в виду не стоимость в рублях, а скорость.
Причём у UTF-8 есть ещё одно положительное качество, терпимость к ошибкам. Если при передаче теряется один байт, то бьётся только один символ и со следующего символа можно работать дальше, если при передаче UCS теряется один байт, то этого нельзя определить.
UTF-8 не ужасна сама по себе. Она ужасна, если её применять не по назначению. С тем же успехом можно говорить, что микроскоп это ужасный молоток, и держать его не удобно и гвозди гнутся…
Причём у UTF-8 есть ещё одно положительное качество, терпимость к ошибкам. Если при передаче теряется один байт, то бьётся только один символ и со следующего символа можно работать дальше, если при передаче UCS теряется один байт, то этого нельзя определить.
UTF-8 не ужасна сама по себе. Она ужасна, если её применять не по назначению. С тем же успехом можно говорить, что микроскоп это ужасный молоток, и держать его не удобно и гвозди гнутся…
Скорость? Если бы всех заботил этот показатель, на всех сайтах мы бы видели gzip. Кроме того, бОльшую часть объёма среднего сайта составляет не текст, а картинки.
По поводу потерь... Что-то я не понимаю о чём вы. Какие потери байтов? Где? Назначение у UTF-8 одно - быстро добавить Unicode к программам, которые его не понимают. И ключевое слово здесь — быстро.
По поводу потерь... Что-то я не понимаю о чём вы. Какие потери байтов? Где? Назначение у UTF-8 одно - быстро добавить Unicode к программам, которые его не понимают. И ключевое слово здесь — быстро.
> кодировка имеет нефиксированную длину символа, поэтому все strlen, получение символа по номеру и прочее имеют низкую производительность,
> Мерседес — это плохой автомобиль, он не ездит на 72 бензине.
Оба этих минуса несущественны, т.к. не надо в строке в кодировке UTF-8 получать символ по номеру и не надо в мерседес заливать 72 бензин…
> Мерседес — это плохой автомобиль, он не ездит на 72 бензине.
Оба этих минуса несущественны, т.к. не надо в строке в кодировке UTF-8 получать символ по номеру и не надо в мерседес заливать 72 бензин…
корень зла в корпорации Microsoft, вынуждающей всех попавших к ней в лапы пользоваться их набором кодировок.
Т.е. автора не смущают эти два визуально идентичных, но по сути _разных_ URL'а?
habrahabr.ru/xoce
habrahabr.ru/хосе
habrahabr.ru/xoce
habrahabr.ru/хосе
Почему они должны меня смущать? В этом нет ничего плохого.
А я вот ондажды повёлся, пройдя по URL'у microsoft.com, в коротом не то «о», не то «с» были не латинские, и обнаружив какой-то левый сайт. Визуальная идентичность адресов — это большая проблема. В китай-нете все давно пользуются иероглифами в URL'ах, но с ними сложно что-то спутать.
Любой браузер можно научить распознавать, скажем, смешанные языки доменного имени/урла и предупреждать пользователя об этом. Не даром все с недавних пор так пекутся о защите от фишинга. Мое мнение таково, что из-за таких вот глупостей — отказываться от использования национальных символов — кощунство и неуважение с своему языку. Как еще назвать вынужденное применение транслита или всю эту %D1%85%D1%83%D0%B9%D0%BD%D1%8E в урлах?
Судя по «%D1%85» вы используете FF... в моей Opera кириллица чудесно существует в URL'ах ;)
http://ru.wikipedia.org/wiki/%D0%97%D0%B…. // FF
http://ru.wikipedia.org/wiki/Заглавная_с… // Opera
http://ru.wikipedia.org/wiki/%D0%97%D0%B…. // FF
http://ru.wikipedia.org/wiki/Заглавная_с… // Opera
Sign up to leave a comment.
Кодировки must die