爲什麼人們不使用base128？

爲什麼大家都用base 64在網上傳輸二進制數據？我問，因爲ASCII字符集有128個字符，理論上可以代表基數128 ...爲什麼人們不使用base128？

來源

2011-05-15 gilmad

+49

甚至爲什麼不基於256？ – Gumbo 2011-05-15 11:20:36

+19

我認爲重點是*打印*字符（雖然也有超過64 ...） – 2011-05-15 11:20:59

+26

我認爲基地128屬於我們前一陣子。被分配到後衛基地64的隊伍仍然在外。 – 2011-05-15 11:23:09

問題是，至少有32個字符的ASCII字符集是'控制字符'，可以由接收終端解釋。例如，有BEL（鈴）字符使接收終端響鈴。有SOT（傳輸開始）和EOT（傳輸結束）字符，它們完全符合他們的名字暗示。並且不要忘記字符CR和LF，其中可能在數據結構如何串行化/拼合成流方面具有特殊含義。

Adobe創建了the Base85 encoding以在ASCII字符集中使用更多字符，但AFAIK受專利保護。

來源

2011-05-15 13:43:39 pepoluan

Base91似乎是一個很好的開源選項：http://base91.sourceforge.net/ – 2013-10-09 12:06:11

它是值得考慮的是2的冪更容易適合字節數據，並且編碼更簡單。然後是可移植性;每種語言都有base64編碼和/或base64解碼。 – Lodewijk 2014-07-28 12:15:47

Re * Base85和Adobe *：如果引用了專利號和授予的年份，答案可能會更有用。如果專利是一個問題，那麼始於1990年的['btoa']（https://en.wikipedia.org/wiki/Ascii85#btoa_version）不受專利權限制，並且無論如何都肯定會過期。 – agc 2017-03-08 14:22:28

不確定，但我認爲較低的值（代表控制代碼或其他）不能可靠地傳輸爲文本/字符HTTP請求/響應，而127以上的值可能是locale/codepage/whatever-specific，所以沒有128個不同的字符可以在所有瀏覽器/平臺上工作。

來源

2011-05-15 11:22:53 esaj

因爲這128個字符中的一些字符是不可打印的（主要是那些低於碼點0x20的字符）。因此，它們不能可靠地作爲電線上的線傳輸。而且，如果你高於codepoint 128，那麼由於跨系統使用不同的編碼，你可能會遇到編碼問題。

來源

2011-05-15 11:23:23 driis

Base94在github中存在，它使用所有94個可打印的ASCII字符：https：//gist.github.com/iso2022jp/4054241 – 2015-07-05 11:07:00

esaji是對的。 Base64用於編碼二進制數據以便使用僅需要文本的協議進行傳輸。這是正確的在Wiki條目。

來源

2011-05-15 11:24:51

正如其他答案中所述，關鍵是要將字符集減少到可打印的。更高效的編碼方案是basE91，因爲它使用較大的字符集，並且仍然避免在低ASCII範圍內的控制/空白字符。該網頁包含了一個很好的比較二進制與base64與basE91編碼效率。

我曾經清理過Java的實現。如果人們有興趣，我可以把它推到GitHub上。

更新：現在是on GitHub。

來源

2011-05-15 14:59:01

我會對java版本感興趣 – 2011-11-09 10:26:50

推送到：https：//github.com/bwaldvogel/base91 – 2011-11-10 21:09:04

太棒了。我只是做了一個端口到紅寶石，我將不得不比較它們 – 2011-11-11 02:40:37

簽出base128 PHP級。使用ISO 8859-1字符集進行編碼和解碼。

GoogleCode PHP-Class Base128

來源

2012-05-05 11:57:52 seizu

我希望它使用utf-8代替... – 2012-09-20 13:12:50

基本編碼與底層數據無關。您可以使用任何您希望編碼文本/數據的文本編碼。他的意思是Base ##索引表使用ISO 8859-1 ASCII字符集作爲轉換。 – Chad 2014-05-21 05:55:13

只要您嘗試在文本中嵌入基本編碼的二進制數據，它的確與底層數據有關。如果該文本以另一種編碼進行編碼，則會出現問題。 – 2017-01-04 01:45:19

這前32個字符是控制字符已經完全沒有任何意義，因爲你不必使用它們來獲得128個字符。我們有256個字符可供選擇，只有前32個是控制字符。這留下192個字符，因此128完全可能不使用控制字符。

這是原因：它必須是一樣的東西，無論在哪裏，都可以複製和粘貼。因此，它必須是在任何論壇，聊天，電子郵件等上顯示相同的字符。這意味着我們不能使用字符，即論壇/聊天/電子郵件客戶端可能通常用於格式化或忽略。不管字體，語言和區域設置如何，它也必須是相同的字符。

這就是原因！

來源

2013-12-19 13:07:50 user3119289

控制字符是相關的，因爲幾乎每個人都已經假設你的觀點是它應該儘可能地作爲代碼頁/編碼中立。這必然會限制您僅使用（7位）ASCII，這是大多數相關編碼的子集。也不是所有的互聯網都是8位的，而且大部分都是事實上的ASCII。你的觀點值得一提。 – 2014-11-09 13:04:31

只需添加：ASCII僅定義128個字符。字符＃128到＃255在ASCII中沒有定義。由於該問題明確引用了ASCII而不是「任何8位編碼」，所有答案都將其自身限制爲ASCII集的128個字符。 – pepoluan 2016-05-12 05:50:29

Base64是常見的，因爲它解決各種各樣的問題（作品幾乎無處不在，你能想到的）

您不必擔心交通是否8-bit clean與否。
編碼中的所有字符都是可打印的。你可以看到他們。你可以複製並粘貼他們。您可以在URL中使用它們（特定變體）。等等。
固定的編碼大小。你知道m字節總是可以編碼爲n字節。
大家都聽說過它 - 它得到了廣泛的支持，很多庫，很容易互操作。

Base128並不具備所有這些優點。

它看起來像8位清潔 - 但回想一下base64使用65個符號。如果沒有帶外字符，則無法獲得固定編碼大小的好處。如果您使用帶外字符，則不能再進行8位清理。

雖然這並非全是消極的。

base128比base64更容易編碼/解碼 - 您只需使用班次和掩碼。對於嵌入式實現可能很重要
base128通過使用更多的可用位，使傳輸的使用效率比base64略高一些。

人做使用base128 - 我用它的東西了。這只是不常見。

來源

2014-10-13 03:45:47

另外請記住，郵件/新聞系統及其同類（以及XML）對於前32個碼點並不總是友善的（例如，考慮CR LF vs LF），但是否則您的答案看起來非常好。 – SamB 2015-01-25 01:21:40

「base64使用65個符號。」 =>錯字還是我錯過了什麼？ – Kikiwa 2016-11-22 13:39:17

@Kikiwa，看看這個[在維基百科的java樣本]（https://en.wikipedia.org/wiki/Base64#Sample_Implementation_in_Java）。檢查'CODES'變量的長度。 – 2016-11-22 21:50:24

爲什麼人們不使用base128？

回答

相關問題