百分號編碼，又稱 URL 編碼是特定上下文的統一資源定位符（URL）的編碼機制，實際上也適用於統一資源標誌符（URI）的編碼。也用於為 applicationxwwwformurlencoded MIME 準備資料，因為它用於透過 HTTP 的請求操作（request）提交 HTML 表單資料。 URI 的百分號編碼 URI 的字元型別 URI 所允許的字元分作保留與未保留。保留字元是那些具有特殊含義的字元，例如：斜線字元用於 URL（或 URI）不同部分的分界符；未保留字元沒有這些特殊含義。百分號編碼把保留字元表示為特殊字元序列。上述情形隨 URI 與 URI 的不同版本規格會有輕微的變化。 section 22 保留字元 （2005 年 1 月） section 23 未保留字元 （2005 年 1 月） A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 _ URI 中的其它字元必須用百分號編碼。 對保留字元的百分號編碼 如果一個保留字元在特定上下文中具有特殊含義（稱作 reserved purpose） 且 URI 中必須使用該字元用於其它目的，那麼該字元必須百分號編碼。百分號編碼一個保留字元，首先需要把該字元的 ASCII 的值表示為兩個 16 進位制的數字，然後在其前面放置跳脫字元，置入 URI 中的相應位置。（對於非 ASCII 字元，需要轉換為 UTF8 位元組序，然後每個位元組按照上述方式表示。） 例如，，如果用作 URI 的路徑成份的分界符，則是具有特殊含義的保留字元。如果該字元需要出現在 URI 一個路徑成分的內部，則三字元序列 2F 或 2f 就用於代替原本的 出現在該 URI 路徑成分的內部 保留字元的百分號編碼 21 23 24 26 27 28 29 2A 2B 2C 2F 3A 3B 3D 3F 40 5B 5D 在特定上下文中沒有特殊含義的保留字元也可以被百分號編碼，在語義上與不百分號編碼的該字元沒有差別。 在 URI 的 查詢 成分（ 字元後的部分）中，例如 仍然是保留字元但是沒有特殊含義，除非一個特定的 URI 有其它規定。該 字元在沒有特殊含義時不需要百分號編碼。 如果保留字元具有特殊含義，那麼該保留字元用百分號編碼的 URI 與該保留字元僅用其自身表示的 URI 具有不同的語義。 對未保留字元的百分號編碼 未保留字元不需要百分號編碼。 兩個 URI 的差別如果僅在於未保留字元是用百分號編碼還是用字元自身表示，那麼這兩個 URI 具有等價的語義。但 URI 處理器實際上並不總是把二者視作等價。例如，URI 的消費者不應該把 41 與 A，7E 與 視作不同，但是某些 URI 的消費者就是這麼做了。為了最大的互操作性，URI 的製造者不應該對未保留字元進行百分號編碼。 對百分號字元的百分號編碼 由於百分號字元表示百分號編碼位元組流的存在，因此百分號字元應該被編碼為 3 個位元組的序列：25，用於 URI 內部。 對任意資料的百分號編碼 大多數 URI 涉及表示任意資料，例如 IP 地址或檔案系統路徑作為 URI 的成分。 二進資料 1994 年釋出的規定 RFC 1738 22 RFC 2396 24 RFC 3986 121 21 25， URI 中的二進位制資料應該表示為 8 位元組的序列，然後對每個 8 位元組按照上述方式百分號編碼。例如，位元組值 0F（十六進位制）應表示為 0F，位元組值 41（十六進位制）應表示為 A 或 41 優先使用未保留字元來表示這些位元組值，因為這使得 URL 更短。 字元資料 二進資料的百分號編碼過程已經被外推到字元資料，甚至到不適合或未被完全規範的地步。在 WWW 初創階段，僅僅處理 ASCII 字元是否編碼問題，還沒有什麼問題。但隨後發展到對非 ASCII 字元如何在 URI 中編碼，缺少標準規範的情況下導致了歧義性的解釋 URI 的錯誤。 例如， 基於 RFC 1738 與的協議規定，字元資料先要根據某種字元編碼轉換為位元組流，然後再表示為 URI。如果 URI 不提供是何種字元編碼的提示資訊，那麼這個 URI 難以可靠的解析。 當前標準 2005 年 1 月釋出的 RFC 3986，建議所有新的 URI 必須對未保留字元不加以百分號編碼；其它字元建議先轉換為 UTF8 位元組序列，然後對其位元組值使用百分號編碼。此前的 URI 不受此標準的影響。 非標準的實現 有一些不符合標準的把 Unicode 字元在 URI 中表示為： uxxxx 其中 xxxx 是用 4 個十六進位制數字表示的 Unicode 的碼位值。任何 RFC 都沒有這樣的字元表示方法，並且已經被 W3C 拒絕 。第三版的 ECMA262 仍然包含函式 escape string 使用這種語法，但也有函式 encodeURI uri 轉換字元到 UTF8 位元組序列並用百分號編碼每個位元組。 applicationxwwwformurlencoded 型別 當 HTML 表單中的資料被提交時，表單的域名與值被編碼並透過 HTTP 的 GET 或者 POST 方法甚至更古遠的 emailUseragent support for email based HTML form submission using a mailto URL as the form action was proposed in RFC 1867 section 56 during the HTML 32 era Various web browsers implemented it by invoking a separate email program or using their own rudimentary SMTP capabilities Although sometimes unreliable it was briefly popular as a simple way to transmit form data without involving a web server or CGI scripts 把請求傳送給伺服器。這裡的編碼方法採用了一個非常早期的通用的 URI 百分號編碼方法，並且有很多小的修改如換行規範化以及把空格符的編碼 20 替換為 。按這套方法編碼的資料的 MIME 型別是 applicationxwwwformurlencoded，當前仍用於（雖然非常過時了）HTML 與 XForms 規範中。此外，CGI 規範包括了 web 伺服器如何解碼這類資料、利用這類資料的內容。 如果傳送的是 HTTP GET 請求，applicationxwwwformurlencoded 資料包含在所請求 URI 的查詢成分中。如果傳送的是 HTTP POST 請求或透過 email，資料被放置在訊息體中，媒體型別的名字被包含在訊息的 ContentType 頭內部。 參見 Quotedprintable 參考文獻 外部連結 RFC 3986 STD 66 plus errata the current generic URI syntax specification RFC 2396 obsolete plus errata and RFC 2732 plus errata together comprised the previous version of the generic URI syntax specification RFC 1738 mostly obsolete and RFC 1808 obsolete which define URLs RFC 1630 obsolete the first generic URI syntax specification W3C Guidelines on Naming and Addressing URIs URLs W3C explanation of UTF8 in URIs W3C HTML form content types 線上 URL 編解碼工具 B B B