當(dāng)需要對(duì)二進(jìn)制數(shù)據(jù)進(jìn)行編碼時(shí)，通常需要使用Base64編碼方案，該二進(jìn)制數(shù)據(jù)需要在旨在處理文本數(shù)據(jù)的媒體上存儲(chǔ)和傳輸。這是為了確保數(shù)據(jù)在傳輸過(guò)程中保持完整而無(wú)需修改。但是，不是因?yàn)槲覀兊臋C(jī)器存儲(chǔ)的內(nèi)存始終以二進(jìn)制形式存儲(chǔ)/傳輸數(shù)據(jù)，而是僅以二進(jìn)制形式存儲(chǔ)/傳輸數(shù)據(jù)嗎？因此，無(wú)論您編碼位模式010011010110000101101110為ManASCII或如TWFu為Base64，你最終將存儲(chǔ)相同的位模式。如果最終編碼是用零和一表示的，并且每臺(tái)機(jī)器和媒體都可以處理它們，那么將數(shù)據(jù)表示為ASCII還是Base64有什么關(guān)系呢？“旨在處理文本數(shù)據(jù)的媒體”是什么意思？他們可以處理二進(jìn)制=>他們可以處理任何東西。謝謝大家，我想我現(xiàn)在明白了。當(dāng)我們發(fā)送數(shù)據(jù)時(shí)，我們不能確定數(shù)據(jù)將以我們期望的格式解釋。因此，我們發(fā)送雙方都可以理解的以某種格式（例如Base64）編碼的數(shù)據(jù)。這樣，即使發(fā)送方和接收方對(duì)相同內(nèi)容的解釋不同，但由于它們?cè)诰幋a格式上達(dá)成共識(shí)，因此不會(huì)錯(cuò)誤地解釋數(shù)據(jù)。以Mark Byers為例如果我要發(fā)送Helloworld!一種方法是像ASCII一樣發(fā)送72 101 108 108 111 10 119 111 114 108 100 33但是字節(jié)10可能無(wú)法在另一端正確解釋為換行符。因此，我們使用ASCII的子集對(duì)其進(jìn)行編碼，如下所示83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61即使接收器碰巧對(duì)其余字符集有不同的解釋，這也會(huì)以相同信息量傳輸更多數(shù)據(jù)為代價(jià)，從而確保接收器可以按預(yù)期方式解碼數(shù)據(jù)。
3 回答
慕村9548890
TA貢獻(xiàn)1884條經(jīng)驗(yàn) 獲得超4個(gè)贊
您的第一個(gè)錯(cuò)誤是認(rèn)為ASCII編碼和Base64編碼可以互換。他們不是。它們用于不同的目的。
使用ASCII編碼文本時(shí)，您將從文本字符串開(kāi)始并將其轉(zhuǎn)換為字節(jié)序列。
在Base64中對(duì)數(shù)據(jù)進(jìn)行編碼時(shí)，您將從字節(jié)序列開(kāi)始并將其轉(zhuǎn)換為文本字符串。
要了解為什么首先需要Base64，我們需要一些計(jì)算歷史。
計(jì)算機(jī)以二進(jìn)制形式（0和1）進(jìn)行通信，但是人們通常希望與更豐富的表單數(shù)據(jù)（例如文本或圖像）進(jìn)行通信。為了在計(jì)算機(jī)之間傳輸此數(shù)據(jù)，首先必須將其編碼為0和1，然后發(fā)送，然后再次解碼。以文本為例-有許多不同的方法可以執(zhí)行此編碼。如果我們都可以同意一個(gè)編碼，這會(huì)簡(jiǎn)單得多，但不幸的是事實(shí)并非如此。
最初，創(chuàng)建了許多不同的編碼（例如Baudot碼），每個(gè)字符使用不同的位數(shù)，直到最終ASCII成為每個(gè)字符7位的標(biāo)準(zhǔn)。但是，大多數(shù)計(jì)算機(jī)將二進(jìn)制數(shù)據(jù)存儲(chǔ)在每個(gè)字節(jié)由8位組成的字節(jié)中，因此ASCII不適合傳輸此類數(shù)據(jù)。有些系統(tǒng)甚至?xí)脸罡呶弧４送?，跨系統(tǒng)的行尾編碼的差異意味著有時(shí)還會(huì)修改ASCII字符10和13。
為了解決這些問(wèn)題，引入了Base64編碼。這樣，您就可以將ribribry字節(jié)編碼為已知可以安全發(fā)送而不損壞的字節(jié)（ASCII字母數(shù)字字符和幾個(gè)符號(hào)）。缺點(diǎn)是使用Base64編碼消息會(huì)增加其長(zhǎng)度-每3個(gè)字節(jié)的數(shù)據(jù)就會(huì)編碼為4個(gè)ASCII字符。
發(fā)送文本可靠，你可以先編碼，使用您的選擇（例如UTF-8），然后的文本編碼字節(jié)后的Base64編碼生成的二進(jìn)制數(shù)據(jù)轉(zhuǎn)換為文本字符串，它是安全發(fā)送編碼為ASCII。接收者將不得不逆轉(zhuǎn)此過(guò)程以恢復(fù)原始消息。當(dāng)然，這要求接收者知道使用了哪種編碼，并且該信息通常需要單獨(dú)發(fā)送。
從歷史上看，它已用于對(duì)電子郵件中的二進(jìn)制數(shù)據(jù)進(jìn)行編碼，其中電子郵件服務(wù)器可能會(huì)修改行尾。一個(gè)更現(xiàn)代的示例是使用Base64編碼將圖像數(shù)據(jù)直接嵌入HTML源代碼中。在這里，有必要對(duì)數(shù)據(jù)進(jìn)行編碼，以避免像“ <”和“>”這樣的字符被解釋為標(biāo)簽。
這是一個(gè)工作示例：
我希望發(fā)送兩行短信
你好
世界！
如果以ASCII（或UTF-8）格式發(fā)送，則如下所示：
72 101 108 108 111 10 119 111 114 108 100 33
字節(jié)10在某些系統(tǒng)中已損壞，因此我們可以將這些字節(jié)以64為基數(shù)編碼為Base64字符串：
SGVsbG8sCndvcmxkIQ ==
使用ASCII編碼時(shí)，如下所示：
83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61
這里的所有字節(jié)都是已知的安全字節(jié)，因此，幾乎沒(méi)有任何系統(tǒng)會(huì)破壞此消息的機(jī)會(huì)。我可以發(fā)送此消息而不是原始消息，然后讓接收者撤消該過(guò)程以恢復(fù)原始消息。
長(zhǎng)風(fēng)秋雁
TA貢獻(xiàn)1757條經(jīng)驗(yàn) 獲得超7個(gè)贊
用XML編碼二進(jìn)制數(shù)據(jù)
假設(shè)您要在XML文檔中嵌入幾個(gè)圖像。圖像是二進(jìn)制數(shù)據(jù)，而XML文檔是文本。但是XML無(wú)法處理嵌入式二進(jìn)制數(shù)據(jù)。你是怎么做到的？
一種選擇是將圖像編碼為base64，將二進(jìn)制數(shù)據(jù)轉(zhuǎn)換為XML可以處理的文本。
代替：
<images>
<image name="Sally">{binary gibberish that breaks XML parsers}</image>
<image name="Bobby">{binary gibberish that breaks XML parsers}</image>
</images>
你做：
<images>
<image name="Sally" encoding="base64">j23894uaiAJSD3234kljasjkSD...</image>
<image name="Bobby" encoding="base64">Ja3k23JKasil3452AsdfjlksKsasKD...</image>
</images>
XML解析器將能夠正確解析XML文檔并提取圖像數(shù)據(jù)。
添加回答
舉報(bào)
0/150
提交
取消