Bộ Mã Hóa Giải Mã Base32

Văn bản thường được mã hóa thành UTF-8 trước, sau đó chuyển sang Base32.
0 ký tự đầu vào

Mã hóa và giải mã Base32 online với 4 biến thể, chuyển đổi tệp, kiểm soát padding, xuất hex và tải xuống cục bộ cho secret TOTP và ID dễ đọc.

Đề xuất Liên quan

Base32 là gì?

Base32 là kiểu mã hóa nhị phân sang văn bản, biểu diễn byte bằng 32 ký tự có thể in được. Dạng chuẩn đến từ RFC 4648 và dùng A-Z cùng 2-7. Mỗi 5 bit tạo ra 1 ký tự, nên kết quả thường lớn hơn dữ liệu gốc khoảng 60%.

Base32 không phải định dạng ngắn nhất, nhưng hữu ích khi cần ít ký tự đặc biệt, môi trường không phân biệt hoa thường hoặc chuỗi mà con người phải đọc và nhập. Secret TOTP, một số giá trị DNS/config, mã kích hoạt và ID dễ đọc thường dùng Base32.

Trang này hỗ trợ RFC 4648 Base32, Base32hex, Crockford Base32 và z-base-32, cùng kiểm tra nghiêm ngặt, kiểm soát padding, xuống dòng, chuyển đổi văn bản/tệp và xem hex.

Trường hợp sử dụng

  • Kiểm tra secret TOTP/OTP có phải Base32 chuẩn hay không, hoặc chuyển sang Crockford hay z-base-32 để dễ đọc hơn.
  • Chuyển cấu hình nhị phân, đoạn certificate, mã kích hoạt offline hoặc fingerprint tài nguyên thành chuỗi dễ đọc, ít ký tự đặc biệt.
  • Gỡ lỗi giá trị Base32 từ hệ thống bên thứ ba bị lỗi vì thiếu padding, sai biến thể hoặc độ dài bất thường.
  • Kiểm tra payload Base32 chưa rõ dưới dạng UTF-8 hoặc hex trước, rồi tải file nhị phân nếu cần.

Cách Sử dụng

  1. Trước tiên chọn đúng biến thể: RFC 4648, Base32hex, Crockford hoặc z-base-32.
  2. Khi encode, chọn input là văn bản hoặc file, rồi đặt padding, chữ thường và độ rộng xuống dòng.
  3. Khi decode, dán chuỗi Base32; bật strict validation nếu cần kiểm tra độ dài và padding.
  4. Xem kết quả theo loại payload: văn bản, hex hoặc file nhị phân có thể tải xuống.

Tính năng

  • Chuyển giữa 4 biến thể Base32: RFC 4648, Base32hex, Crockford và z-base-32.
  • Xử lý văn bản và tệp: mã hóa văn bản UTF-8 hoặc tệp cục bộ sang Base32.
  • Xem kết quả giải mã dưới dạng văn bản UTF-8, hex hoặc tệp nhị phân có thể tải xuống.
  • Kiểm soát padding, chữ thường và xuống dòng ở 64, 76 hoặc độ rộng tùy chỉnh.
  • Kiểm tra nghiêm ngặt độ dài và padding ngay trong trình duyệt, không tải dữ liệu lên.

Khi nào nên dùng Base32, Base64 hoặc Base58?

Các định dạng này đều chuyển dữ liệu nhị phân thành chuỗi in được, nhưng phù hợp với các workflow khác nhau.

Định dạngPhù hợp nhất choĐánh đổi
Base32secret TOTP, ID dễ đọc và môi trường không phân biệt hoa thườngAlphabet thân thiện hơn với con người, nhưng output dài hơn Base64.
Base64Truyền văn bản/file thông thường, Data URL và API payloadGọn hơn, nhưng có thể chứa +, / và =; với URL hoặc tên file thường cần biến thể URL-safe.Bộ mã hóa Base64Base64 URL Safe
Base58Địa chỉ nhập tay, QR payload ngắn và ID kiểu blockchainTránh nhầm 0/O/I/l, nhưng không thuộc họ RFC 4648.Bộ mã hóa/giải mã Base58

Best Practices

Xác nhận biến thể trước khi gỡ lỗi

Lỗi Base32 thường gặp nhất không nằm ở thuật toán mà ở alphabet hoặc variant không khớp. Nếu hệ thống đích cần Base32hex, Crockford hoặc z-base-32, output chuẩn có thể trông đúng nhưng vẫn bị từ chối.

Xem hex trước khi cho rằng kết quả là văn bản

Byte sau khi decode Base32 không nhất thiết là văn bản UTF-8. Chế độ hex giúp nhận ra payload là certificate, header ảnh, archive, random key hay plain text.

Ưu tiên Crockford hoặc z-base-32 cho nhập tay

Nếu mục tiêu là giảm lỗi nhập liệu thay vì tuân thủ RFC 4648 nghiêm ngặt, các biến thể này giảm nhầm lẫn trực quan như O/0 và I/1.

Đừng ép toàn bộ quy trình ở Base32

Trong nhiều tác vụ thực tế, bước tiếp theo phù hợp hơn với Base64, hex hoặc file gốc. Đổi định dạng theo workflow thường tiết kiệm thời gian hơn.

Bộ mã hóa Base64Hex

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

Khi nào nên chọn Base32 thay vì Base64?

Base64 ngắn hơn và phổ biến hơn. Base32 phù hợp khi cần ít ký tự đặc biệt, môi trường không phân biệt hoa thường hoặc secret TOTP mà con người phải đọc và nhập.

RFC 4648, Base32hex, Crockford và z-base-32 khác nhau thế nào?

Khác biệt chính là bảng ký tự và khả năng chịu lỗi. RFC 4648 là chuẩn chung, Base32hex đặt số trước, Crockford tốt cho nhập tay, z-base-32 ưu tiên chữ thường dễ đọc.

Tại sao một số chuỗi Base32 kết thúc bằng =?

RFC 4648 Base32/Base32hex thường dùng = làm padding, còn Crockford và z-base-32 thường bỏ qua.

Decoded output looks wrong

Dữ liệu gốc có thể không phải UTF-8. Hãy xem hex hoặc tải tệp nhị phân.

File conversion supported?

Có. Bạn có thể chuyển tệp sang Base32 rồi khôi phục lại byte nhị phân.

Data upload?

Không. Việc xử lý diễn ra cục bộ trong trình duyệt.

Xử lý sự cố

Vì sao giá trị không khớp với kết quả của bên thứ ba?

Trước tiên hãy kiểm tra biến thể. Base32 chuẩn, Base32hex, Crockford và z-base-32 dùng alphabet khác nhau, nên khác biệt nhỏ cũng đổi toàn bộ kết quả.

Vì sao strict mode báo độ dài không hợp lệ?

Chuỗi có thể thiếu padding, chứa ký tự không hợp lệ hoặc được tạo từ biến thể khác. Hãy thử chế độ linh hoạt để nhận diện nội dung, rồi sửa chuỗi gốc.

Vì sao văn bản sau decode bị trống hoặc lỗi?

Dữ liệu gốc có thể không phải văn bản UTF-8 mà là file nhị phân hoặc byte ngẫu nhiên. Hãy dùng chế độ hex hoặc tải binary đã decode.

Thuật ngữ

RFC 4648 Base32
Biến thể Base32 chuẩn phổ biến nhất. Dùng A-Z và 2-7, có thể có padding =.
Base32hex
Biến thể theo thứ tự thập lục phân trong RFC 4648. Bảng ký tự là 0-9 và A-V.
Crockford Base32
Biến thể thân thiện với con người, bỏ I, L, O, U và chấp nhận O/0 cùng I/1/L/1 khi giải mã.
z-base-32
Biến thể cho nhập liệu con người, thường dùng chữ thường và không padding.
padding
Các ký tự = cuối chuỗi để bù độ dài cho Base32 chuẩn.

Bảng nhanh 4 biến thể Base32

Nếu chưa chắc nên chọn biến thể nào, hãy bắt đầu từ alphabet và cách dùng điển hình.

Biến thểAlphabetThường dùng =Cách dùng điển hình
RFC 4648A-Z + 2-7Thường cóTOTP và tương thích Base32 chuẩn
Base32hex0-9 + A-VThường cóThứ tự số hoặc field protocol cụ thể
Crockford0-9 + A-Z (without I/L/O/U)Thường khôngNhập tay, mã ngắn và chịu lỗi gõ nhầm
z-base-32ybndrfg8ejkmcpqxot1uwisza345h769Thường khôngChuỗi ngắn chữ thường dễ đọc hơn

Độ dài và padding của Base32 chuẩn

Trong RFC 4648 / Base32hex, số lượng = ở cuối phụ thuộc vào độ dài byte gốc.

Byte inputKý tự Base32 hiệu dụngPadding = cần thêm
126
244
353
471
580

Authoritative References