Base64 Encoding: When to Use It and When Not To

Ba năm trước, tôi đã chứng kiến một lập trình viên junior trong đội của mình mã hóa một tệp video 50MB hoàn toàn thành Base64 và nhúng nó trực tiếp vào phản hồi API JSON. Ứng dụng đã dừng hoạt động. Người dùng phàn nàn về thời gian tải mất tới một phút. Chi phí CDN của chúng tôi tăng gấp ba lần trong một đêm. Khi tôi hỏi anh ta tại sao lại làm như vậy, anh ta nói: "Tôi đã đọc rằng Base64 giúp dữ liệu an toàn khi truyền qua internet."

Anh ta không hoàn toàn sai – nhưng cũng không hoàn toàn đúng. Sự cố đó đã tốn của chúng tôi khoảng 12.000 đô la trong việc mở rộng hạ tầng khẩn cấp và khoảng 200 giờ thời gian của lập trình viên để tái cấu trúc. Nó cũng đã dạy cho tôi một điều quan trọng: Mã hóa Base64 là một trong những công nghệ có vẻ đơn giản về bề mặt nhưng thường bị hiểu lầm trong thực tế.

Tôi là Marcus Chen, và tôi đã dành 14 năm qua để xây dựng các ứng dụng đòi hỏi nhiều dữ liệu – đầu tiên tại một công ty dịch vụ tài chính xử lý hàng triệu giao dịch mỗi ngày, sau đó tại một công ty khởi nghiệp chăm sóc sức khỏe xử lý dữ liệu nhạy cảm của bệnh nhân, và bây giờ là kỹ sư chính tại một công ty SaaS phục vụ hơn 50.000 doanh nghiệp. Trong thời gian đó, tôi đã thấy Base64 được sử dụng một cách thông minh và thảm họa, thường là trong cùng một mã nguồn.

Bài viết này là nỗ lực của tôi để làm rõ thông tin. Tôi sẽ giải thích những gì Base64 thực sự làm, khi nào nó là công cụ đúng cho công việc, khi nào thì hoàn toàn không phù hợp, và cách đưa ra những quyết định sáng suốt mà không quay lại ám ảnh bạn lúc 3 giờ sáng khi ứng dụng của bạn đang gặp sự cố.

Base64 Thực Sự Làm Gì (Và Không Làm Gì)

Hãy bắt đầu với những điều cơ bản, vì tôi nhận thấy rằng hầu hết các trường hợp sử dụng sai Base64 xuất phát từ những hiểu lầm cơ bản về nó.

Base64 là một hệ thống mã hóa chuyển đổi dữ liệu nhị phân thành văn bản ASCII sử dụng 64 ký tự có thể in (A-Z, a-z, 0-9, +, và /). Chỉ vậy thôi. Nó không phải là mã hóa. Nó không phải là nén. Nó không phải là biện pháp an ninh. Nó là một cơ chế dịch thuật – giống như việc chuyển đổi một cuốn sách từ tiếng Pháp sang tiếng Anh. Nội dung không thay đổi; chỉ có cách thể hiện là thay đổi.

Dưới đây là những gì diễn ra bên trong: Base64 lấy mỗi ba byte dữ liệu đầu vào (24 bit) và đại diện chúng bằng bốn ký tự ASCII (32 bit). Điều này có nghĩa là dữ liệu của bạn sẽ tăng khoảng 33% sau khi mã hóa. Một tệp 1MB trở thành khoảng 1.33MB. Một bản sao lưu cơ sở dữ liệu 100MB trở thành 133MB. Chi phí này không phải là điều nhỏ nhặt, và đó là điều đầu tiên mà mọi người quên khi họ sử dụng Base64.

Lý do Base64 tồn tại là lịch sử. Trong những ngày đầu của internet, nhiều hệ thống chỉ có thể xử lý văn bản ASCII 7 bit một cách đáng tin cậy. Dữ liệu nhị phân – hình ảnh, tệp thực thi, tệp nén – sẽ bị hỏng khi được truyền qua các máy chủ email, lưu trữ trong các cơ sở dữ liệu chỉ được thiết kế cho văn bản, hoặc được truyền qua các hệ thống mà giải thích một số giá trị byte nhất định như là ký tự điều khiển. Base64 đã giải quyết điều này bằng cách đảm bảo rằng dữ liệu nhị phân có thể giả làm văn bản thuần túy và tồn tại trong những hành trình đó một cách nguyên vẹn.

Tôi nhớ làm việc trên một hệ thống email cũ vào năm 2012 sẽ âm thầm làm hỏng bất kỳ tin nhắn nào chứa byte có giá trị trên 127. Chúng tôi đã phải mã hóa Base64 tất cả các tệp đính kèm chỉ để đưa chúng qua ống dẫn. Nhưng: hầu hết các hệ thống hiện đại không có giới hạn này nữa. HTTP có thể xử lý dữ liệu nhị phân một cách dễ dàng. Các cơ sở dữ liệu hiện đại có loại BLOB. Hệ thống tập tin không quan tâm dữ liệu của bạn là văn bản hay nhị phân.

Tuy nhiên, các lập trình viên vẫn tiếp tục sử dụng Base64 như thể chúng tôi vẫn còn sống ở năm 1996. Tại sao? Bởi vì nó dễ dàng, quen thuộc và dường như hoạt động – cho đến khi không còn nữa.

Khi Nào Base64 Thực Sự Là Lựa Chọn Đúng

Mặc dù có những câu chuyện cảnh báo của tôi, Base64 không hoàn toàn xấu. Có những kịch bản hợp lý, có lý do rõ ràng mà nó là công cụ chính xác. Để tôi hướng dẫn bạn qua những kịch bản đó.

"Base64 là một cơ chế dịch thuật, không phải là một biện pháp an ninh. Coi nó như mã hóa giống như nghĩ rằng một người phiên dịch ngôn ngữ làm cho bí mật của bạn an toàn - nó không, nó chỉ làm cho chúng có thể đọc được bằng một bảng chữ cái khác."

Trường hợp sử dụng hợp lệ phổ biến nhất là nhúng các tài sản nhị phân nhỏ trực tiếp vào các định dạng dựa trên văn bản. Data URIs trong CSS và HTML là một ví dụ hoàn hảo. Nếu bạn có một biểu tượng 2KB xuất hiện trên mỗi trang của ứng dụng, việc nhúng nó dưới dạng một Data URI Base64 thực sự có thể cải thiện hiệu suất bằng cách loại bỏ một yêu cầu HTTP. Phép tính rất đơn giản: chi phí của yêu cầu HTTP (thường từ 50-200ms bao gồm tra cứu DNS, thiết lập kết nối và xử lý server) vượt quá chi phí của việc truyền thêm 667 byte (chi phí 33% trên 2KB).

Tôi sử dụng kỹ thuật này một cách rộng rãi cho các tài sản quan trọng ở trên cùng. Trong một dự án, chúng tôi đã giảm thời gian tạo trang ban đầu từ 1,2 giây xuống 0,8 giây bằng cách mã hóa Base64 năm biểu tượng SVG nhỏ (tổng cộng 8KB) trực tiếp vào CSS quan trọng của chúng tôi. 2.6KB chi phí bổ sung đã được bù đắp hoàn toàn bằng cách loại bỏ năm yêu cầu HTTP riêng biệt.

Một trường hợp hợp lệ khác là lưu trữ dữ liệu nhị phân trong các hệ thống thực sự chỉ hỗ trợ văn bản. JSON là ví dụ rõ ràng. JSON không có kiểu nhị phân bản địa, vì vậy nếu bạn cần bao gồm dữ liệu nhị phân trong một payload JSON – chẳng hạn, một hình ảnh thu nhỏ nhỏ trong phản hồi API – Base64 là lựa chọn duy nhất của bạn. Nhưng hãy lưu ý rằng tôi đã nói "nhỏ." Tôi có một quy tắc cứng: không bao giờ mã hóa Base64 bất kỳ thứ gì lớn hơn 50KB để đưa vào JSON. Vượt qua ngưỡng đó, bạn nên sử dụng yêu cầu multipart, các điểm cuối riêng biệt, hoặc các giao thức nhị phân trực tiếp.

Các mã thông báo xác thực và các hoạt động mật mã là một lĩnh vực hợp lệ khác. JWT (JSON Web Tokens) sử dụng mã hóa Base64URL cho các phần tiêu đề và payload của nó. Điều này có lý do vì các JWT cần được truyền trong các tiêu đề HTTP và URL, cả hai đều là ngữ cảnh dựa trên văn bản. Các mã thông báo thường nhỏ (dưới 2KB), và chi phí 33% là chấp nhận được với sự tiện lợi khi có thể truyền chúng dưới dạng chuỗi đơn giản.

Tôi cũng sử dụng Base64 khi tạo ra các định danh duy nhất cần phải an toàn với URL và nhỏ gọn hơn so với hệ thập lục phân. Một UUID 128-bit mã hóa trong hex là 32 ký tự; UUID tương tự trong Base64 chỉ có 22 ký tự. Khi bạn đang tạo ra hàng triệu ID và lưu trữ chúng trong các chỉ mục cơ sở dữ liệu, tiết kiệm không gian 31% cộng dồn lại. Trong một hệ thống tôi đã xây dựng, việc chuyển từ mã hóa hex sang Base64URL cho các khóa chính đã giảm kích thước chỉ mục của chúng tôi xuống 180GB trên toàn cụm của chúng tôi.

Chi Phí Hiệu Suất Mà Không Ai Nói Đến

Hãy nói về các con số, vì tôi nhận thấy rằng các cảnh báo trừu tượng về "chi phí hiệu suất" không giữ được. Những phép đo cụ thể thì có.

Tôi đã chạy một loạt các bài kiểm tra trên một máy chủ ứng dụng điển hình (Intel Xeon 4 lõi, 16GB RAM) mã hóa và giải mã các kích thước tệp khác nhau. Mã hóa một tệp 10MB thành Base64 mất trung bình 42 mili giây. Giải mã lại mất 38 mili giây. Điều đó có thể không nghe có vẻ nhiều, nhưng hãy xem xét: nếu bạn đang mã hóa các hình ảnh do người dùng tải lên trên mỗi yêu cầu, và bạn đang xử lý 100 yêu cầu mỗi giây, bạn đang dành 4.2 giây thời gian CPU mỗi giây chỉ cho việc mã hóa Base64. Điều đó nhiều hơn một lõi CPU hoàn toàn chỉ dành cho chi phí mã hóa.

Tác động đến bộ nhớ thậm chí còn tồi tệ hơn. Bởi vì việc mã hóa Base64 yêu cầu lưu trữ toàn bộ đầu vào và đầu ra trong bộ nhớ cùng một lúc, mã hóa tệp 10MB thực sự yêu cầu khoảng 23MB bộ nhớ.