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

Encode văn bản sang Base64 hoặc decode Base64 về văn bản ngay lập tức. Hỗ trợ UTF-8, ASCII, URL-safe — tiện cho API, mã hóa dữ liệu và phát triển web.

Có góp ý? Báo lỗi, đề xuất tính năng, hoặc chia sẻ suy nghĩ — chúng tôi đọc tất cả

Mã hóa/Giải mã Base64 - Encode và Decode Base64 Online

Công cụ mã hóa và giải mã Base64 online mạnh mẽ cho phép bạn dễ dàng mã hóa văn bản sang định dạng Base64 hoặc giải mã chuỗi Base64 về văn bản gốc. Hỗ trợ nhiều bộ ký tự (UTF-8, ASCII, UTF-16, ISO-8859-1), tùy chọn mã hóa URL-safe và chuyển đổi ngay lập tức. Hoàn hảo cho lập trình viên, quản trị viên hệ thống và bất kỳ ai làm việc với mã hóa Base64 trong phát triển web, API hoặc truyền tải dữ liệu.

Base64 là gì và khi nào tôi nên dùng nó?

Base64 là một sơ đồ mã hóa nhị phân sang văn bản được định nghĩa trong RFC 4648, biểu diễn các byte 8-bit tùy ý bằng bảng chữ cái 64 ký tự (A-Z, a-z, 0-9, + và /). Nó không phải là mã hóa bảo mật — hoàn toàn không cung cấp tính bí mật. Bạn dùng nó khi cần vận chuyển hoặc nhúng dữ liệu nhị phân bên trong một kênh chỉ chấp nhận văn bản: thân email (MIME, RFC 2045), tiêu đề xác thực HTTP Basic, tải JSON hoặc XML, URI data: cho ảnh nội tuyến trong HTML và CSS, các đoạn JWT, khóa và chứng chỉ PEM, và các cột cơ sở dữ liệu chỉ chấp nhận văn bản. Cứ ba byte đầu vào tạo ra bốn ký tự đầu ra, nên dạng đã mã hóa lớn hơn nguồn khoảng 33%. Nếu dữ liệu của bạn đã là văn bản, đừng mã hóa Base64 — bạn lãng phí byte và phá vỡ tính dễ đọc.

Tại sao đầu ra lớn hơn đầu vào 33%?

Base64 ánh xạ mỗi 3 byte (24 bit) thành 4 ký tự 6 bit mỗi ký tự, tạo ra tỷ lệ mở rộng 4:3 khoảng 1,333. Nếu độ dài đầu vào không phải bội số của 3, bộ mã hóa đệm nhóm cuối cùng bằng một hoặc hai ký tự = để độ dài đầu ra luôn là bội số của 4. Đối với tải trọng điển hình, điều này có nghĩa là chi phí khoảng 33%, cộng với một vài byte đệm. Với đầu vào rất nhỏ, chi phí tương đối lớn hơn; với một byte duy nhất bạn nhận được 4 ký tự (mở rộng 300%). Nếu kích thước quan trọng, hãy cân nhắc Base85/Ascii85 (chi phí khoảng 25%) hoặc vận chuyển nhị phân thô. Nén lại chuỗi Base64 bằng gzip hầu như không bao giờ có ích.

Sự khác biệt giữa Base64 chuẩn và Base64 an toàn cho URL là gì?

Base64 chuẩn (RFC 4648 mục 4) dùng + và / làm hai ký tự bảng chữ cái cuối cùng và = để đệm. Ba ký hiệu đó xung đột với các ký tự dành riêng trong URL, chuỗi truy vấn và tên tệp. Base64 an toàn cho URL (RFC 4648 mục 5) thay - cho + và _ cho /, và thường loại bỏ phần đệm = ở cuối. Các byte đã giải mã giống hệt nhau — chỉ bảng chữ cái khác. Token JWT, trạng thái OAuth và hầu hết các API web hiện đại đều dùng biến thể an toàn cho URL. Nếu bạn giải mã chuỗi chứa - hoặc _ bằng bộ giải mã chuẩn, bạn sẽ nhận được rác hoặc lỗi. Hãy đảm bảo bộ mã hóa và bộ giải mã của bạn thống nhất về bảng chữ cái.

Base64 có thể xử lý chuỗi Unicode hay chỉ ASCII?

Base64 hoạt động trên byte, không phải ký tự, nên câu hỏi rút gọn thành: chuỗi của bạn được chuyển thành byte như thế nào trước khi mã hóa? Câu trả lời phổ quát là UTF-8 (RFC 3629). Mã hóa chuỗi "café" trước hết thành các byte 63 61 66 C3 A9 trong UTF-8, rồi Base64 tạo ra "Y2Fmw6k=". Một bộ giải mã diễn giải các byte đó trở lại dưới dạng UTF-8 sẽ trả về "café" chính xác. Nếu người gửi và người nhận không thống nhất về mã hóa văn bản — một bên dùng UTF-8 và bên kia Latin-1 — chuyến đi khứ hồi sẽ tạo ra mojibake. Công cụ này dùng UTF-8 xuyên suốt. Khi gỡ lỗi văn bản quốc tế, hãy xác minh chuỗi byte trước bằng trình xem hex.

Mã hóa/Giải mã Base64 — Encode văn bản sang Base64 hoặc decode Base64 về văn bản ngay lập tức. Hỗ trợ UTF-8, ASCII, URL-safe — tiện cho API, mã — **Mã hóa/Giải mã Base64**

Tại sao tôi nhận được lỗi "ký tự không hợp lệ" khi giải mã?

Bảng chữ cái chuẩn có chính xác 64 ký tự cộng với = để đệm. Bất kỳ byte nào khác — xuống dòng, khoảng trắng, tab, dấu nháy thông minh, emoji, hoặc một dấu + đã bị trình phân tích URL biến thành khoảng trắng — sẽ làm thất bại quá trình giải mã nghiêm ngặt. Nguyên nhân phổ biến: (1) chuỗi đi qua một hệ thống ngắt dòng ở 76 ký tự theo quy ước MIME nhưng bộ giải mã không ở chế độ khoan dung MIME; (2) một biểu mẫu URL đã coi + như khoảng trắng; (3) chuỗi đến từ một thuộc tính HTML nơi & đã được mã hóa thành thực thể; (4) phần đệm = bị loại bỏ trên đường đi. Cách khắc phục: loại bỏ khoảng trắng trước khi giải mã, thay khoảng trắng bằng +, và thêm lại = ở cuối để độ dài là bội số của 4.

Base64 có được coi là mã hóa bảo mật hay bất kỳ hình thức bảo mật nào không?

Không — Base64 là mã hóa biểu diễn, không phải mã hóa bảo mật. Phép biến đổi hoàn toàn có thể đảo ngược mà không cần bất kỳ khóa nào, và mọi bộ giải mã Base64 trên Trái Đất đều có thể đọc đầu ra của bạn. Coi Base64 như một cách để "giấu" mật khẩu, khóa API hoặc thông tin cá nhân là một trong những sai lầm bảo mật phổ biến nhất trong các đợt rà soát mã nguồn. Ví dụ, xác thực HTTP Basic gửi thông tin đăng nhập dưới dạng Base64("người dùng:mật khẩu") — đó là lý do tại sao Basic auth yêu cầu HTTPS để an toàn. Nếu bạn cần tính bí mật, hãy dùng mật mã thực sự: AES-GCM hoặc ChaCha20-Poly1305 cho mã hóa đối xứng, RSA-OAEP hoặc X25519 cho trao đổi khóa, và một thư viện đã được kiểm chứng (libsodium, Web Crypto API, OpenSSL).

Làm sao mã hóa luồng một tệp lớn mà không tải vào bộ nhớ?

Base64 thân thiện với khối vì cứ 3 byte đầu vào ánh xạ gọn gàng thành 4 ký tự đầu ra, nên bạn có thể mã hóa theo từng khối miễn là mỗi khối là bội số của 3 byte (trừ khối cuối cùng, nơi nhận phần đệm). Trong Node.js, dẫn tệp qua fs.createReadStream vào một Transform gọi Buffer.toString('base64') trên mỗi khối bội-số-của-3. Trong Python, dùng base64.encodebytes trên các lần đọc lặp, ví dụ 57 KB (bội số của 3, vừa với dòng MIME 76 ký tự). Trong trình duyệt, API FileReader.readAsDataURL xử lý việc này cho bạn, nhưng với tệp khổng lồ hãy ưu tiên Blob.stream() với TransformStream. Tránh bẫy mã hóa các khối độc lập rồi nối lại: nếu kích thước khối nào đó không chia hết cho 3, dấu = ở giữa sẽ làm hỏng đầu ra.

Base64URL không đệm là gì, và tại sao JWT dùng nó?

JWT (RFC 7519) và JOSE (RFC 7515) chỉ định các đoạn được mã hóa base64url với toàn bộ phần đệm = bị loại bỏ. Lý do thuần túy là về thẩm mỹ và vận hành: token đi qua URL, tiêu đề HTTP và cookie nơi = hoặc cần mã hóa phần trăm (=%3D) hoặc kích hoạt các trình phân tích kỳ vọng cặp khóa=giá trị. Loại bỏ phần đệm rút ngắn token đi 1-3 ký tự và tránh đau đầu về thoát ký tự. Để giải mã, bạn phải thêm lại phần đệm để độ dài chuỗi là bội số của 4: thêm "", "==" hoặc "=" tùy theo độ dài mod 4. Hầu hết các thư viện JWT làm điều này cho bạn, nhưng nếu bạn giải mã thủ công bằng Buffer.from(str, 'base64url') trong Node 16+ hiện đại thì nó hoạt động ngay. Trong trình duyệt, atob() không hiểu bảng chữ cái an toàn cho URL.