Wikipedia nói

Các lược đồ mã hóa Base64 thường được sử dụng khi có nhu cầu mã hóa dữ liệu nhị phân cần lưu trữ và chuyển qua phương tiện được thiết kế để xử lý dữ liệu văn bản. Điều này là để đảm bảo rằng dữ liệu vẫn còn nguyên vẹn mà không cần sửa đổi trong quá trình vận chuyển.

Nhưng không phải dữ liệu luôn được lưu trữ / truyền trong hệ nhị phân vì bộ nhớ mà máy của chúng tôi có lưu trữ nhị phân và nó chỉ phụ thuộc vào cách bạn diễn giải nó? Vì vậy, cho dù bạn mã hóa mẫu bit 010011010110000101101110như Mantrong ASCII hay như TWFutrong Base64, cuối cùng bạn cũng sẽ lưu trữ cùng một mẫu bit.

Nếu mã hóa cuối cùng là về số không và các mã và mọi máy móc và phương tiện truyền thông có thể xử lý chúng, thì dữ liệu được biểu diễn dưới dạng ASCII hay Base64 như thế nào?

"Phương tiện được thiết kế để xử lý dữ liệu văn bản" nghĩa là gì? Họ có thể đối phó với nhị phân => họ có thể đối phó với bất cứ điều gì.

Cảm ơn tất cả mọi người, tôi nghĩ rằng tôi hiểu bây giờ.

Khi chúng tôi gửi dữ liệu, chúng tôi không thể chắc chắn rằng dữ liệu sẽ được diễn giải theo cùng định dạng như chúng tôi dự định. Vì vậy, chúng tôi gửi dữ liệu được mã hóa theo một số định dạng (như Base64) mà cả hai bên đều hiểu. Theo cách đó, ngay cả khi người gửi và người nhận giải thích những điều khác nhau, nhưng vì họ đồng ý về định dạng được mã hóa, dữ liệu sẽ không bị hiểu sai.

Từ ví dụ Mark Byers

Nếu tôi muốn gửi

Hello
world!

Một cách là gửi nó trong ASCII như

72 101 108 108 111 10 119 111 114 108 100 33

Nhưng byte 10 có thể không được hiểu chính xác là một dòng mới ở đầu kia. Vì vậy, chúng tôi sử dụng một tập hợp con của ASCII để mã hóa nó như thế này

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

với chi phí truyền dữ liệu nhiều hơn cho cùng một lượng thông tin đảm bảo rằng người nhận có thể giải mã dữ liệu theo cách dự định, ngay cả khi người nhận tình cờ có các cách hiểu khác nhau cho phần còn lại của bộ ký tự.

Sai lầm đầu tiên của bạn là nghĩ rằng mã hóa ASCII và mã hóa Base64 có thể hoán đổi cho nhau. Họ không phải. Chúng được sử dụng cho các mục đích khác nhau.

• Khi bạn mã hóa văn bản trong ASCII, bạn bắt đầu bằng một chuỗi văn bản và chuyển đổi nó thành một chuỗi byte.
• Khi bạn mã hóa dữ liệu trong Base64, bạn bắt đầu với một chuỗi byte và chuyển đổi nó thành một chuỗi văn bản.

Để hiểu tại sao Base64 là cần thiết ở nơi đầu tiên chúng ta cần một chút lịch sử của máy tính.

Máy tính giao tiếp dưới dạng nhị phân - 0 và 1 - nhưng mọi người thường muốn giao tiếp với dữ liệu biểu mẫu phong phú hơn như văn bản hoặc hình ảnh. Để truyền dữ liệu này giữa các máy tính, trước tiên, nó phải được mã hóa thành 0 và 1, sau đó được giải mã lại. Để lấy văn bản làm ví dụ - có nhiều cách khác nhau để thực hiện mã hóa này. Sẽ đơn giản hơn nhiều nếu tất cả chúng ta có thể đồng ý về một mã hóa duy nhất, nhưng thật đáng buồn, đây không phải là trường hợp.

Ban đầu, rất nhiều mã hóa khác nhau đã được tạo ra (ví dụ mã Baudot ) sử dụng số bit khác nhau cho mỗi ký tự cho đến khi cuối cùng ASCII trở thành tiêu chuẩn với 7 bit cho mỗi ký tự. Tuy nhiên, hầu hết các máy tính lưu trữ dữ liệu nhị phân theo byte bao gồm 8 bit mỗi bit ASCII không phù hợp để chuyển loại dữ liệu này. Một số hệ thống thậm chí sẽ xóa sạch bit đáng kể nhất. Hơn nữa, sự khác biệt trong mã hóa kết thúc dòng trên các hệ thống có nghĩa là ký tự ASCII 10 và 13 đôi khi cũng được sửa đổi.

Để giải quyết những vấn đề này Base64 hóa đã được giới thiệu. Điều này cho phép bạn mã hóa các byte thông thường thành các byte được biết là an toàn để gửi mà không bị hỏng (các ký tự chữ và số ASCII và một vài ký hiệu). Nhược điểm là mã hóa tin nhắn bằng Base64 làm tăng độ dài của nó - cứ 3 byte dữ liệu được mã hóa thành 4 ký tự ASCII.

Để gửi văn bản một cách đáng tin cậy, trước tiên bạn có thể mã hóa thành byte bằng cách sử dụng mã hóa văn bản mà bạn chọn (ví dụ UTF-8) và sau đó Base64 mã hóa dữ liệu nhị phân kết quả thành một chuỗi văn bản an toàn để gửi được mã hóa dưới dạng ASCII. Người nhận sẽ phải đảo ngược quá trình này để khôi phục thông điệp ban đầu. Điều này tất nhiên đòi hỏi người nhận phải biết mã hóa nào đã được sử dụng và thông tin này thường cần phải được gửi riêng.

Trong lịch sử, nó đã được sử dụng để mã hóa dữ liệu nhị phân trong các email mà máy chủ email có thể sửa đổi các kết thúc dòng. Một ví dụ hiện đại hơn là việc sử dụng mã hóa Base64 để nhúng dữ liệu hình ảnh trực tiếp vào mã nguồn HTML . Ở đây cần phải mã hóa dữ liệu để tránh các ký tự như '<' và '>' bị hiểu là thẻ.

Dưới đây là một ví dụ hoạt động:

Tôi muốn gửi một tin nhắn văn bản với hai dòng:

xin chào
thế giới!

Nếu tôi gửi nó dưới dạng ASCII (hoặc UTF-8), nó sẽ trông như thế này:

72 101 108 108 111 10 119 111 114 108 100 33

Byte 10 bị hỏng trong một số hệ thống, vì vậy chúng ta có thể cơ sở 64 mã hóa các byte này dưới dạng chuỗi Base64:

SGVsbG8sCndvcmxkIQ ==

Mà khi được mã hóa bằng ASCII trông như thế này:

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

Tất cả các byte ở đây đều được biết là byte an toàn, do đó, rất ít khả năng bất kỳ hệ thống nào sẽ làm hỏng thông báo này. Tôi có thể gửi tin nhắn này thay vì tin nhắn ban đầu của mình và để người nhận đảo ngược quá trình để khôi phục tin nhắn ban đầu.

Mã hóa dữ liệu nhị phân trong XML

Giả sử bạn muốn nhúng một vài hình ảnh trong tài liệu XML. Các hình ảnh là dữ liệu nhị phân, trong khi tài liệu XML là văn bản. Nhưng XML không thể xử lý dữ liệu nhị phân nhúng. vậy bạn sẽ làm sao?

Một tùy chọn là mã hóa hình ảnh trong base64, biến dữ liệu nhị phân thành văn bản mà XML có thể xử lý.

Thay vì:

<images>
  <image name="Sally">{binary gibberish that breaks XML parsers}</image>
  <image name="Bobby">{binary gibberish that breaks XML parsers}</image>
</images>

bạn làm:

<images>
  <image name="Sally" encoding="base64">j23894uaiAJSD3234kljasjkSD...</image>
  <image name="Bobby" encoding="base64">Ja3k23JKasil3452AsdfjlksKsasKD...</image>
</images>

Và trình phân tích cú pháp XML sẽ có thể phân tích chính xác tài liệu XML và trích xuất dữ liệu hình ảnh.

Tại sao không tìm đến RFC hiện đang định nghĩa Base64 ?

Mã hóa dữ liệu cơ sở được sử dụng trong nhiều tình huống để lưu trữ hoặc truyền
dữ liệu trong các môi trường, có lẽ vì lý do cũ, bị hạn chế đối với dữ liệu US-ASCII [1]. Mã hóa cũng có thể được sử dụng trong các ứng dụng mới không bị hạn chế về di sản, đơn giản vì nó cho phép thao tác với các đối tượng bằng trình soạn thảo văn bản.

Trước đây, các ứng dụng khác nhau có các yêu cầu khác nhau và do đó đôi khi thực hiện mã hóa cơ sở theo những cách hơi khác nhau. Ngày nay, các đặc tả giao thức đôi khi sử dụng mã hóa cơ sở nói chung và "base64" nói riêng, không có mô tả hoặc tham chiếu chính xác. Tiện ích mở rộng thư Internet đa năng (MIME) [4] thường được sử dụng làm tài liệu tham khảo cho cơ sở64 mà không xem xét hậu quả đối với các ký tự bao quanh dòng hoặc không có bảng chữ cái. Mục đích của đặc điểm kỹ thuật này là để thiết lập bảng chữ cái và mã hóa thông thường. Điều này hy vọng sẽ làm giảm sự mơ hồ trong các tài liệu khác, dẫn đến khả năng tương tác tốt hơn.

Base64 ban đầu được nghĩ ra như một cách để cho phép dữ liệu nhị phân được gắn vào email như một phần của Tiện ích mở rộng Internet Mail đa năng.

Phương tiện được thiết kế cho dữ liệu văn bản tất nhiên cũng là nhị phân, nhưng phương tiện văn bản thường sử dụng các giá trị nhị phân nhất định cho các ký tự điều khiển. Ngoài ra, phương tiện văn bản có thể từ chối các giá trị nhị phân nhất định là phi văn bản.

Mã hóa Base64 mã hóa dữ liệu nhị phân thành các giá trị chỉ có thể được hiểu là văn bản trong phương tiện văn bản và không có bất kỳ ký tự đặc biệt và / hoặc ký tự điều khiển nào, do đó dữ liệu cũng sẽ được lưu giữ trên phương tiện văn bản.

Thêm nữa là phương tiện xác nhận mã hóa chuỗi, vì vậy chúng tôi muốn đảm bảo rằng dữ liệu được chấp nhận bởi một ứng dụng xử lý (và không chứa chuỗi nhị phân đại diện cho EOL chẳng hạn)

Hãy tưởng tượng bạn muốn gửi dữ liệu nhị phân trong email có mã hóa UTF-8 - Email có thể không hiển thị chính xác nếu luồng dữ liệu và số không tạo ra một chuỗi không hợp lệ Unicode trong mã hóa UTF-8.

Loại điều tương tự xảy ra trong URL khi chúng tôi muốn mã hóa các ký tự không hợp lệ cho một URL trong chính URL:

http://www.foo.com/hello bạn của tôi -> http://www.foo.com/hello%20my%20friend

Điều này là do chúng tôi muốn gửi một không gian qua một hệ thống sẽ nghĩ rằng không gian đó có mùi.

Tất cả những gì chúng tôi đang làm là đảm bảo có ánh xạ 1 đến 1 giữa một chuỗi bit tốt, có thể chấp nhận và không gây bất lợi cho chuỗi bit khác theo nghĩa đen và ứng dụng xử lý không phân biệt mã hóa.

Trong ví dụ của bạn, mancó thể là ASCII hợp lệ ở dạng đầu tiên; nhưng thường bạn có thể muốn truyền các giá trị nhị phân ngẫu nhiên (nghĩa là gửi một hình ảnh trong email):

MIME-Phiên bản: 1.0
Nội dung-Mô tả: "Mã hóa Base64 của a.gif"
Loại nội dung: image / gif; name = "a.gif"
Mã hóa chuyển
nội dung : Base64 Bố trí nội dung: tệp đính kèm; tên tệp = "a.gif"

Ở đây chúng ta thấy rằng một hình ảnh GIF được mã hóa trong base64 dưới dạng một đoạn email. Ứng dụng email đọc các tiêu đề và giải mã nó. Do mã hóa, chúng tôi có thể chắc chắn rằng GIF không chứa bất kỳ thứ gì có thể được hiểu là giao thức và chúng tôi tránh chèn dữ liệu mà SMTP hoặc POP có thể thấy đáng kể.

Base64 thay vì thoát các ký tự đặc biệt

Tôi sẽ cung cấp cho bạn một ví dụ rất khác nhưng thực tế: Tôi viết mã javascript để được chạy trong trình duyệt. Thẻ HTML có giá trị ID, nhưng có các ràng buộc về ký tự nào hợp lệ trong ID.

Nhưng tôi muốn ID của mình không tham khảo các tệp trong hệ thống tệp của mình. Các tập tin trong thực tế có thể có tất cả các loại ký tự kỳ lạ và tuyệt vời trong đó từ dấu chấm than, ký tự có dấu, dấu ngã, thậm chí là biểu tượng cảm xúc! Tôi không thể làm việc này:

<div id="/path/to/my_strangely_named_file!@().jpg">
    <img src="http://myserver.com/path/to/my_strangely_named_file!@().jpg">
    Here's a pic I took in Moscow.
</div>

Giả sử tôi muốn chạy một số mã như thế này:

# ERROR
document.getElementById("/path/to/my_strangely_named_file!@().jpg");

Tôi nghĩ rằng mã này sẽ thất bại khi thực thi.

Với Base64 tôi có thể đề cập đến một cái gì đó phức tạp mà không cần lo lắng về ngôn ngữ nào cho phép các ký tự đặc biệt và những gì cần thoát:

document.getElementById("18GerPD8fY4iTbNpC9hHNXNHyrDMampPLA");

Không giống như sử dụng MD5 hoặc một số chức năng băm khác, bạn có thể đảo ngược mã hóa để tìm ra chính xác dữ liệu thực sự hữu ích.

Tôi ước tôi biết về Base64 năm trước. Tôi sẽ tránh xé tóc bằng ' encodeURIComponent' vàstr.replace(‘\n’,’\\n’)

Chuyển văn bản SSH:

Nếu bạn đang cố gắng truyền dữ liệu phức tạp qua ssh (ví dụ: dotfile để bạn có thể cá nhân hóa trình bao của mình), thì may mắn làm điều đó mà không cần Base 64. Đây là cách bạn sẽ làm với cơ sở 64 (Tôi biết bạn có thể sử dụng SCP, nhưng điều đó sẽ mất nhiều lệnh - làm phức tạp các ràng buộc chính cho sshing vào máy chủ):

• https://superuser.com/a/1376076/114723

Một ví dụ khi tôi thấy thuận tiện là khi cố gắng nhúng dữ liệu nhị phân vào XML . Một số dữ liệu nhị phân đã bị trình phân tích SAX giải thích sai bởi vì dữ liệu đó có thể là bất cứ thứ gì theo nghĩa đen, bao gồm các ký tự đặc biệt XML. Base64 mã hóa dữ liệu ở đầu truyền và giải mã nó ở đầu nhận đã khắc phục vấn đề đó.

Hầu hết các máy tính lưu trữ dữ liệu ở định dạng nhị phân 8 bit, nhưng đây không phải là một yêu cầu. Một số máy và phương tiện truyền dẫn chỉ có thể xử lý 7 bit (hoặc thậm chí ít hơn) tại một thời điểm. Phương tiện như vậy sẽ diễn giải luồng theo bội số 7 bit, vì vậy nếu bạn gửi dữ liệu 8 bit, bạn sẽ không nhận được những gì bạn mong đợi ở phía bên kia. Base-64 chỉ là một cách để giải quyết vấn đề này: bạn mã hóa đầu vào thành định dạng 6 bit, gửi nó qua phương tiện của bạn và giải mã nó trở lại định dạng 8 bit ở đầu nhận.

Ngoài các câu trả lời khác (hơi dài dòng): thậm chí bỏ qua các hệ thống cũ chỉ hỗ trợ ASCII 7 bit, các vấn đề cơ bản với việc cung cấp dữ liệu nhị phân ở chế độ văn bản là:

• Dòng mới thường được chuyển đổi trong chế độ văn bản.
• Người ta phải cẩn thận không coi byte NUL là phần cuối của chuỗi văn bản, điều này quá dễ thực hiện trong bất kỳ chương trình nào có dòng C.

"Phương tiện được thiết kế để xử lý dữ liệu văn bản" nghĩa là gì?

Các giao thức đó được thiết kế để xử lý văn bản (thường là văn bản tiếng Anh ) thay vì dữ liệu nhị phân (như hình ảnh .png và .jpg).

Họ có thể đối phó với nhị phân => họ có thể đối phó với bất cứ điều gì.

Nhưng điều ngược lại là không đúng sự thật. Một giao thức được thiết kế để thể hiện văn bản có thể xử lý không đúng dữ liệu nhị phân có chứa:

• Các byte 0x0A và 0x0D, được sử dụng cho các kết thúc dòng, khác nhau theo nền tảng.
• Các ký tự điều khiển khác như 0x00 (bộ kết thúc chuỗi NULL = C), 0x03 (END OF TEXT), 0x04 (END OF TRANSMISSION) hoặc 0x1A (tệp kết thúc DOS) có thể báo hiệu sớm kết thúc dữ liệu.
• Byte trên 0x7F (nếu giao thức được thiết kế cho ASCII).
• Trình tự byte không hợp lệ UTF-8.

Vì vậy, bạn không thể chỉ gửi dữ liệu nhị phân qua giao thức dựa trên văn bản. Bạn bị giới hạn ở các byte đại diện cho các ký tự ASCII không kiểm soát không gian, trong đó có 94. Lý do Base 64 được chọn là vì nó hoạt động nhanh hơn với sức mạnh của hai và 64 là ký tự lớn nhất hoạt động .

Một câu hỏi mặc dù. Làm thế nào mà các hệ thống vẫn không đồng ý về một kỹ thuật mã hóa phổ biến như UTF-8 phổ biến như vậy?

Trên trang web, ít nhất, họ chủ yếu có. Phần lớn các trang web sử dụng UTF-8 .

Vấn đề ở phương Tây là có rất nhiều phần mềm cũ hỗ trợ 1 byte = 1 ký tự và không thể hoạt động với UTF-8.

Vấn đề ở phương Đông là sự gắn bó của họ với các bảng mã như GB2312 và Shift_JIS.

Và thực tế là Microsoft dường như vẫn chưa nhận được việc chọn mã hóa UTF sai. Nếu bạn muốn sử dụng API Windows hoặc thư viện thời gian chạy Microsoft C, bạn bị giới hạn ở UTF-16 hoặc mã hóa "ANSI" của miền địa phương. Điều này gây khó khăn khi sử dụng UTF-8 vì bạn phải chuyển đổi mọi lúc.

Tại sao / Làm thế nào để chúng tôi sử dụng mã hóa Base64?

Base64 là một trong những lược đồ mã hóa nhị phân thành văn bản có hiệu suất 75%. Nó được sử dụng để dữ liệu nhị phân điển hình (như hình ảnh) có thể được gửi an toàn qua các kênh "không phải là 8 bit" cũ. Trong các mạng email trước đó (cho đến đầu những năm 1990), hầu hết các email đều là văn bản thuần túy trong bộ ký tự US-ASCII 7 bit. Vì vậy, nhiều chuẩn giao thức comm sớm được thiết kế để hoạt động trên các liên kết comm "7 bit" "không sạch 8 bit". Hiệu suất của sơ đồ là tỷ lệ giữa số bit trong đầu vào và số bit trong đầu ra được mã hóa. Hệ thập lục phân (Base16) cũng là một trong các sơ đồ mã hóa nhị phân thành văn bản với hiệu suất 50%.

Các bước mã hóa Base64 (Đơn giản hóa):

1. Dữ liệu nhị phân được sắp xếp theo từng khối 24 bit (3 byte) liên tục.
2. Mỗi đoạn 24 bit được nhóm thành bốn phần 6 bit mỗi phần.
3. Mỗi nhóm 6 bit được chuyển đổi thành các giá trị ký tự Base64 tương ứng, tức là mã hóa Base64 chuyển đổi ba octet thành bốn ký tự được mã hóa. Tỷ lệ byte đầu ra so với byte đầu vào là 4: 3 (33% phí).
4. Điều thú vị là, các ký tự giống nhau sẽ được mã hóa khác nhau tùy thuộc vào vị trí của chúng trong nhóm ba octet được mã hóa để tạo ra bốn ký tự.
5. Người nhận sẽ phải đảo ngược quá trình này để khôi phục thông điệp ban đầu.

"Phương tiện được thiết kế để xử lý dữ liệu văn bản" nghĩa là gì?

Ngày trước khi ASCII thống trị thế giới đối phó với các giá trị không phải ASCII là một vấn đề đau đầu. Mọi người nhảy qua tất cả các loại vòng để chuyển chúng qua dây mà không mất thông tin.