User-Agent 文字列を一括して理解する必要があったのは、SEO プロジェクト中でした wpadminify.com、サーバーアクセスログを見つめて、トラフィックのどれだけが実際の人々で、どれだけがクローラーであるかを調べようとしています。 すべてはから始まる文字列の列がありました Mozilla/5.0、すべてSafariについて言及し、そのうちの半分は、あるブラウザである一方で、実際には別のブラウザであるという嘘をついていました 目で見て読むのは絶望的でした それがUser-Agentパーサーが行う仕事であり、何度もハードな方法でそれを構築した後 Toolz.dev。これがそれと、その背後にある驚くほど厄介なヘッダーへのガイドです。
tl;dr: ザ ツールツ ユーザーエージェントパーサー user-agent 文字列を取得し、ブラウザ、レンダリング エンジン、オペレーティング システム、デバイスの種類、CPU アーキテクチャに分割します。 header's は検出順序を適用します。 quirks は要求を変化させるため、Chrome やモバイル Safari が実際のバージョン トークンから読み取られるため、Edge は誤読されません。既知のボットにもフラグを立てます。すべてがクライアント側で実行されます。アップロードなし、サインアップなし、実際のログ行に安全です。
User-Agent 文字列とは何ですか?
User-Agent 文字列は、 の値です User-Agent ブラウザまたは HTTP クライアントがほぼすべてのリクエストとともに送信するリクエスト ヘッダー。 でヘッダーが定義されています RFC 9110、HTTPセマンティクス仕様、サーバーが要求を行うソフトウェアを識別できるようにする製品識別子とコメントのシーケンスとして記述します 実際には、ブラウザ、そのバージョン、レンダリングエンジン、オペレーティングシステム、そしてしばしばデバイスに名前を付けます。
その意図は合理的でした。サーバーが応答を適応させたり統計を収集したりできるように、接続しているものを知る方法をサーバーに提供することです。現実には、文字列は Web 上で最も信頼性の低い自己報告データの 1 つになっています。これは、文字列が悪意があるからではなく、20 年にわたる互換性ハッキングにより、明らかな読み取り値が通常間違うまでトークンが重ねられてしまったためです。
Windows上の最新のChrome文字列は次のとおりです:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Mozillaであると主張し、AppleWebKitに言及し、Safariという言葉で終わります。 それはそれらのもののどれも; Chromeです。 以前のすべてのトークン Chrome/126 は歴史的な堆積物である。 parser が存在するのは、最も権威のあるように見えるトークンを信頼できないからにほかならない。
User-Agent の解析がエラーになりやすいのはなぜですか?
ヘッダーは模倣によって成長しました 初期のブラウザ戦争では、サーバーはどのバージョンのページを送信するかを決定するために User-Agent をチェックし、多くの場合単純な部分文字列が一致する不器用にチェックしました 良い最新のページを受け取りたい新しいブラウザには、サーバーが探していたトークンを含める必要があったため、各ブラウザは前の勝者をコピーしました Netscape は自らを Mozilla と名乗っていたため、Internet Explorer は Mozilla 互換であると主張しました WebKit ブラウザが到着すると、Mozilla と KHTML トークンを保持しました Chrome は WebKit からフォークし、WebKit を嗅ぐサーバーが適切に処理できるように AppleWebKit と Safari の両方を保持しました。その結果、単一の文字列に 4 つの異なるブラウザ系統の名前を正直に含めることができます。
これにより、文字列を読む人のための具体的なトラップが作成されます:
- Edge と Opera は両方とも含まれます
Chrome。 Microsoft Edge 追加Edg/126.0.0.0と Opera 付加OPR/、しかし、両方もフル運ぶChrome/126chromium ベースであるためトークン。まず Chrome をテストすると、すべての Edge および Opera ユーザーに Chrome というラベルが付けられます。 - Safari は実際のバージョンを隠します。 デスクトップと iOS では、Safari はユーザー向けバージョンを a で報告します
Version/17.5トークン、一方Safari/604.1末尾近くのトークンはブラウザのバージョンではなく、webkitのビルド番号です。 読むSafari/バージョンとして、意味のない数字が得られます。 - iOS 上の Chrome は Chrome's エンジンではありません。 AppleはWebKitを使用するためにすべてのiOSブラウザを必要とするため、iPhone上のChromeが報告します
CriOSそしてblinkではなくwebkitを実行します。 iOS上のFirefoxはFxiOS、 また WebKit. - 文字列にWindows 11 は存在しません。 MicrosoftはNTカーネルトークンをぶつけたことがないため、Windows 10 とWindows 11 の両方が報告します
Windows NT 10.0.文字列はそれらをまったく区別できません.
パーサーとは、これらのトラップについて知っている順序付けられたルールの小さな山です。実際にはそれだけですが、順序を正しく設定することがゲーム全体です。
Toolz ユーザーエージェントパーサーはどのように動作しますか?
ザ・ パーサ 上のトラップをエンコードする順序の一連のチェックを実行します。それは別のbrowser& #39; sトークンを最初に埋め込むブラウザを探します。 Chromeの前にエッジ, Chromeの前にオペラ, サムスンインターネットとUCブラウザは、Chromeの前に, だから借りた Chrome トークンは偶然に勝つことはありません。 から Safari を読み出します Version/ そのものではなくトークン Safari/ ビルドトークン。 iOS のバリアントを認識します CriOS あんど FxiOS エンジンを WebKit として正しく報告しながら、それぞれ Chrome と Firefox として報告します。
オペレーティング システムの場合、Windows NT カーネル番号をマーケティング名にマッピングします Windows NT 6.1 windows 7 になり、 Windows NT 10.0 文字列が本当にそれらを区別することができないので、ペアとして正直に述べられた、windows 10 または11 になります。 iOSとmacOSバージョンの点線の形式を復元し、ヘッダーがアンダースコアで次のように書き込みます 17_5、android、Chrome OS、Linux を認識します。
デバイスでは、リクエストをデスクトップ、モバイル、タブレット、またはボットとして分類します。タブレットのルールは面倒なものです。iPad はタブレット、Android デバイスのないものです Mobile トークンはタブレットであり、それに一致するものはすべてです Mobile、 iPhone、または Windows Phone は電話機です。文字列が Android ビルド文字列や Apple 製品名などのデバイス モデルを公開すると、パーサーはそれをサーフェスします。
また、ボットにフラグを立てます。これは、アクセス ログを読み取るときに最も役立つ唯一の質問は、トラフィックのどれだけが自動化されているかであるため、私が最も多く到達するフィールドです。パーサーは、検索クローラー、ソーシャル プレビュー フェッチャー、コマンド ライン クライアントをカバーする広範な署名セットに一致します。
ユーザーエージェントは何を教えてくれますか?また、何が教えてくれないでしょうか?
文字列を事実として扱うと誤った決定につながるため、制限については正確に説明する価値があります。
| 質問 | UAはそれに答えることができますか? | 注意事項 |
|---|---|---|
| どのブラウザファミリー | 通常はそうです | 正しい検出順序で |
| 正確なブラウザのバージョン | 通常はそうです | ますます凍結または縮小されます |
| オペレーティングシステムの名前 | 通常はそうです | Windows 10 vs 11 は不可能です |
| デバイスの種類 | ざっくり | ヒューリスティック、保証されていません |
| 正確なデバイスモデル | 時々 | 文字列がそれを含むときのみ |
| クライアントが本物かどうか | いやー | 自明に偽装可能 |
| 画面のサイズまたは機能 | いやー | 代わりに特徴検出を使用します |
最後の2 行が最も重要です ユーザーエージェントは自己報告で、1 行のコードで変更したり、任意のHTTPクライアントで設定したり、ブラウザでフリーズしてプライバシーを確保したりできます スクレーパーはWindowsでChromeであることをアナウンスでき、文字列には矛盾するものは何もありません そのため、解析された結果はクライアントが主張するものを教えてくれます これは統計やデバッグには役立ちますが、何も証明するものではありません ブラウザが実際に何ができるかを知る必要がある場合、名前から機能を推測するのではなく、JavaScriptで機能を検出するという回復力のあるフロントエンドコードを記述する背後にあるのと同じ原理です Web 開発者ツールキット ラウンドアップは繰り返しに戻ります.
User-Agent 文字列は消えていますか?
正確ではありませんが、意図的に削減されています Chromiumブラウザは、レガシー文字列を数年間フリーズおよびトリミングし、公開される詳細レベル、特にマイナーバージョン番号といくつかのプラットフォーム詳細を上限として、置き換えられています ユーザーエージェントクライアントのヒント、サーバーが必要なクライアント情報の部分を正確に要求するメカニズム Sec-CH-UA ヘッダーをリクエストします navigator.userAgentData JavaScript API, むしろ、1 つの長い文字列を受信するそれは解析する必要があります。 クライアントヒントはまた、Windows 10 対 11 の区別が最終的に利用可能になる場所, を通じて Sec-CH-UA-Platform-Version。
今後数年間の実際的な結果は、両方が存在することです。古典 User-Agent header still shipped on every request from every browser and every non-browser client, and a great deal of tooling, analytics, and server-side logic still reads it.したがって、文字列を解析することは、クライアントを特定するための最もポータブルな方法であり、より豊富なデータがClient Hintsに移動しても、新しいものを構築していて、プラットフォームのバージョンを正確にしたい場合は、Client Hints; を読みます 既存のログを分析しているか、最も幅広いクライアントをサポートしている場合は、文字列を解析します。
パーサーはどのように使うのですか?
フローは意図的にシンプルです ボックスに User-Agent 文字列を貼り付けるか、組み込みサンプルのいずれかをクリックして、代表的なデスクトップ、モバイル、またはボットの文字列を表示します 自分のものをつかむには、ブラウザコンソールを開いて入力します navigator.userAgent、そして結果を貼り付けます。 、入力すると、ブラウザ、エンジン、オペレーティングシステム、デバイスの種類、CPUアーキテクチャ、およびボットフラグがライブで更新され、押すボタンがありません。結果を他の場所にしたい場合は、スプレッドシートまたはバグレポートにきれいに貼り付けるタブ区切りのテーブルとしてコピーします。
全体がブラウザで実行されるため、生のアクセスログ行または実際の訪問者文字列を、マシンから離れることなく貼り付けることができます。そのクライアント側モデルは意図的であり、サイト上のすべてのツールの背後にあるものと同じです。 で説明されています データプライバシー オンラインツール ガイド。リクエストと並行してデバッグしている資格情報については、 基本的なauthジェネレータ そして、 JWT デコーダ 同じアップロードなしアプローチに従ってください。
パーサーが他の Web ツールと適合する場所
ユーザー エージェント パーサーは、サイト上のリクエスト アンド レスポンス ツールの小さなクラスターに配置されます。ドメインへのトラフィックを検査するとき、 ドメイン検索 ツールは、誰が所有し、操作しているかを回答します。 リクエストに、検査する必要があるベアラー トークンが含まれている場合、 JWT デコーダ そこからクレームを読み出します。そもそも認証されたリクエストを構築しているとき、 基本的なauthジェネレータ を構築します Authorization ヘッダー。そして、ページがクローラーにどのように表示されるかを作業しているとき、クローラーは独自の User-Agents の下でページを読みます メタタグジェネレータ 彼らが消費するタグを形作ります。
これらの個人的なセットを組み立てる人のために、 開発者の生産性向上ツール このガイドでは、サイト上のブラウザベースのユーティリティが営業日にどのように適合するかを説明します。これらをまとめておくポイントは、HTTP インタラクションのデバッグにこれらの質問の 1 つだけが含まれることはほとんどないということです。
実践的なワークフロー: トラフィック ログの読み取り
この道を進むきっかけとなったタスクでこれを具体化させてください アクセスログのスライスをエクスポートして 理解したいのです 素朴なアプローチは ユーザーエージェント欄を目視することです まさにトラップが噛みつく場所として 丁寧に識別するクローラーです Googlebot 簡単ですが、通常の Chrome ビルドであることをアナウンスするヘッドレス スクレーパーは、他の信号を確認するまでは実際の訪問者と同じように見えます。
パーサーは2 つの方法で役立ちます まず、ボットフラグが正直なクローラーと一般的な自動化クライアントをすぐにキャッチするため、明らかなマシントラフィックを1 回のパスで人間のトラフィックから分離できます 次に、残りのトラフィックの正しいブラウザとOSの内訳は、オーディエンスについて何か本当のことを教えてくれます: モバイルを歪めるかどうか、どのオペレーティングシステムが支配しているか、古いブラウザがまだテストするのに十分なほど重要であるかどうか WP Adminifyの作業では、その内訳はテストに優先したブラウザを変更し、オーガニックトラフィックのように見えるもののチャンクがリーダーではなくプレビューと監視ボットであることを確認しました文字列を解析すると、ノイズの壁が決定に変わりました。
守るべき規律は 1 つ、「限界」セクションからの規律です。解析された結果は証明ではなく主張です。決定されたスクレーパーは説得力のある文字列を偽造します。どのパーサーもそれを User-Agent だけでキャッチすることはできません。リスクが高い場合は、解析をリクエスト パターン、レート、その他の信号と組み合わせます。ただし、日常の統計やデバッグでは、正しい解析がまさに必要なことであり、それを手作業で行うのは間違いです。
レンダリングエンジンとCPUフィールドは何を教えてくれますか?
解析されたフィールドのうち2 つはブラウザやOSよりも注目されないが、どちらも有用である レンダリングエンジンは実際にHTMLとCSSをピクセルにするコンポーネントであり、ページの動作をブラウザ名よりも予測するのに優れている Chrome、Edge、Opera、Brave、Samsung Internet、その他ほとんどのコンポーネントはBlinkエンジンを共有しているため、通常、1 つに表示されるレンダリングバグがそれらのすべてに表示されます; FirefoxはGeckoを使用します; そしてSafariは、iOS上のすべてのブラウザとともに、WebKitレイアウトのバグをトリアージしているときに、ブラウザ名ではなくエンジンでトラフィックをグループ化すると、テストする必要がある真に異なるレンダリングパスの数がわかりますが、これは多くの場合わずか3 つです。
このパーサーは、ブラウザのラベルではなくプラットフォームのトークンからエンジンを派生させているため、どちらも同じ AppleWebKit トークンの子孫であるにもかかわらず、Chromium ブラウザ用の Blink と Safari 用の WebKit をレポートできるだけでなく、古いエンジンである Internet Explorer 用の Trident と従来の Edge 用の EdgeHTML もキャッチします。これらは依然としてエンタープライズ ログに表示されます。
CPU アーキテクチャ フィールドは、プラットフォーム トークンを読み取ります x86_64、 Win64、 arm64、およびそれらの親戚、クライアントが64 ビット、32 ビット、またはARMマシンであるかどうかを報告する これは、プラットフォーム固有のダウンロードを提供するときにチェックするフィールドであり、訪問者が実行できるビルドを知る必要があり、それはあなたの聴衆& #39; sハードウェアがどれほど現代的であるかの静かなシグナルです。
よくある質問
User-Agent 文字列とは何ですか? User-Agent 文字列は、ブラウザまたはクライアントが各リクエストで送信する User-Agent HTTP ヘッダーの値です。これは、RFC 9110 で定義されている、ブラウザ、そのレンダリング エンジン、オペレーティング システム、および多くの場合デバイスに名前を付ける製品トークンのリストです。サーバーはそれを読み取り、接続しているソフトウェアを識別します。
自分のユーザーエージェントを見つけるにはどうすればよいですか? browser' s developer console を開き、navigator.userAgent と入力し、Enter キーを押します。出力される文字列は、ブラウザがサーバーに送信するものとまったく同じです。 user agent パーサーに貼り付けて、デコードするブラウザ、オペレーティング システム、デバイスを確認します。
Chrome' s User-AgentにSafariという単語が含まれているのはなぜですか? 下位互換性のために。 chrome はエンジンを Apple's WebKit からフォークし、初期のサーバーは最新のページを提供する前に Safari トークンをチェックしたため、Chrome はダウングレードを避けるためにトークンを保持しました。同じ歴史があるため、ほぼすべてのブラウザは依然として Mozilla/5.0 で文字列を開始しています。
ユーザーエージェントは Windows 10 と Windows 11 を区別できますか? いいえ どちらも Windows NT 10.0 を報告しています。これは、Microsoft が Windows 11 用の NT カーネル トークンをインクリメントしたことがないため、文字列だけでは 2 つを区別できないためです。それらを区別する最新の方法は、ユーザー エージェント クライアント ヒント、特に Sec-CH-UA-Platform-Version ヘッダーです。
User-Agent はデバイスを識別するのに信頼できますか? 証明ではなく、有用なヒントです User-Agents は、1 行のコードで変更したり、任意の HTTP クライアントで設定したり、スクレーパーで偽装したり、ブラウザでフリーズしてプライバシーを確保したり、解析された結果をクライアントが主張する内容として扱い、精度が重要な場合は他の信号と組み合わせたりできます。
パーサーはボットとクローラーをどのように検出しますか? これは、Googlebot や Bingbot などの検索クローラー、ソーシャル プレビュー フェッチャー、curl、wget、headless Chrome などの自動化クライアントなど、既知の署名の広範なリストと文字列を照合します。一致するとボット フラグが設定され、デバイスがクローラーとして分類されます。
ここに生産ログ User-Agents を貼り付けるのは安全ですか? はい.JavaScript を使用すると、すべての解析がブラウザで実行され、文字列がどのサーバーにも送信されることはありません。生のアクセスログ行や実際の訪問者ユーザーエージェントをデバイスから削除せずに貼り付けることができます。
User-Agent 文字列は非推奨ですか? ヘッダーは削除されず、フリーズおよび縮小されています。 Chromium ブラウザーは、従来の文字列の詳細に上限を設け、代わりに User-Agent クライアント ヒントを通じてより豊富なデータを公開するようになりました。クラシックな文字列は依然としてすべてのリクエストに出荷されるため、解析することがクライアントの詳細を読み取る最もポータブルな方法であることに変わりはありません。
