Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
Так вот оно что) Оказывается не во всех грехах виноват IE)
Лояльность в отношении трактовки стандартов ни к чему хорошему, как правило, не приводит ;)
Да? Т.е. надо сразу после встретившейся ошибки упасть на бок или выдать грозное сообщение, которое простому пользователю ни о чем не говорит? Есть известные распространенные ошибки, и хороший браузер должен как можно более прозрачно для пользователя постараться их исправить. Да, в какой-то мере это способствует распространению этих ошибок. Но с другой стороны пользователь не имеет возможности повлиять на содержимое/настройки посещаемого сайта/сервера. А посему лично я бы предпочел тот браузер, который корректно отобразит наибольшее количество страниц, несмотря на ошибки в них.
Кстати, разработчики стандартов сами ошибки допускают, которые потом вынужденно копируются теми, кто по этому стандарту работает. Яркий тому пример поле referer при том, что правильно было бы referrer.
Раньше IE много ругали за то, что он слишком мягко относится к стандартам, сейчас ругают за то, что следует им. Не угодишь.
то что он совсем не следует одним стандартам не противоречит тому, что он слишком строго следит за другими :)
Я ИЕ в данном случае не ругаю, что вы. Я говорю, что из двух браузеров я выберу тот, который лучше отобразит ошибочные страницы.
IE ровно поэтому и мягко относился к стандартам. Но сейчас важно им следовать. Слишком быстро веб прошлого превратился в ад из-за такого отношения.
Ответьте на простой вопрос: что лучше — выдать ошибку, с которой посетитель сайта ничего не может поделать, т.к. не контролирует посещаемый ресурс, или попытаться отобразить по какой-то определенной логике?
Я не говорю о том, что надо нарушать стандарты стандарты, я говорю о том, что надо гибко обходить ошибки. Пользователь прежде всего!
Я вам приведу такой пример отвлеченный, чтобы легче было ответить: попадается вам битый архив (или упакованный с нарушением стандарта). Какая реализация архиватора будет лучше: та, которая попытается распаковать архив или та, которая выдаст кучу матюков и пошлет пользователя куда подальше?
Я не говорю о том, что надо нарушать стандарты стандарты, я говорю о том, что надо гибко обходить ошибки. Пользователь прежде всего!
Я вам приведу такой пример отвлеченный, чтобы легче было ответить: попадается вам битый архив (или упакованный с нарушением стандарта). Какая реализация архиватора будет лучше: та, которая попытается распаковать архив или та, которая выдаст кучу матюков и пошлет пользователя куда подальше?
Отвечаю: лучше следовать стандарту.
Вспомните как раньше IE пытался ориентироваться не на mime type, а на содержимое. Ничего хорошего из этого не вышло. Туда же можно отнести уязвимость с UTF-7.
Вспомните как раньше IE пытался ориентироваться не на mime type, а на содержимое. Ничего хорошего из этого не вышло. Туда же можно отнести уязвимость с UTF-7.
Лучше выдать ошибку, это поможет правильно настроить сервер (указать правильную кодировку в конфиге).
Как это поможет _посетителю_?
_Посетитель_ придет на сайт, разработанный по жестким стандартам и отлаженный на этапе разработки.
Я не имею в виду, что разработчикам ИЕ прямо сейчас надо «дергать рубильник», отключающий самостоятельность поведения. Этот рубильник не надо было трогать еще тогда, в самом начале своего пути.
Я не имею в виду, что разработчикам ИЕ прямо сейчас надо «дергать рубильник», отключающий самостоятельность поведения. Этот рубильник не надо было трогать еще тогда, в самом начале своего пути.
И где бы тогда был Microsoft.
Вообще история веба началась с самовольного впиливания в HTML не включенного в стандарт тега IMG… Правда мелкософт тут не причем.
Другая древняя история с полями в див, когда Microsoft сделали отображение % в дивах как логично, а не как написано. Что весьма доставляло дизайнерам в 6ом эксполрере. А в итоге с 7 эксплорером, где микрософтовцы извинились, покаялись и «сделали всё обратно» куча резинового дизайна «поехало».
Вообще история веба началась с самовольного впиливания в HTML не включенного в стандарт тега IMG… Правда мелкософт тут не причем.
Другая древняя история с полями в див, когда Microsoft сделали отображение % в дивах как логично, а не как написано. Что весьма доставляло дизайнерам в 6ом эксполрере. А в итоге с 7 эксплорером, где микрософтовцы извинились, покаялись и «сделали всё обратно» куча резинового дизайна «поехало».
до посетителя такая ошибка попросу не дойдёт ибо будет замечена гораздо раньше выкладки на продакшен.
Посетитель, ошибки не увидит, её раньше заметит веб-разработчик, погуглит, найдет эту статью и сообщит администратору сервера, что у него не все в порядке с настройками.
Странно, почему программеры на сях, яве и т.д. никогда не парились на тему ошибок из-за собственной криворукости. Есть ошибка — надо править. Задолбали, право слово.
И еще, ИЕ не мягко относился к стандартам, он их прямо нарушал, отсюда ад. А вот добавление еще одного нестандартного алиаса к кодировке ничего плохого не несет в себе. Все браузеры имеют собственные расширения стандартов, и это нормально. Считайте utf8 — проприетарным расширением стандарта. Да, ие не обязан ему следовать, но раз ошибка распространена, то, учитывая это, можно сделать программу более дружественной по отношению к пользователю, который сможет-таки увидеть нужный ему контент.
И еще, ИЕ не мягко относился к стандартам, он их прямо нарушал, отсюда ад. А вот добавление еще одного нестандартного алиаса к кодировке ничего плохого не несет в себе.Конечно, и определение содержимого не по mime type — тоже ничего плохого, правда? Зато пользователю покажем всё как надо.
Вопрос лишь в нарушении стандартов. Если оно есть, значит это плохо. Если нарушения нет, то зависит от надежности алгоритма и качества имплементации. Если сделано качественно, то это только плюс софту.
Отдельно хочу написать слово минусаторам: посетите на досуге вот этот урл: validator.w3.org/check?uri=http%3A%2F%2Fhabrahabr.ru%2Fblogs%2Fwebdev%2F130511%2F&charset=%28detect+automatically%29&doctype=Inline&group=0 (теги у меня не пролезают на хабр, поэтому таким образом размещаю).
Прикиньте, если бы браузер начал брыкаться, метериться и отказался бы в итоге загрузить хабрахабр? Вы бы выкинули его и поставили другой, который был бы не таким капризным к ошибкам, или перестали бы посещать Хабр?
Прикиньте, если бы браузер начал брыкаться, метериться и отказался бы в итоге загрузить хабрахабр? Вы бы выкинули его и поставили другой, который был бы не таким капризным к ошибкам, или перестали бы посещать Хабр?
Хабрапрограммеры исправили бы.
Да это не важно, я не об этом. На хабре куча несоответствий XHTML 1.0 Transitional, но браузеры именно благодаря терпимости к ошибкам отображают сайт без проблем, и почему-то никто не возмущается таким их поведением. А вот поддержка utf8 (вместо utf-8) почему-то определена оппонентами как «зло». Двойные стандарты? :)
IE в данном случае как раз действует ровно в соответствии со стандартными названиями кодировок (http://www.iana.org/assignments/character-sets). См. также статью IE9 Compatibility: Proper Use of the Charset Token от Eric Lawrense
wtf8
Удивительно.
У меня есть сервера которые устанавливались еще в далеком 2008 году. Где кодировка выставлено верно, а именно URF-8.
Хотелось бы узнать в каких дистрибутивах автор нашел подобное неверное обозначение кодировки.
У меня есть сервера которые устанавливались еще в далеком 2008 году. Где кодировка выставлено верно, а именно URF-8.
Хотелось бы узнать в каких дистрибутивах автор нашел подобное неверное обозначение кодировки.
> верно, а именно URF-8.
действительно, не подкопаться.
действительно, не подкопаться.
В смысле «в каких дистрибутивах»? Речь идет о дистрибутивах Linux? они-то тут причем?
Данное поведение имеет место независимо от дистрибутива, и зависит от того, какие настройки прописаны в виртуальных хостах.
Данное поведение имеет место независимо от дистрибутива, и зависит от того, какие настройки прописаны в виртуальных хостах.
Именно. Только если вы возьмете исходники апача вы там уведите верное определение кодировки.
А это означает, что появление НЕВЕРНОГО описания кодировки на совести того кто собирал дистрибутив (из которого взят был пакет), или конфигурировал сам апач в ручную, изменив значение по умолчанию с верного на неверное.
А это означает, что появление НЕВЕРНОГО описания кодировки на совести того кто собирал дистрибутив (из которого взят был пакет), или конфигурировал сам апач в ручную, изменив значение по умолчанию с верного на неверное.
Проблема не в исходниках того или иного веб-сервера, тут исходники вообще не причем. Да и nginx и apache отрабатывают верно — к ним претензий нет. Проблема в том, что люди зачастую в настройках виртуальных хостов сами вручную указывают неверную кодировку, даже не подозревая об этом (просто скопировав откуда-нибудь из примеров, коих бесчисленное множество в интернете, и в последствии при разработке возникают нетривильные ошибки
Простите еще раз. Когда Вы что то ставите из исходников, к ним в обязательном порядке идет и конфиг. Чтобы сделать сейчас неправильно — нужно залезть и исправить с правильного на неправильное.
Вот мне и стало интересно, где кто сто столкнулся с этой абсурдной ситуацией.
Вот мне и стало интересно, где кто сто столкнулся с этой абсурдной ситуацией.
то есть у вы пользуетесь только дефолтными конфигами?
абсолютно не могу такое представить в отношении веб-серверов :)
абсолютно не могу такое представить в отношении веб-серверов :)
Все очень просто: Эникейщик взял, скопипастил, а в конфиги даже не смотрел.
Ненене… кажется, вы неправильно понимаете. Конфиг компиляции — это одно, а конфиг виртуального хоста — это другое. После того как веб-сервер скомпилялся, надо же настроить на какую директорию он будет смотреть, какой хост (домен) цеплять и т.п. И именно за это и отвечает конфиг виртуального хоста. А кодировка по-умолчанию, насколько мне известно, вообще не прописывается даже в тестовых виртуальных хостах.
А вот вам статистика. Я собирал материалы для доклада и пробежал спайдером по 200 тыс. сайтов в рунете. Помимо нужных мне данных собрал и кодировки из заголовков.
И вот, при правильном написании
Более редкие случаи связаны с неправильным аргументом в функции, формирующие заголовок Content-type:
Особо ушлый товарищ выдал такое:
Мол, выбирайте по вкусу.
Короче, итог такой: из всей выборки 2.43% сайтов неправильно отдают charset. Конкретно по utf8 — 0.27% из всех вариантов написания кодировки UTF-8.
И вот, при правильном написании
windows-1251 и UTF-8 мне встретились:win-1251 windows1251 windows_1251 x-cp1251 windows-cp1251 unicode utf8 UTF
Более редкие случаи связаны с неправильным аргументом в функции, формирующие заголовок Content-type:
=utf-8 cp-1251>charset=windows-1251
Особо ушлый товарищ выдал такое:
koi8-r/windows-1251
Мол, выбирайте по вкусу.
Короче, итог такой: из всей выборки 2.43% сайтов неправильно отдают charset. Конкретно по utf8 — 0.27% из всех вариантов написания кодировки UTF-8.
IE также не понимает cp1251 прописанным в htaccess. Как раз на днях столкнулся с этим, вообще никак не хотело реагировать на jQuery, изменил на windows-1251 и все проблемы исчезли
1) Масштабные ошибки в документации встречаются сплошь и рядом. Скажем, вспоминается, что не только в документации (точнее FAQ) nginx, но даже в дефолтном (который идет в комплекте с системой!!!) htaccess, который поставляется в комплекте Drupal — дается некорректный конфиг для SEO-урлов, из-за которого без корректировки не будут работать мультиязычные сайты. Ошибка черте сколько времени кочует туда-обратно…
2) Не надо приставать особо к IE. Он стал жертвой обстоятельств. :-) Впору вообще писать топик про ошибки Файрфокса, некоторые из которых существуют годами и хрен бы кто их исправил… Скажем, попробуйте абсолютно отпозиционировать элемент внутри fieldset с position:relative. Все браузеры, включая IE6, не имеют с этим никаких проблем, а вот FF косячит. Вот буквально на днях вроде наконец поправили и в FF10 все станет нормально… Но, блин, IE6, которому больше 10 лет этого косяка не имеет!
2) Не надо приставать особо к IE. Он стал жертвой обстоятельств. :-) Впору вообще писать топик про ошибки Файрфокса, некоторые из которых существуют годами и хрен бы кто их исправил… Скажем, попробуйте абсолютно отпозиционировать элемент внутри fieldset с position:relative. Все браузеры, включая IE6, не имеют с этим никаких проблем, а вот FF косячит. Вот буквально на днях вроде наконец поправили и в FF10 все станет нормально… Но, блин, IE6, которому больше 10 лет этого косяка не имеет!
IE6 на Windows XP Pro & SP2 тут ни каких кракозябр не показывает (хотя IE ох как любит ставить по дефолту windows-1251). Скажите, дохтур, что я делаю не так?
эм… вот только что проверил на своей виртуалке в IE6 (который ставится по дефолту в WinXP). Бага воспроизводится: bit.ly/r6nWRe. Ну и вот тут можно проверить: ipinfo.info/netrenderer/ через online-эмуляцию IE.
Виртуалки это конечно неплохо, но у меня нативная установка и бага в ней нет. Что лично мне позволяет усомниться в наличие оного. Нам нужен еще один пользователь без виртуалок который может зайти на урл.
Так, проверили на Windows 7 с IE 9.0.8112 и так крокозябры таки да, имеются. Я же на своем 6.0.2900.2180.xpsp_sp2_rtm ни чего подобного не наблюдаю. Учитывая, что это не дефольтный у меня браузер, а чисто для тестов, то и настроек в нем ни когда не подкручивал.
Кстати, добавлю пару замечаний. Во-первых, писать header(Content-Type) в PHP — это быдлокод, надо просто в конфиг PHP вписать default_mimetype и default_charset. Во-вторых, несмотря на то, что кодировка называется utf-8, при работе с MySQL, ее надо писать (в конфиге и в переменных типа SET NAMES) в виде utf8 — как не странно.
А разработчики ИЕ все делают в этот раз правильно.
А разработчики ИЕ все делают в этот раз правильно.
StraNNikk, дай тебя расцелую!!!
Блин, я всю голову сломал с одним проектом, который у меня напрочь отказывался аяксовые запросы делать в IE хрен знает сколько времени убил на то, чтобы найти ошибку.
А тут бац, зашел на хабр, тут статья. Поставил дефис, все заработало! Ну это ппц вообще, я в шоке. :) Еще раз спасибо, жаль кармы нет тебе плюсиков наставить((((
Блин, я всю голову сломал с одним проектом, который у меня напрочь отказывался аяксовые запросы делать в IE хрен знает сколько времени убил на то, чтобы найти ошибку.
А тут бац, зашел на хабр, тут статья. Поставил дефис, все заработало! Ну это ппц вообще, я в шоке. :) Еще раз спасибо, жаль кармы нет тебе плюсиков наставить((((
всегда пожалуйста! ;-) а про плюсики… никакие плюсики не заменят ощущение того, что статья принесла кому-то реальную пользую! ;-)
И от меня спасибо тоже, правда появись эта статья на 3 дня раньше цены б ей небыло. а то какраз эта ошибка вывкакивала, но нарыл уже в других местах.
Еще по дури вылазила у меня ошибка с ajax.response (Firefox, Chrome — нормально работали ) а вот ИЕ в обязательном порядке требовал responseText.
И еще Firefox Chrome нормально отрабатывают такой код:
А ИЕ в этом случае выдает ошибку так как наверное хочет чтоб ему делали таблицу в DOM-е а не на чистом HTML
Еще по дури вылазила у меня ошибка с ajax.response (Firefox, Chrome — нормально работали ) а вот ИЕ в обязательном порядке требовал responseText.
И еще Firefox Chrome нормально отрабатывают такой код:
tbl = document.createElement('table')
tbl.innerHTML = ''
А ИЕ в этом случае выдает ошибку так как наверное хочет чтоб ему делали таблицу в DOM-е а не на чистом HTML
К слову у меня вот это использовалось jqueryui.com/demos/tabs/ и я долго не мог понять почему пример взятый с сайта работает в IE, а после того как я перенес к себе в проект не работает. Оказалось в одном модуле, который вообще не я писал (шаблонизатора) стояло как раз utf8 и никого не трогало, не где не проявлялось, пока я не решил добавить ajax формочек. Вот там-то и всплыл этот баг с IE, при чем ошибка выдавалась стандартная аяксовая, по типу «не могу загрузить и все тут». А из миллиона причин та что с utf8 я бы наверное проверил последней.
Разница между utf-8 и utf8, кстати, не только в контексте браузеров присутствует. В моём любимом языке программирования Perl между ними вообще коренные различия, хотя кто бы ожидал такого от лишнего тире…
Или же использовать в HTML следующий тег:
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
А я-то думал браузеры-то на него давно забили и кодировку выставляют исключительно (кроме случаев ручного выбора) как раз согласно тому, что сообщил сервер в header-е http-ответа. Неужели нет?
ммм… нет. а почему браузеры должны были на него забивать? как раз этот тег позволяет «рулить» кодировками независимо от того, что ответил сервер в заголовках. А если говорить точнее, то значения данного тега имеют наивысший приоритет при выборе заголовков ответа от сервера.
Автор, добавьте, что в MySQL запросах нужно писать utf8, а то щас ломанутся все исправлять свой «set names utf8» на «set names utf-8»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Правильная» utf-8 кодировка в настройках nginx/apache