Bộ giải mã URL

Bộ giải mã URL là công cụ miễn phí giúp chuyển văn bản URL được mã hóa phần trăm về dạng chuỗi ban đầu.

Giải mã URL có tác dụng gì?

Giải mã URL đảo ngược cơ chế thoát ký tự dùng để truyền khoảng trắng, dấu câu và các byte khác qua URL cũng như những cú pháp có quy định sử dụng mã hóa phần trăm. Với cách mã hóa này, mỗi byte được biểu diễn bằng dấu phần trăm, theo sau là hai chữ số thập lục phân. Kiểu mã hóa URL dùng cho biểu mẫu còn dùng dấu + để biểu thị khoảng trắng. Ví dụ, khoảng trắng có thể được viết thành %20 và dấu và thành %26.

Ví dụ ngắn trước và sau khi giải mã:

Dữ liệu đầu vào đã mã hóa: red%20%26%20blue

Kết quả đã giải mã: red & blue

Cách mã hóa này cần thiết vì một số ký tự có vai trò cấu trúc trong URL. Dấu hỏi phân tách phần truy vấn của URL, còn trong dữ liệu truy vấn kiểu biểu mẫu, dấu và theo nghĩa đen thường dùng để ngăn cách các trường. Việc mã hóa những ký tự đó cho phép ứng dụng truyền chúng dưới dạng dữ liệu thay vì ký hiệu phân tách.

Mã hóa URL không phải là mã hóa bảo mật và không giữ bí mật dữ liệu. Bất kỳ ai đọc được giá trị đã mã hóa đều có thể giải mã nó. Không nên xem mật khẩu, mã truy cập hoặc thông tin cá nhân được mã hóa phần trăm là dữ liệu đã được bảo vệ.

Cách dùng Bộ giải mã URL như thế nào?

Dán hoặc nhập văn bản đã mã hóa, tiến hành xử lý, rồi xem giá trị được khôi phục trong trường kết quả URL đã giải mã. Công cụ sử dụng hàm urldecode của PHP, vì vậy các chuỗi %HH hợp lệ sẽ được chuyển đổi và dấu cộng được coi là khoảng trắng.

1. Sao chép thành phần đã mã hóa, chẳng hạn như giá trị của một tham số truy vấn.
2. Nhập giá trị được mã hóa URL mà không thêm dấu ngoặc kép, trừ khi các dấu đó thực sự là một phần của giá trị.
3. Xử lý dữ liệu URL đầu vào rồi kiểm tra kết quả URL đã giải mã.
4. Nếu kết quả vẫn còn các chuỗi như %2F hoặc %20, hãy kiểm tra xem dữ liệu nguồn có bị mã hóa nhiều lần hay không trước khi giải mã lại.

Quá trình xử lý diễn ra trên máy chủ. Dữ liệu đầu vào được gửi tới máy chủ qua HTTPS và không được lưu trữ, nhưng vẫn rời khỏi thiết bị của bạn trong lúc xử lý. Không dán thông tin bí mật vào Bộ giải mã URL này, trừ khi việc xử lý trên máy chủ phù hợp với dữ liệu đó.

Mã hóa URL được dùng ở đâu?

Bạn thường gặp mã hóa URL trong chuỗi truy vấn, dữ liệu gửi từ biểu mẫu và các giá trị được nhúng trong liên kết. Nó cũng xuất hiện ở một số nơi ít rõ ràng hơn, khi dữ liệu phải đi qua định dạng văn bản bị giới hạn.

• Chuỗi truy vấn: nội dung tìm kiếm "tea & cake" có thể xuất hiện dưới dạng q=tea+%26+cake.
• URI dữ liệu: dữ liệu văn bản có thể được mã hóa phần trăm sau loại phương tiện, dù Base64 cũng là một cách biểu diễn phổ biến.
• Liên kết email: liên kết mailto có thể mã hóa khoảng trắng, dấu xuống dòng và dấu câu trong tham số tiêu đề hoặc nội dung. Các kiểu mã hóa truyền MIME dùng bên trong thư điện tử là những định dạng riêng biệt.
• Payload JSON: bản thân JSON có quy tắc thoát ký tự riêng, nhưng một chuỗi JSON có thể chứa URL hoặc giá trị truy vấn đã được mã hóa và cần giải mã riêng.
• Tên miền quốc tế hóa: nhãn tên miền chứa ký tự ngoài ASCII thường dùng Punycode thay vì mã hóa phần trăm. Các thành phần đường dẫn và truy vấn vẫn có thể chứa những byte UTF-8 được mã hóa phần trăm.

Nếu văn bản đã mã hóa là một nhãn tên miền bắt đầu bằng xn--, hãy dùng Trình chuyển đổi Punycode IDN. Bộ giải mã URL dành cho các thành phần URL được mã hóa phần trăm, không dùng để chuyển đổi Punycode.

Ví dụ giải mã URL cụ thể

Các ví dụ dưới đây minh họa những dữ liệu đầu vào thường gặp và văn bản tương ứng sau khi giải mã URL.

• hello%20world trở thành hello world.
• name=Tom+Jones trở thành name=Tom Jones.
• fish%26chips trở thành fish&chips.
• %C2%A3 trở thành £ khi các byte biểu diễn văn bản UTF-8.
• %E6%9D%B1%E4%BA%AC trở thành 東京 khi được diễn giải dưới dạng UTF-8.
• 100%25 trở thành 100%.

Chữ cái, chữ số và dấu câu chưa mã hóa thường được giữ nguyên như dữ liệu đã nhập. Dữ liệu đầu vào trống tạo ra kết quả URL đã giải mã trống. Dữ liệu đầu vào rất dài vẫn tuân theo các quy tắc giải mã tương tự, dù trình duyệt, máy chủ và hệ thống tiếp nhận có thể áp dụng giới hạn riêng đối với độ dài yêu cầu hoặc URL.

Các ký tự có dấu và ký tự không thuộc bảng chữ cái Latinh thường được mã hóa thành một chuỗi byte UTF-8, trong đó từng byte được viết riêng. Nếu hệ thống ban đầu sử dụng một bảng mã ký tự khác, các byte sau khi giải mã có thể hiển thị thành ký hiệu thay thế hoặc văn bản có vẻ vô nghĩa.

Vì sao giải mã URL thất bại hoặc cho ra ký tự khó hiểu?

Kết quả giải mã URL có thể không thay đổi hoặc không như mong đợi nếu dữ liệu đầu vào chứa chuỗi phần trăm chưa hoàn chỉnh, đã bị mã hóa nhiều lần, được diễn giải bằng sai bộ ký tự hoặc hoàn toàn không phải dữ liệu mã hóa URL. Hàm urldecode của PHP giữ nguyên các chuỗi phần trăm sai định dạng, còn dữ liệu bị mã hóa hai lần chỉ cho ra kết quả trung gian sau một lượt giải mã. Hãy kiểm tra nguồn ban đầu trước khi giải mã lặp lại.

• Dữ liệu bị mã hóa hai lần: %2520 được giải mã một lần thành %20 và chỉ trở thành khoảng trắng sau lượt giải mã thứ hai. Chỉ giải mã thêm khi bạn biết chắc có một lớp mã hóa khác.
• Chuỗi phần trăm chưa hoàn chỉnh: mỗi byte đã mã hóa cần hai chữ số thập lục phân. Dấu % ở cuối hoặc giá trị như %2 bị sai định dạng và không thể biểu diễn một byte mã hóa hoàn chỉnh, vì vậy hàm urldecode của PHP giữ nguyên chúng.
• Sai bảng mã ký tự: giải mã phần trăm khôi phục các byte. Chẳng hạn, nếu diễn giải byte ISO-8859-1 dưới dạng UTF-8, kết quả có thể trở nên khó hiểu dù các chuỗi phần trăm hoàn toàn hợp lệ.
• Dữ liệu nhị phân thay vì văn bản: các byte đã giải mã có thể là hình ảnh, tệp nén hoặc nội dung nhị phân khác. Loại kết quả này không thể hiển thị thành văn bản dễ đọc như thông thường.
• Sai họ mã hóa: nếu kết quả giải mã URL sau đó được đưa vào Bộ giải mã Base64, công cụ đó có thể thất bại do khác biệt giữa bảng ký tự chuẩn và bảng ký tự an toàn cho URL, thiếu phần đệm = hoặc dữ liệu đầu vào bị hỏng. Mã hóa phần trăm URL không có phần đệm và không dùng bảng ký tự Base64. Việc giải mã URL cũng không xác thực hoặc sửa những lỗi Base64 này.

Hãy cẩn thận với dấu cộng theo nghĩa đen. Trong kiểu mã hóa URL dùng cho biểu mẫu, + có nghĩa là khoảng trắng. Dấu cộng thực sự thường phải được mã hóa thành %2B trước khi giải mã.

Câu hỏi thường gặp

Nên giải mã toàn bộ URL hay chỉ một phần?

Nếu có thể, chỉ nên giải mã riêng từng đoạn đường dẫn hoặc giá trị tham số truy vấn. Giải mã toàn bộ URL có thể biến các ký tự dành riêng đã mã hóa như %26, %3F hoặc %2F thành dấu phân tách và làm thay đổi cách URL được phân tích.

Bộ giải mã URL có xử lý mã thập lục phân viết thường không?

Có. Chữ số thập lục phân trong chuỗi phần trăm không phân biệt chữ hoa và chữ thường, vì vậy %2f và %2F đều biểu diễn cùng một byte. Chuỗi kết hợp cả chữ hoa lẫn chữ thường cũng hợp lệ.

Công cụ có giải mã lặp lại cùng một giá trị không?

Không. Mỗi lần gọi urldecode chỉ thực hiện một lượt giải mã. Nếu %252F trở thành %2F, cần thêm một lượt nữa để tạo ra dấu gạch chéo. Tuy nhiên, việc giải mã lặp lại có thể làm thay đổi dữ liệu vốn được chủ ý để chứa một chuỗi phần trăm theo nghĩa đen.

Giải mã URL có khôi phục được văn bản bị hỏng không?

Không. Quá trình này có thể đảo ngược mã hóa phần trăm hợp lệ, nhưng không thể tái tạo các chữ số thập lục phân bị thiếu hoặc xác định chắc chắn bảng mã ký tự ban đầu. Hãy kiểm tra hệ thống nguồn, tiêu đề HTTP hoặc tài liệu liên quan nếu các byte đã giải mã không hiển thị đúng.

Tôi nên làm gì với giá trị bắt đầu bằng xn--?

Hãy coi đó là nhãn tên miền Punycode, không phải văn bản mã hóa phần trăm thông thường. Dùng Trình chuyển đổi Punycode IDN, sau đó kiểm tra kỹ tên miền nhận được vì các ký tự Unicode trông giống nhau có thể thuộc những hệ chữ viết khác nhau.