UTF-8的問題在于它不是最節(jié)省空間的編碼 . 此外，一些隨機(jī)二進(jìn)制字節(jié)序列是無效的UTF-8編碼 . 因此，您不能將隨機(jī)二進(jìn)制字節(jié)序列解釋為某些UTF-8數(shù)據(jù)，因?yàn)樗鼘⑹菬o效的UTF-8編碼 . 這種對(duì)UTF-8編碼的約束的好處在于它使得它很可靠并且可以定位多字節(jié)字符開始和結(jié)束我們開始查看的任何字節(jié) .

因此，如果在[0..127]范圍內(nèi)編碼字節(jié)值只需要UTF-8編碼中的一個(gè)字節(jié)，則編碼[128..255]范圍內(nèi)的字節(jié)值將需要2個(gè)字節(jié)！比那更糟糕 . 在JSON中，控制字符“和\”不允許出現(xiàn)在字符串中 . 因此二進(jìn)制數(shù)據(jù)需要進(jìn)行一些轉(zhuǎn)換才能正確編碼 .

讓我們看看 . 如果我們?cè)诙M(jìn)制數(shù)據(jù)中假設(shè)均勻分布的隨機(jī)字節(jié)值，那么平均來說，一半字節(jié)將在一個(gè)字節(jié)中編碼，另一半在兩個(gè)字節(jié)中編碼 . UTF-8編碼的二進(jìn)制數(shù)據(jù)將具有初始大小的150％ .

Base64編碼僅增長(zhǎng)到初始大小的133％ . 所以Base64編碼效率更高 .

那么使用其他Base編碼呢？在UTF-8中，對(duì)128個(gè)ASCII值進(jìn)行編碼是最節(jié)省空間的 . 在8位中，您可以存儲(chǔ)7位 . 因此，如果我們以7位塊的形式剪切二進(jìn)制數(shù)據(jù)以將它們存儲(chǔ)在UTF-8編碼字符串的每個(gè)字節(jié)中，則編碼數(shù)據(jù)將僅增長(zhǎng)到初始大小的114％ . 比Base64好 . 不幸的是，我們不能使用這個(gè)簡(jiǎn)單的技巧，因?yàn)镴SON不允許一些ASCII字符 . ASCII([0..31]和127)的33個(gè)控制字符和“和\”必須被排除 . 這使得我們只有128-35 = 93個(gè)字符 .

因此理論上我們可以定義一個(gè)Base93編碼，它將編碼大小增加到8 / log2(93)= 8 * log10(2)/ log10(93)= 122％ . 但Base93編碼不如Base64編碼方便 . Base64需要以6位塊的形式剪切輸入字節(jié)序列，以便簡(jiǎn)單的按位運(yùn)算 . 除133％外，不超過122％ .

這就是我獨(dú)立得出的結(jié)論，即Base64確實(shí)是用JSON編碼二進(jìn)制數(shù)據(jù)的最佳選擇 . 我的回答是一個(gè)為它辯護(hù) . 我同意從性能的角度來看它并不是很有吸引力，但也要考慮使用JSON的好處，它的人類可讀字符串表示易于在所有編程語言中操作 .

如果性能至關(guān)重要，則應(yīng)將純二進(jìn)制編碼視為JSON的替代 . 但是對(duì)于JSON，我的結(jié)論是Base64是最好的 .

總結(jié)

以上是生活随笔為你收集整理的java json转二进制数据_JSON字符串中的二进制数据 . 比Base64更好的东西的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。