Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
EncodeURI vs EncodeURIComponent: mỗi ký tự để lại một mình
· Cách thức hoạt động
url-encoding javascript developer-workflow
Hai hàm JavaScript khác nhau chính xác 11 ký tự và việc chọn sai sẽ làm hỏng URL hoặc không thoát được một giá trị. Bài đăng này mô tả các bộ và đưa ra một quy tắc mà bạn có thể nhớ.
Tìm kiếm trả về mọi thứ vì & trong 'R&D' đã chia tách truy vấn — một lỗi cụ thể do chức năng sai
Việc tìm kiếm R&D có thể vô tình trả về kết quả cho R nếu mã xây dựng ?q=R&D bằng tay. Dấu và là dấu phân cách giữa các tham số truy vấn; nó không được bảo tồn như một phần của q trừ khi bạn mã hóa giá trị. Việc chọn mã hóaURI cho phần nhỏ đó là lỗi chứ không phải lỗi máy chủ. Tùy chọn an toàn nhất trong mã ứng dụng thường là URLSearchParams, nhưng việc hiểu hai nguyên hàm JavaScript giúp mã hiện tại dễ gỡ lỗi hơn nhiều.
Điểm chung của cả hai hàm — tập hợp không được đặt trước mà chúng không bao giờ chạm vào và mã hóa phần trăm UTF-8 mà cả hai đều áp dụng
Cả hai phương pháp đều để lại ASCII chữ cái, chữ số và dấu câu không được đặt trước - _ . ! ~ * ' ( ) không bị ảnh hưởng theo quy tắc mã hóa của JavaScript. Họ chuyển đổi các ký tự không phải ASCII thành UTF-8 byte trước khi viết phần trăm bộ ba: é trở thành %C3%A9, không phải một chữ Latin-1 byte. Họ cũng mã hóa khoảng trắng dưới dạng %20. Mã hóa phần trăm nhằm bảo toàn cấu trúc của URI; nó không phải là HTML thoát, xác thực đầu vào hoặc bảo vệ chống lại tập lệnh độc hại trên trang nhận.
Chỉ có mười một ký tự được giữ lại trong EncodeURI — ; , / ? : @ & = + $ # và tại sao mỗi cái có ý nghĩa cấu trúc trong URL
EncodeURI còn bảo toàn thêm 11 ký tự cấu trúc mà EncodeURIComponent mã hóa: ; , / ? : @ & = + $ #. Đối với một địa chỉ đầy đủ, chỉ để lại dấu gạch chéo và dấu chấm hỏi sẽ giữ nguyên đường dẫn và cú pháp truy vấn của nó. Đối với một giá trị truy vấn, việc cho phép & hoặc = xuyên qua sẽ thay đổi danh sách tham số, trong khi dấu # không thoát có thể bắt đầu một đoạn. Các hàm này khác nhau một cách chính xác vì một hàm dành cho toàn bộ địa chỉ và hàm kia dành cho một thành phần bên trong địa chỉ đó.
Một quy tắc giữ vững: các giá trị nhận được mã hóaURIComponent, các URL hoàn chỉnh nhận được mã hóaURI — và tại sao 'hoàn thành URL' lại hiếm hơn người ta tưởng
Các giá trị hầu như luôn nhận được mã hóaURIComponent; địa chỉ hoàn chỉnh, có cấu trúc sẵn là trường hợp ít phổ biến hơn đối với EncodeURI. Đối với URL bạn đang xây dựng theo chương trình, hãy sử dụng URL API để xử lý đường dẫn và tham số tìm kiếm thay vì ghép nối hỗn hợp các phần thô và được mã hóa. Không mã hóa toàn bộ URL bằng EncodeURIComponent, sau đó mong đợi dấu gạch chéo và dấu hai chấm tiếp tục hoạt động như dấu phân cách. Ngược lại, không cung cấp thuật ngữ truy vấn của người dùng thông qua EncodeURI và để ký hiệu của nó hoạt động.
Ví dụ hoạt động: cùng một chuỗi thông qua cả hai hàm - một bảng kết quả đầu ra cho một giá trị có dấu cách, &, / và dấu
Lấy R&D / café làm một giá trị truy vấn. mã hóaURIComponent trả về R%26D%20%2F%20caf%C3%A9, bảo vệ ký hiệu và dấu gạch chéo. EncodeURI trả về% R&D20/%20caf%C3%A9, bảo quản dấu câu cấu trúc; tiền tố ?q= ngây thơ bây giờ sẽ tạo ra một dấu phân cách ngoài ý muốn. Cả hai đều mã hóa không gian và trọng âm, do đó, bài kiểm tra chỉ sử dụng “hello world” sẽ bỏ lỡ sự khác biệt quan trọng. So sánh các chuỗi được tạo trong ToolAcre, sau đó dán chúng vào một URL trình phân tích cú pháp và kiểm tra xem có bao nhiêu tham số truy vấn xuất hiện.
Các lỗi phổ biến — mã hóa toàn bộ URL bằng mã hóaURIComponent và giải mã bằng đối tác sai
Mã hóa đầy đủ URL dưới dạng một thành phần sẽ tạo ra %3A%2F%2F trong đó người tiêu dùng mong đợi ://. Giải mã toàn bộ địa chỉ trước khi xác thực địa chỉ đó có thể giới thiệu lại các dấu phân cách dành riêng với ý nghĩa mới. Ngoài ra, hãy tránh mã hóa kép một giá trị đã chứa %26: bản thân dấu phần trăm có thể trở thành %25, do đó, lớp giải mã thứ hai có thể lại thay đổi ý nghĩa. Ghép nối bộ mã hóaURIComponent với bộ giải mãURIComponent cho một thành phần và coi phần trăm thoát không đúng định dạng là lỗi đầu vào.
Điều này không bao gồm những gì - mã hóa biểu mẫu bằng + và tạo URL bằng URLSearchParams
Mã hóa truy vấn biểu mẫu HTML sử dụng dấu cộng cho khoảng trắng trong ứng dụng/x-www-form-urlencoded,, dấu này khác với kết quả đầu ra %20 của hai hàm này. URLSearchParams xử lý các quy tắc biểu mẫu đó cho bạn. Bài viết này không đề cập đến việc chuẩn hóa đường dẫn, chuyển đổi tên máy chủ Unicode hoặc quyết định xem URL đã giải mã có an toàn để yêu cầu hay không; Mã hóa URL là bước trình bày chứ không phải chính sách ủy quyền.
Bài học rút ra: mã hóa các phần chứ không phải toàn bộ — cách bộ mã hóa và giải mã URL hiển thị cả hai chế độ để bạn có thể thấy sự khác biệt trên đầu vào của riêng mình
Ranh giới đáng nhớ là các phần so với toàn bộ: giá trị tham số là một phần, vì vậy hãy sử dụng EncodeURIComponent hoặc URLSearchParams. Bộ mã hóa & giải mã URL hiển thị cả hai chức năng của trình duyệt cho cùng một chuỗi và duy trì thử nghiệm cục bộ. Kiểm tra đầu vào có chứa &, =, #, dấu gạch chéo và dấu trước khi quyết định rằng hai bộ mã hóa có thể hoán đổi cho nhau.