Trong URL, các dấu cách sẽ được mã hóa bằng% 20 hoặc +?

Question

Trong URL, tôi có nên mã hóa khoảng trắng bằng cách sử dụng %20 hoặc + không? Ví dụ, trong ví dụ sau, cái nào là đúng?

www.mydomain.com?type=xbox%20360 
www.mydomain.com?type=xbox+360 

Công ty chúng tôi đang nghiêng với trước đây, nhưng sử dụng phương pháp Java URLEncoder.encode(String, String) với "xbox 360" (và "UTF-8") returns the latter.

Vì vậy, sự khác biệt là gì?

Answer 1

Nó không nên vấn đề, nhiều hơn nếu bạn mã hóa chữ A là% 41.

Tuy nhiên, nếu bạn đang xử lý một hệ thống không nhận dạng được một biểu mẫu, có vẻ như bạn sẽ phải cung cấp cho nó những gì nó mong đợi bất kể "spec" nói gì.

Answer 2

Dữ liệu biểu mẫu (cho GET hoặc POST) thường được mã hóa là application/x-www-form-urlencoded: chỉ định + cho khoảng trắng.

URL được mã hóa là RFC 1738 chỉ định %20.

Về lý thuyết tôi nghĩ bạn nên có% 20 trước khi ? và + sau:

example.com/foo%20bar?foo+bar 

Answer 3

Theo W3C (và họ là những nguồn chính thức về những điều này), một nhân vật không gian trong chuỗi truy vấn (và chỉ trong chuỗi truy vấn) có thể được mã hóa thành "%20" hoặc "+". Từ phần "Chuỗi truy vấn" trong "Đề xuất":

Trong chuỗi truy vấn, ký hiệu dấu cộng được đặt làm ký hiệu viết tắt cho dấu cách. Do đó, dấu cộng thực phải được mã hóa. Phương pháp này được sử dụng để làm cho các URI truy vấn dễ dàng hơn trong các hệ thống không cho phép các khoảng trống.

Theo mục 3.4 của RFC2396 đó là đặc điểm kỹ thuật chính thức về URI nói chung, "truy vấn" thành phần là URL phụ thuộc vào:

3,4. Thành phần truy vấn Thành phần truy vấn là một chuỗi thông tin được diễn giải bởi tài nguyên.

query   = *uric 

Trong thành phần truy vấn, các ký tự ";", "/", "?" ":", "@", "&", "=", "+", "" và "$" được đặt trước.

Do đó, lỗi trong phần mềm khác nếu nó không chấp nhận các URL có dấu cách trong chuỗi truy vấn được mã hóa là ký tự "+".

Đối với phần thứ ba của câu hỏi, một cách (mặc dù hơi xấu xí) để sửa đầu ra từ URLEncoder.encode() là sau đó callreplaceAll("\\+","%20") trên giá trị trả lại.

Answer 4

Bạn cũng có thể sử dụng - nghĩa là hầu hết mọi người đều chọn "+" vì có nhiều người dễ đọc hơn.

Answer 5

Khi mã hóa giá trị truy vấn, biểu mẫu, cộng hoặc phần trăm-20, hợp lệ; tuy nhiên, vì băng thông của Internet không phải là vô hạn, bạn nên sử dụng dấu cộng vì nó có ít hơn hai byte.

Answer 6

sự nhầm lẫn này là do URL vẫn tấm '' cho đến ngày nay

Hãy "http://www.google.com" ví dụ. Đây là một URL. URL là Trình định vị tài nguyên đồng nhất và thực sự là một con trỏ đến trang web (trong hầu hết các trường hợp). URL thực sự có một cấu trúc rất rõ ràng từ đặc tả đầu tiên vào năm 1994.

Chúng ta có thể trích xuất thông tin chi tiết về "http://www.google.com" URL:

+---------------+-------------------+ 
|  Part  |  Data   | 
+---------------+-------------------+ 
| Scheme  | http    | 
| Host address | www.google.com | 
+---------------+-------------------+ 

Nếu chúng ta nhìn vào một nhiều hơn URL phức tạp như "https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third" chúng tôi có thể trích xuất thông tin sau:

+-------------------+---------------------+ 
|  Part  |  Data   | 
+-------------------+---------------------+ 
| Scheme   | https    | 
| User    | bob     | 
| Password   | bobby    | 
| Host address  | www.lunatech.com | 
| Port    | 8080    | 
| Path    | /file    | 
| Path parameters | p=1     | 
| Query parameters | q=2     | 
| Fragment   | third    | 
+-------------------+---------------------+ 

Các nhân vật dự trữ khác nhau đối với từng bộ phận

Đối với HTTP URL, một không gian trong một phần đường đoạn phải được mã hóa để "% 20" (không, hoàn toàn không phải là "+") , trong khi ký tự "+" trong đường dẫn phần đoạn có thể không được mã hóa. Bây giờ trong phần truy vấn, khoảng trắng có thể được mã hóa thành "+" (cho tương thích ngược: không tìm cách tìm kiếm trong tiêu chuẩn URI ) hoặc "% 20" trong khi ký tự "+" (do kết quả của sự không rõ ràng này ) phải được chuyển sang "% 2B".

Điều này có nghĩa là chuỗi "blue + light blue" phải được mã hóa khác nhau trong đường dẫn và phần truy vấn: "http://example.com/blue+light%20blue?blue%2Blight+blue". Từ đó bạn có thể suy ra rằng mã hóa URL được xây dựng hoàn chỉnh là không thể mà không có nhận thức cú pháp về cấu trúc URL.

Điều này boils xuống đến là

bạn nên có %20 trước ? và + sau

Source