Hỗ trợ kỹ thuật
Vì sao Base64 làm file lớn hơn?
Base64 thường làm dữ liệu nhị phân lớn thêm khoảng một phần ba. Xem cấu trúc 3 byte thành 4 ký tự, phần đệm, overhead Data URL, và khi nào phần tăng đó đáng.
Base64 thường làm dữ liệu nhị phân lớn thêm khoảng một phần ba vì nó biểu diễn mỗi 3 byte nhị phân bằng 4 ký tự Base64 in được.
Nếu độ dài đầu vào không phải bội số đúng của 3, Base64 có đệm chuẩn có thể thêm ký tự =. Độ dài sau mã hóa là 4 × ceil(n / 3), với n là số byte gốc.
“Khoảng 33%” mô tả đầu vào lớn. Đầu vào rất nhỏ có thể trông tăng nhiều hơn vì phần đệm. Base64 không phải nén. Về biểu diễn Base64 so với mã hóa bảo mật, xem [Base64 không phải mã hóa bảo mật: nó thực sự làm gì](/vi/story/base64-is-not-encryption).
Bài viết này giải thích vì sao đầu ra Base64 lớn hơn các byte gốc. Đây không phải hướng dẫn an ninh. Nếu cần phân biệt biểu diễn Base64 với mã hóa bảo mật, hãy dùng Base64 không phải mã hóa bảo mật: nó thực sự làm gì.
Vì sao Base64 cần nhiều chỗ hơn?
3 byte là 24 bit. Base64 tách 24 bit đó thành 4 nhóm 6 bit. Mỗi nhóm ánh xạ thành một ký tự Base64, nên 3 byte đầu vào thành 4 ký tự đầu ra. Lưu mỗi ký tự ASCII 1 byte thì 4 / 3 ≈ 1.333 — tăng khoảng 33.3%.
- 3 byte (24 bit)
- Tách thành 4 nhóm 6 bit
- Mỗi nhóm → một ký tự Base64
- 4 ký tự (thường 4 byte văn bản)
Một ví dụ đơn giản, kiểm tra được
Các chuỗi này khớp Base64 có đệm chuẩn.
Man
Man
Base64
TWFu
Man là 3 byte UTF-8/ASCII. TWFu là 4 ký tự: 3 → 4.
Hello
Hello
Base64
SGVsbG8=
Hello là 5 byte. SGVsbG8= là 8 ký tự, gồm một =. Với dữ liệu nhỏ, phần đệm làm phần trăm trông lớn hơn 33%.
Tính kích thước Base64 thế nào?
Với Base64 có đệm chuẩn, encodedLength = 4 × ceil(originalBytes / 3).
| Byte gốc | Ký tự Base64 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1 hoặc 2 byte vẫn ra 4 ký tự. Dùng công thức, đừng dùng 33% cố định.
Phần đệm “=” nghĩa là gì?
Dấu = cho thấy khối 3 byte cuối chưa đầy. 1 byte đầu vào dùng hai =; 2 byte dùng một; 3 byte không dùng. Phần đệm không phải mã hóa bảo mật hay tính năng an ninh.
Base64URL có tốn ít chỗ hơn không?
Base64URL đổi + thành - và / thành _, và Mã hóa Base64 bỏ = cuối khi mã hóa. Chuỗi có thể ngắn đi đúng số = đó. Cấu trúc 3 byte → 4 ký tự vẫn vậy, nên Base64URL không phải định dạng nhị phân tiết kiệm chỗ hơn.
Vì sao đầu vào rất nhỏ có thể tăng hơn 33%?
1 byte → 4 ký tự là tăng độ dài 300%. 2 byte → 4 là 100%. 3 byte → 4 khoảng 33.3%. Khi n lớn dần, phần đệm ít ảnh hưởng hơn và overhead tiến gần khoảng 33%. Base64 không phải lúc nào cũng lớn đúng 33%.
Vì sao Data URL Base64 còn lớn hơn nữa?
Data URL thêm tiền tố như data:image/png;base64, trước phần nội dung. Trên file rất nhỏ, tiền tố đó có thể chiếm phần lớn tỷ lệ. Mã hóa Base64 có thể xuất Base64 thô hoặc Data URL; Data URL dùng bảng chữ cái chuẩn.
Base64 và nhị phân: cái nào nhỏ hơn?
Nhị phân thô tiết kiệm chỗ hơn khi truyền và lưu. Base64 lớn hơn, nhưng an toàn dạng chữ trong JSON, email và các đường chỉ văn bản khác. Đây là mã hóa nhị phân-sang-chữ, không phải nén.
Base64 có nén file không?
Không. Base64 không phải định dạng nén. Văn bản đã mã hóa thường lớn hơn byte gốc. Nếu sau đó áp gzip hoặc Brotli lên văn bản đó, một phần dư thừa có thể co lại—kết quả tùy dữ liệu và bộ nén. gzip không xóa hết overhead Base64.
Base64 đem gzip thì sao?
Nén HTTP có thể giảm một số mẫu lặp trong văn bản Base64. JPEG, PNG hoặc ZIP thường nén kém ngay cả dạng byte thô, và Base64 rồi gzip vẫn tùy trường hợp. Không có phần trăm thêm phổ quát sau gzip.
Có nên lưu file dạng Base64?
Base64 có thể nhét nhị phân vào trường JSON, tài sản nhúng nhỏ, API chỉ chữ, copy/paste, hoặc Data URL. Với file lớn, lưu trữ, bộ nhớ và kích thước tải đều tăng. Đó không phải “đừng bao giờ dùng Base64 cho file.”
Vì sao Base64 phổ biến trong API JSON?
JSON không có kiểu nhị phân thô sẵn, nên API thường để byte trong chuỗi Base64. Với file lớn, multipart/form-data, object storage, hoặc tải nhị phân trực tiếp có thể hợp hơn. Không lựa chọn nào luôn tốt nhất.
Vì sao email dùng Base64?
MIME có thể dùng Base64 để tệp đính kèm nhị phân đi dưới dạng ký tự an toàn cho văn bản. Cùng overhead kích thước vẫn áp dụng. Đây là cách biểu diễn khi truyền, không phải file nhỏ hơn.
Khi nào phần kích thước thêm là đáng?
Phần thêm có thể đáng khi nhị phân phải nằm trong văn bản, tải nhỏ, API bắt Base64, hoặc bạn cần Data URL. Với media lớn, ưu tiên nhị phân thô khi hệ thống cho phép.
Khi nào nên tránh Base64?
Bỏ qua với file lớn, băng thông chặt, truyền thường xuyên, hoặc khi đã có đường nhị phân—tùy tình huống, không phải “Base64 là thói xấu.”
Độ dài Base64 có đệm bạn có thể kiểm
Số byte gốc và số ký tự Base64 có đệm chuẩn:
| Byte gốc | Ký tự Base64 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
Mọi hàng theo 4 × ceil(n / 3). Đây là số ký tự Base64.
Ví dụ: file 1,000 byte sẽ lớn bao nhiêu?
4 × ceil(1000 / 3). ceil(333.333…) = 334, và 4 × 334 = 1336. Vậy 1,000 byte thành 1,336 ký tự Base64. Lưu UTF-8/ASCII thì mỗi ký tự thường 1 byte—đừng coi 1,336 là số byte bộ nhớ chính xác.
Base64 có dùng nhiều bộ nhớ hơn kích thước file gợi ý?
Một số môi trường lưu chuỗi với hơn 1 byte mỗi ký tự, và mã hóa/giải có thể giữ buffer cùng chuỗi. Dùng bộ nhớ không đúng bằng độ dài ký tự.
Hướng dẫn quyết định kích thước đơn giản
Nếu hệ thống nhận nhị phân thô, hãy ưu tiên vì kích thước. Nếu chỉ cho phép chữ, Base64 có thể hợp. Tải lớn thì kiểm đường tải nhị phân. Cần chữ an toàn URL thì cân nhắc Base64URL—phần mở 3 thành 4 vẫn còn.
- Cần gửi dữ liệu nhị phân
- Cho phép nhị phân thô? Ưu tiên nhị phân vì kích thước
- Trường chỉ chữ? Base64 có thể phù hợp
- Tải lớn? Kiểm đường tải nhị phân
- Cần chữ an toàn URL? Cân nhắc Base64URL
- Kỳ vọng khoảng thêm 33% chữ trên đầu vào lớn
Base64 không được thiết kế để làm dữ liệu nhỏ hơn. Nó giúp nhị phân dễ biểu diễn trong hệ thống dựa trên chữ, và cái giá là kích thước thêm.
Mã hóa hoặc giải Base64 trong trình duyệt
NEXNARA Mã hóa Base64 mã hóa và giải văn bản, đồng thời có thể biến file thành Base64 hoặc Data URL và biến Base64 trở lại thành file.
Văn bản dùng byte UTF-8 rồi Base64—không chỉ ASCII. Chọn Standard hoặc Base64URL. Đầu ra file có thể là Base64 thô hoặc Data URL (bảng chữ cái chuẩn). Đầu vào không hợp lệ bị từ chối. Byte không phải UTF-8 cần về file, đừng giải thành chữ.
File trên 10 MB có thể làm chậm thẻ (cảnh báo). File trên 32 MB bị chặn.
Mã hóa và giải diễn ra trong trình duyệt của bạn. File không được gửi tới máy chủ NEXNARA cho công cụ này. Quảng cáo và tính năng khác của trang vẫn dùng mạng.
Dán chữ hoặc file vào Mã hóa Base64 và so số byte gốc với độ dài sau mã hóa.
FAQ
Vì sao Base64 tăng kích thước file?
Nó ánh xạ 3 byte (24 bit) thành 4 ký tự (4 × 6 bit). Lưu thành chữ thì đầu vào lớn khoảng thêm một phần ba.
Base64 có luôn lớn hơn 33% không?
Không. Đầu vào lớn tiến gần khoảng 33.3%. Đầu vào rất nhỏ có thể tăng nhiều hơn vì phần đệm. Dùng 4 × ceil(n / 3).
Base64 lớn hơn nhị phân bao nhiêu?
Độ dài có đệm chuẩn là 4 × ceil(n / 3) ký tự. Tiền tố Data URL còn cộng thêm.
Nén Base64 có làm file nhỏ hơn không?
Base64 không nén. Gzip hoặc Brotli trên văn bản đã mã hóa có thể co một phần; chúng không xóa overhead trong mọi trường hợp.
Base64URL có tốn ít chỗ hơn không?
Nó có thể bỏ đệm =, nên chuỗi có thể ngắn hơn 0–2 ký tự. Cấu trúc mã hóa 3-thành-4 vẫn giống.
Tôi có nên dùng Base64 cho file lớn?
Chỉ khi bạn cần chữ. Với truyền lớn hoặc thường xuyên, đường nhị phân thường nhỏ hơn. Base64 không phải lúc nào cũng sai với API.