Bộ mã hóa & giải mã Base64

Base64 mã hóa byte tùy ý thành 64 ký tự ASCII in được, để các kênh truyền không an toàn với nhị phân (chuỗi JSON, URL, nội dung email, biến môi trường, HTTP Basic auth) có thể mang chúng mà không bị hỏng. Công cụ này xử lý đầu vào UTF-8 đúng cách — trước tiên mã hóa chuỗi của bạn thành byte UTF-8, sau đó mã hóa các byte đó bằng Base64, nên các ký tự không phải ASCII đi vòng sạch sẽ. Đầu ra lớn hơn đầu vào khoảng 33% (cứ 3 byte trở thành 4 ký tự).

Ví dụ

Mã hóa văn bản "Hello, world!":

SGVsbG8sIHdvcmxkIQ==

Mã hóa cùng văn bản với An toàn URL bật (đã bỏ padding):

SGVsbG8sIHdvcmxkIQ

Mã hóa văn bản emoji "café ☕":

Y2Fmw6kg4piV

Tại sao chuỗi Base64 của tôi không giải mã được?

• Không khớp giữa standard và An toàn URL. Chuỗi có - hoặc _ là base64url, không phải standard Base64. Chuyển hộp kiểm An toàn URL để khớp.
• Thiếu padding. Độ dài chuỗi standard Base64 phải là bội của 4. SGVsbG8 thất bại; SGVsbG8= hoạt động. Đệm = cho đến khi độ dài chia hết cho 4.
• Khoảng trắng và xuống dòng bên trong giá trị. Một số hệ thống bọc Base64 tại 76 ký tự bằng \n. Hầu hết bộ giải mã dung nạp điều này, nhưng những bộ nghiêm ngặt hơn thì không. Xóa khoảng trắng trước khi giải mã.
• Vô tình giải mã hai lần. Giải mã U0dWc2JHOA== cho SGVsbG8, bản thân cũng là chuỗi Base64. Nếu đầu ra của bạn trông giống Base64 nữa, hãy giải mã lại.
• Dữ liệu nhị phân không phải UTF-8. Nếu các byte đã giải mã không phải UTF-8 hợp lệ (ví dụ: header PNG), giải mã dưới dạng văn bản sẽ thất bại hoặc hiển thị rác. Dùng công cụ Base64 nhận biết tệp cho nhị phân.
• Dấu nháy thông minh hoặc dấu ba chấm nhìn thấy được. Sao chép từ trình xử lý văn bản có thể thay " bằng dấu nháy cong hoặc cắt chuỗi dài bằng dấu ba chấm. Dán qua trình soạn thảo văn bản thuần trước.

Sự khác biệt giữa standard Base64 và Base64 An toàn URL là gì?

Standard Base64 (RFC 4648) dùng + và / và đệm bằng =. Base64 An toàn URL (base64url) thay + bằng - và / bằng _ và thường bỏ padding để chuỗi tồn tại như đường dẫn URL hoặc tham số truy vấn không thay đổi. JWT dùng base64url. Chọn hộp kiểm An toàn URL khi đầu ra đi vào URL.

Công cụ này có xử lý emoji và văn bản không phải ASCII đúng không?

Có. Đầu vào trước tiên được mã hóa thành byte UTF-8, sau đó các byte đó được mã hóa Base64. Giải mã đảo ngược cả hai bước. Đó là lý do dán "café" và giải mã kết quả trả lại "café", không phải mojibake. Nhiều công cụ Base64 cũ giả định Latin-1 và làm hỏng mọi thứ ngoài ASCII.

Tôi có thể mã hóa tệp nhị phân như hình ảnh hoặc PDF không?

Trang này chỉ mã hóa văn bản. Để mã hóa Base64 một tệp, thả tệp vào công cụ đọc nó dưới dạng nhị phân (hoặc dùng console trình duyệt với FileReader.readAsDataURL). Công cụ này để mã hóa chuỗi — trường hợp sử dụng điển hình khi nhúng thông tin xác thực, cấu hình hoặc trường JSON.

Tại sao đầu ra giải mã của tôi trông như rác?

Thường đầu vào ban đầu không phải Base64, hoặc đó là Base64 An toàn URL được giải mã như standard (hoặc ngược lại). Thử chuyển hộp kiểm An toàn URL. Nguyên nhân phổ biến khác là giải mã một chuỗi thực sự là nhị phân được mã hóa Base64, không phải văn bản — trong trường hợp đó các byte không phải UTF-8 hợp lệ.

Padding = có quan trọng không?

Standard Base64 đệm đầu ra để độ dài là bội của 4. Hầu hết bộ giải mã chấp nhận đầu vào không có padding, nhưng một số bộ nghiêm ngặt từ chối nó. Base64 An toàn URL thường bỏ padding. Nếu bộ giải mã phàn nàn, thêm dấu = cho đến khi độ dài chia hết cho 4, hoặc bỏ hết và thử lại.

Bạn có lưu văn bản tôi mã hóa hoặc giải mã không?

Không. Chúng tôi không lưu bất kỳ văn bản nào bạn dán vào đây. Đầu vào của bạn bị loại bỏ ngay khi bạn đóng hoặc làm mới trang — không có gì được giữ, và không có hồ sơ về những gì bạn đã mã hóa hoặc giải mã. Nếu muốn thêm một lớp yên tâm, bạn có thể kiểm tra developer tools của trình duyệt.