開發者工具 · URL 編碼器和解碼器
為什麼不一致的 URL 編碼會在分析中將一頁拆分為多行
· 為什麼它很重要
分析 url 編碼 標準化
%20 和 +、%2F 和 /, %c3 和 %C3 都可以描述相同的 URL，但報告將它們視為不同的頁面。這篇文章解釋了變異的來源以及如何在計數之前對它們進行標準化。
報告中包含六個 URL 的登陸頁 — 並排的變體及其分配的流量
資料分析師注意到一個登陸頁面在分析儀表板中顯示為六個不同的 URL。相同的頁面可以： /landing?utm_source=email, /landing?utm_source=%65mail, /landing?utm_source=email%20campaign, /landing?utm_source=email+campaign, /landing?utm_source=email%20Campaign, /landing?utm_source=email%2bcampaign. 每個變體都算作單獨的頁面視圖，從而對流量進行碎片化。來自電子表格、電子郵件和表單的資料引入了編碼變更。
不一致的編碼源自於多個資料來源和轉換。手寫連結使用原始空格或不使用編碼。電子表格匯出會產生百分比編碼的 URL。電子郵件用戶端會破壞或重新編碼 URL。重定向鏈標準化不一致。 API 整合、JavaScript 框架和分析程式碼應用不同的規則。相同的 URL 概念會經過各層，以不同的方式進行編碼和重新編碼。
變更的來源 — 手寫連結、電子表格匯出、郵件用戶端與重新導向鏈
十六進位數字表示第一個標準化問題。 RFC 3986 指定十六進位數字應為大寫：%2F，而非 %2f。大寫和小寫十六進制編碼相同的位元組。嚴格比較以不同方式對待 %2F 和 %2f。作為 %65 的字元“e”應規範化為未編碼的“e”，因為 RFC 3986 將字母分類為未保留。對整個 URL 進行過度編碼會產生不同的分析記錄。
RFC 3986 中的非保留集合包括：A-Z、a-z、0-9、連字符、句點、底線和波形符。這些不應在規範化 URL 中進行百分比編碼。 RFC 規範化指定 %41 解碼為「A」應規範為未編碼的「A」。跨 URL 應用此功能可以消除冗餘編碼。像是 %2f%6c%61%6e%64%69%6e%67 這樣的 URL 解碼後會變成 /landing 。
十六進位數字與未保留集合的大小寫 — RFC 3986 說的是等價的，什麼不是
保留字元不可互換，且在規範化過程中必須保持不同。 RFC 3986 保留產生分隔符號 (:, /, ?, #, [, ], @) 與子分隔符號 (!, $, &, ', (, ), *, +, ,, ;, =)。這些都有結構意義。路徑中的正斜線充當分隔符，不應進行編碼。當相同字元作為查詢值中的資料出現時，應編碼為 %2F。盲目解碼會破壞 URL 結構。
標準化的細微差別帶來了需要上下文理解的挑戰。僅解碼非保留字符，保留編碼的保留字符。像 /landing?data=%2F%20%2f 這樣的 URL 仍然不清楚。查詢字串以 ? 開頭（保留，結構）。在查詢值中，任何內容都可以出現 - 問號需要 %3F 編碼。編碼為 %2f%6c%61%6e%64%69%6e%67%3fkey%3dvalue 的 URL 標準化為 /landing?key=value.
保留字元不可互換 - 為什麼 %2F 和 / 可以合法地表示不同的意義
工作範例：規範化六個 URL 變體演示了完全規範化。基本 URL 表示 /page?utm_source=email&campaign=test。六個變體：1) /page?utm_source=email&campaign=test (規範), 2) /page?utm_source=%65%6d%61%69%6c&campaign=test (小寫十六進位), 3) /page?utm_sourcecamp=eign%20&aigne. /page?utm_source=email+&campaign=test （加空格），5) /page?utm_source=EMAIL&campaign=test （不同大小寫），6) /page?utm_source=email&%63ampaign=test （名稱中的十六進位）。
規範變體 2 需要修復十六進位大小寫並解碼未保留的字母：%65%6d%61%69%6c 成為電子郵件。帶有加號的變體 4 需要上下文感知 - 如果來源是 HTML 表單，加號表示空格；否則 plus 就是字面意思。變體 5 具有大寫“EMAIL”；小寫的“email”是規範的，因為電子郵件不區分大小寫。變體 6 有 %63 （十六進位表示「c」）；無保留解碼產生與規範相符的「活動」。
工作範例：標準化一個 URL 的六種變體 — 解碼安全字元、修復十六進位大小寫以及保持不同的內容
在管道中實現標準化（對攝取進行標準化並保留原始值）是建議的分析架構。在 URL 進入資料庫的攝取點（日誌記錄端點），在儲存或衍生頁面視圖金鑰之前套用規範化。規範化：1) 將 URL 解析為元件，2) 解碼未保留的序列（修復十六進位大小寫），3) 規範化參數順序，4) 產生用於分組的規範形式，5) 儲存規範化形式和原始值。這可確保所有六個變體雜湊到同一組密鑰。
基於規範化 URL 的雜湊函數可確保所有變體對應到報告中的相同頁面。如果分析系統缺乏內建規範化，資料工程層（ETL 管道）會在資料庫寫入之前進行標準化。對於 Google Analytics 等工具，可設定的篩選器允許使用正規表示式分組或傳送與 URL 分開的標題。最強大的方法在來源進行標準化：當追蹤程式碼將 URL 傳送到分析時，請確保規範化的形式。
在管道中執行此操作 - 標準化攝取並保留原始值，將其描述為模式
這不包括追蹤參數剝離和 SEO 規範標籤，它們是相關但不同的。 utm_source 和 utm_campaign 等追蹤參數可能會從分析中刪除，以按有機內容進行分組。這是單獨的業務邏輯。 HTML 規範標籤整合了 SEO 變體的頁面視圖，但不影響內部分析。綜合策略採用結合這兩種方法的多個重複資料刪除層。
分析空間標準化支援差異很大。 Google Analytics 會自動處理一些標準化，但可能會遺漏變體。其他工具需要手動設定。付費搜尋平台對行銷活動 URL 應用不同的標準化。伺服器日誌記錄未經標準化接收的 URL。全面的策略記錄了每一層應用的標準化以及保存用於審計的原始資料。 URL 編碼器和解碼器有助於檢查變體。
這不包括什麼 - 追蹤參數剝離策略和 SEO 規範標籤
重點：在計數之前進行規範化 - URL 編碼器和解碼器有助於檢查任何變體，顯示其編碼內容以及是否與規範形式相符。對於可疑的分析變體，貼在解碼器中檢查解碼的輸出。如果兩個 URL 解碼為相同的形式，則它們代表相同的頁面並應該合併。該工具可準確顯示編碼的字元、它們的十六進位值和結果。此檢查是故障排除的第一步。
在對分析差異進行故障排除時，建立所有觀察到的 URL 變體的列表，並使用 URL 編碼器和解碼器對每個變體進行解碼。比較解碼的形式。如果表單的資料內容不同（例如不同的 utm_source 值），則它們實際上是不同的頁面。如果它們僅在編碼方面不同（例如 %65mail 與電子郵件），則它們是需要標準化的重複項。記錄規範形式並實施規範化。 URL編碼器和解碼器提供診斷；分析管道提供了解決方案。
重點：在計數之前進行標準化 — URL 編碼器和解碼器如何幫助您檢查任何變體以了解其實際編碼的內容
重點：在計數之前進行規範化 - URL 編碼器和解碼器有助於檢查任何變體，顯示其編碼內容以及是否與規範形式相符。對於可疑的分析變體，貼在解碼器中檢查解碼的輸出。如果兩個 URL 解碼為相同的形式，則它們代表相同的頁面並應該合併。該工具可準確顯示編碼的字元、它們的十六進位值和結果。
在排除分析差異時，建立所有觀察到的 URL 變體的列表，並使用 URL 編碼器和解碼器對每個變體進行解碼。比較解碼的形式。如果表單的資料內容不同（例如不同的 utm_source 值），則它們實際上是不同的頁面。如果它們僅在編碼方面不同（例如 %65mail 與電子郵件），則它們是需要標準化的重複項。記錄規範形式並實施規範化。