Mã hóa/Giải mã chuỗi Base64 – Base64 string encoder/decoder

Công cụ mã hóa và giải mã chuỗi Base64 là gì?

Công cụ mã hóa và giải mã chuỗi Base64 là tiện ích chuyển đổi hai chiều giữa văn bản UTF-8 và chuỗi Base64. Ở chiều encode, công cụ chuyển nội dung bạn nhập thành các byte UTF-8 rồi biểu diễn chúng bằng Base64. Ở chiều decode, công cụ đọc chuỗi Base64, khôi phục các byte và diễn giải chúng thành văn bản UTF-8.

Phạm vi được xác nhận từ mã nguồn là chuyển đổi chuỗi văn bản, bao gồm tiếng Việt và emoji có biểu diễn Unicode hợp lệ. Kết quả được cập nhật khi đầu vào thay đổi hoặc khi đổi chế độ. Công cụ không tự nhận diện chiều chuyển đổi: cùng một nội dung sẽ được xử lý theo chế độ đang chọn.

Từ “mã hóa” trên giao diện được dùng theo nghĩa encode, tức thay đổi cách biểu diễn dữ liệu, không phải encrypt, tức mã hóa bảo mật bằng khóa. Người có chuỗi Base64 có thể khôi phục dữ liệu mà không cần mật khẩu. Vì vậy, một đoạn chữ trở nên khó đọc bằng mắt không có nghĩa là nó đã được giữ bí mật.

Base64 cũng không phải phương pháp nén hay cơ chế xác thực người gửi. Nó thường làm biểu diễn dữ liệu dài hơn, không chứng minh nội dung chưa bị sửa và không xác nhận nguồn gốc. Công cụ phù hợp khi cần tạo hoặc đọc Base64 của văn bản, chứ không thay thế giải pháp bảo vệ thông tin.

Các thuật ngữ cần hiểu khi chuyển đổi Base64

Base64

Base64 là cách biểu diễn dữ liệu byte bằng bảng chữ cái gồm 64 ký hiệu. Dạng chuẩn dùng chữ hoa, chữ thường, chữ số, dấu cộng và dấu gạch chéo; cuối chuỗi có thể có dấu đệm =. Với công cụ này, Base64 là dạng đầu ra của encode và dạng đầu vào của decode. Điểm dễ nhầm nhất là coi chuỗi khó đọc đó như dữ liệu đã được bảo vệ: Base64 không cần khóa và có thể đảo ngược.

UTF-8

UTF-8 là cách biểu diễn các điểm mã Unicode hợp lệ bằng một đến bốn byte. Nó giúp văn bản tiếng Việt, ký hiệu và emoji trở thành dữ liệu byte để Base64 xử lý. Hai lớp này khác nhau: UTF-8 trả lời “văn bản được biểu diễn bằng byte nào”, còn Base64 trả lời “các byte ấy được viết thành chuỗi ký hiệu nào”. Khi decode, byte khôi phục phải hợp lệ theo UTF-8; Base64 đúng chưa đủ để bảo đảm có văn bản đọc được.

Byte

Byte là đơn vị dữ liệu gồm tám bit, không đồng nghĩa với một ký tự nhìn thấy trên màn hình. Một chữ ASCII thường chiếm một byte UTF-8, trong khi chữ có dấu hoặc emoji có thể cần nhiều byte. Sự khác biệt này ảnh hưởng trực tiếp tới độ dài chuỗi Base64. Khi ước lượng kết quả, không nên chỉ đếm số chữ: một ký tự hiển thị còn có thể được cấu thành từ nhiều điểm mã Unicode.

Padding

Padding là phần đệm, thường được biểu diễn bằng dấu = ở cuối Base64 chuẩn. Base64 xử lý từng nhóm ba byte; nếu nhóm cuối chưa đủ ba byte, dấu đệm giúp hoàn chỉnh nhóm biểu diễn bốn ký hiệu. Vì vậy, đuôi = hoặc == không phải dấu bằng vốn có trong văn bản gốc. Không phải kết quả nào cũng có đệm, và việc tự xóa đệm có thể làm chuỗi không phù hợp với hệ thống nhận.

Base64URL

Base64URL là biến thể dùng dấu - và _ thay cho + và /; một số quy ước còn bỏ dấu đệm. Biến thể này thường xuất hiện trong dữ liệu dùng với URL, nhưng không phải URL encoding. Mã nguồn công cụ không có bước chuyển đổi bảng chữ cái Base64URL sang Base64 chuẩn. Do đó, không nên mặc định mọi chuỗi mang tên Base64 đều có thể dán trực tiếp và nhận kết quả giống nhau.

Đầu vào và kết quả của từng chế độ

Văn bản đầu vào khi encode

Encode nhận văn bản và giữ nội dung đầu vào, bao gồm dấu cách, dấu câu và xuống dòng. Các thành phần này được chuyển thành byte cùng với chữ, nên việc thêm một dấu cách có thể làm thay đổi kết quả. Văn bản phải có biểu diễn Unicode hợp lệ để chuyển sang UTF-8; những chuỗi Unicode bất thường có thể gây lỗi. Mã được cung cấp không khai báo giới hạn số ký tự.

Chuỗi đầu vào khi decode

Decode nhận chuỗi Base64 theo dạng mà bộ giải mã của trình duyệt chấp nhận. Trước khi chuyển đổi, công cụ bỏ khoảng trắng ở hai đầu và các ký tự khoảng trắng được quy tắc xử lý nhận diện, bao gồm dấu cách và xuống dòng. Sau đó, các byte khôi phục phải tạo thành UTF-8 hợp lệ. Chuỗi biểu diễn dữ liệu nhị phân có thể vượt qua bước đọc Base64 nhưng thất bại ở bước chuyển thành văn bản.

Cách đọc kết quả và trạng thái

Ô kết quả chỉ đọc. Trạng thái thành công cho biết phép chuyển đổi hoàn tất, không chứng nhận nội dung đáng tin. Đầu vào chỉ chứa khoảng trắng khác đầu vào rỗng: encode vẫn biểu diễn các khoảng trắng; decode loại bỏ chúng và có thể trả kết quả rỗng với trạng thái “Đã giải mã”.

Công cụ chuyển đổi Base64 theo quy tắc nào?

Từ văn bản tới Base64 và ngược lại

Ở chiều encode, công cụ chuyển văn bản thành byte UTF-8 trước khi tạo Base64. Bước trung gian này quan trọng với chữ có dấu và emoji: chúng không được xử lý như các ký tự một byte đơn giản. Ở chiều ngược lại, công cụ làm sạch khoảng trắng của chuỗi Base64, khôi phục byte rồi đọc các byte đó theo UTF-8.

Đây là hai phép chuyển đổi liên tiếp, không phải thao tác thay từng chữ bằng một ký hiệu cố định. Nếu byte sau decode không phù hợp với UTF-8, quá trình dừng ở nhánh lỗi dù cách biểu diễn Base64 ban đầu có thể hợp lệ.

Độ dài Base64 phụ thuộc số byte

Theo quy tắc nền tảng, ba byte chứa 24 bit được chia thành bốn nhóm sáu bit; mỗi nhóm tương ứng một ký hiệu Base64. Nhóm cuối thiếu byte sẽ dùng dấu đệm. Với Base64 chuẩn có đệm, độ dài là 4 × ceil(n / 3), trong đó n là số byte đầu vào và ceil nghĩa là làm tròn lên tới số nguyên.

Chẳng hạn, năm byte tạo ra tám ký tự Base64. Đây là độ dài của biểu diễn, không phải dung lượng nén. Khi văn bản có tiếng Việt hoặc emoji, cần tính số byte UTF-8 thay vì chỉ đếm ký tự nhìn thấy.

Tính lại kết quả và xử lý lỗi

Công cụ tính lại khi sửa đầu vào và khi đổi chế độ. Đổi chế độ sẽ diễn giải lại nội dung hiện có, không tự chuyển nội dung đó sang dạng phù hợp trước. Hoán đổi thì khác: công cụ lấy kết quả hiện tại làm đầu vào mới, đảo chiều chuyển đổi rồi tính lại, chứ không trao đổi nguyên trạng hai ô.

Các ngoại lệ chuyển đổi được gộp vào một thông báo lỗi chung. Sao chép và hoán đổi không được thực hiện nếu kết quả rỗng hoặc chứa chuỗi chữ LỖI. Điều kiện này dựa trên nội dung kết quả, không phải một phép đánh giá riêng về tính hợp lệ của văn bản.

Ví dụ chuyển đổi ASCII, Unicode và dữ liệu không hợp lệ

Văn bản ASCII đơn giản

Các kết quả dưới đây được suy ra từ thuật toán và quy tắc UTF-8/Base64, không phải báo cáo chạy thử. Giả sử đầu vào encode là đúng năm chữ Hello, không có dấu cách, dấu nháy hay xuống dòng. Năm ký tự ASCII này tương ứng năm byte UTF-8, cho kết quả SGVsbG8=.

Độ dài đầu ra là 4 × ceil(5 / 3) = 8 ký tự, tính cả dấu đệm. Nếu dùng chuỗi SGVsbG8= làm đầu vào decode, các byte được khôi phục thành Hello. Ví dụ minh họa khả năng đảo ngược, không phải khả năng bảo vệ câu chữ khỏi người đọc.

Chữ có dấu và emoji

Giả sử đầu vào chỉ có chữ é ở dạng điểm mã Unicode U+00E9. Chữ này dùng hai byte UTF-8, có giá trị thập lục phân C3 A9, và được biểu diễn bằng Base64 là w6k=. Bốn ký tự đầu ra gồm một dấu đệm; số byte đầu vào không bằng số chữ hiển thị.

Với emoji 😀 ở điểm mã U+1F600, đầu vào gồm bốn byte UTF-8 F0 9F 98 80. Kết quả là 8J+YgA==, dài tám ký tự. Dù mỗi ví dụ trông như chỉ có một ký tự, độ dài byte và Base64 khác nhau. Nếu chữ có dấu được tạo bằng tổ hợp nhiều điểm mã thay vì dạng đã nêu, không nên mặc định chuỗi Base64 vẫn giống hệt.

Khoảng trắng và lỗi UTF-8

Giả sử đầu vào decode có dấu cách đầu cuối, một dấu cách giữa SG và Vs, cùng một xuống dòng thực giữa Vs và bG8=:

 SG Vs
bG8= 

Sau khi bỏ khoảng trắng, chuỗi còn lại là SGVsbG8=, nên văn bản khôi phục vẫn là Hello. Việc làm sạch này chỉ áp dụng cho decode; dấu cách trong văn bản encode vẫn thuộc dữ liệu.

Ngược lại, /w== biểu diễn byte FF. Đây không phải byte tạo thành văn bản UTF-8 hợp lệ, nên công cụ trả “LỖI: Dữ liệu không hợp lệ!” và trạng thái “Lỗi định dạng”. Không nên diễn giải trường hợp này là sai cú pháp Base64. Với đầu vào gồm ba dấu cách, decode làm sạch thành chuỗi rỗng, cho kết quả rỗng nhưng vẫn báo đã giải mã.

Khi nào nên dùng công cụ chuyển đổi chuỗi Base64?

Chuyển đổi và đối chiếu văn bản mẫu

Công cụ hữu ích khi cần tạo Base64 cho một đoạn văn bản mẫu hoặc đọc nội dung Base64 mà bạn được phép xử lý. Ví dụ, một hệ thống yêu cầu trường văn bản ở dạng Base64: bạn có thể chuẩn bị giá trị chuyển đổi, nhưng vẫn cần tuân thủ yêu cầu riêng về UTF-8, biến thể Base64 và dấu đệm của hệ thống đó.

Chuyển đổi hai chiều cũng giúp đối chiếu nội dung trước và sau: dấu tiếng Việt có còn đúng không, xuống dòng có được giữ không, hoặc có vô tình thêm khoảng trắng vào văn bản gốc không. Việc khôi phục được nội dung phù hợp cho thấy hai chiều chuyển đổi nhất quán với dữ liệu mẫu, không chứng minh người gửi là ai hay dữ liệu chưa bị can thiệp trước đó.

Chọn đúng phạm vi chuỗi hay tệp

Hãy phân biệt nhu cầu chuyển một đoạn chữ với nhu cầu biểu diễn toàn bộ tệp hoặc ảnh. Giao diện được cung cấp chỉ có đầu vào văn bản, không có tải tệp hay xem ảnh. Nếu nhu cầu liên quan đến tệp, chủ đề chuyển đổi file sang Base64 phù hợp hơn để tìm hiểu; đây không phải xác nhận về khả năng cụ thể hay sự tích hợp của công cụ khác.

Nên dùng dữ liệu mẫu không nhạy cảm khi kiểm tra cách chuyển đổi. Mật khẩu, thông tin cá nhân và nội dung riêng tư không được bảo vệ chỉ nhờ trở thành Base64.

Base64 khác URL encoding, mã hóa bảo mật và hàm băm ra sao?

Base64 và URL encoding

Base64 biểu diễn byte bằng bảng ký hiệu riêng. URL encoding biểu diễn ký tự hoặc byte theo quy tắc phù hợp với từng thành phần URL, thường gặp dạng phần trăm như %20. Hai cách không thay thế máy móc cho nhau: dấu + hoặc / trong Base64 có thể cần xử lý theo ngữ cảnh URL. Chủ đề encode và decode chuỗi URL giúp phân biệt nhu cầu này.

Encode, encrypt và hash

Đây là so sánh kiến thức nền, không phải danh sách chức năng của công cụ. Mã nguồn chỉ xác nhận chuyển đổi Base64 với văn bản UTF-8; không có đầu vào khóa, thao tác encrypt hoặc chức năng hash. Việc dùng chung từ “mã hóa” không làm các cơ chế này tương đương.

Decode không phải xác minh chữ ký

Decode chỉ khôi phục dữ liệu từ cách biểu diễn. Nó không kiểm tra chữ ký số, danh tính hay quyền gửi nội dung. Một chuỗi do người khác chỉnh sửa vẫn có thể decode thành công nếu đáp ứng điều kiện định dạng. Muốn xác minh nguồn gốc hoặc tính toàn vẹn cần cơ chế phù hợp riêng; không thể dùng trạng thái “Đã giải mã” thay cho bằng chứng xác thực.

Giới hạn và lưu ý trước khi sử dụng

Dữ liệu không thuộc phạm vi văn bản UTF-8

Base64 của ảnh hoặc tệp không mặc nhiên trở thành văn bản đọc được. Công cụ không có bộ xem nhị phân, đầu vào tải tệp hay chức năng dựng ảnh trong mã được cung cấp. Một số byte có thể gây lỗi UTF-8; một số khác có thể thành ký tự khó đọc mà vẫn không giúp hiểu nội dung tệp.

Base64URL và Data URL cũng không có bước xử lý chuyên biệt. Công cụ không tự đổi -, _ sang bảng chữ cái chuẩn, không tự tách tiền tố data: và không có bước chủ động bổ sung dấu đệm. Cần biết định dạng nguồn thay vì trông chờ tự nhận diện.

Khả năng trình duyệt và dữ liệu nhạy cảm

Không có ngưỡng dung lượng được khai báo không đồng nghĩa xử lý không giới hạn. Chuỗi lớn vẫn phụ thuộc bộ nhớ, khả năng đáp ứng và trình duyệt; chưa có căn cứ để cam kết tốc độ hay dung lượng cụ thể.

Sao chép phụ thuộc khả năng và quyền truy cập clipboard của trình duyệt. Ngoài ra, kết quả hợp lệ chứa chữ LỖI vẫn bị chặn sao chép và hoán đổi do điều kiện kiểm tra nội dung. Việc thấy logic chuyển đổi bằng API trình duyệt cũng không chứng minh toàn trang không gửi, ghi log hoặc lưu dữ liệu. Các thành phần khác chưa được xác minh, nên không nhập dữ liệu nhạy cảm dựa trên giả định riêng tư tuyệt đối.

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

Có nên dùng Base64 để bảo vệ mật khẩu không?

Không. Base64 không tạo lớp bảo vệ bí mật cho mật khẩu vì bất kỳ người nào có chuỗi đó đều có thể decode mà không cần khóa. Nếu một hệ thống yêu cầu biểu diễn Base64, đó chỉ là yêu cầu định dạng, không chứng minh mật khẩu được bảo vệ khi truyền hoặc lưu. Bạn cần cơ chế bảo mật phù hợp với hệ thống đang sử dụng. Khi tìm hiểu công cụ, hãy dùng chuỗi giả định thay vì mật khẩu thật hoặc thông tin đăng nhập đang có hiệu lực.

Vì sao một chuỗi Base64 vẫn báo lỗi khi decode?

Lỗi có thể xuất phát từ cách viết Base64 không được bộ giải mã chấp nhận hoặc từ các byte không tạo thành UTF-8 hợp lệ. Hai nguyên nhân này được hiển thị bằng cùng một thông báo, nên không thể kết luận chỉ dựa vào nhãn lỗi. Hãy xác định chuỗi nguồn là Base64 chuẩn, Base64URL hay dữ liệu kèm tiền tố, đồng thời xem nó vốn biểu diễn văn bản hay dữ liệu nhị phân. Công cụ không có chức năng tự sửa mọi dạng đầu vào.

Có thể dùng công cụ này để giải mã Base64 của ảnh hoặc tệp không?

Không nên dùng công cụ này để khôi phục ảnh hoặc tệp như một sản phẩm đầu ra hoàn chỉnh. Bạn có thể nhập chuỗi, nhưng công cụ cố diễn giải byte thành văn bản UTF-8, không dựng ảnh hoặc tạo tệp tải xuống. Dữ liệu ảnh thường là nhị phân nên có thể báo lỗi ở bước đọc UTF-8. Ngay cả khi có chữ xuất hiện, điều đó không xác nhận tệp đã được phục hồi đúng. Ngoại lệ phù hợp là nội dung vốn chỉ là văn bản UTF-8 được biểu diễn bằng Base64.

Chuỗi Base64URL chứa ‘-‘ và ‘_’ có dùng trực tiếp được không?

Không nên coi chuỗi có hai ký hiệu này là đầu vào được hỗ trợ trực tiếp. Mã nguồn không có bước chuyển bảng chữ cái Base64URL sang Base64 chuẩn trước khi decode. Nếu một chuỗi Base64URL tình cờ chỉ dùng các ký hiệu chung, nó có thể không thể hiện khác biệt đó, nhưng không chứng minh công cụ hỗ trợ đầy đủ biến thể. Hãy kiểm tra quy ước của nguồn cung cấp, bao gồm dấu đệm, và chọn cách xử lý đúng định dạng thay vì đổi chế độ để thử đoán.

Có thể dán nguyên chuỗi bắt đầu bằng ‘data:’ để giải mã không?

Không, công cụ không tự tách phần dữ liệu khỏi một Data URL đầy đủ. Chuỗi dạng này còn chứa thông tin loại nội dung và dấu phân cách, không chỉ có Base64. Nếu biết chắc Data URL sử dụng Base64, cần phân biệt phần mô tả với phần dữ liệu trước khi xử lý. Dù đã lấy riêng phần Base64, kết quả vẫn phải đáp ứng yêu cầu UTF-8 để hiển thị thành văn bản. Data URL chứa ảnh không vì được bỏ tiền tố mà trở thành văn bản phù hợp.

Vì sao có kết quả nhưng không sao chép hoặc hoán đổi được?

Có hai nhóm nguyên nhân cần phân biệt. Công cụ không thực hiện sao chép hoặc hoán đổi nếu kết quả rỗng hay chứa đúng chuỗi chữ LỖI, kể cả khi đó là một phần của văn bản hợp lệ. Riêng sao chép còn có thể thất bại do quyền hoặc điều kiện hoạt động của clipboard trong trình duyệt; khi thao tác này phát sinh lỗi, công cụ thông báo “Lỗi sao chép!”. Vì vậy, kết quả nhìn thấy được không bảo đảm mọi thao tác phụ đều khả dụng, và vấn đề clipboard không đồng nghĩa chuyển đổi sai.

Vì sao đầu vào chỉ có khoảng trắng vẫn báo đã giải mã?

Vì công cụ kiểm tra đầu vào rỗng trước khi loại bỏ khoảng trắng. Một chuỗi gồm các dấu cách vẫn có nội dung ở lần kiểm tra đầu tiên, nên đi tiếp vào xử lý decode. Sau khi làm sạch, nó trở thành chuỗi rỗng và được chuyển đổi thành văn bản rỗng mà không phát sinh lỗi, dẫn tới trạng thái “Đã giải mã”. Trạng thái này chỉ phản ánh xử lý hoàn tất, không cho biết đã có nội dung hữu ích. Nếu đầu vào rỗng ngay từ đầu, trạng thái sẽ là chờ nhập liệu.