Mã hóa tệp Base64 miễn phí

Base64 từ đâu đến, và tại sao chúng ta vẫn sử dụng nó

Base64 được thiết kế để mang dữ liệu nhị phân 8 bit qua các đường ống ASCII 7 bit. Đặc tả chính thức đầu tiên là RFC 989 (tháng 2 năm 1987) cho Privacy-Enhanced Mail. RFC 1341 (tháng 6 năm 1992) và đặc biệt là RFC 2045 «MIME Phần Một» (tháng 11 năm 1996) đã làm cho nó trở thành cách chuẩn để đính kèm các tệp nhị phân vào email. Tài liệu chuẩn hiện tại là RFC 4648 (tháng 10 năm 2006), cũng định nghĩa biến thể URL-safe. Cơ chế đơn giản: lấy 3 byte đầu vào (24 bit), chia thành bốn nhóm 6 bit, tra cứu mỗi nhóm trong bảng chữ cái 64 ký tự A-Z a-z 0-9 + /, thêm đệm = để làm cho chiều dài đầu ra là bội số của 4. Kích thước đầu ra chính xác là 4 ÷ 3 ≈ 133 % của đầu vào. Để nhúng trong URL (JWT, OAuth, URL S3 pre-signed), biến thể URL-safe từ RFC 4648 §5 thay thế - cho + và _ cho /; đệm thường được bỏ qua.

URL data:: Base64 trong HTML và CSS của bạn

Lược đồ URL data: đã được chỉ định trong RFC 2397 (tháng 8 năm 1998). Định dạng: data:[<mediatype>][;base64],<data>. Ví dụ: <img src="data:image/png;base64,iVBORw0KGgo..."> nhúng một PNG inline mà không có yêu cầu HTTP bổ sung. WHATWG URL Living Standard quản lý cách các trình duyệt hiện đại giải thích các URL này và HTML Living Standard xác nhận rằng chúng hợp lệ ở bất cứ nơi nào URL được cho phép, bao gồm <img>, <link>, <iframe>, và hàm CSS url(). Hướng dẫn thực tế: sử dụng URL data cho các tài sản dưới khoảng 4 KB, nơi tiết kiệm một yêu cầu HTTP đánh bại 33 phần trăm sự cồng kềnh payload. Trên 10 KB, các tham chiếu tệp thông thường với bộ nhớ đệm trình duyệt hầu như luôn thắng, đặc biệt qua đa kênh HTTP/2.

API trình duyệt cung cấp năng lượng cho công cụ này

Trang này sử dụng API FileReader từ HTML Living Standard (ban đầu là W3C File API First Public Working Draft tháng 11 năm 2009; được vận chuyển trong Chrome 13 / Firefox 3.6 / Safari 6 / Internet Explorer 10). FileReader.readAsDataURL(blob) trả về chuỗi đầy đủ data:<mime>;base64,<...> bằng một cuộc gọi. Sự thay thế kế thừa là btoa() (được đặt tên theo lệnh Unix lịch sử «binary-to-ASCII» và một di tích JavaScript DOM Level 0), nhưng nó ném đối với đầu vào không phải Latin-1 trừ khi bạn chuyển mã trước qua UTF-8. Sự thay thế hiện đại là Uint8Array.prototype.toBase64(), được thêm vào ECMAScript 2025 tại TC39 Stage 4. Nó được vận chuyển trong Chrome 132 (tháng 1 năm 2025), Firefox 133 (tháng 11 năm 2024), và Safari 18.2 (tháng 12 năm 2024). Sử dụng API mới cho bất kỳ mã mới nào; dành btoa cho khả năng tương thích với các trình duyệt cũ hơn.

Nơi đầu ra của công cụ này thực sự đi đến

• Biểu tượng inline và hình ảnh nhỏ trong HTML / CSS cho các tài liệu tự chứa hoặc ưu tiên ngoại tuyến.
• Payload tải lên tệp JSON khi backend mong đợi một chuỗi Base64 trong trường JSON thay vì multipart/form-data.
• Tệp đính kèm email MIME: RFC 2045 yêu cầu Base64 (hoặc quoted-printable) cho bất kỳ thân nào không phải 7 bit, nghĩa là mọi tệp đính kèm PDF, hình ảnh hoặc tài liệu.
• Token JWT / OAuth: mỗi JWT là ba phân đoạn Base64 URL-safe được nối bằng ..
• Cố định kiểm thử được cam kết vào git, để hình ảnh kiểm thử / tài liệu mẫu di chuyển với tệp kiểm thử.
• Payload Web Push khi giao một blob nhị phân thông qua Push API.
• Phông chữ web critical-path được nhúng trong CSS để tránh FOIT (nhấp nháy văn bản vô hình) trong lần vẽ đầu tiên, đánh đổi được chấp nhận.

Sai lầm phổ biến

• Coi Base64 là mã hóa. Base64 là mã hóa, không phải bảo mật. Bất cứ ai có chuỗi đều có thể giải mã nó trong trình duyệt của họ. Không bao giờ sử dụng Base64 để «ẩn» thông tin xác thực, khóa API hoặc PII.
• Quên tiền tố data:<mime>;base64,. Chuỗi Base64 trần không phải là URL data. Một <img> cần dạng đầy đủ data:image/png;base64,<base64-của-bạn> để hiển thị.
• Trộn URL-safe và Base64 chuẩn. JWT và URL S3 pre-signed sử dụng URL-safe (- và _). Dán Base64 chuẩn (+ và /) vào các ngữ cảnh này tạo ra lỗi giải mã thầm lặng.
• Quên chỉ thị CSP data:. Một trang có img-src 'self' trong Content Security Policy của nó sẽ từ chối tải bất kỳ URL data:image/... nào. Bạn phải cho phép rõ ràng img-src 'self' data: (và tương tự cho font-src, media-src, v.v.).
• Mã hóa tệp 100 MB đồng bộ trên luồng chính. FileReader.readAsDataURL chặn UI trong vài giây trên tệp 200 MB. Đối với bất cứ điều gì trên ~20 MB, sử dụng Web Worker hoặc các chunk dòng.
• Gọi btoa("é") trực tiếp. Nó ném InvalidCharacterError vì btoa mong đợi Latin-1, không phải UTF-8. Hoặc sử dụng btoa(unescape(encodeURIComponent(text))) (kế thừa), hoặc chuyển một Uint8Array qua phương thức hiện đại toBase64().
• Inline logo 500 KB dưới dạng URL data. Sự cồng kềnh 33 phần trăm cộng với mất bộ nhớ đệm trình duyệt có nghĩa là mỗi lần tải trang tải xuống 665 KB thay vì 500 KB-một-lần. Sử dụng tham chiếu tài sản thông thường.

Câu hỏi thường gặp khác

Chi phí kích thước chính xác của Base64 là gì?

Chính xác 4 ÷ 3 ≈ 1.333× đầu vào, cộng với 1-2 byte đệm =. Đầu vào 999 byte trở thành 1332 ký tự Base64 (không đệm vì 999 ÷ 3 = 333 chính xác). Đầu vào 1000 byte trở thành 1336 (một byte đệm). Đối với URL data, thêm byte tiền tố (ví dụ data:image/png;base64, là 23 ký tự).

Làm cách nào để có Base64 URL-safe cho JWT hoặc URL S3 pre-signed?

Lấy đầu ra Base64 chuẩn từ công cụ này và áp dụng hai thay thế: + → -, / → _. JWT cụ thể loại bỏ đệm = ở cuối; S3 giữ nó. RFC 4648 §5 ghi lại biến thể.

Tôi có thể chuyển đi-về một tệp qua Base64 mà không bị hỏng không?

Có. Base64 là mã hóa không mất dữ liệu. Mã hóa thành Base64 sau đó giải mã trở lại tạo ra bản gốc giống hệt byte. Cách duy nhất để mất dữ liệu là cắt ngắn chuỗi Base64 (ví dụ giới hạn ký tự trong bộ nhớ của bạn) hoặc nhầm lẫn bảng chữ cái chuẩn và URL-safe khi giải mã.

Kích thước tệp tối đa mà công cụ này có thể xử lý là gì?

Không có giới hạn cứng; trong thực tế bộ nhớ trình duyệt là trần. Mã hóa tệp 100 MB yêu cầu khoảng 100 MB đầu vào cộng với 133 MB đầu ra, cộng với chi phí DOM cho chuỗi kết quả, có lẽ tổng cộng 400 MB. Trên di động, mong đợi thất bại trên khoảng 30 MB. Mã hóa chạy trên luồng chính, vì vậy UI đóng băng trong quá trình xử lý; đối với các tệp trên 20 MB, giải pháp phía máy chủ hoặc Web Worker thoải mái hơn.

Tệp của tôi có được tải lên đâu không?

Không. Tệp được đọc bằng API FileReader.readAsDataURL của trình duyệt, chạy hoàn toàn trong trình duyệt của bạn. Không có yêu cầu mạng nào được thực hiện và không có bản sao tệp của bạn được lưu trữ trên bất kỳ máy chủ nào. Mở tab Mạng trong DevTools và thả tệp vào: bạn sẽ thấy không có yêu cầu đi ra trong quá trình mã hóa.