Комментарии 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 на местный рынок.
НЛО прилетело и опубликовало эту надпись здесь
Кстати странно гуглевая реклама реагирует на смену кодировки :)
Поменял на этой странице в 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кодировки must die