URL 编码器 / 解码器

互联网架构要求统一资源定位符（URL）必须通过 HTTP 使用标准的 US-ASCII 字符集进行传输。如果 URL 中包含了超出此严格字符集的字符（例如空格、Emoji 或中文）， Web 浏览器或服务器可能会发生解析错误。

为了在 URL 查询字符串中安全传输复杂数据，我们必须使用 URL 编码（通常称为百分号编码）。该算法将不安全字符转换为 % 符号，后跟该字符 ASCII/UTF-8 值的十六进制表示。

例如，标准空格字符会变成 %20，而 & 符号（&）会变成 %26。这确保了数据能够完好无损地送达后端服务器。

JavaScript Web 开发中常见的 Bug 之一就是使用了错误的 URL 编码函数。理解两者的区别对于避免 404 错误和无效的 API 请求至关重要。

• encodeURI(): 该函数假设您传入的是一个完整且有效的 URL。它会编码空格和外文字符，但不会编码在 URL 中具有结构含义的字符，如 ?、=、&、/ 或 :。
• encodeURIComponent(): 该函数假设您正在编码要插入到 URL 查询字符串内部的具体数据。它会对几乎所有字符（包括斜杠和 & 符号）进行强力编码。当获取用户输入并将其作为 URL 参数附加时，必须使用此函数。

Utiliome 的 URL 编码器严格采用 encodeURIComponent() 语义，以确保转义开发者 Payload 时的最大安全性。

开发者经常需要解码复杂的 URL 字符串来调试 OAuth 重定向或 Webhook Payload（例如 ?email=user%40example.com&token=abc%3D%3D）。

如果您将此字符串粘贴到普通的在线 SEO 工具中，该 URL 会通过 HTTP POST 请求发送到远程服务器。服务器管理员可以轻而易举地记录您的敏感 OAuth Token、Session ID 和个人隐私信息。

Utiliome 基于零信任、本地优先的架构运行。解码计算完全在您浏览器的本地内存中运行。您可以安全地解码生产环境 API Key，数据绝不会触及外部网络。

在互联网早期，URL 严格限制为英文 ASCII。如今，URL 中频繁出现各国语言和复杂的 Emoji。

现代 URL 编码标准（RFC 3986）规定，非 ASCII 字符必须首先转换为 UTF-8 字节序列，然后再对每个字节单独进行百分号编码。

例如，火箭 Emoji（🚀）在 UTF-8 中需要 4 个字节。通过 Utiliome 的 URL 编码器处理后，它会被准确转换为 %F0%9F%9A%80。这确保了任何后端服务器均可安全路由和解码该 Emoji。

要精通 URL 编码，开发者必须了解 RFC 3986 规范下的字符分类。

• 非保留字符： A-Z、a-z、0-9、-、_、. 和 ~。这些字符天然安全，URL 编码器会忽略并保留原样。
• 保留字符： ! * ' ( ) ; : @ & = + $ , / ? # [ ]。这些字符充当互联网的“语法”。例如，& 符号用于分隔变量。如果您的实际变量数据中包含 & 符号（如 "M&M Candy"），则必须将其编码为 %26，以免服务器将数据切断。

开发者常困惑于为何空格字符有时被编码为 %20，有时又被编码为 + 符号。

这源于早期的互联网架构。在提交 HTML 表单时使用的 application/x-www-form-urlencoded 规范中，历史上规定将空格转换为加号以节省带宽。

然而在标准 URL 路径和现代 API 查询字符串中，空格字符必须严格编码为 %20。Utiliome 统一采用现代 encodeURIComponent() 规范，保证将空格安全转换为 %20，防止 REST API 后端解码报错。