RFC 3986 URL 編碼規範完整說明

RFC 3986 是由 IETF（Internet Engineering Task Force）制定的標準，正式名稱為 Uniform Resource Identifier (URI): Generic Syntax。
本文件定義了 URL / URI 的通用語法結構與字元編碼方式（Percent-Encoding）。

一、URI 基本結構

scheme://authority/path?query#fragment

範例：

https://example.com/products/list?id=100#top

二、字元分類

1. Unreserved Characters（不需編碼）

A–Z
a–z
0–9
- _ . ~

這些字元可以直接使用，不需要進行編碼。

2. Reserved Characters（保留字元）

: / ? # [ ] @
! $ & ' ( ) * + , ; =

這些字元在 URL 中有特殊用途，若作為資料使用，必須進行編碼。

三、Percent-Encoding（百分比編碼）

編碼格式：

%HH

HH 為字元的十六進位表示（ASCII 或 UTF-8 byte）。

四、非 ASCII 字元（UTF-8 編碼規則）

所有非 ASCII 字元必須：

1. 轉為 UTF-8
2. 逐 byte 轉為 %HH

例如：「中文」

UTF-8:
E4 B8 AD E6 96 87

Percent-Encoding:
%E4%B8%AD%E6%96%87

五、實際範例（德文句子）

此字串包含：

• ß
• ü
• ä
• ö

這些都不是 ASCII 字元，因此必須進行 UTF-8 + Percent-Encoding。

eristeinflei%C3%9FigerSch%C3%BClerw%C3%A4hrenddueinegro%C3%9FeLehrerinbistalsok%C3%B6nntihrFreundesein

編碼後才符合 RFC 3986 規範。

六、空白是 %20 還是 + ?

七、RFC 3986 的用途

• 設計 RESTful API
• OAuth 簽名計算
• 雲端服務請求簽章（如 AWS Signature）
• 瀏覽器 URL 解析
• 避免雙重編碼漏洞
• 避免 Query 參數解析錯誤

若未遵守 RFC 3986，可能導致：

• API 參數錯誤
• 驗證簽名失敗
• 資安漏洞（例如編碼繞過）

八、總結

• 安全字元可直接使用
• 保留字元作為資料時必須編碼
• 所有非 ASCII 字元必須轉為 UTF-8 再編碼
• 標準 URI 空白必須為 %20

本文件依 RFC 3986 標準整理說明