Комментарии 72
Так вот оно что) Оказывается не во всех грехах виноват IE)
+34
НЛО прилетело и опубликовало эту надпись здесь
Лояльность в отношении трактовки стандартов ни к чему хорошему, как правило, не приводит ;)
+47
Да? Т.е. надо сразу после встретившейся ошибки упасть на бок или выдать грозное сообщение, которое простому пользователю ни о чем не говорит? Есть известные распространенные ошибки, и хороший браузер должен как можно более прозрачно для пользователя постараться их исправить. Да, в какой-то мере это способствует распространению этих ошибок. Но с другой стороны пользователь не имеет возможности повлиять на содержимое/настройки посещаемого сайта/сервера. А посему лично я бы предпочел тот браузер, который корректно отобразит наибольшее количество страниц, несмотря на ошибки в них.
+4
Кстати, разработчики стандартов сами ошибки допускают, которые потом вынужденно копируются теми, кто по этому стандарту работает. Яркий тому пример поле referer при том, что правильно было бы referrer.
+2
Раньше IE много ругали за то, что он слишком мягко относится к стандартам, сейчас ругают за то, что следует им. Не угодишь.
+22
то что он совсем не следует одним стандартам не противоречит тому, что он слишком строго следит за другими :)
+3
Я ИЕ в данном случае не ругаю, что вы. Я говорю, что из двух браузеров я выберу тот, который лучше отобразит ошибочные страницы.
-2
IE ровно поэтому и мягко относился к стандартам. Но сейчас важно им следовать. Слишком быстро веб прошлого превратился в ад из-за такого отношения.
+3
Ответьте на простой вопрос: что лучше — выдать ошибку, с которой посетитель сайта ничего не может поделать, т.к. не контролирует посещаемый ресурс, или попытаться отобразить по какой-то определенной логике?
Я не говорю о том, что надо нарушать стандарты стандарты, я говорю о том, что надо гибко обходить ошибки. Пользователь прежде всего!
Я вам приведу такой пример отвлеченный, чтобы легче было ответить: попадается вам битый архив (или упакованный с нарушением стандарта). Какая реализация архиватора будет лучше: та, которая попытается распаковать архив или та, которая выдаст кучу матюков и пошлет пользователя куда подальше?
Я не говорю о том, что надо нарушать стандарты стандарты, я говорю о том, что надо гибко обходить ошибки. Пользователь прежде всего!
Я вам приведу такой пример отвлеченный, чтобы легче было ответить: попадается вам битый архив (или упакованный с нарушением стандарта). Какая реализация архиватора будет лучше: та, которая попытается распаковать архив или та, которая выдаст кучу матюков и пошлет пользователя куда подальше?
-2
Отвечаю: лучше следовать стандарту.
Вспомните как раньше IE пытался ориентироваться не на mime type, а на содержимое. Ничего хорошего из этого не вышло. Туда же можно отнести уязвимость с UTF-7.
Вспомните как раньше IE пытался ориентироваться не на mime type, а на содержимое. Ничего хорошего из этого не вышло. Туда же можно отнести уязвимость с UTF-7.
+4
Лучше выдать ошибку, это поможет правильно настроить сервер (указать правильную кодировку в конфиге).
+1
Как это поможет _посетителю_?
0
НЛО прилетело и опубликовало эту надпись здесь
_Посетитель_ придет на сайт, разработанный по жестким стандартам и отлаженный на этапе разработки.
Я не имею в виду, что разработчикам ИЕ прямо сейчас надо «дергать рубильник», отключающий самостоятельность поведения. Этот рубильник не надо было трогать еще тогда, в самом начале своего пути.
Я не имею в виду, что разработчикам ИЕ прямо сейчас надо «дергать рубильник», отключающий самостоятельность поведения. Этот рубильник не надо было трогать еще тогда, в самом начале своего пути.
0
И где бы тогда был Microsoft.
Вообще история веба началась с самовольного впиливания в HTML не включенного в стандарт тега IMG… Правда мелкософт тут не причем.
Другая древняя история с полями в див, когда Microsoft сделали отображение % в дивах как логично, а не как написано. Что весьма доставляло дизайнерам в 6ом эксполрере. А в итоге с 7 эксплорером, где микрософтовцы извинились, покаялись и «сделали всё обратно» куча резинового дизайна «поехало».
Вообще история веба началась с самовольного впиливания в HTML не включенного в стандарт тега IMG… Правда мелкософт тут не причем.
Другая древняя история с полями в див, когда Microsoft сделали отображение % в дивах как логично, а не как написано. Что весьма доставляло дизайнерам в 6ом эксполрере. А в итоге с 7 эксплорером, где микрософтовцы извинились, покаялись и «сделали всё обратно» куча резинового дизайна «поехало».
0
до посетителя такая ошибка попросу не дойдёт ибо будет замечена гораздо раньше выкладки на продакшен.
+1
Посетитель, ошибки не увидит, её раньше заметит веб-разработчик, погуглит, найдет эту статью и сообщит администратору сервера, что у него не все в порядке с настройками.
0
Странно, почему программеры на сях, яве и т.д. никогда не парились на тему ошибок из-за собственной криворукости. Есть ошибка — надо править. Задолбали, право слово.
+1
И еще, ИЕ не мягко относился к стандартам, он их прямо нарушал, отсюда ад. А вот добавление еще одного нестандартного алиаса к кодировке ничего плохого не несет в себе. Все браузеры имеют собственные расширения стандартов, и это нормально. Считайте utf8 — проприетарным расширением стандарта. Да, ие не обязан ему следовать, но раз ошибка распространена, то, учитывая это, можно сделать программу более дружественной по отношению к пользователю, который сможет-таки увидеть нужный ему контент.
-2
И еще, ИЕ не мягко относился к стандартам, он их прямо нарушал, отсюда ад. А вот добавление еще одного нестандартного алиаса к кодировке ничего плохого не несет в себе.Конечно, и определение содержимого не по mime type — тоже ничего плохого, правда? Зато пользователю покажем всё как надо.
+2
Вопрос лишь в нарушении стандартов. Если оно есть, значит это плохо. Если нарушения нет, то зависит от надежности алгоритма и качества имплементации. Если сделано качественно, то это только плюс софту.
0
Отдельно хочу написать слово минусаторам: посетите на досуге вот этот урл: validator.w3.org/check?uri=http%3A%2F%2Fhabrahabr.ru%2Fblogs%2Fwebdev%2F130511%2F&charset=%28detect+automatically%29&doctype=Inline&group=0 (теги у меня не пролезают на хабр, поэтому таким образом размещаю).
Прикиньте, если бы браузер начал брыкаться, метериться и отказался бы в итоге загрузить хабрахабр? Вы бы выкинули его и поставили другой, который был бы не таким капризным к ошибкам, или перестали бы посещать Хабр?
Прикиньте, если бы браузер начал брыкаться, метериться и отказался бы в итоге загрузить хабрахабр? Вы бы выкинули его и поставили другой, который был бы не таким капризным к ошибкам, или перестали бы посещать Хабр?
0
Хабрапрограммеры исправили бы.
+3
Да это не важно, я не об этом. На хабре куча несоответствий XHTML 1.0 Transitional, но браузеры именно благодаря терпимости к ошибкам отображают сайт без проблем, и почему-то никто не возмущается таким их поведением. А вот поддержка utf8 (вместо utf-8) почему-то определена оппонентами как «зло». Двойные стандарты? :)
0
НЛО прилетело и опубликовало эту надпись здесь
IE в данном случае как раз действует ровно в соответствии со стандартными названиями кодировок (http://www.iana.org/assignments/character-sets). См. также статью IE9 Compatibility: Proper Use of the Charset Token от Eric Lawrense
+5
wtf8
+24
Удивительно.
У меня есть сервера которые устанавливались еще в далеком 2008 году. Где кодировка выставлено верно, а именно URF-8.
Хотелось бы узнать в каких дистрибутивах автор нашел подобное неверное обозначение кодировки.
У меня есть сервера которые устанавливались еще в далеком 2008 году. Где кодировка выставлено верно, а именно URF-8.
Хотелось бы узнать в каких дистрибутивах автор нашел подобное неверное обозначение кодировки.
-3
> верно, а именно URF-8.
действительно, не подкопаться.
действительно, не подкопаться.
+29
Объясните, это шутка юмора такая?
Я уже начал думать, что у меня сильные пробелы в знаниях, Гугл уверено предлагает поискать про UTF-8.
Я уже начал думать, что у меня сильные пробелы в знаниях, Гугл уверено предлагает поискать про UTF-8.
-11
Дайте пожалуйста ссылку на URF-8 — я совершенно серьёзно не смог найти, запрос предлагают сменить на UTF-8 и всё.
0
В смысле «в каких дистрибутивах»? Речь идет о дистрибутивах Linux? они-то тут причем?
Данное поведение имеет место независимо от дистрибутива, и зависит от того, какие настройки прописаны в виртуальных хостах.
Данное поведение имеет место независимо от дистрибутива, и зависит от того, какие настройки прописаны в виртуальных хостах.
+1
Именно. Только если вы возьмете исходники апача вы там уведите верное определение кодировки.
А это означает, что появление НЕВЕРНОГО описания кодировки на совести того кто собирал дистрибутив (из которого взят был пакет), или конфигурировал сам апач в ручную, изменив значение по умолчанию с верного на неверное.
А это означает, что появление НЕВЕРНОГО описания кодировки на совести того кто собирал дистрибутив (из которого взят был пакет), или конфигурировал сам апач в ручную, изменив значение по умолчанию с верного на неверное.
0
Проблема не в исходниках того или иного веб-сервера, тут исходники вообще не причем. Да и nginx и apache отрабатывают верно — к ним претензий нет. Проблема в том, что люди зачастую в настройках виртуальных хостов сами вручную указывают неверную кодировку, даже не подозревая об этом (просто скопировав откуда-нибудь из примеров, коих бесчисленное множество в интернете, и в последствии при разработке возникают нетривильные ошибки
0
Простите еще раз. Когда Вы что то ставите из исходников, к ним в обязательном порядке идет и конфиг. Чтобы сделать сейчас неправильно — нужно залезть и исправить с правильного на неправильное.
Вот мне и стало интересно, где кто сто столкнулся с этой абсурдной ситуацией.
Вот мне и стало интересно, где кто сто столкнулся с этой абсурдной ситуацией.
-4
то есть у вы пользуетесь только дефолтными конфигами?
абсолютно не могу такое представить в отношении веб-серверов :)
абсолютно не могу такое представить в отношении веб-серверов :)
0
Все очень просто: Эникейщик взял, скопипастил, а в конфиги даже не смотрел.
0
Ненене… кажется, вы неправильно понимаете. Конфиг компиляции — это одно, а конфиг виртуального хоста — это другое. После того как веб-сервер скомпилялся, надо же настроить на какую директорию он будет смотреть, какой хост (домен) цеплять и т.п. И именно за это и отвечает конфиг виртуального хоста. А кодировка по-умолчанию, насколько мне известно, вообще не прописывается даже в тестовых виртуальных хостах.
0
А вот вам статистика. Я собирал материалы для доклада и пробежал спайдером по 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.
0
НЛО прилетело и опубликовало эту надпись здесь
IE также не понимает cp1251 прописанным в htaccess. Как раз на днях столкнулся с этим, вообще никак не хотело реагировать на jQuery, изменил на windows-1251 и все проблемы исчезли
0
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 лет этого косяка не имеет!
+3
эм… вот только что проверил на своей виртуалке в IE6 (который ставится по дефолту в WinXP). Бага воспроизводится: bit.ly/r6nWRe. Ну и вот тут можно проверить: ipinfo.info/netrenderer/ через online-эмуляцию IE.
0
Виртуалки это конечно неплохо, но у меня нативная установка и бага в ней нет. Что лично мне позволяет усомниться в наличие оного. Нам нужен еще один пользователь без виртуалок который может зайти на урл.
0
Так, проверили на Windows 7 с IE 9.0.8112 и так крокозябры таки да, имеются. Я же на своем 6.0.2900.2180.xpsp_sp2_rtm ни чего подобного не наблюдаю. Учитывая, что это не дефольтный у меня браузер, а чисто для тестов, то и настроек в нем ни когда не подкручивал.
0
Кстати, добавлю пару замечаний. Во-первых, писать header(Content-Type) в PHP — это быдлокод, надо просто в конфиг PHP вписать default_mimetype и default_charset. Во-вторых, несмотря на то, что кодировка называется utf-8, при работе с MySQL, ее надо писать (в конфиге и в переменных типа SET NAMES) в виде utf8 — как не странно.
А разработчики ИЕ все делают в этот раз правильно.
А разработчики ИЕ все делают в этот раз правильно.
+3
StraNNikk, дай тебя расцелую!!!
Блин, я всю голову сломал с одним проектом, который у меня напрочь отказывался аяксовые запросы делать в IE хрен знает сколько времени убил на то, чтобы найти ошибку.
А тут бац, зашел на хабр, тут статья. Поставил дефис, все заработало! Ну это ппц вообще, я в шоке. :) Еще раз спасибо, жаль кармы нет тебе плюсиков наставить((((
Блин, я всю голову сломал с одним проектом, который у меня напрочь отказывался аяксовые запросы делать в IE хрен знает сколько времени убил на то, чтобы найти ошибку.
А тут бац, зашел на хабр, тут статья. Поставил дефис, все заработало! Ну это ппц вообще, я в шоке. :) Еще раз спасибо, жаль кармы нет тебе плюсиков наставить((((
+10
всегда пожалуйста! ;-) а про плюсики… никакие плюсики не заменят ощущение того, что статья принесла кому-то реальную пользую! ;-)
+3
И от меня спасибо тоже, правда появись эта статья на 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
0
К слову у меня вот это использовалось jqueryui.com/demos/tabs/ и я долго не мог понять почему пример взятый с сайта работает в IE, а после того как я перенес к себе в проект не работает. Оказалось в одном модуле, который вообще не я писал (шаблонизатора) стояло как раз utf8 и никого не трогало, не где не проявлялось, пока я не решил добавить ajax формочек. Вот там-то и всплыл этот баг с IE, при чем ошибка выдавалась стандартная аяксовая, по типу «не могу загрузить и все тут». А из миллиона причин та что с utf8 я бы наверное проверил последней.
0
Разница между utf-8 и utf8, кстати, не только в контексте браузеров присутствует. В моём любимом языке программирования Perl между ними вообще коренные различия, хотя кто бы ожидал такого от лишнего тире…
0
Или же использовать в HTML следующий тег:
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
А я-то думал браузеры-то на него давно забили и кодировку выставляют исключительно (кроме случаев ручного выбора) как раз согласно тому, что сообщил сервер в header-е http-ответа. Неужели нет?
0
ммм… нет. а почему браузеры должны были на него забивать? как раз этот тег позволяет «рулить» кодировками независимо от того, что ответил сервер в заголовках. А если говорить точнее, то значения данного тега имеют наивысший приоритет при выборе заголовков ответа от сервера.
-1
значения данного тега имеют наивысший приоритет
Что-то не замечал, вроде на практике получалось наоборот. Спасибо, полезно знать. Поэкспериментирую.
+1
Наивысший приоритет имеет заголовок СЕРВЕРА. На HTML тег браузер смотрит только если сервер ничего ему не выдает.
+1
НЛО прилетело и опубликовало эту надпись здесь
Автор, добавьте, что в MySQL запросах нужно писать utf8, а то щас ломанутся все исправлять свой «set names utf8» на «set names utf-8»
0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
«Правильная» utf-8 кодировка в настройках nginx/apache