Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
Từ RFC 1738 đến tiêu chuẩn URL: quy tắc mã hóa phần trăm đã phát triển như thế nào
· Lý lịch
url-encoding rfc-history web-standards
Các quy tắc thoát ký tự trong URL đã được viết lại nhiều lần kể từ 1994. Bài đăng này tuân theo RFC 1738, RFC 2396, RFC 3986 và tiêu chuẩn WHATWG URL và giải thích những gì đã thay đổi mỗi lần.
Từ RFC 1738 đến tiêu chuẩn URL—các quy tắc mã hóa phần trăm đã phát triển như thế nào
Dấu ngã (~) minh họa cách các quy tắc mã hóa thay đổi qua các thế hệ và quá trình triển khai tiêu chuẩn. RFC 1738 (1994) được yêu cầu %7E ở mọi nơi; RFC 2396 (1998) đã chuyển dấu ngã sang không đặt trước cho phép không được mã hóa. RFC 3986 (2005) đã xác nhận trạng thái không được đặt trước. Các URL cũ có %7E vẫn hợp lệ; đầu ra của nhà xây dựng mới ~. Sự phát triển phản ánh các bài học triển khai khi web hoàn thiện và cơ sở hạ tầng được chuẩn hóa. RFC 1738 thận trọng vì cơ sở hạ tầng ban đầu không đồng nhất và đa dạng.
RFC 1738 đã mã hóa 1994 hành vi của trình duyệt. Triển khai được chuẩn hóa trên UTF-8; những hạn chế tỏ ra không cần thiết. Các tiêu chuẩn sau này đã nới lỏng các hạn chế về ký tự. RFC 3986 cho phép giải mã an toàn các ký tự không được bảo vệ.
RFC 1738 (1994): các ký tự 'không an toàn' và các quy tắc thoát đầu tiên — điều gì được coi là nguy hiểm và tại sao
RFC 1738 đã xác định các ký tự "không an toàn" là những ký tự xung đột với cú pháp URI (dấu cách, dấu gạch chéo), được sử dụng trước đây trong các giao thức (ký tự điều khiển) hoặc các hệ thống đó không thể truyền tải một cách an toàn. Danh sách bảo thủ được mã hóa phần trăm nhiều hơn mức cần thiết cho Internet hiện đại. Nhiều hệ thống ban đầu có trước RFC; nó hệ thống hóa hành vi của họ. Các ký tự điều khiển thực sự nguy hiểm trong các giao thức; khoảng trắng là sự cố truyền dẫn đối với ứng dụng khách HTTP đọc từ dòng lệnh. Các hệ thống hiện đại xử lý những trường hợp này một cách khéo léo hơn thông qua mã hóa rõ ràng.
Việc kiểm tra RFC 1738 cho thấy những gì hệ thống cũ mong đợi. Mã hóa một ký tự từ đặc tả URL những năm 1990 và so sánh với RFC 3986 hiện đại. Sự khác biệt cho thấy những gì đã được thư giãn. Bộ không đặt trước được mở rộng theo thời gian. Dấu gạch nối, dấu chấm, dấu gạch dưới luôn an toàn. Tilde cần RFC 2396 để trở nên an toàn. Cách tiếp cận bảo thủ có nghĩa là khả năng tương thích ngược. Các URL cũ được xây dựng theo quy tắc RFC 1738 vẫn hợp lệ cho đến ngày nay. Việc chuẩn hóa trong phần RFC 3986 6 cho phép giải mã các ký tự không được mã hóa theo phần trăm không cần thiết một cách an toàn.
RFC 2396 (1998) — dành riêng so với không đặt trước, cú pháp chung và dấu ngã được phục hồi
RFC 2396 (1998) đã làm rõ các bộ ký tự chặt chẽ hơn RFC 1738. Nó chính thức hóa các ký tự dành riêng phục vụ cấu trúc URI so với các ký tự không được đặt trước dưới dạng dữ liệu bằng chữ. Mở rộng không cần đặt trước bao gồm dấu gạch ngang, dấu chấm, dấu gạch dưới, dấu ngã. Nó thừa nhận cú pháp URI chung tách biệt với các quy tắc dành riêng cho lược đồ. RFC 2396 đã giới thiệu sự phân biệt giữa gen-delims (:, /, ?, #, [, ], @) và sub-delims (!, $, &, ', (, ), *, +, ,, ;, =). Việc đặt tên làm rõ các ký tự dành riêng chia thành hai nhóm có vai trò cấu trúc khác nhau.
RFC 2396 đã giới thiệu hướng dẫn chuẩn hóa chỉ định những ký tự được mã hóa phần trăm nào có thể giải mã mà không thay đổi ý nghĩa. Giải mã ký tự không được bảo vệ được bình thường hóa. Que mã hóa ký tự dành riêng. RFC 3986 ký hiệu được đơn giản hóa hơn nữa. Các tiêu chuẩn duy trì khả năng tương thích ngược một cách quyết liệt.
RFC 3986 (2005) — ! * ' ( ) di chuyển đến các dấu phân cách phụ, các dấu phân cách gen được đặt tên và hướng dẫn chuẩn hóa sẽ xuất hiện
RFC 3986 (2005) là tiêu chuẩn tham chiếu hiện đại cho mã hóa phần trăm. Nó giữ lại sự khác biệt/unreserved nhưng đã đơn giản hóa ký hiệu và thêm hướng dẫn chuẩn hóa. Tilde di chuyển rõ ràng không chút dè dặt. Các ký tự không đặt trước được mã hóa theo phần trăm được làm rõ theo tiêu chuẩn có thể giải mã mà không thay đổi ý nghĩa. Phần RFC 3986 3 mô tả cú pháp URI một cách chính xác. Phần 2 xác định danh mục ký tự. Phần 6 dành các quy tắc chính thức cho việc chuẩn hóa cú pháp. Chuẩn hóa dựa trên so sánh coi các URI giống hệt nhau nếu các dạng chuẩn hóa khớp với nhau. Việc loại bỏ phân đoạn dấu chấm khỏi đường dẫn được bình thường hóa mà không thay đổi ý nghĩa.
Việc chuẩn hóa đóng vai trò quan trọng đối với việc phân tích, bộ nhớ đệm, theo dõi liên kết. Các URL chỉ khác nhau ở dạng chữ số thập lục phân (RFC 3986 thích viết hoa) phải giống hệt nhau trong thực tế. Việc chuẩn hóa sẽ ngăn chặn các mục nhật ký trùng lặp và lỗi bộ nhớ đệm. Bộ nhớ đệm được khóa trên các URL được chuẩn hóa sẽ phân phát nội dung bất kể tùy chọn mã hóa của người yêu cầu. RFC 3986 hướng dẫn chuẩn hóa cho phép hệ thống đưa ra quyết định nhất quán. Nhưng việc thực thi nghiêm ngặt sẽ phá vỡ các URL hoạt động tốt trên internet hiện tại.
Tiêu chuẩn WHATWG URL: phân tích những gì trình duyệt thực sự nhận được — bộ mã hóa, sơ đồ đặc biệt và khả năng chịu lỗi
WHATWG URL Tiêu chuẩn (2016–hiện tại) xuất hiện từ trải nghiệm trình duyệt với các URL không tuân theo RFC 3986 một cách hoàn hảo. Các trình duyệt phải đối mặt với không gian không được mã hóa, mã hóa hỗn hợp, các lỗi kỳ quặc. WHATWG mô tả phân tích cú pháp trình duyệt thực tế chứ không phải ngữ pháp lý thuyết. Các trình duyệt trong thế giới thực đã phát triển các quy tắc thực tế để chấp nhận khoảng trắng, xử lý các ký tự thoát, khôi phục từ đầu vào không đúng định dạng. RFC 3986 đã đến 2005 và xác định ngữ pháp chính thức, nhưng các trình duyệt trong thực tế đã hơi khác một chút.
WHATWG xác định chín bộ mã hóa với các quy tắc theo ngữ cảnh cụ thể. Khoảng trống trong đường dẫn trở thành %20; dấu gạch chéo trong thông tin người dùng trở thành %2F. Trình duyệt áp dụng tiêu chuẩn hẹp hơn cho web. RFC 3986 cung cấp đường cơ sở; WHATWG được xây dựng dựa trên đó.
Ví dụ đã hoạt động: một URL có dấu ngã, dấu cách và ký tự không phải ASCII — cách mỗi thế hệ quy tắc mã hóa nó
Các miền được quốc tế hóa sử dụng mã hóa punycode (München trở thành xn--mnchen-3ya). Đường dẫn và truy vấn vẫn sử dụng mã hóa phần trăm. Phần miền sử dụng punycode; phần đường dẫn và truy vấn sử dụng mã hóa phần trăm. Các lớp không trộn lẫn hoặc can thiệp.
IDNA (Tên miền quốc tế hóa trong ứng dụng) giải quyết vấn đề tên máy chủ. Punycode mã hóa non-ASCII thành ASCII để có khả năng tương thích DNS. Tiền tố xn-- báo hiệu mã hóa punycode. Thuật toán có tính xác định: münchen luôn trở thành xn--mnchen-3ya. Các ký tự không phải ASCII phải chuyển đổi trước độ phân giải DNS. Mã hóa phần trăm không hoạt động đối với tên máy chủ do các ràng buộc DNS và giới hạn nhãn. Mỗi cách tiếp cận giải quyết vấn đề khác nhau một cách chính xác. Các tiêu chuẩn được phát triển riêng biệt vì những lý do chính đáng.
Điều này không bao gồm những gì - IRI và tên miền quốc tế hóa, có lịch sử riêng
Việc lựa chọn tiêu chuẩn phụ thuộc vào bối cảnh. Xây dựng URL cho trình duyệt? Theo dõi RFC 3986; trình duyệt áp dụng WHATWG. Hệ thống cũ hơn? Triển khai thử nghiệm. Hiểu biết về sự tiến hóa ngăn ngừa sự nhầm lẫn.
Các nhà xây dựng hiện đại nên tuân theo RFC 3986 hoặc WHATWG theo ngữ cảnh. URL cũ và mới cùng tồn tại đòi hỏi phải suy nghĩ cẩn thận về khả năng tương thích. Bộ mã hóa và giải mã URL tuân theo RFC 3986 xuyên suốt, cung cấp tham chiếu cố định tách biệt với hoạt động của trình duyệt. WHATWG thêm các bộ mã hóa dành riêng cho thành phần ngoài những điều cơ bản về RFC. Biết được điều gì đã thay đổi khi nào sẽ giúp hiểu được tại sao các hệ thống lại không đồng ý. Việc kiểm tra URL của bạn với cả hai tiêu chuẩn sẽ tiết lộ những biện pháp kiểm soát tiêu chuẩn nào trong môi trường của bạn. Cả hai tiêu chuẩn đều đúng.
Bài học rút ra: biết mã của bạn tuân theo sách quy tắc nào — cách bộ mã hóa và giải mã URL cung cấp cho bạn hành vi RFC 3986 làm điểm tham chiếu cố định
RFC 3986 chuẩn hóa cho phép giải mã các ký tự không được mã hóa theo phần trăm không cần thiết một cách an toàn. %41 chuẩn hóa thành A. Các ký tự dành riêng được mã hóa như %2F không bao giờ giải mã; thay đổi ý nghĩa phá vỡ cấu trúc. Các cơ quan tiêu chuẩn duy trì khả năng tương thích ngược một cách quyết liệt. Việc sửa chữa đòi hỏi sự phối hợp trên toàn thế giới là điều không thể thực hiện được sau nhiều thập kỷ. Sách tiêu chuẩn không phá vỡ trang web về trước. Việc thay đổi quyết định mã hóa sẽ phá vỡ đồng thời hàng tỷ hệ thống hiện có.
Mã hóa phần trăm trải qua ba thập kỷ phát triển cẩn thận: từ RFC 1738 đến RFC 2396 và RFC 3986 đến Tiêu chuẩn WHATWG URL hiện đại. Mã hiện đại phải tuân theo đường cơ sở RFC 3986. Các URL cũ có mã hóa trước đó vẫn hợp lệ. Kiểm tra các chuyến đi khứ hồi đảm bảo tính chính xác và khả năng tương thích.