Khi nào một không gian trong một URL được mã hóa +
và khi nào nó được mã hóa thành %20
?
Khi nào một không gian trong một URL được mã hóa +
và khi nào nó được mã hóa thành %20
?
Câu trả lời:
Từ Wikipedia (nhấn mạnh và liên kết được thêm vào):
Khi dữ liệu đã được nhập vào biểu mẫu HTML được gửi, tên và giá trị của trường biểu mẫu được mã hóa và gửi đến máy chủ trong thông báo yêu cầu HTTP bằng phương thức GET hoặc POST, hoặc, theo lịch sử, qua email. Mã hóa được sử dụng theo mặc định dựa trên phiên bản đầu tiên của quy tắc mã hóa phần trăm URI chung, với một số sửa đổi như chuẩn hóa dòng mới và thay thế khoảng trắng bằng "+" thay vì "% 20". Kiểu dữ liệu MIME được mã hóa theo cách này là application / x-www-form-urlencoding và hiện được xác định (vẫn theo cách rất lỗi thời) trong thông số kỹ thuật HTML và XForms.
Vì vậy, phần trăm mã hóa thực sự sử dụng %20
trong khi dữ liệu biểu mẫu trong URL ở dạng được sửa đổi sử dụng +
. Vì vậy, rất có thể bạn chỉ nhìn thấy +
trong các URL trong chuỗi truy vấn sau một ?
.
multipart/form-data
sử dụng mã hóa MIME; application/x-www-form-urlencoded
sử dụng +
và sử dụng URI được mã hóa đúng cách %20
.
http://www.bing.com/search?q=hello+world
và một tài nguyên có khoảng trống trong tênhttp://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
mailto:support@example.org?subject=I%20need%20help
. Nếu bạn đã thử với +, email sẽ mở bằng + es thay vì dấu cách.
Sự nhầm lẫn này là do các URL vẫn bị 'hỏng' cho đến ngày nay.
Lấy ví dụ " http://www.google.com ". Đây là một URL. URL là một Bộ định vị tài nguyên thống nhất và thực sự là một con trỏ tới một trang web (trong hầu hết các trường hợp). Các URL thực sự có cấu trúc được xác định rất rõ kể từ thông số kỹ thuật đầu tiên vào năm 1994.
Chúng tôi có thể trích xuất thông tin chi tiết về URL " http://www.google.com ":
+---------------+-------------------+
| Part | Data |
+---------------+-------------------+
| Scheme | http |
| Host | www.google.com |
+---------------+-------------------+
Nếu chúng ta xem một URL phức tạp hơn, chẳng hạn như:
" https: // bob: bulk@www.lunatech.com: 8080 / tệp; p = 1? q = 2 # thứ ba "
chúng ta có thể trích xuất các thông tin sau:
+-------------------+---------------------+
| Part | Data |
+-------------------+---------------------+
| Scheme | https |
| User | bob |
| Password | bobby |
| Host | www.lunatech.com |
| Port | 8080 |
| Path | /file;p=1 |
| Path parameter | p=1 |
| Query | q=2 |
| Fragment | third |
+-------------------+---------------------+
https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third
\___/ \_/ \___/ \______________/ \__/\_______/ \_/ \___/
| | | | | | \_/ | |
Scheme User Password Host Port Path | | Fragment
\_____________________________/ | Query
| Path parameter
Authority
Các nhân vật dành riêng là khác nhau cho mỗi phần.
Đối với URL HTTP, một khoảng trắng trong phần phân đoạn đường dẫn phải được mã hóa thành "% 20" (không, hoàn toàn không phải là "+"), trong khi ký tự "+" trong phần phân đoạn đường dẫn có thể không được mã hóa.
Bây giờ trong phần truy vấn, các khoảng trắng có thể được mã hóa thành "+" (để tương thích ngược: không cố tìm kiếm nó trong tiêu chuẩn URI) hoặc "% 20" trong khi ký tự "+" (do sự mơ hồ này ) phải được thoát đến "% 2B".
Điều này có nghĩa là chuỗi "blue + light blue" phải được mã hóa khác nhau trong phần đường dẫn và truy vấn:
" http://example.com/blue+light%20blue?blue%2Blight+blue ".
Từ đó bạn có thể suy luận rằng việc mã hóa một URL được xây dựng đầy đủ là không thể nếu không có nhận thức cú pháp về cấu trúc URL.
Điều này sôi xuống:
Bạn nên có %20
trước ?
và +
sau.
key1=value1&key1=value2
trong đó các khóa và giá trị được mã hóa theo bất kỳ quy tắc nào encodeURIComponent
tuân theo nhưng AFAIK nội dung của phần truy vấn hoàn toàn tùy thuộc vào ứng dụng. Khác sau đó nó chỉ đi đến đầu tiên #
không có mã hóa chính thức.
Tôi muốn giới thiệu %20
.
Bạn có khó mã hóa chúng không?
Điều này không nhất quán trên các ngôn ngữ, mặc dù. Nếu tôi không nhầm, trong PHP urlencode()
xử lý các khoảng trắng như +
trong khi Python urlencode()
xử lý chúng như %20
.
BIÊN TẬP:
Có vẻ như tôi đã nhầm. Python urlencode()
(ít nhất là trong 2.7.2) sử dụng quote_plus()
thay vì quote()
và do đó mã hóa các khoảng trắng là "+". Dường như đề xuất của W3C là "+" theo đây: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
Và trên thực tế, bạn có thể theo dõi cuộc tranh luận thú vị này trên trình theo dõi vấn đề của chính Python về những gì sẽ sử dụng để mã hóa không gian: http://bugs.python.org/su13866 .
EDIT # 2:
Tôi hiểu rằng cách mã hóa phổ biến nhất "" là "+", nhưng chỉ là một ghi chú, nó có thể chỉ là tôi, nhưng tôi thấy điều này hơi khó hiểu:
import urllib
print(urllib.urlencode({' ' : '+ '})
>>> '+=%2B+'
URLEncoder.encode()
phương thức trong Java cũng chuyển đổi nó +
.
Một khoảng trắng chỉ có thể được mã hóa thành "+" trong phần truy vấn cặp khóa-giá trị loại nội dung "application / x-www-form-urlencoding" của URL. Theo tôi, đây là một tháng 5, không phải là PHẢI. Trong phần còn lại của URL, nó được mã hóa thành% 20.
Theo tôi, tốt hơn là luôn mã hóa khoảng trắng dưới dạng% 20, không phải là "+", ngay cả trong phần truy vấn của URL, bởi vì đó là đặc tả HTML (RFC-1866) đã chỉ định rằng các ký tự khoảng trắng nên được mã hóa thành " + Các cặp khóa-giá trị loại nội dung "trong" application / x-www-form-urlencoding "(xem đoạn 8.2.1. đoạn 1.)
Cách mã hóa dữ liệu biểu mẫu này cũng được đưa ra trong các thông số kỹ thuật HTML sau này. Ví dụ: tìm các đoạn có liên quan về ứng dụng / x-www-form-urlencoding trong Đặc tả HTML 4.01, v.v.
Dưới đây là một chuỗi mẫu trong URL nơi đặc tả HTML cho phép mã hóa không gian dưới dạng dấu cộng: " http://example.com/over/there?name=foo+bar ". Vì vậy, chỉ sau "?", Không gian có thể được thay thế bằng dấu cộng . Trong các trường hợp khác, khoảng trắng nên được mã hóa thành% 20. Nhưng vì thật khó để xác định chính xác bối cảnh, nên cách tốt nhất là không bao giờ mã hóa khoảng trắng là "+".
Tôi khuyên bạn nên mã hóa phần trăm tất cả các ký tự ngoại trừ "không được giám sát" được xác định trong RFC-3986, tr.2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Việc thực hiện phụ thuộc vào ngôn ngữ lập trình mà bạn đã chọn.
Nếu URL của bạn chứa các ký tự quốc gia, trước tiên hãy mã hóa chúng thành UTF-8 và sau đó mã hóa phần trăm kết quả.