Trình mã hóa & giải mã Base64 miễn phí trực tuyến

Base64 là gì?

Base64 là một sơ đồ mã hóa nhị phân-sang-văn bản, một cách để biểu diễn bất kỳ chuỗi byte nào (dữ liệu nhị phân) dưới dạng một chuỗi các ký tự ASCII đơn giản có thể di chuyển qua các kênh chỉ-văn-bản mà không bị hỏng. Tên phản ánh kích thước bảng chữ cái: 64 ký tự được chọn cụ thể vì chúng sống sót qua quá trình truyền sạch 7-bit không thay đổi. Bảng chữ cái tiêu chuẩn là A-Z (vị trí 0-25), a-z (26-51), 0-9 (52-61), sau đó là + (62) và / (63). Ký tự = được dành riêng làm padding khi độ dài đầu vào không phải là bội số chính xác của ba. Cứ ba byte đầu vào (24 bit) trở thành bốn ký tự đầu ra (mỗi ký tự mang 6 bit), đó là lý do tại sao dữ liệu được mã hóa Base64 lớn hơn nguyên bản khoảng 33%.

Cơ chế: lấy ba byte (24 bit), nhóm lại thành bốn khối 6 bit, tra cứu mỗi khối trong bảng chữ cái 64 ký tự. Ví dụ kinh điển: ba byte ASCII M a n (0x4D 0x61 0x6E) tạo thành mẫu 24 bit 01001101 01100001 01101110; được nhóm lại thành các khối 6 bit: 010011 010110 000101 101110 = thập phân 19, 22, 5, 46 = ký tự T W F u. Vì vậy "Man" được mã hóa Base64 thành "TWFu". Nếu độ dài đầu vào không chia hết cho ba, bộ mã hóa sẽ padding bằng một hoặc hai ký tự =: đầu vào 1 byte tạo ra 2 ký tự + ==, đầu vào 2 byte tạo ra 3 ký tự + =.

Một lịch sử ngắn về Base64

Base64 bắt nguồn từ nỗ lực Privacy Enhanced Mail (PEM) của IETF. RFC 989 vào tháng 2 năm 1987 là định nghĩa chính thức đầu tiên; RFC 1113 vào tháng 8 năm 1989 đã sửa đổi nó; RFC 1421 vào tháng 2 năm 1993 đã hoàn thiện đặc tả PEM với mã hóa Base64 được bao gồm. Base64 đã bước vào dòng chính email khi đặc tả MIME (Multipurpose Internet Mail Extensions) áp dụng nó: RFC 2045 vào tháng 11 năm 1996 đã định nghĩa Base64 là mã hóa tiêu chuẩn cho các tệp đính kèm email nhị phân, đó là lý do tại sao mọi PDF hoặc hình ảnh bạn từng đính kèm vào email đều di chuyển qua dây dưới dạng Base64. Đặc tả kinh điển hiện tại là RFC 4648 ("The Base16, Base32, and Base64 Data Encodings"), được xuất bản tháng 10 năm 2006 bởi Simon Josefsson, thay thế RFC 3548 (tháng 7 năm 2003) và hợp nhất các mã hóa họ Base16 / Base32 / Base64 khác nhau thành một tài liệu duy nhất. RFC 4648 là đặc tả mà mọi triển khai Base64 hiện đại nhắm tới.

Base64 URL-Safe, Tại sao Hai Ký tự được Hoán đổi

Bảng chữ cái Base64 tiêu chuẩn sử dụng + và /, cả hai đều là ký tự dành riêng trong URL. + trong chuỗi truy vấn URL thường có nghĩa là "dấu cách" (quy ước form-encoded); / là dấu phân cách đường dẫn. Đặt Base64 tiêu chuẩn trong URL có nghĩa là percent-encoding cả hai, điều này làm phình to chuỗi hơn và làm cho nó xấu. RFC 4648 §5 định nghĩa một biến thể URL-safe: thay thế + bằng - (dấu gạch nối-trừ) và / bằng _ (dấu gạch dưới). Đôi khi được gọi là Base64URL hoặc base64url. Kết quả là một chuỗi rơi thẳng vào URL mà không cần escape thêm, chính xác những gì JWT (JSON Web Tokens), tham số trạng thái OAuth, ID thông tin xác thực WebAuthn và hầu hết các API web hiện đại sử dụng. Một số triển khai cũng loại bỏ padding = trailing vì độ dài là ngầm định từ field tiếp theo. Cấu trúc ba phần được phân tách bằng dấu chấm của JWT (header.payload.signature) là ba đoạn được mã hóa Base64URL; nếu bạn đã từng giải mã JWT thủ công, bạn đã thấy các ký tự - và _ đánh dấu nó là Base64URL chứ không phải Base64 tiêu chuẩn.

Họ Base-N, Base16, Base32, Base58, Base85

Base64 không phải là mã hóa nhị phân-sang-văn bản duy nhất. Base16 (hex) sử dụng 16 ký tự (0-9 và A-F), mở rộng kích thước 100% (mỗi byte trở thành 2 ký tự hex), nhưng có thể đọc đơn giản và là mặc định phổ quát cho đầu ra hash, checksum tệp và định danh máy. Base32 (RFC 4648, cũng là biến thể của Crockford) sử dụng 32 ký tự với sự cẩn trọng để loại trừ các cặp mơ hồ về mặt hình ảnh như 0/O và 1/I/L; mở rộng kích thước 60%; được sử dụng trong khóa bí mật TOTP, ULID và địa chỉ Tor onion. Base58 là Bitcoin-kinh điển: 58 ký tự không bao gồm 0/O/I/l dễ nhầm lẫn, cộng với các ký tự đặc biệt Base64 tiêu chuẩn +/=. Địa chỉ Bitcoin, địa chỉ Solana và nhiều định danh ví crypto sử dụng Base58Check (Base58 cộng với checksum 4 byte). Base85 / Ascii85 đóng gói nhiều mật độ hơn (mã hóa 4 byte thành 5 ký tự, chỉ mở rộng 25%) nhưng sử dụng bảng chữ cái bao gồm dấu chấm câu URL-không an toàn; các định dạng PostScript và PDF của Adobe sử dụng Base85 nội bộ cho dữ liệu nhị phân nhúng. Đánh đổi chung: nhiều ký tự hơn trong bảng chữ cái có nghĩa là mở rộng ít hơn nhưng tập ký tự hạn chế hơn; ít ký tự hơn có nghĩa là vận chuyển an toàn hơn với chi phí đầu ra lớn hơn.

Các trường hợp sử dụng Base64 phổ biến

• Tệp đính kèm email (MIME). RFC 2045 từ năm 1996. Mọi PDF, hình ảnh hoặc tài liệu bạn từng đính kèm vào email đều di chuyển trên mạng dưới dạng Base64 vì SMTP ban đầu là một giao thức văn bản sạch 7-bit không thể xử lý nhị phân thô.
• URI data: trong HTML/CSS. data:image/png;base64,iVBORw0KGgo... nhúng một hình ảnh nhỏ trực tiếp vào HTML hoặc stylesheet CSS, loại bỏ một yêu cầu HTTP. Hữu ích cho biểu tượng dưới ~10 KB; phản tác dụng cho hình ảnh lớn hơn vì mở rộng Base64 33% vượt quá chi phí yêu cầu HTTP tiết kiệm.
• Nhị phân trong payload JSON. JSON chỉ là văn bản theo đặc tả, không có cách nào để đặt byte thô vào giá trị JSON. Các API cần truyền hình ảnh, PDF hoặc nhị phân khác nhúng chúng dưới dạng chuỗi Base64 trong field JSON. Payload webhook của Stripe, API MMS của Twilio và nhiều endpoint AI-vision sử dụng mẫu này.
• JWT (JSON Web Tokens). Ba phần được phân tách bằng dấu chấm của một JWT (header.payload.signature) đều được mã hóa Base64URL. Đặc tả JWT (RFC 7519, tháng 5 năm 2015) được xây dựng trên JOSE (RFC 7515-7518, cũng tháng 5 năm 2015), tất cả đều bắt buộc Base64URL trong toàn bộ.
• OAuth và OpenID Connect. Tham số state, verifier mã PKCE, token ID và token truy cập trong nhiều triển khai sử dụng Base64URL.
• HTTP Basic Authentication. Tiêu đề Authorization: Basic dXNlcjpwYXNz mang Base64(username:password). Lưu ý: đây là mã hóa cho vận chuyển, KHÔNG phải mã hóa, Basic Auth qua HTTP đơn giản phơi bày thông tin xác thực dưới dạng plaintext cho bất kỳ ai theo dõi mạng. Luôn ghép với HTTPS.
• Subresource Integrity (SRI). Thuộc tính integrity="sha384-..." trên các thẻ <script> và <link> mang một hash được mã hóa Base64 của nội dung tệp mong đợi; các trình duyệt xác minh tệp đã tải xuống khớp trước khi thực thi.
• Nền SVG-trong-CSS. background-image: url("data:image/svg+xml;base64,...") nhúng một SVG trực tiếp trong một stylesheet. Hình thức Base64 đôi khi được ưa thích hơn hình thức URL-encoded (giữ SVG có thể đọc được nhưng sử dụng các quy tắc escape khác nhau).

Mã hóa Không phải Mật mã hóa, Một Lỗi Bảo mật Phổ biến

Base64 cung cấp không có bảo mật. Mã hóa hoàn toàn có thể đảo ngược bởi bất kỳ ai trong mili giây, bảng chữ cái là công khai, thuật toán là tầm thường, và bất kỳ trình duyệt hoặc lệnh CLI một dòng nào cũng có thể giải mã nó. Mặc dù vậy, "dữ liệu nhạy cảm được mã hóa Base64" là một trong những ví dụ được trích dẫn nhiều nhất trong MITRE CWE-261 (Mã hóa Yếu cho Mật khẩu) và xuất hiện trong các cuộc kiểm tra bảo mật liên tục: khóa API "được làm mờ" bằng Base64 trong mã client; mật khẩu "được mã hóa" bằng Base64 trong các tệp sao lưu cơ sở dữ liệu; bí mật "được mã hóa" bằng Base64 trước khi commit vào kho lưu trữ Git công khai. Không có cái nào trong số này được bảo vệ. Nếu bạn cần tính bảo mật thực sự, hãy sử dụng mã hóa thực sự: AES-256-GCM cho đối xứng, RSA-OAEP hoặc ECDH+ChaCha20-Poly1305 cho bất đối xứng. Base64 phù hợp cho vận chuyển (biến nhị phân thành hình thức thân thiện với văn bản) nhưng không bao giờ để bảo vệ.

Triển khai Trình duyệt: btoa / atob và Bẫy Unicode

JavaScript cung cấp hai hàm toàn cục tích hợp cho Base64: btoa() (binary-to-ASCII, mã hóa) và atob() (ASCII-to-binary, giải mã). Cả hai đều là API legacy từ thời Netscape sớm và có một hạn chế nổi tiếng: chúng chỉ hoạt động trên chuỗi byte Latin-1. Gọi btoa('é') ném InvalidCharacterError vì chuỗi JavaScript 'é' chứa một điểm mã trên U+00FF không vừa với một byte duy nhất. Cách khắc phục hiện đại là mã hóa thành byte UTF-8 trước thông qua TextEncoder, sau đó chuyển đổi Uint8Array kết quả thành chuỗi Latin-1 để btoa() tiêu thụ. Mẫu: btoa(String.fromCharCode(...new TextEncoder().encode(str))). Giải mã ngược lại: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). Các trình duyệt mới hơn cung cấp Uint8Array.toBase64() và Uint8Array.fromBase64() dưới dạng các phương thức tích hợp, nhưng việc áp dụng vẫn đang triển khai tính đến năm 2026, polyfill thông qua btoa/atob vẫn là mặc định cross-browser. Đối với các tệp cụ thể, FileReader.readAsDataURL() là con đường đơn giản nhất: thả một tệp vào đầu vào, reader trả về một chuỗi data:mime/type;base64,... với mọi thứ được mã hóa chính xác; loại bỏ tiền tố data: để chỉ lấy phần Base64.

Phạm vi Trung thực: Công cụ này Làm gì và Không làm gì

Công cụ này mã hóa văn bản hoặc tệp (lên đến 5 MB) thành Base64 và giải mã chuỗi Base64 trở lại thành văn bản hoặc tệp có thể tải xuống. Nó sử dụng bảng chữ cái tiêu chuẩn RFC 4648 (với + và /) theo mặc định; Base64URL URL-safe (với - và _) là một toggle tính năng tương lai. Văn bản UTF-8 được xử lý chính xác qua TextEncoder, bẫy btoa-Latin-1 đã được khắc phục. Giới hạn kích thước tệp 5 MB tồn tại vì Base64 mở rộng dữ liệu 33% và chuỗi được mã hóa sống hoàn toàn trong bộ nhớ trình duyệt; tệp nhị phân 5 MB tạo ra ~6,7 MB văn bản Base64 cộng với buffer gốc, hoạt động trên mọi thiết bị hiện đại. Đối với các tệp lớn hơn, các lựa chọn thay thế tiêu chuẩn là base64 dòng lệnh trên macOS/Linux (base64 -i input.bin -o output.txt), mô-đun base64 của Python, hoặc Buffer.from(data).toString('base64') của Node.js. Công cụ này không xử lý: streaming Base64 (mã hóa theo từng đoạn cho các tệp lớn hơn bộ nhớ); biến thể URL-safe trong phiên bản này (đã lên kế hoạch); cũng không mã hóa MIME quoted-printable (một sơ đồ RFC 2045 khác cho nội dung email văn bản).

Quyền riêng tư: Tại sao chỉ-Trình duyệt Quan trọng

Base64 không phải là mã hóa, nhưng dữ liệu đang được mã hóa thường nhạy cảm: khóa API bạn đang nhúng trong tệp config, chứng chỉ bạn đang mã hóa để vận chuyển, ảnh chụp màn hình nội bộ bạn đang nhúng dưới dạng URI dữ liệu trong tài liệu, hoặc biên lai PDF bạn đang mã hóa cho khách hàng. Các bộ mã hóa phía máy chủ nhìn thấy đầu vào của bạn. Công cụ này chạy hoàn toàn trong trình duyệt của bạn qua JavaScript, xác minh trong tab Network của DevTools khi bạn nhấp Encode, hoặc đưa trang offline (chế độ máy bay) sau khi tải và công cụ vẫn hoạt động. An toàn để mã hóa thông tin xác thực API, ảnh chụp màn hình PII, tài liệu nội bộ hoặc bất kỳ dữ liệu nào bạn không muốn được sao chép vào ổ cứng của người lạ.

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

Base64 có an toàn không?

Không. Base64 là mã hóa, không phải mã hóa bảo mật. Bất kỳ ai cũng có thể giải mã một chuỗi Base64. Không bao giờ sử dụng Base64 để bảo vệ dữ liệu nhạy cảm, hãy sử dụng mã hóa phù hợp (AES, RSA) để bảo mật.

Tại sao Base64 làm cho tệp lớn hơn?

Mã hóa Base64 làm tăng kích thước dữ liệu khoảng 33%. Ba byte dữ liệu nhị phân trở thành bốn ký tự Base64. Phần bổ sung này là sự đánh đổi để có thể truyền dữ liệu nhị phân dưới dạng văn bản.

Tôi có thể mã hóa tệp không?

Có! Kéo và thả bất kỳ tệp nào vào trình mã hóa hoặc nhấp để duyệt. Tệp sẽ được chuyển đổi thành Base64 Data URI mà bạn có thể dán trực tiếp vào HTML, CSS hoặc JavaScript.

Sự khác biệt giữa Base64 và Base64URL là gì?

Hai ký tự. Base64 tiêu chuẩn (RFC 4648 §4) sử dụng + và / làm ký tự bảng chữ cái thứ 62 và 63. Base64URL URL-safe (RFC 4648 §5) sử dụng - và _ thay vào đó, vì vậy chuỗi được mã hóa rơi thẳng vào URL mà không cần percent-encoding. JWT, OAuth, WebAuthn và hầu hết các API web hiện đại sử dụng Base64URL. Công cụ này hiện đang phát ra Base64 tiêu chuẩn; URL-safe nằm trong danh sách tính năng tương lai. Để chuyển đổi từ tiêu chuẩn sang URL-safe bằng tay: thay + bằng -, / bằng _, tùy chọn loại bỏ padding = trailing.

Tại sao văn bản Unicode của tôi thất bại trong một số công cụ Base64?

Vì hàm legacy btoa() của JavaScript chỉ hoạt động trên chuỗi byte Latin-1, gọi btoa('é') ném InvalidCharacterError. Nhiều bộ mã hóa dựa trên trình duyệt cũ sử dụng btoa trực tiếp mà không có bước chuyển đổi UTF-8, vì vậy bất kỳ đầu vào không-ASCII nào đều bị hỏng. Mã hiện đại (và công cụ này) mã hóa chuỗi qua TextEncoder trước, tạo ra một chuỗi byte UTF-8 mà btoa sau đó có thể mã hóa an toàn. Phương thức tích hợp mới hơn Uint8Array.toBase64() xử lý UTF-8 native nhưng chưa phải là baseline trên tất cả các trình duyệt.

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

Không. Mã hóa và giải mã chạy hoàn toàn trong trình duyệt của bạn qua JavaScript. Văn bản và tệp không bao giờ băng qua mạng, xác minh trong tab Network của DevTools khi bạn nhấp Encode, hoặc đưa trang offline (chế độ máy bay) sau khi tải và công cụ vẫn hoạt động. An toàn cho thông tin xác thực API, ảnh chụp màn hình mang PII, tệp config nội bộ hoặc bất kỳ dữ liệu nào bạn không muốn được sao chép vào ổ cứng của người lạ.

Công cụ liên quan