Каковы средства, выгода и различия между обнаружением пользовательского агента и обнаружением функций?

#javascript #css #html #mobile-website

#javascript #css #HTML #мобильный веб-сайт

Вопрос:

Каковы средства, выгода и различия между обнаружением пользовательского агента и обнаружением функций? и какой из них лучше?

И, пожалуйста, приведите примеры использования для обоих.

Ответ №1:

Основная причина использования обнаружения функций в отличие от прослушивания пользовательского агента — это проверка на будущее.

Допустим, например, что вы хотите использовать некоторые новые функции XMLHttpRequest 2.0 (просто придумывая это). Вы знаете, что IE не поддерживает это, но Firefox поддерживает, и поэтому у вас есть подобный код в вашем JS:

 if (!IE) {
    UseNewAjax();
} else {
    UseOldAjax();
}
  

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

С другой стороны, если вы обнаруживаете функции:

 if (document.hasCoolNewAjax) {
    UseNewAjax();
} else {
    UseOldAjax();
}
  

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

Отслеживание браузера / пользовательского агента: использование языка программирования для определения того, какой браузер использует посетитель, поэтому для этого браузера может быть написана специальная логика. Неэффективно и считается плохой практикой в сообществе разработчиков.

Обнаружение функций: использование языка программирования для определения, поддерживает ли браузер определенную функцию. Считается лучшей практикой в сообществе разработчиков, потому что она надежна и рассчитана на будущее.

Из Википедии:

Прослушивание пользовательского агента в основном считается плохой практикой, поскольку оно поощряет дизайн, специфичный для браузера, и наказывает новые браузеры за непризнанные идентификаторы пользовательского агента. Вместо этого W3C рекомендует создавать стандартную HTML-разметку, позволяющую корректно отображать как можно больше браузеров, и тестировать конкретные функции браузера, а не конкретные версии браузера или бренды.

JavaScript — не единственный язык, с помощью которого вы можете отслеживать пользовательский агент или обнаруживать функции. Например, .NET framework обладает свойствами, которые позволяют считывать всевозможную информацию о браузере:

http://msdn.microsoft.com/en-us/library/3yekbd5b.aspx

http://modernizr.com

Комментарии:

1. Эли — Не могли бы вы, пожалуйста, объяснить оба термина простым способом?

2. Особенно в случае IE, не будет ли обнаружение пользовательского агента также включать определение версии? Если это так, не будет ли справедливо сказать, что функции не изменятся в одной и той же версии браузера?

3. Это возможно, но зачем рисковать, когда вы могли бы закодировать это один раз одним способом и заставить это всегда работать?

4. @Eli — и возможно ли обнаружение функций только на стороне клиента (Javascript)?

5. Я не слишком подробно изучал это, но вот кое-что интересное: tripleodeon.com/2010/10/modernizr-on-the-server-side

Ответ №2:

Обнаружение функций всегда лучше, чем обнаружение пользовательского агента, потому что пользователи могут подделать свою строку пользовательского агента, поэтому она ненадежна.

Комментарии:

1. users can spoof their user agent string не могли бы вы объяснить это, пожалуйста?

2. но user agent switcher предназначен для разработчиков, а не для обычных пользователей

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

4. @Wesley Существуют отдельные проблемы. Все три являются плохими практиками (прослушивание UA, не поддержка не-JS и не защита от SQL-инъекций). Там все плохо по тем же причинам

5. @JitendraVyas ;_; обнаружение UA на стороне сервера — это дьявол. Не отправляйте своему клиенту другой контент, основанный на том, кем, по вашему мнению, он является. Отправьте то, что было запрошено.

Ответ №3:

Помимо других очень веских причин, приведенных в других ответах, вот некоторый псевдокод, дающий другой пример:

  if (new_feature_available)
 {
    use_new_feature();
 }
 else
 {
    use_old_feature();
 }
  

против:

 // We had to look up what features are available in each to make this list
// There are probably browsers we're missing here as well...
// TODO: Make this list really big and include all known browsers
// TODO: Double check that this feature is not supported in listed browsers

 if (
         browser not IE5, IE6, IE7, Opera8, Firefox1.8, Seamonkey,
         OR browser is Chrome10, Firefox4, IE9
     )
 {
    use_new_feature();
 }
 else
 {
    use_old_feature();
 }
  

Видя это, разве обнаружение функций не имеет больше смысла?

Комментарии:

1. но я думал, что обнаружение функций усложнит код, потому что весь код будет находиться в одном файле для old и new feature , в то время как в UA detection мы можем хранить содержимое в отдельных файлах и доставлять в определенные браузеры.

2. @JitendraVyas: Это зависит, ваш вопрос очень обобщенный. Это (обнаружение функций) в основном то, что jQuery делает для многих функций. api.jquery.com/jQuery.support

Ответ №4:

Отслеживание браузера ненадежно и его трудно поддерживать.

Это ненадежно, потому что:

  • подмена пользовательского агента может превратить iPad в настольный компьютер под управлением IE6 и наоборот
  • связь между версией пользовательского агента / версией ОС / версией движка JS очень низкая, если не совсем отсутствует

Это сложно поддерживать, потому что:

  • пользовательские агенты постоянно развиваются, заставляя вас разветвляться, разветвляться и разветвляться
  • ваш код тесно связан с конкретными браузерами / движком, что приводит к множеству компромиссов и обходных путей
  • ваш код в основном основан на предположениях и, следовательно, очень хрупок

Обнаружение функций упрощает и очищает код. Указанный код — в некотором смысле — абстрагирован от браузеров и почти полностью рассчитан на будущее.

Комментарии:

1. но я думал, что обнаружение функций усложнит код, потому что весь код будет находиться в одном файле для старой и новой функции, в то время как в UA detection мы можем хранить содержимое в отдельных файлах и доставлять в определенные браузеры.

2. @Vyas Насколько мне известно, единственный (на стороне клиента) способ указать разные файлы для разных браузеров — это использовать условные комментарии, и это работает только для Internet Explorer. В любом случае, желание избежать «тяжелого кода» не является оправданием неаккуратного кода, а обнаружение пользовательского агента неаккуратно.

3. @Vyas — Обнаружение функций усложняет ваш код, если ваш проект сильно зависит от новейших функций, доступных в новейшем движке JS, и вы хотите сделать его обратно совместимым. При такой стратегии ваш проект развалится и станет кошмаром в обслуживании. Если вы используете в основном обычные материалы, у вас будет обнаружение функций только в нескольких обобщенных местах, таких как менеджер событий и метод ajax или что-то в этом роде. Ваш код будет чистым, эффективным и рассчитанным на будущее. Наличие всего этого в одном файле не имеет никакого значения.