Mã hóa Base64 là gì và tại sao nó được gọi là 'Base64'?

Base64 là một sơ đồ mã hóa nhị phân-thành-văn-bản đại diện cho dữ liệu nhị phân dùng 64 ký tự ASCII in được: A-Z (26), a-z (26), 0-9 (10), cộng '+' và '/' (2), tổng cộng 64. Ký tự '=' được dùng làm padding. Nó được gọi là Base64 vì có 64 giá trị có thể cho mỗi ký tự được mã hóa, và mỗi ký tự mã hóa chính xác 6 bit của dữ liệu gốc (2^6 = 64).

Mã hóa Base64 có mã hóa dữ liệu của tôi không?

Không. Base64 là một sơ đồ mã hóa, không phải một thuật toán mã hóa bảo mật. Mã hóa có thể đảo ngược mà không cần khóa — bất kỳ ai có chuỗi Base64 đều có thể giải mã ngay lập tức dùng bất kỳ bộ giải mã Base64 nào. Nếu bạn cần bảo vệ dữ liệu khỏi truy cập trái phép, bạn phải dùng mã hóa bảo mật (như AES-256) trước hoặc thay vì mã hóa. Base64 chỉ hữu ích để làm cho dữ liệu nhị phân an toàn cho truyền tải trong các giao thức dựa trên văn bản — nó không cung cấp tính bảo mật nào cả.

Đầu ra Base64 lớn hơn dữ liệu gốc bao nhiêu?

Mã hóa Base64 tăng kích thước dữ liệu khoảng 33%. Mỗi 3 byte đầu vào trở thành 4 ký tự Base64, cộng với các ký tự padding ('=') được thêm để làm độ dài đầu ra là bội số của 4. Ví dụ, 3 byte trở thành 4 ký tự, 6 byte trở thành 8 ký tự, và 1 MB trở thành khoảng 1.37 MB sau khi mã hóa. Chi phí này là đánh đổi chính khi quyết định liệu có dùng Base64 không.

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

Base64 tiêu chuẩn dùng '+' và '/' làm ký tự thứ 62 và 63. Các ký tự này có ý nghĩa đặc biệt trong URL: '+' được giải mã là khoảng trắng trong các chuỗi truy vấn, và '/' là dấu phân cách đường dẫn. Base64 an toàn URL (còn gọi là Base64url) thay '+' bằng '-' và '/' bằng '_', làm cho chuỗi được mã hóa an toàn để bao gồm trong các URL và tên tệp mà không cần mã hóa phần trăm bổ sung. Các ký tự padding ('=') thường bị bỏ qua trong mã hóa an toàn URL. Các token JWT, chẳng hạn, dùng Base64url không padding.

Tôi có nên dùng Base64 để lưu trữ mật khẩu không?

Tuyệt đối không. Base64 dễ dàng đảo ngược — bất kỳ chuỗi Base64 nào cũng có thể được giải mã thành giá trị gốc trong vài mili giây. Lưu trữ mật khẩu được mã hóa Base64 tương đương với lưu trữ chúng dưới dạng văn bản thuần. Mật khẩu phải được băm với một hàm băm mật khẩu phù hợp như bcrypt, scrypt hoặc Argon2, được thiết kế để tốn kém về mặt tính toán và không thể đảo ngược. Base64 không có vai trò trong lưu trữ mật khẩu.

Khi nào KHÔNG nên dùng mã hóa Base64?

Tránh Base64 khi: (1) Bạn cần bảo mật — Base64 không phải là mã hóa bảo mật. (2) Bạn đang nhúng các tệp lớn như ảnh trong HTML/CSS — chi phí kích thước 33% và không thể cache tài nguyên riêng biệt làm hại hiệu năng. (3) Bạn đang lưu trữ dữ liệu nhị phân lớn trong một cơ sở dữ liệu — lưu trữ nhị phân trong một cột nhị phân chuyên dụng hoặc lưu trữ đối tượng như S3, không phải dưới dạng các chuỗi Base64. (4) Bạn cần xử lý nhanh — mã hóa và giải mã Base64 thêm chi phí CPU cho các payload lớn. Dùng Base64 chỉ khi bạn thực sự cần đại diện cho dữ liệu nhị phân dưới dạng văn bản ASCII trong một giao thức hoặc định dạng không thể xử lý nhị phân thô.

Hiểu Mã Hóa Base64 — Hướng Dẫn Nhà Phát Triển Đầy Đủ

10 tháng 5, 2026 Toova

Mã hóa Base64 xuất hiện trong hầu như mọi lĩnh vực của phát triển web — các token JWT, data URI, các tệp đính kèm email, các payload API, các chữ ký mật mã và các tệp cấu hình. Mặc dù phổ biến, nó thường bị hiểu lầm: các nhà phát triển đôi khi nhầm lẫn nó với mã hóa bảo mật, hoặc dùng nó trong các tình huống khiến mọi thứ tệ hơn. Hướng dẫn này giải thích chính xác Base64 hoạt động như thế nào, khi nào tiếp cận nó, khi nào tránh nó, và cách sử dụng nó đúng đắn trong JavaScript.

Mã Hóa Base64 Là Gì (Và Không Là Gì)

Base64 là một sơ đồ mã hóa nhị phân-thành-văn-bản. Công việc duy nhất của nó là chuyển dữ liệu nhị phân tùy ý thành một chuỗi các ký tự ASCII in được. Nó không nén dữ liệu, nó không mã hóa bảo mật dữ liệu, và nó không xác thực dữ liệu. Nó hoàn toàn là một biến đổi biểu diễn — lấy các byte có thể bao gồm các byte null, các ký tự điều khiển hoặc các giá trị sẽ phá vỡ các giao thức dựa trên văn bản, và chuyển chúng thành một bộ ký tự an toàn.

Tên đến từ 64 ký tự in được được dùng làm bảng chữ cái mã hóa: A–Z (26 ký tự), a–z (26 ký tự), 0–9 (10 ký tự), cộng + và / (2 ký tự). Ký tự = được dùng cho padding. Vì có 64 giá trị có thể cho mỗi vị trí ký tự và 2^6 = 64, mỗi ký tự Base64 mã hóa chính xác 6 bit của dữ liệu gốc.

Base64 Hoạt Động Như Thế Nào — "Hello" Từng Bước

Cách tốt nhất để hiểu Base64 là theo dõi một ví dụ cụ thể. Hãy mã hóa chuỗi Hello.

Bước 1: Chuyển thành byte

Mỗi ký tự trong Hello ánh xạ đến mã ASCII của nó, sau đó được biểu thị bằng nhị phân (8 bit mỗi byte):

H  e  l  l  o
72 65 6C 6C 6F   (ASCII / hex)
01001000 01100101 01101100 01101100 01101111   (nhị phân)

Bước 2: Nhóm thành các đoạn 6 bit

Nối tất cả các bit: 0100100001100101011011000110110001101111 (40 bit). Base64 xử lý 3 byte (24 bit) một lần và ánh xạ chúng đến 4 ký tự Base64 (4 × 6 = 24 bit). Nhóm 40 bit thành các đoạn 6 bit, đệm nhóm cuối với các số không để lấp đầy nó:

010010 000110 010101 101100 011011 000110 1111
18     6      21     44     27     6      (nhóm cuối được đệm vào 6 bit: 111100 = 60)

Bước 3: Ánh xạ đến bảng chữ cái Base64

Mỗi giá trị 6 bit ánh xạ đến một ký tự trong bảng chữ cái Base64 (A=0, B=1, ... Z=25, a=26, ... z=51, 0=52, ... 9=61, +=62, /=63). Vì 5 byte không phải là bội số của 3, một ký tự padding = được thêm vào:

Chỉ số: 18  6   21  44  27  6   60
Ký tự:  S   G   V   s   b   G   8
Kết quả: SGVsbG8=   (= là padding)

Kết Quả

"Hello" → "SGVsbG8="

Bạn có thể xác minh điều này ngay lập tức với Toova Base64 encoder/decoder — dán Hello, nhấp Encode, và bạn nhận được SGVsbG8=. Nhấp Decode để đảo ngược nó.

Chi Phí Kích Thước 33%

Mã hóa Base64 luôn tăng kích thước dữ liệu khoảng 33%. Phép toán đơn giản: 3 byte đầu vào (24 bit) tạo ra 4 ký tự Base64 (24 bit được mã hóa trong 4 nhóm 6 bit). Đó là tỷ lệ 4/3, hoặc 33.3% chi phí. Thêm các ký tự padding và chi phí thực sự là giữa 33% và 36%, tùy vào độ dài đầu vào.

Điều này quan trọng đáng kể cho hiệu năng. Một ảnh 1 MB được nhúng dưới dạng data URI Base64 trong HTML trở thành khoảng 1.37 MB. Một API mã hóa tất cả các payload nhị phân trong Base64 gửi nhiều hơn 33% dữ liệu cần thiết. Đối với các giá trị nhỏ như các token ngắn hoặc các tổng kiểm tra, chi phí là không đáng kể. Đối với các tệp lớn, đó là một chi phí thực sự.

Biến Thể An Toàn URL

Base64 tiêu chuẩn dùng + và / làm hai ký tự bảng chữ cái cuối cùng. Cả hai đều có vấn đề trong URL:

+ được giải mã là ký tự khoảng trắng trong các chuỗi truy vấn
/ là dấu phân cách đường dẫn trong URL

Base64 an toàn URL (còn gọi là Base64url, được định nghĩa trong RFC 4648 Phần 5) thay + bằng - và / bằng _. Padding (=) thường bị bỏ qua trong các ngữ cảnh an toàn URL vì nó cũng có thể bị hiểu sai bởi một số bộ phân tích URL.

Các token JWT dùng Base64url không padding. Khi bạn giải mã header hoặc payload JWT thủ công, bạn phải xử lý cả thay thế ký tự và padding thiếu. Đây là cách làm điều đó trong JavaScript:

// Base64 an toàn URL (thay + bằng - và / bằng _)
function toBase64Url(base64) {
  return base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');
}

function fromBase64Url(base64url) {
  const padded = base64url.padEnd(
    base64url.length + (4 - base64url.length % 4) % 4,
    '='
  );
  return atob(padded.replace(/-/g, '+').replace(/_/g, '/'));
}

Toova Base64 encoder/decoder hỗ trợ cả biến thể tiêu chuẩn và an toàn URL với một toggle duy nhất.

Base64 Trong JavaScript

Trình duyệt: btoa() và atob()

Các trình duyệt cung cấp hai hàm tích hợp: btoa() (binary to ASCII, tức là mã hóa) và atob() (ASCII to binary, tức là giải mã). Mặc dù thứ tự tên gây nhầm lẫn, chúng đã có sẵn trong các trình duyệt trong hơn một thập kỷ.

// Trình duyệt — atob / btoa (chỉ chuỗi, an toàn ASCII)
const encoded = btoa("Hello");
console.log(encoded); // "SGVsbG8="

const decoded = atob("SGVsbG8=");
console.log(decoded); // "Hello"

Hạn chế quan trọng: btoa() chỉ chấp nhận các chuỗi với các ký tự trong phạm vi Latin-1 (mã điểm 0–255). Nếu bạn truyền một chuỗi với các ký tự Unicode như emoji hoặc các ký tự CJK, nó throw DOMException. Để mã hóa dữ liệu nhị phân tùy ý, chuyển nó thành Uint8Array trước:

// Trình duyệt — mã hóa nhị phân tùy ý (Uint8Array)
const bytes = new Uint8Array([72, 101, 108, 108, 111]);
const encoded = btoa(String.fromCharCode(...bytes));
console.log(encoded); // "SGVsbG8="

Để mã hóa các chuỗi tùy ý có thể chứa các ký tự Unicode, cách tiếp cận hiện đại được khuyến nghị là dùng TextEncoder để lấy một Uint8Array trước, sau đó mã hóa như hiển thị ở trên.

Node.js: Buffer

Node.js cung cấp lớp Buffer, xử lý dữ liệu nhị phân đúng đắn và hỗ trợ nhiều mã hóa bao gồm Base64 và Base64url:

// Node.js — Buffer (xử lý nhị phân an toàn)
const encoded = Buffer.from('Hello').toString('base64');
console.log(encoded); // "SGVsbG8="

const decoded = Buffer.from('SGVsbG8=', 'base64').toString('utf8');
console.log(decoded); // "Hello"

// Biến thể an toàn URL trong Node.js
const urlSafe = Buffer.from('Hello').toString('base64url');
console.log(urlSafe); // "SGVsbG8" (không padding)

Tùy chọn mã hóa base64url (có sẵn từ Node.js 16) xử lý việc thay thế ký tự và loại bỏ padding tự động, làm cho nó dễ hơn nhiều so với việc thực hiện biến đổi thủ công.

Đối với các môi trường trình duyệt cần xử lý các tệp nhị phân lớn, phương thức FileReader.readAsDataURL mã hóa tệp dưới dạng data URI Base64 mà không tải mọi thứ vào bộ nhớ cùng một lúc.

Khi Nào Dùng Base64

Nhúng dữ liệu nhị phân trong các giao thức chỉ văn bản

Trường hợp sử dụng ban đầu cho Base64 là mã hóa các tệp đính kèm email nhị phân trong SMTP, một giao thức chỉ hỗ trợ văn bản ASCII 7-bit. Nguyên tắc tương tự áp dụng ở bất cứ đâu bạn cần bao gồm dữ liệu nhị phân trong một định dạng không thể xử lý byte thô: các payload API JSON, các tài liệu XML, các thuộc tính HTML, các giá trị CSS, các header HTTP.

Data URI cho các tài sản nhỏ

CSS và HTML cho phép bạn nhúng các ảnh, font và SVG dưới dạng data URI Base64. Điều này loại bỏ một round-trip HTTP cho các tài sản nhỏ như các icon và loại bỏ flash-of-unstyled-content cho các ảnh quan trọng above-the-fold.

<!-- Icon SVG inline dưới dạng data URI Base64 -->
<img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0c..." alt="icon" />

<!-- Background CSS inline -->
.icon {
  background-image: url("data:image/png;base64,iVBORw0KGgo...");
}

Sự đánh đổi: các data URI Base64 không thể được cache riêng từ tệp HTML/CSS chứa chúng. Nếu ảnh không bao giờ thay đổi nhưng HTML xung quanh thay đổi, trình duyệt tải lại dữ liệu ảnh trên mỗi lần tải lại trang. Dùng data URI chỉ cho các tài sản nhỏ (lý tưởng dưới 4 KB) nơi việc loại bỏ một round-trip vượt qua hình phạt cache.

Mã hóa dữ liệu nhị phân cho JSON hoặc các tham số URL

JSON là một định dạng văn bản — nó không thể đại diện cho các byte nhị phân thô trực tiếp. Khi một API cần truyền dữ liệu nhị phân (các thumbnail ảnh, các chữ ký mật mã, dữ liệu đã nén), Base64 là cách tiêu chuẩn để bao gồm nó trong một payload JSON. Tương tự, nếu bạn cần truyền dữ liệu nhị phân trong một tham số truy vấn URL, mã hóa Base64url đảm bảo dữ liệu tồn tại qua mã hóa phần trăm mà không bị hỏng.

JWT và các định dạng token khác

Các token JWT dùng Base64url để mã hóa các phần header và payload của chúng. Điều này làm cho token là một chuỗi có thể in, an toàn URL có thể được truyền trong các header HTTP, cookie hoặc các tham số URL. Mã hóa không phải vì bảo mật (payload có thể đọc bởi bất kỳ ai có token) — nó hoàn toàn cho việc truyền tải an toàn.

Khi Nào KHÔNG Dùng Base64

Bảo mật hoặc tính bảo mật

Base64 cung cấp bảo mật bằng không. Nó dễ dàng đảo ngược trong vài mili giây. Đừng dùng nó để "che giấu" mật khẩu, khóa API hoặc các giá trị cấu hình nhạy cảm. Bất kỳ nhà phát triển nào thấy một chuỗi Base64 sẽ giải mã nó ngay lập tức. Nếu bạn cần tính bảo mật, dùng mã hóa bảo mật.

Lưu trữ mật khẩu

Lưu trữ mật khẩu được mã hóa Base64 giống như lưu trữ chúng dưới dạng văn bản thuần — mã hóa có thể đảo ngược ngay lập tức. Mật khẩu phải được băm với một hàm băm mật khẩu phù hợp như bcrypt, Argon2 hoặc scrypt.

Các tệp nhị phân lớn

Mã hóa một tệp 10 MB dưới dạng Base64 tạo ra một chuỗi 13.7 MB. Nếu bạn lưu trữ điều đó trong một cột cơ sở dữ liệu, tìm kiếm qua nó hoặc truyền nó qua một API, bạn trả chi phí 33% mỗi lần. Đối với dữ liệu nhị phân lớn, dùng lưu trữ nhị phân chuyên dụng: các cột BLOB/BYTEA cơ sở dữ liệu, lưu trữ đối tượng như S3 hoặc GCS, hoặc stream nhị phân trực tiếp.

Các tình huống nơi bạn có thể dùng nhị phân trực tiếp

Nếu giao thức hoặc định dạng của bạn hỗ trợ nhị phân thô — ví dụ, một WebSocket với loại tin nhắn nhị phân, một multipart/form-data HTTP upload, hoặc một định dạng tệp nhị phân — dùng nhị phân trực tiếp. Base64 chỉ cần thiết khi phương tiện truyền tải thực sự không thể xử lý byte thô.

Các Bẫy Phổ Biến

Nhầm lẫn mã hóa với mã hóa bảo mật

Đây là sai lầm phổ biến nhất. Base64 có thể nhìn thấy. Nó không phải là cơ chế bảo mật. Các bình luận code như "mật khẩu được lưu trữ Base64-encoded vì bảo mật" chỉ ra một sự hiểu lầm nghiêm trọng nên được bắt trong xem xét code.

Dùng btoa() với các chuỗi Unicode

Gọi btoa() trên một chuỗi chứa các ký tự với các mã điểm trên 255 throw DOMException: Failed to execute 'btoa': The string to be encoded contains characters outside of the Latin1 range. Luôn chuyển sang Uint8Array qua TextEncoder trước khi mã hóa các chuỗi có thể chứa các ký tự Unicode.

Quên padding khi giải mã

Các chuỗi Base64 phải có độ dài là bội số của 4. Nếu một chuỗi Base64 được tạo mà không có padding (phổ biến trong mã hóa an toàn URL), bạn phải thêm trở lại số lượng đúng các ký tự = trước khi giải mã. Một chuỗi Base64 với độ dài n cần (4 - n % 4) % 4 ký tự padding. Quên điều này gây ra các lỗi giải mã có thể khó chẩn đoán.

Mã hóa kép

Một chuỗi Base64 tự nó là ASCII hợp lệ, vì vậy btoa(btoa(data)) hoạt động mà không có lỗi nhưng tạo ra đầu ra được mã hóa kép. Khi truyền các giá trị Base64 qua nhiều lớp tuần tự hóa (JSON bên trong JSON, chẳng hạn), dễ dàng mã hóa cùng dữ liệu hai lần. Luôn giải mã chính xác số lần bạn đã mã hóa.

Tham Khảo Nhanh: Base64 Trong Thực Tế

Để mã hóa và giải mã trong trình duyệt mà không viết code, Toova Base64 encoder/decoder chạy hoàn toàn trong trình duyệt của bạn — không round-trip máy chủ. Nó hỗ trợ các biến thể tiêu chuẩn và an toàn URL, tải tệp lên để mã hóa các tệp nhị phân, và cả đầu ra văn bản và hex cho dữ liệu đã giải mã.

Nếu bạn đang làm việc với nội dung được mã hóa bên trong các URL, URL encoder/decoder xử lý mã hóa phần trăm riêng biệt với Base64. Đối với các thực thể HTML, bộ chuyển đổi thực thể HTML xử lý escape ký tự trong các ngữ cảnh HTML. Đây là các sơ đồ mã hóa riêng biệt — mỗi cái có một trường hợp sử dụng cụ thể.

Tham khảo chính cho Base64 là RFC 4648, định nghĩa Base64 tiêu chuẩn (Phần 4), Base64url (Phần 5) và Base32 (Phần 6–7). Đối với các API trình duyệt btoa() và atob(), tài liệu MDN cho btoa() bao quát khả năng tương thích trình duyệt và hạn chế Unicode chi tiết.

Tóm Lược

Mã hóa Base64 chuyển dữ liệu nhị phân thành ASCII in được dùng một bảng chữ cái 64 ký tự. Nó tăng kích thước dữ liệu 33%, hoàn toàn có thể đảo ngược, và không cung cấp bảo mật. Dùng nó khi bạn cần nhúng dữ liệu nhị phân trong một định dạng dựa trên văn bản — các payload JSON, data URI HTML, các token JWT, các tệp đính kèm email, các tham số URL. Tránh nó khi bạn cần bảo mật, khi giao thức hỗ trợ nhị phân trực tiếp, hoặc khi chi phí 33% quan trọng ở quy mô.

Hiểu Base64 là gì — và nó không là gì — ngăn ngừa các sai lầm phổ biến nhất: dùng nó cho bảo mật, áp dụng nó cho các tệp lớn không cần thiết và nhầm lẫn nó với các sơ đồ mã hóa khác như mã hóa URL hoặc các thực thể HTML. Mỗi sơ đồ mã hóa giải quyết một vấn đề cụ thể. Base64 giải quyết chính xác một: làm cho dữ liệu nhị phân an toàn cho các kênh chỉ văn bản.

Sẵn sàng để mã hóa hoặc giải mã? Thử Toova Base64 encoder/decoder — dán văn bản hoặc thả tệp, chuyển tiêu chuẩn hoặc an toàn URL, và sao chép kết quả. Không tài khoản, không máy chủ, không giới hạn.