JSON Dizesinde İkili Veri. Base64'ten daha iyi bir şey

JSON biçimi doğal olarak ikili veri desteklemez. İkili veriler, JSON'da bir dize öğesine (çift eğik çizgiler kullanarak sıfır veya daha fazla Unicode karakter) yerleştirilebilecek şekilde kaçmalıdır.

İkili verilerden kaçmanın bariz bir yöntemi Base64 kullanmaktır. Ancak, Base64 yüksek bir işleme yüküne sahiptir. Ayrıca 3 baytı 4 karaktere genişletir ve bu da veri boyutunu yaklaşık% 33 oranında arttırır.

Bunun bir kullanım örneği, CDMI bulut depolama API'sı belirtiminin v0.8 taslağıdır . Veri nesnelerini JSON kullanarak bir REST-Webservice aracılığıyla oluşturursunuz;

PUT /MyContainer/BinaryObject HTTP/1.1
Host: cloud.example.com
Accept: application/vnd.org.snia.cdmi.dataobject+json
Content-Type: application/vnd.org.snia.cdmi.dataobject+json
X-CDMI-Specification-Version: 1.0
{
    "mimetype" : "application/octet-stream",
    "metadata" : [ ],
    "value" :   "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
    IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
    dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
    dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
    ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=",
}

İkili verileri JSON dizelerine kodlamak için daha iyi yollar ve standart yöntemler var mı?

JSON özelliğine göre bir bayt olarak temsil edilebilecek 94 Unicode karakter vardır (JSON'unuz UTF-8 olarak iletilirse). Bunu akılda tutarak, uzay-bilge yapabileceğiniz en iyi şey, dört baytı beş karakter olarak temsil eden base85 olduğunu düşünüyorum . Bununla birlikte, bu base64'e göre sadece% 7'lik bir iyileşme, hesaplanması daha pahalı ve uygulamalar base64'e göre daha az yaygındır, bu yüzden muhtemelen bir kazanç değildir.

Ayrıca her giriş baytını U + 0000-U + 00FF içindeki karşılık gelen karakterle eşleştirebilir, ardından bu karakterleri geçirmek için JSON standardının gerektirdiği minimum kodlamayı yapabilirsiniz; buradaki avantaj, gerekli kod çözmenin yerleşik işlevlerin ötesinde sıfır olmasıdır, ancak alan verimliliği kötüdür - base85 için% 25 veya base64 için% 33'e karşılık% 105'lik bir genişleme (tüm giriş baytları eşit derecede olasıysa).

Son karar: base64, bence, yaygın, kolay ve değiştirmeyi garanti edecek kadar kötü olmadığı gerekçesiyle kazanıyor .

Ayrıca bakınız: Base91 ve Base122

Aynı problemle karşılaştım ve bir çözümü paylaşacağımı düşündüm: çoklu bölüm / form verileri

Çok parçalı bir form göndererek önce JSON meta verilerinizi dize olarak gönderir ve ardından İçerik-İmha adıyla dizine ek olarak ham ikili (resim (ler), wavs, vb.) Olarak gönderirsiniz .

İşte obj-c'de bunun nasıl yapılacağı hakkında güzel bir öğretici ve burada dize verilerinin form sınırıyla nasıl bölümleneceğini ve ikili verilerden nasıl ayrılacağını açıklayan bir blog makalesi .

Gerçekten yapmanız gereken tek şey sunucu tarafında; POST'lu ikili verilere (İçerik-Eğim sınırını kullanarak) uygun şekilde referans vermesi gereken meta verilerinizi yakalamanız gerekir.

Verilen sunucu tarafında ek çalışma gerektirir, ancak çok fazla görüntü veya büyük görüntü gönderiyorsanız, buna değer. İsterseniz bunu gzip sıkıştırmasıyla birleştirin.

Base64 kodlu verileri gönderen IMHO bir saldırıdır; RFC çok parçalı / form verileri şu gibi sorunlar için oluşturulmuştur: metin veya meta verilerle birlikte ikili veri gönderme.

UTF-8 ile ilgili sorun, en fazla yer tasarrufu sağlayan kodlama olmamasıdır. Ayrıca, bazı rastgele ikili bayt dizileri geçersiz UTF-8 kodlamasıdır. Bu nedenle, rastgele bir ikili bayt dizisini bazı UTF-8 verileri olarak yorumlayamazsınız, çünkü geçersiz UTF-8 kodlaması olacaktır. UTF-8 kodlamasındaki bu kısıtlamanın yararı, baktığımız her baytın başladığı ve bittiği çok baytlık karakterlerin bulunmasını sağlam ve mümkün kılmasıdır.

Sonuç olarak, [0..127] aralığındaki bir bayt değerini kodlamak UTF-8 kodlamasında yalnızca bir bayta ihtiyaç duyarsa, [128..255] aralığındaki bir bayt değerini kodlamak 2 bayt gerektirir! Bundan daha kötü. JSON'da, denetim karakterlerinin "ve \ bir dizede görünmesine izin verilmez. Bu nedenle, ikili verilerin düzgün bir şekilde kodlanması için bazı dönüşümler gerekir.

Hadi görelim. İkili verilerimizde eşit dağılımlı rasgele bayt değerleri varsayarsak, ortalama olarak baytların yarısı bir baytta, diğer yarısı iki baytta kodlanır. UTF-8 kodlu ikili veriler başlangıç ​​boyutunun% 150'sine sahip olacaktır.

Base64 kodlaması, başlangıç ​​boyutunun yalnızca% 133'üne kadar büyür. Dolayısıyla Base64 kodlaması daha verimlidir.

Başka bir Base kodlaması kullanmaya ne dersiniz? UTF-8'de 128 ASCII değerini kodlamak en fazla yer tasarrufu sağlar. 8 bitte 7 bit saklayabilirsiniz. Bu nedenle, UTF-8 kodlu dizenin her baytında depolamak için ikili verileri 7 bitlik parçalar halinde kesersek, kodlanan veriler başlangıç ​​boyutunun yalnızca% 114'üne kadar büyür. Base64'ten daha iyi. Ne yazık ki bu kolay hileyi kullanamayız çünkü JSON bazı ASCII karakterlerine izin vermez. ASCII'nin 33 kontrol karakteri ([0..31] ve 127) ve "ve \ hariç tutulmalıdır. Bu bize yalnızca 128-35 = 93 karakter bırakmalıdır.

Teoride, kodlanmış boyutu 8 / log2 (93) = 8 * log10 (2) / log10 (93) =% 122 olacak şekilde büyütecek bir Base93 kodlaması tanımlayabiliriz. Ancak bir Base93 kodlaması, Base64 kodlaması kadar uygun olmaz. Base64, basit bitsel işlemin iyi çalıştığı 6 bitlik parçalar halinde giriş bayt dizisini kesmeyi gerektirir. Ayrıca% 133,% 122'den fazla değildir.

Bu yüzden bağımsız olarak Base64'ün JSON'daki ikili verileri kodlamak için en iyi seçim olduğu ortak sonucuna vardım. Cevabım bunun için bir gerekçe sunuyor. Performans açısından çok çekici olmadığını kabul ediyorum, ancak JSON'un tüm programlama dillerinde kullanımı kolay, insan tarafından okunabilir dize temsili ile kullanmanın faydasını da düşünün.

Performans saf bir ikili kodlamadan daha kritikse, JSON'un yerini almalıdır. Ama JSON ile benim sonucum Base64 en iyisidir.

BSON (Binary JSON) sizin için işe yarayabilir. http://en.wikipedia.org/wiki/BSON

Düzenleme: FYI .NET kütüphanesi json.net bazı C # sunucu tarafı aşk arıyorsanız bson okuma ve yazma destekler.

Bant genişliği sorunlarıyla ilgileniyorsanız, önce istemci tarafında verileri sıkıştırmaya çalışın, sonra base64-it.

Böyle bir sihire güzel örnek http://jszip.stuartk.co.uk/ adresinde ve bu konuyla ilgili daha fazla tartışma Gzip'in JavaScript uygulamasında

ync sizin için çalışabilir:

http://en.wikipedia.org/wiki/Yenc

"yEnc, [text] içindeki ikili dosyaları aktarmak için bir ikili-metin kodlama şemasıdır. 8-bit Genişletilmiş ASCII kodlama yöntemini kullanarak önceki US-ASCII tabanlı kodlama yöntemlerine göre ek yükü azaltır. her bayt değeri yaklaşık olarak ortalama olarak aynı frekansta görünür) uuencode ve Base64 gibi 6 bit kodlama yöntemleri için% 33 -% 40 ek yüke kıyasla% 1-2 kadar ... 2010 yılına kadar yEnc fiili standart oldu Usenet ikili dosyaları için kodlama sistemi. "

Bununla birlikte, yEnc 8 bitlik bir kodlamadır, bu yüzden bir JSON dizesinde saklamak orijinal ikili verileri depolamakla aynı sorunlara sahiptir - bunu saf bir şekilde yapmak, base64'den daha kötü olan% 100 genişleme anlamına gelir.

Base64'ün ~% 33 genişleme oranına sahip olduğu doğru olsa da, işlem yükünün bundan çok daha fazla olduğu doğru değildir: gerçekten kullandığınız JSON kütüphanesine / araç setine bağlıdır. Kodlama ve kod çözme basit ve basit işlemlerdir ve hatta wrt karakter kodlaması optimize edilebilir (JSON yalnızca UTF-8/16 / 32'yi desteklediği için) - base64 karakterleri her zaman JSON String girişleri için tek bayttır. Örneğin, Java platformunda işi oldukça verimli bir şekilde yapabilen kütüphaneler vardır, böylece ek yük çoğunlukla genişletilmiş boyuttan kaynaklanır.

Daha önceki iki cevaba katılıyorum:

• base64 basit, yaygın olarak kullanılan standarttır, bu nedenle JSON ile kullanmak için daha iyi bir şey bulmak pek olası değildir (base-85, postscript vb. tarafından kullanılır; ancak bunu düşündüğünüzde faydalar en az marjinaldir)
• kodlamadan önce (ve kod çözmeden sonra) kullandığınız verilere bağlı olarak çok mantıklı olabilir

Gülümseme biçimi

Kodlamak, kod çözmek ve sıkıştırmak çok hızlı

Hız karşılaştırması (java tabanlı ancak yine de anlamlı): https://github.com/eishay/jvm-serializers/wiki/

Ayrıca bayt dizileri için base64 kodlamasını atlamanızı sağlayan bir JSON uzantısıdır.

Gülümseme kodlu dizeler, alan kritik olduğunda sıkıştırılabilir

( 7 yıl sonra düzenleyin : Google Gears gitti. Bu yanıtı yoksayın.)

Google Gears ekibi, ikili veri türü eksikliği sorunuyla karşılaştı ve sorunu çözmeye çalıştı:

Blob API'sı

JavaScript'in metin dizeleri için yerleşik bir veri türü vardır, ancak ikili veriler için hiçbir şey yoktur. Blob nesnesi bu sınırlamayı gidermeye çalışır.

Belki bir şekilde örebilirsin.

İkili verileri kesinlikle metin tabanlı ve çok sınırlı bir formata sokabilme yeteneği aradığınızdan, Base64'ün ek yükünün JSON ile sürdürmeyi beklediğiniz kolaylığa kıyasla minimum olduğunu düşünüyorum. Gücü ve iş hacmini işlemek önemliyse, muhtemelen dosya biçimlerinizi yeniden gözden geçirmeniz gerekir.

Sadece tartışmaya kaynak ve karmaşıklık bakış açısını eklemek. Yeni kaynakları saklamak ve değiştirmek için PUT / POST ve PATCH yaptığından, içerik aktarımının depolanan ve bir GET işlemi yapılarak alınan içeriğin tam bir temsili olduğunu hatırlamak gerekir.

Çok parçalı bir mesaj genellikle kurtarıcı olarak kullanılır, ancak basitlik nedeni ve daha karmaşık görevler için içeriği bir bütün olarak verme fikrini tercih ederim. Kendi kendini açıklar ve basittir.

Ve evet JSON sakat bir şey ama sonunda JSON'un kendisi ayrıntılı. Ve BASE64 ile eşleştirmenin yükü küçüktür.

Çok Parçalı mesajları doğru bir şekilde kullanmak için gönderilecek nesneyi sökmek, otomatik kombinasyon için parametre adı olarak bir özellik yolu kullanmak veya sadece yükü ifade etmek için başka bir protokol / format oluşturmak gerekir.

BSON yaklaşımından da hoşlanan bu, olması gerektiği gibi geniş ve kolay bir şekilde desteklenmiyor.

Temel olarak, burada sadece bir şey özledik ama ikili veriyi base64 olarak gömmek iyi kurulmuş ve gerçek ikili aktarımı yapma ihtiyacını gerçekten belirlemediyseniz (bu çoğu zaman böyle değil).

Biraz daha fazla kazıyorum (uygulanması sırasında base128'in ) ve ascii kodlarının 128'den büyük olduğu karakterleri gönderdiğimizde tarayıcıdan (krom) aslında bir tane yerine İKİ karakter (bayt) gönderiyoruz :( . varsayılan olarak , 127'nin üzerinde ascii kodları olan karakterlerin chmike cevabı ile belirtilen iki bayt tarafından kodlandığı utf8 karakterlerini kullanın.Bu şekilde test yaptım: chrome url bar chrome yazın: // net-export / , "Ham ekle bayt ", yakalamaya başlayın, POST istekleri gönderin (altta snippet kullanarak), yakalamayı durdurun ve json dosyasını ham istek verileriyle kaydedin. Sonra o json dosyasının içine bakıyoruz:

• 4142434445464748494a4b4c4d4eBu hex kodlaması dize bularak base64 isteğimizi bulabilir ABCDEFGHIJKLMNve bunun "byte_count": 639için göreceğiz .
• Yukarıdaki 727 isteğimizi, string C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38B-request utf8 karakter kodları ¼½ÀÁÂÃÄÅÆÇÈÉÊË(ancak bu karakterlerin ascii hex kodları c1c2c3c4c5c6c7c8c9cacbcccdce) dize bularak bulabiliriz . "byte_count": 703Daha uzun 127 Yukarıdaki ASCII kodları ile karakter kodu istekte 2 byte tarafından çünkü base64 talep daha 64bytes yani :(

Aslında> 127 :( kodlu karakterler göndermekle karımız yok. Base64 dizeleri için bu tür olumsuz davranışları gözlemlemiyoruz (muhtemelen base85 için de - kontrol etmiyorum) - ancak bu sorunun bazı çözümleri olabilir answerlex yanıtta açıklanan POST çok parçalı / form verilerinin ikili kısmında veri gönderme (ancak genellikle bu durumda herhangi bir temel kodlama kullanmamız gerekmez ...).

Alternatif yaklaşım, iki bayt veri bölümünü, geçerli bir utf8 karakterine base65280 / base65k gibi bir şey kullanarak kodlayarak eşleştirmeye dayanabilir, ancak muhtemelen utf8 belirtimi nedeniyle base64'ten daha az etkili olacaktır ...

function postBase64() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("base64ch", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/");
  req.open("POST", '/testBase64ch');
  req.send(formData);
}


function postAbove127() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("above127", "¼½ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüý");
  req.open("POST", '/testAbove127');
  req.send(formData);
}

<button onclick=postBase64()>POST base64 chars</button>
<button onclick=postAbove127()>POST chars with codes>127</button>

Veri türü gerçekten endişe verici. Yükü RESTful kaynağından göndermekle ilgili farklı senaryoları test ettim. Kodlama için Base64 (Apache) ve sıkıştırma GZIP (java.utils.zip. *) Kullandım.Faydalı yük film, görüntü ve ses dosyası hakkında bilgi içerir. Performansı önemli ölçüde düşüren görüntü ve ses dosyalarını sıkıştırdım ve kodladım. Sıkıştırmadan önce kodlama iyi çıktı. Görüntü ve ses içeriği kodlanmış ve sıkıştırılmış bayt olarak gönderilmiştir [].

Bakınız: http://snia.org/sites/default/files/Multi-part%20MIME%20Extension%20v1.0g.pdf

İkili verilerin base64 dönüştürülmesine gerek kalmadan 'CDMI içerik türü' işlemlerini kullanarak bir CDMI istemcisi ile sunucu arasında ikili veri aktarmanın bir yolunu açıklar.

'CDMI olmayan içerik türü' işlemini kullanabiliyorsanız, 'verileri' bir nesneye / nesneden aktarmak idealdir. Daha sonra meta veriler daha sonra bir 'CDMI içerik türü' işlemi olarak nesneye eklenebilir / nesneye geri alınabilir.

Şimdi benim çözümüm, XHR2 ArrayBuffer kullanıyor. İkili dizi olarak ArrayBuffer, çoklu içerik türlerine sahip çok parçalı içerik, video, ses, grafik, metin vb. İçerir. Hepsi Bir Arada Yanıt.

Modern tarayıcıda, farklı Bileşenler için DataView, StringView ve Blob'a sahip olmak. Ayrıca daha fazla bilgi için http://rolfrost.de/video.html adresine bakın.