Đôi khi các không gian nhận URL được mã hóa thành +dấu hiệu, một số lần khác %20. Sự khác biệt là gì và tại sao điều này nên xảy ra?
Câu trả lời:
+nghĩa là một khoảng trắng chỉ trong application/x-www-form-urlencodednội dung, chẳng hạn như phần truy vấn của URL:
http://www.example.com/path/foo+bar/path?query+name=query+value
Trong URL này, tên tham số query namecó một khoảng trắng và giá trị là query valuevới một khoảng trắng, nhưng tên thư mục trong đường dẫn là theo nghĩa đen foo+bar, không phải foo bar .
%20là một cách hợp lệ để mã hóa một khoảng trắng trong một trong hai bối cảnh này. Vì vậy, nếu bạn cần mã hóa URL một chuỗi để đưa vào một phần của URL, việc thay thế khoảng trắng bằng %20và dấu cộng bằng luôn là an toàn %2B. Đây là những gì ví dụ. encodeURIComponent()hiện trong JavaScript. Thật không may, đó không phải là những gì urlencode làm trong PHP ( rawurlencode an toàn hơn).
query+name=query+valuetham số từ một biểu mẫu với <input name="query name" value="query value">. Nó sẽ không tạo ra query%20nametừ một hình thức, nhưng nó hoàn toàn an toàn để sử dụng thay vào đó, ví dụ. nếu bạn đang gửi một biểu mẫu cùng với chính bạn cho một XMLHttpRequest. Nếu bạn có một URL có một khoảng trắng trong đó, <a href="http://www.example.com/foo bar/">thì trình duyệt sẽ mã hóa nó để %20bạn sửa lỗi, nhưng có lẽ tốt nhất là không nên dựa vào.
foo barđể foo+bar?
encodeURIComponent(s).replace(/%20/g, '+')nếu bạn thực sự cần+
http://www.example.com/some/path/to/resource?param1=value1
Phần trước dấu chấm hỏi phải sử dụng mã hóa% (vì vậy %20đối với dấu cách), sau dấu chấm hỏi, bạn có thể sử dụng %20hoặc +cho khoảng trắng. Nếu bạn cần một thực tế +sau khi sử dụng dấu hỏi %2B.
decodeURIComponentkhông giải mã nó.
+là một ký tự dành riêng nên nó sẽ được trình duyệt bảo tồn.
+theo mặc định ( { foo: 'bar bar'}.to_query=> foo=bar+bar)
Vì vậy, các câu trả lời ở đây là một chút không đầy đủ. Việc sử dụng '% 20' để mã hóa khoảng trắng trong URL được xác định rõ ràng trong RFC3986 , định nghĩa cách xây dựng URI. Không có đề cập nào trong thông số kỹ thuật này về việc sử dụng '+' cho các không gian mã hóa - nếu bạn chỉ sử dụng thông số kỹ thuật này, một khoảng trắng phải được mã hóa thành '% 20'.
Việc đề cập đến việc sử dụng '+' cho các không gian mã hóa xuất phát từ các phiên bản khác nhau của đặc tả HTML - cụ thể là trong phần mô tả loại nội dung 'application / x-www-form-urlencoding'. Điều này được sử dụng để đăng dữ liệu mẫu.
Bây giờ, Đặc tả HTML 2.0 (RFC1866) đã nói rõ ràng, trong phần 8.2.2, rằng phần Truy vấn của chuỗi URL của yêu cầu GET phải được mã hóa dưới dạng 'application / x-www-form-urlencoding'. Về lý thuyết, điều này cho thấy rằng việc sử dụng '+' trong URL trong chuỗi truy vấn (sau '?') Là hợp pháp.
Nhưng ... có thật không? Hãy nhớ rằng, HTML tự nó là một đặc tả nội dung và các URL có chuỗi truy vấn có thể được sử dụng với nội dung không phải là HTML. Hơn nữa, trong khi các phiên bản sau của thông số HTML tiếp tục định nghĩa '+' là hợp pháp trong nội dung 'application / x-www-form-urlencoding', chúng hoàn toàn bỏ qua phần nói rằng chuỗi truy vấn yêu cầu GET được xác định là loại đó. Trên thực tế, không có bất kỳ đề cập nào về mã hóa chuỗi truy vấn trong bất cứ điều gì sau thông số HTML 2.0.
Điều này để lại cho chúng tôi câu hỏi - nó có hợp lệ không? Chắc chắn có rất nhiều mã kế thừa hỗ trợ '+' trong các chuỗi truy vấn và cũng có rất nhiều mã tạo ra mã đó. Vì vậy, tỷ lệ cược là tốt, bạn sẽ không phá vỡ nếu bạn sử dụng '+'. (Và trên thực tế, tôi đã thực hiện tất cả các nghiên cứu về vấn đề này gần đây vì tôi phát hiện ra một trang web lớn không chấp nhận '% 20' trong truy vấn GET dưới dạng khoảng trắng. Họ thực sự đã không giải mã được BẤT K character ký tự được mã hóa nào. Vì vậy, dịch vụ của bạn Việc sử dụng cũng có thể có liên quan.)
Nhưng từ việc đọc các thông số kỹ thuật thuần túy, không có ngôn ngữ từ thông số kỹ thuật HTML 2.0 được chuyển sang các phiên bản mới hơn, các URL được bao phủ hoàn toàn bởi RFC3986, có nghĩa là các không gian phải được chuyển đổi thành '% 20'. Và chắc chắn đó là trường hợp nếu bạn yêu cầu bất cứ thứ gì ngoài tài liệu HTML.
%20( <a href="?q=a b">), nhưng khi bạn gửi biểu mẫu, nó sẽ sử dụng +dấu hiệu. Bạn có thể ghi đè bằng cách sử dụng +dấu ( <a href="?q=a+b">) hoặc bằng cách gửi biểu mẫu bằng cách sử dụng XMLHTTPRequest.
Tốt hơn hết là luôn mã hóa khoảng trắng dưới dạng% 20, không phải là "+".
Đó là RFC-1866 (đặc tả HTML 2.0), đã chỉ định rằng các ký tự khoảng trắng phải đượ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, hãy tìm các đoạn có liên quan về ứng dụng / x-www-form-urlencoding.
Dưới đây là ví dụ về một chuỗi như vậy trong URL trong đó RFC-1866 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, theo RFC-1866. 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ì khó xác định 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 / "-" / "." / "_" / "~"
Sự khác biệt là gì: Xem các câu trả lời khác.
Khi sử dụng +thay vì %20? Sử dụng +nếu, vì một số lý do, bạn muốn làm cho chuỗi truy vấn URL ( ?.....) hoặc đoạn băm ( #....) dễ đọc hơn. Ví dụ: Bạn thực sự có thể đọc điều này:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
( %2B= +)
Nhưng những điều sau đây khó đọc hơn nhiều: (ít nhất là với tôi)
Tôi nghĩ rằng +không có khả năng phá vỡ bất cứ điều gì, vì Google sử dụng +(xem liên kết đầu tiên ở trên) và có lẽ họ đã nghĩ về điều này. Tôi sẽ sử dụng +bản thân mình chỉ vì có thể đọc được + Google cho rằng nó ổn.