Mã hóa & giải mã Base64 / URL / JWT
Mã hóa và giải mã Base64 hoặc URL, xem phần header và payload của JWT ngay trên trình duyệt.
Cách sử dụng
- Dán hoặc nhập dữ liệu vào ô "Văn bản hoặc JWT": văn bản thường để mã hóa, chuỗi Base64 hoặc chuỗi mã hóa phần trăm để giải mã, hoặc một JWT để xem nội dung.
- Nhấp "Mã hóa Base64" hoặc "Giải mã Base64" để chuyển đổi giữa văn bản và Base64, hoặc "Mã hóa URL" hay "Giải mã URL" để thêm hoặc bỏ mã hóa phần trăm. Kết quả, hoặc thông báo lỗi, hiện trong ô "Kết quả".
- Để xem một token, hãy dán token đó, có hoặc không có tiền tố Bearer, rồi nhấp "Giải mã JWT". Header và payload hiện dưới dạng JSON có thụt lề, còn các claim iat, nbf và exp có trong payload được liệt kê trong "Các claim thời gian của JWT", với giá trị dạng số được chuyển sang giờ UTC và giờ địa phương của bạn.
- Nhấp "Sao chép kết quả" để sao chép đầu ra. Để đảo ngược việc mã hóa, hãy dán văn bản đã mã hóa vào ô "Văn bản hoặc JWT" rồi nhấp nút giải mã tương ứng. Giải mã rồi mã hóa lại có thể không cho ra đúng bản gốc: Base64 an toàn cho URL hoặc không có phần đệm sẽ trở về bảng chữ cái chuẩn, kèm phần đệm = khi cần, và "Mã hóa URL" biến dấu + mà "Giải mã URL" để lại thành %2B.
Câu hỏi thường gặp
Văn bản hoặc token tôi dán có được gửi đi đâu không?
Không. Việc mã hóa và giải mã chạy bằng JavaScript trên trình duyệt của bạn, và nội dung bạn nhập không được gửi tới LeedyBox. JWT thường được dùng làm thông tin đăng nhập, và ai có token cũng có thể dùng được cho đến khi nó hết hạn hoặc bị thu hồi, nên hãy đối xử với token còn hiệu lực như mật khẩu và đừng chia sẻ nó qua ảnh chụp màn hình hay tin nhắn.
Vì sao "Giải mã Base64" báo dữ liệu không phải văn bản UTF-8 hợp lệ?
"Giải mã Base64" hiển thị các byte đã giải mã dưới dạng văn bản UTF-8 và dừng lại với lỗi này khi chúng không phải UTF-8 hợp lệ, ví dụ với ảnh PNG hoặc JPEG, hầu hết tệp PDF và dữ liệu nén, và thường cả văn bản được lưu bằng bảng mã khác như Latin-1 hoặc Shift_JIS. Công cụ không lưu các byte đã giải mã thành tệp, vì vậy hãy dùng nó cho Base64 chứa văn bản. Data URI như data:image/png;base64,... bị từ chối vì là Base64 không hợp lệ, do dấu hai chấm, dấu chấm phẩy và dấu phẩy không phải ký tự Base64.
Công cụ có xử lý được Base64 an toàn cho URL và Base64 thiếu phần đệm không?
Có, khi giải mã: "Giải mã Base64" chấp nhận cả bảng chữ cái chuẩn (+ và /) lẫn bảng chữ cái an toàn cho URL (- và _), có hoặc không có phần đệm =, và bỏ qua dấu cách cũng như dấu xuống dòng. "Mã hóa Base64" xuất ra theo bảng chữ cái chuẩn có phần đệm; để có dạng an toàn cho URL dùng trong JWT, hãy thay + bằng -, / bằng _ và xóa các dấu = ở cuối. Văn bản được mã hóa UTF-8 đúng như khi nhập, nên một dấu cách hoặc dấu xuống dòng ở cuối sẽ làm thay đổi kết quả, và dấu xuống dòng trong ô được mã hóa thành LF.
Tôi có nên dán cả một URL vào "Mã hóa URL" không?
Thường là không. "Mã hóa URL" hoạt động như encodeURIComponent của JavaScript: nó mã hóa phần trăm mọi ký tự trừ A–Z, a–z, 0–9 và - _ . ! ~ * ' ( ), nên các ký tự / ? & = : và # tạo nên cấu trúc URL cũng bị mã hóa. Hãy dùng nó cho một phần riêng lẻ, chẳng hạn giá trị của một tham số truy vấn. Dấu cách thành %20, còn ký tự ngoài ASCII được mã hóa theo các byte UTF-8 của nó, nên é thành %C3%A9.
Vì sao dấu cộng không được đổi thành dấu cách, và khi nào "Giải mã URL" báo lỗi?
"Giải mã URL" hoạt động như decodeURIComponent của JavaScript: nó giải mã các chuỗi thoát %XX và giữ nguyên dấu +, vì trong cú pháp URL tổng quát (RFC 3986), + không biểu thị dấu cách. Dữ liệu biểu mẫu HTML (application/x-www-form-urlencoded), định dạng mà nhiều chuỗi truy vấn sử dụng, mã hóa dấu cách thành +, nên với loại dữ liệu này, hãy thay mỗi dấu + bằng dấu cách trước khi giải mã; dấu cộng thật trong định dạng đó được viết là %2B và vẫn được giải mã đúng. Lỗi xuất hiện khi sau % không có hai chữ số thập lục phân, như trong 50% off, hoặc khi các byte được thoát không phải UTF-8 hợp lệ, như trong %E2%82.
"Giải mã JWT" đọc được những token nào?
Các token ở dạng rút gọn ba phần header.payload.signature mà JWT có chữ ký (JWS) sử dụng, kể cả token không ký có phần chữ ký trống. Phần chữ ký không được kiểm tra, nên một token giải mã được không chứng minh rằng nó là thật. Token mã hóa (JWE) có năm phần và không thể đọc payload nếu không có khóa, nên sẽ gặp lỗi định dạng. Header hoặc payload không giải mã được từ Base64 sang JSON, hoặc payload là một giá trị đơn như chuỗi hay số thay vì đối tượng JSON, sẽ cho thông báo "Lỗi phân tích JWT". Số nguyên lớn hơn 9.007.199.254.740.991 trong header hoặc payload có thể bị làm tròn khi trình duyệt phân tích JSON, nên các ID dạng số dài có thể hiển thị khác ở vài chữ số cuối.
Thời gian exp, nbf và iat được hiển thị thế nào, và khi nào token bị đánh dấu là hết hạn?
Các giá trị được đọc là thời gian Unix tính bằng giây, đúng như chuẩn JWT (RFC 7519) quy định, và được hiển thị theo giờ UTC và giờ địa phương của bạn. "ĐÃ HẾT HẠN" và "Chưa có hiệu lực" so sánh exp và nbf với đồng hồ của thiết bị tại thời điểm bạn nhấp "Giải mã JWT", không tính đến chênh lệch đồng hồ, nên đồng hồ sai sẽ cho trạng thái sai. Máy chủ có thể cho phép một khoảng dung sai nhỏ, thường không quá vài phút, nên ở gần thời điểm exp hoặc nbf, máy chủ có thể đánh giá khác với trạng thái hiển thị ở đây. Thời gian được ghi dưới dạng chuỗi, như "1700000000", sẽ được báo là không phải dấu thời gian Unix dạng số hợp lệ.