开发者工具 · 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_source=email%20&campaign=test (值中存在空格)、4) /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 与电子邮件），则它们是需要标准化的重复项。记录规范形式并实施规范化。