Mã hóa / Giải mã
Mã hóa hoặc giải mã Base64, Base64URL, mã hóa phần trăm URL, thực thể HTML và hex ngay khi gõ, hỗ trợ đầy đủ UTF-8.
Không có gì bạn nhập được lưu lại - dữ liệu được chuyển đổi và trả về ngay trong cùng một yêu cầu.
Mã hóa hoặc giải mã Base64, Base64URL, mã hóa phần trăm URL, thực thể HTML và hex ngay khi gõ, hỗ trợ đầy đủ UTF-8.
Không có gì bạn nhập được lưu lại - dữ liệu được chuyển đổi và trả về ngay trong cùng một yêu cầu.
Một token trong log, một query string trong lệnh chuyển hướng, một email đầy &: văn bản đã mã hóa xuất hiện khắp nơi trong công việc. Dán vào đây, chọn định dạng và xem kết quả mã hóa hoặc giải mã ngay khi gõ.
JSON Web Token gồm ba phần Base64URL nối bằng dấu chấm: header, payload và chữ ký. Dán phần ở giữa, chọn Base64URL rồi giải mã, bạn sẽ thấy các claim JSON như id người dùng và thời điểm hết hạn exp (một Unix timestamp có thể đọc bằng công cụ Chuyển đổi Unix timestamp). Giải mã không phải là xác minh: ai cũng đọc được payload của JWT, và chỉ việc kiểm tra chữ ký trên máy chủ mới chứng minh nó không bị sửa.
Base64 bị bỏ padding, điều mà một số hệ thống làm để tiết kiệm chỗ, sẽ lỗi ở các bộ giải mã nghiêm ngặt; công cụ này thêm các dấu = còn thiếu và báo cho bạn. Nhiều máy chủ hiểu dấu + trong query string là dấu cách, nên giá trị Base64 dán thẳng vào liên kết mà không mã hóa sẽ bị hỏng khi đến nơi; hãy mã hóa nó như một thành phần URL hoặc dùng Base64URL. Văn bản bị mã hóa hai lần hiện ra dạng %2520 hoặc & và cần giải mã hai lần.
Giải mã Base64 bỏ qua khoảng trắng và xuống dòng, nên một giá trị bị ngắt thành nhiều dòng, như trong email, vẫn được giải mã nguyên như khi dán. Base64URL cũng chấp nhận + và /, nhưng Base64 thường từ chối - và _, nên một phần của JWT cần tùy chọn Base64URL. Giải mã hex bỏ qua khoảng trắng, dấu hai chấm, dấu phẩy, gạch nối và tiền tố 0x, nên cả 48:65:6c:6c:6f và 0x48 0x65 đều được. Giải mã URL biến + thành khoảng trắng, nên một dấu cộng thật phải được gửi dưới dạng %2B. Mã hóa HTML thoát năm ký tự & < > " và '; giải mã HTML hiểu mọi thực thể có tên của HTML5 như và …, cùng thực thể dạng số như ₹ cho ký hiệu rupee.
Mã hóa URL ở đây mã hóa một giá trị, chẳng hạn một tham số truy vấn, nên mọi ký tự dành riêng đều được thoát: https://example.com/a b?x=1&y=2 thành https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2. Chỉ mã hóa giá trị bạn chèn vào liên kết, đừng mã hóa cả liên kết. Văn bản ngoài ASCII được mã hóa theo các byte UTF-8: café ₹ thành caf%C3%A9%20%E2%82%B9, và hex hiển thị đúng các byte đó, é là c3 a9 và ₹ là e2 82 b9. Base64 của user:pass là dXNlcjpwYXNz, giá trị mà header HTTP Basic Authorization mang theo (RFC 7617), vì vậy bất kỳ ai thấy header đó đều đọc được mật khẩu.
Các byte vốn là UTF-8 nhưng ở đâu đó đã bị đọc như Latin-1 hoặc Windows-1252 trước khi mã hóa. Giải mã ở đây hiển thị đúng các byte như chúng vốn có; cần sửa ở hệ thống đã tạo ra chúng.
Dán văn bản tối đa 200.000 ký tự. Với tệp nhị phân như hình ảnh, các byte đã giải mã được hiển thị dạng hex thay vì trở thành tệp tải xuống.
Không. Base64 chỉ thay đổi cách viết các byte để chúng đi qua được những hệ thống chỉ chấp nhận văn bản thuần. Ai cũng giải mã được; đừng bao giờ dùng nó để giấu mật khẩu hay bí mật.
Base64URL thay "+" và "/" bằng "-" và "_" và thường bỏ padding "=", nên kết quả an toàn trong URL và tên tệp. JSON Web Token dùng định dạng này.
Không. Văn bản được chuyển đổi và trả về trong cùng một yêu cầu và không bao giờ được ghi vào cơ sở dữ liệu hay log.
Công cụ này còn thoát cả ! ' ( ) và *, những ký tự mà encodeURIComponent giữ nguyên, nên it's (50%) off! thành it%27s%20%2850%25%29%20off%21. Cả hai dạng đều giải mã ra cùng một văn bản, và thoát các ký tự đó luôn an toàn trong giá trị truy vấn. Dấu cách thành %20, không phải +; dạng + đến từ mã hóa biểu mẫu HTML, và bộ giải mã ở đây đọc được cả hai.
Trên Linux hoặc Mac, echo -n 'Hello, World' | base64 cho ra SGVsbG8sIFdvcmxk, và echo 'SGVsbG8sIFdvcmxk' | base64 --decode chuyển nó về lại văn bản. Nếu bỏ -n, echo sẽ thêm một ký tự xuống dòng và ký tự đó cũng bị mã hóa, cho ra SGVsbG8sIFdvcmxkCg==: lý do phổ biến nhất khiến hai công cụ cho kết quả khác nhau. Trong PowerShell, [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) mã hóa và [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) giải mã. Trang này mã hóa đúng các ký tự bạn dán vào, dưới dạng UTF-8, và không thêm ký tự xuống dòng.
Chỉ dán phần sau dấu phẩy: trong data:image/png;base64,iVBORw0KGgo... đó là iVBORw0KGgo..., vì tiền tố data:image/png;base64, không phải Base64 và cả chuỗi sẽ bị từ chối. Chọn Base64 rồi Decode. Các byte không phải văn bản được hiển thị dạng hex thay vì vẽ thành ảnh, và như vậy đủ để biết đó là tệp gì: PNG bắt đầu bằng 89 50 4e 47, JPEG bằng ff d8 ff, còn cả một tệp .docx, .xlsx hoặc tệp dựa trên ZIP khác bằng 50 4b 03 04. Để xem chính bức ảnh, hãy dán toàn bộ data URI vào thanh địa chỉ của trình duyệt. Đầu vào tối đa 200.000 ký tự, khoảng 150.000 byte tệp.
Base64 viết mỗi 3 byte thành 4 ký tự và đệm nhóm cuối bằng dấu = cho đủ bội số của 4 (RFC 4648), nên đầu ra bằng 4/3 số byte đầu vào, làm tròn lên. Hello, World là 12 byte và thành 16 ký tự SGVsbG8sIFdvcmxk. Đơn vị đếm là byte UTF-8, không phải chữ: café có 4 ký tự nhưng 5 byte và thành Y2Fmw6k=, còn ₹100 là 6 byte và thành 4oK5MTAw. Chữ tiếng Việt có dấu thường chiếm 2 hoặc 3 byte, nên Base64 của văn bản tiếng Việt dài hơn so với số ký tự. Tệp đính kèm email còn lớn thêm một chút vì MIME ngắt Base64 thành các dòng tối đa 76 ký tự (RFC 2045); trang này bỏ qua các dấu xuống dòng đó khi giải mã. Base64URL không đệm chỉ tiết kiệm được các dấu =.