Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
Khoảng trắng trong liên kết tải xuống tệp: tại sao %20, + và khoảng trống thô không giống nhau
· Tại sao nó quan trọng
url-encoding http developer-workflow
Tệp có tên 'Báo cáo Q3 (cuối cùng).pdf' có thể được liên kết theo ba cách khác nhau và chỉ có một cách chính xác đáng tin cậy. Bài đăng này giải thích lý do tại sao tên tệp phá vỡ các liên kết tải xuống và cách mã hóa chúng để mọi khách hàng đều đồng ý.
Quá trình tải xuống không thành công đối với một số người dùng và hoạt động với những người khác — tên tệp có dấu cách và dấu cộng
Các tệp như "Q3 report.pdf" hoạt động tốt khi được lưu trữ cục bộ nhưng không thành công qua liên kết tải xuống đối với một số người dùng trong khi những người khác lại thành công mà không gặp sự cố. Khoảng trắng thô không hợp lệ trong các URL theo thông số RFC 3986. Các trình duyệt chấp nhận chúng trên thanh địa chỉ nhưng khách hàng HTTP nghiêm khắc từ chối chúng. Hiểu %20, dấu cộng và khoảng trắng thô là điều vô cùng cần thiết để phân phối đáng tin cậy. Sự khác biệt giữa các phương pháp mã hóa ảnh hưởng trực tiếp đến tỷ lệ tải xuống thành công trên các nền tảng khác nhau, nhiều công cụ tự động hóa khác nhau và HTTP triển khai ứng dụng khách trên toàn thế giới. Các nhà phát triển phải hiểu sự khác biệt này khi xây dựng hệ thống tải xuống. Bối cảnh quan trọng đối với các lựa chọn mã hóa và khả năng tương thích của hệ thống.
Nhà phát triển phải chọn giữa các khoảng trắng thô, %20 hoặc dấu cộng khi tạo liên kết tải xuống. Thử nghiệm với Curl, wget và Python sẽ tiết lộ ứng dụng khách nào thực thi tuân thủ RFC. Tải xuống trình duyệt thành công do khôi phục lỗi nhưng quá trình tích hợp API không thành công khi gặp phải khoảng trắng chưa được mã hóa.
Tại sao không gian thô không hợp lệ trong URL — và tại sao trình duyệt chấp nhận nó trên thanh địa chỉ nhưng ứng dụng khách HTTP thì không
Khoảng trắng thô trong URL có nguồn gốc lịch sử trong thiết kế giao thức. Các URL đi qua hệ thống coi khoảng trắng là dấu phân cách giữa các mã thông báo. Một khoảng trắng trong URL có thể bị hiểu sai là dấu kết thúc của nó. HTTP ứng dụng khách đọc từ dòng lệnh sẽ bị cắt bớt ở khoảng trắng đầu tiên. Thiết kế nền tảng này vẫn còn trong quá trình triển khai giao thức và khó có thể thay đổi.
Trình duyệt chấp nhận không gian thô thông qua chuyển đổi im lặng sang %20 trước khi gửi yêu cầu HTTP. Hành vi thân thiện với người dùng này ẩn các yêu cầu về giao thức khỏi việc người dùng cuối dán URL vào thanh địa chỉ. Hệ thống tự động thiếu lớp khôi phục này. Tập lệnh không thành công trên các URL có khoảng trống thô. Ứng dụng email khách gặp phải lỗi khi mở các liên kết như vậy.
%20 so với + trong một đoạn đường dẫn — quy ước mã hóa biểu mẫu không áp dụng cho đường dẫn
%20 so với dấu cộng thể hiện sự khác biệt cơ bản trong bối cảnh mã hóa URL. Trong các đoạn đường dẫn, dấu cách phải mã hóa dưới dạng %20 trên RFC 3986. Dấu cộng không phải là mã hóa khoảng trắng trong đường dẫn. Quy ước này bắt nguồn từ mã hóa biểu mẫu HTML trong đó nó đóng vai trò mã hóa khoảng trắng trong chuỗi truy vấn. Các nhà phát triển thường áp dụng sai quy tắc biểu mẫu cho đường dẫn.
Các quy ước mã hóa biểu mẫu cho phép dấu cộng không áp dụng cho các đường dẫn có yêu cầu cấu trúc khác nhau. Trong chuỗi truy vấn, ký hiệu và tham số phân cách bằng. Việc sử dụng dấu cộng cho khoảng trắng trong giá trị truy vấn sẽ không tạo ra sự mơ hồ vì dấu cộng không phải là dấu phân cách. Trong đường dẫn, dấu cộng không có ý nghĩa đặc biệt. Các quy ước trộn lẫn sẽ tạo ra các liên kết tải xuống bị hỏng.
Tên tệp không phải ASCII - UTF-8 mã hóa phần trăm và khóa lưu trữ đối tượng lưu trữ tên thô
Tên tệp không phải ASCII yêu cầu mã hóa UTF-8 phần trăm trước khi truyền an toàn trong URL. Tên tệp như "Über report.pdf" chứa "Ü" (U+00DC) nằm ngoài phạm vi ASCII. Mã hóa UTF-8 chuyển đổi giá trị này thành byte C3 9C. Các byte phần trăm này được mã hóa dưới dạng %C3%9C trong URL. Mỗi byte UTF-8 có bộ ba riêng, tạo ra tên tệp được mã hóa dài hơn.
Các dịch vụ lưu trữ đối tượng như Amazon S3 đưa ra các trường hợp thú vị đối với tên tệp không phải ASCII. Một số hệ thống cho phép UTF-8 byte thô trong khóa trong khi các hệ thống khác yêu cầu mã hóa phần trăm. Chiến lược mã hóa phụ thuộc vào nhà cung cấp bộ nhớ và mức sử dụng URL. Quyền truy cập dựa trên URL yêu cầu UTF-8 được mã hóa phần trăm. Nhà phát triển phải phối hợp các lớp lưu trữ và URL thế hệ.
Ví dụ đã hoạt động: mã hóa 'báo cáo quý 3 Über (cuối cùng)+notes.pdf' cho một đường dẫn — đầu ra chính xác và lý do dấu + phải trở thành %2B
Ví dụ đã hoạt động: mã hóa "Über report (cuối cùng)+notes.pdf" thể hiện mã hóa hoàn chỉnh. Tên tệp chứa dấu cách, ký tự không phảiASCII và dấu cộng bằng chữ. UTF-8 mã hóa "Ü" tạo ra %C3%9C. Trong mã hóa đường dẫn, dấu cách trở thành %20 (không giống như mã hóa biểu mẫu bằng dấu cộng). Dấu cộng theo nghĩa đen trở thành %2B. Dấu ngoặc đơn mã hóa dưới dạng %28 và %29. Kết quả: %C3%9CberQ3%20report%20%28cuối cùng%29%2Bnotes.pdf.
Thử nghiệm với bộ mã hóa và giải mã URL cho thấy sự chuyển đổi chính xác. Việc dán tên tệp vào chế độ một giá trị sẽ tạo ra các phân đoạn được mã hóa phần trăm chính xác bằng cách sử dụng quy tắc đường dẫn. Công cụ này giữ nguyên các dấu phân cách đường dẫn trong khi chỉ mã hóa các thành phần tên tệp. So sánh trực quan giữa đầu vào và đầu ra giúp các quy tắc trở nên rõ ràng và có thể kiểm chứng trước khi sản xuất. So sánh điều này với chế độ biểu mẫu để thấy sự khác biệt về ngữ cảnh.
Tham số Content-Disposition và filename* — một mã hóa riêng cho lời nhắc tải xuống, được đề cập để đảm bảo tính đầy đủ
Các tham số Bố trí nội dung và tên tệp* biểu thị các lớp mã hóa thay thế cho lời nhắc tải xuống. Máy chủ bao gồm các tiêu đề Bố trí nội dung chỉ định tên tệp cho hộp thoại tải xuống. Tham số tên tệp sử dụng mã hóa RFC 2183 trong khi tên tệp* sử dụng RFC 5987 với mã hóa phần trăm. Trình duyệt diễn giải các tiêu đề này để quyết định tên tệp lưu. Tên tệp giống nhau mã hóa hai lần với các lược đồ khác nhau.
Hai lớp mã hóa tạo cơ hội cho lỗi chuyển mã. URL tên tệp được mã hóa và mã hóa tiêu đề có thể không chính xác nếu máy chủ và máy khách không đồng ý. Để có khả năng tương thích tối đa, nhà phát triển nên mã hóa tên tệp trong đường dẫn URL bằng cách sử dụng %20 và UTF-8 mã hóa phần trăm, đồng thời đặt tiêu đề Bố trí nội dung bằng tên tệp được giải mã. Điều này đảm bảo tất cả ứng dụng khách và trình duyệt HTTP đều hoạt động chính xác.
Điều này không bao gồm những gì - tên tệp dành riêng trên các hệ điều hành cụ thể và các yêu cầu riêng của nhà cung cấp lưu trữ
Tên tệp dành riêng trên các hệ điều hành cụ thể sẽ làm tăng thêm độ phức tạp cho quá trình mã hóa URL. Windows dành riêng các tên như CON, PRN và AUX cho thiết bị. Các tệp có tên theo nghĩa đen là "CON.pdf" không thể tồn tại trên NTFS. macOS có quy ước đặt tên và quy tắc thuộc tính mở rộng. Linux phân biệt chữ hoa chữ thường. Tên tệp được mã hóa URL hợp lệ có thể không hợp lệ để lưu trữ trên một số hệ thống nhất định.
Các đặc điểm riêng của nhà cung cấp dịch vụ lưu trữ làm tăng thêm độ phức tạp cho việc phân phối trên nhiều nền tảng. Amazon S3 chấp nhận khóa UTF-8 và phân biệt chữ hoa chữ thường. Google Cloud Storage hoạt động tương tự với các hạn chế bổ sung. Azure Blob Storage có các quy tắc ký tự khác nhau. Tên tệp hoạt động trên S3 có thể bị lỗi trên Azure. Kiến trúc sư phải kiểm tra tài liệu của nhà cung cấp và kiểm tra bằng tên tệp thực không phảiASCII.
Bài học rút ra: mã hóa phân đoạn, không phải URL - cách chế độ một giá trị của bộ mã hóa & giải mã URL tạo ra tên tệp an toàn cho đường dẫn
Bài học rút ra: mã hóa phân đoạn chứ không phải URL—chế độ một giá trị duy nhất của bộ mã hóa và giải mã URL tạo ra tên tệp an toàn cho đường dẫn. Công cụ này chấp nhận tên tệp thô và tạo ra các phân đoạn được mã hóa phần trăm. Điều này ngăn chặn bối cảnh mã hóa kép và trộn. Việc sử dụng chế độ một giá trị sẽ tránh việc cân bằng các quy tắc mã hóa đường dẫn, truy vấn và phân đoạn. Các phân đoạn đã tạo có thể an toàn để chèn vào URL.
Phương pháp hay nhất là mã hóa tên tệp khi chúng nhập vào cấu trúc URL. Đừng cho rằng trình duyệt khắc phục được sự cố mã hóa. Thử nghiệm với ứng dụng khách HTTP thực tế được người dùng mục tiêu sử dụng: Curl, wget, Python, Java httplib và API tìm nạp trình duyệt. Xác minh tên tệp tồn tại trong toàn bộ hệ thống. Bộ mã hóa & giải mã URL là điểm khởi đầu đảm bảo tính chính xác.