Mã hóa & Giải mã Base64

Base64 thực ra là gì

Base64 là một encoding — cách biểu diễn dữ liệu nhị phân bất kỳ bằng đúng 64 ký tự ASCII in được: A–Z, a–z, 0–9, +, /. Chuẩn này được mô tả trong RFC 4648 và ra đời từ thập niên 1980 để file đính kèm nhị phân có thể đi qua email mà không bị hỏng.

Base64 không phải mã hóa bảo mật. Ai có chuỗi đã mã hóa đều giải mã lại được mà không cần key. Khi cần bảo mật, dùng AES hoặc tầng TLS — Base64 chỉ giải bài toán "làm sao đẩy bytes qua kênh chỉ chấp nhận text".

Phép biến đổi rất cơ học: mỗi 3 byte đầu vào thành 4 ký tự đầu ra. Nếu đầu vào không chia hết cho 3, đầu ra được đệm = để tổng độ dài luôn chia hết cho 4. Đó là lý do bạn thấy = cuối một số chuỗi đã mã hóa (không có, một, hoặc hai dấu).

Khi nào bạn cần Base64

• Data URI: nhúng ảnh nhỏ trực tiếp vào CSS/HTML: url("data:image/png;base64,iVBOR…").
• JWT: mỗi phần của JSON Web Token là JSON được mã hóa Base64URL.
• HTTP Basic auth: header Authorization: Basic … chính là user:pass đã Base64.
• Đính kèm email (MIME): file nhị phân được wrap Base64 để qua mail server an toàn.
• Payload API: gửi blob nhị phân qua JSON (vốn không có kiểu binary).
• Lưu nhị phân trong database hoặc biến môi trường vốn chỉ chấp nhận text.

Không dùng Base64 để "thu gọn" dữ liệu — nó làm to thêm ~33%. Đây là encoding cho transport, không phải nén.

Lỗ hổng UTF-8

Hàm btoa() có sẵn của trình duyệt nhìn có vẻ làm đúng việc — và lặng lẽ tạo rác ngay khi bạn nhập ký tự không phải ASCII:

btoa('Hello')      // "SGVsbG8="              ✓
btoa('Tiếng Việt') // InvalidCharacterError   ✗
btoa('🌏')         // InvalidCharacterError   ✗

Lý do: btoa thao tác trên Latin-1 (byte 0–255), không phải UTF-8. Ký tự ế không nằm trong một byte nên hàm từ chối. Tương tự cho emoji, chữ Trung, chữ Ả Rập, mọi thứ ngoài Latin cơ bản.

Cách fix: encode chuỗi sang chuỗi byte UTF-8 trước, rồi mới Base64 các byte đó. Công cụ này làm đúng việc đó mặc định — mọi input được xem là UTF-8, nên emoji và unicode round-trip sạch sẽ.

Base64 vs Base64URL

Base64 chuẩn dùng + và /, đều có ý nghĩa đặc biệt trong URL và tên file. Base64URL (RFC 4648 §5) thay bằng - và _, và bỏ luôn padding =. Nhờ vậy chuỗi an toàn để gắn vào query parameter, đoạn JWT, hoặc tên file.

Khi bạn bật URL-safe ở trên, công cụ phát ra - và _ thay vì + và /, không có padding. Khi decode, công cụ chấp nhận cả hai bộ — tự nhận diện.

Ví dụ

Mã hóa văn bản thường:

Input: Hello, World! Output: SGVsbG8sIFdvcmxkIQ==

Mã hóa tiếng Việt có dấu:

Input: Tiếng Việt có dấu Output: VGnhur9uZyBWaeG7h3QgY8OzIGThuqV1

Giải mã 1 đoạn payload JWT (Base64URL):

Input: eyJzdWIiOiIxMjM0NTY3ODkwIn0 Output: {"sub":"1234567890"}

Lưu ý bảo mật

• Đừng lưu mật khẩu dưới dạng Base64. Hoàn toàn có thể đảo ngược. Dùng hàm hash mật khẩu (bcrypt, argon2, scrypt) thay thế.
• Đừng tin JSON đã giải mã từ Base64 mà không validate lại. Chữ ký của JWT mới là thứ chứng minh tính toàn vẹn; lớp Base64 không chứng minh được gì.
• Cẩn thận kích thước input khi decode. Vài KB ổn, nhưng vài trăm MB cùng lúc có thể làm sập tab. Công cụ này xử lý đồng bộ; với file rất lớn nên dùng cách streaming.

Quyền riêng tư

Trang này chạy toàn bộ logic mã hóa/giải mã trong trình duyệt của bạn bằng thư viện mã nguồn mở js-base64. Dữ liệu không được gửi lên server, không được log, không rời khỏi máy bạn. Mở tab Network của trình duyệt và thử đi — sẽ thấy zero request.

Công cụ liên quan

• JWT Decoder — phân tích JSON Web Token (gồm ba đoạn Base64URL).
• URL Encoder — percent-encoding cho URL, một loại encoding khác (thường dùng bổ sung).

Base64 có phải mã hóa bảo mật không?

Không. Base64 là encoding có thể đảo ngược — ai có chuỗi đã mã hóa đều decode lại được mà không cần key. Dùng nó để đẩy dữ liệu nhị phân qua kênh text, không phải để giữ bí mật.

Tại sao btoa() lỗi với emoji hoặc tiếng Việt?

Hàm btoa() mặc định của trình duyệt chỉ chấp nhận Latin-1 (byte 0–255). Ký tự như ế hay 🌏 là nhiều byte trong UTF-8, không vừa nên btoa ném lỗi. Công cụ này encode UTF-8 trước rồi mới Base64 — nhờ vậy unicode round-trip sạch.

Base64 chuẩn và Base64URL khác nhau ra sao?

Base64 chuẩn dùng + và /, đệm =. Base64URL thay +/ thành -_ và bỏ padding, an toàn để dùng trong URL, đoạn JWT, hoặc tên file. Bật "URL-safe" ở trên để chuyển bộ ký tự.

Vì sao có dấu = ở cuối một số chuỗi mã hóa?

Base64 mã hóa mỗi 3 byte input thành 4 ký tự output. Khi độ dài input không chia hết cho 3, encoder đệm một hoặc hai = để output luôn chia hết cho 4. Base64URL bỏ phần padding này.

Dữ liệu của tôi có được gửi lên server không?

Không. Tất cả xử lý chạy trong trình duyệt bằng thư viện js-base64. Mở tab Network — bạn sẽ thấy zero request khi gõ. Trang còn hoạt động được khi mất mạng (đã cache).

Input lớn nhất bao nhiêu thì xử lý nổi?

Trên thực tế khoảng vài MB mỗi lần. Vượt ~10 MB tab có thể đứng vài giây vì xử lý đồng bộ. Với file vài trăm MB nên dùng decoder dạng streaming trong Web Worker hoặc công cụ phía server.

Text giải mã ra trông như rác — bị gì?

Hầu như luôn là một trong ba: (1) input mã hóa bằng bộ ký tự khác (URL-safe vs chuẩn — thử bật/tắt), (2) input bị cắt mất padding, hoặc (3) gốc không phải text UTF-8 mà là nhị phân tình cờ không hợp lệ UTF-8 (lúc đó "text giải mã" vô nghĩa; thứ bạn muốn là raw byte).

Có dùng Base64 để nén dữ liệu được không?

Không — Base64 làm dữ liệu to thêm ~33%, không thu gọn. Cần thu gọn thì dùng gzip, brotli, hoặc codec chuyên dụng cho domain, sau đó mới Base64 các byte đã nén nếu cần đẩy dạng text.