Data Biner dalam String JSON. Sesuatu yang lebih baik dari Base64

615

The format JSON native tidak mendukung data biner. Data biner harus melarikan diri sehingga dapat ditempatkan ke elemen string (yaitu nol atau lebih karakter Unicode dalam tanda kutip ganda menggunakan backslash escapes) di JSON.

Metode yang jelas untuk melarikan diri data biner adalah menggunakan Base64. Namun, Base64 memiliki overhead pemrosesan yang tinggi. Juga memperluas 3 byte menjadi 4 karakter yang mengarah pada peningkatan ukuran data sekitar 33%.

Satu kasus penggunaan untuk ini adalah draft v0.8 dari spesifikasi API penyimpanan awan CDMI . Anda membuat objek data melalui REST-Webservice menggunakan JSON, misalnya

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=",
}

Adakah cara dan metode standar yang lebih baik untuk menyandikan data biner ke dalam string JSON?

tuan
sumber
30
Untuk mengunggah: Anda hanya melakukannya sekali, jadi ini bukan masalah besar. Untuk mengunduh, Anda mungkin akan terkejut seberapa baik base64 kompres di bawah gzip , jadi jika Anda mengaktifkan gzip di server Anda, Anda mungkin juga baik-baik saja.
cloudfeet
2
Solusi lain yang layak msgpack.org untuk para nerd hardcore: github.com/msgpack/msgpack/blob/master/spec.md
nicolallias
2
@cloudfeet, Sekali per pengguna per tindakan . Kesepakatan yang sangat besar.
Pacerier
2
Perhatikan bahwa karakter biasanya masing-masing 2 byte memori . Dengan demikian, base64 mungkin memberikan + 33% (4/3) overhead pada kabel, tetapi menempatkan data itu pada kabel, mengambilnya, dan menggunakannya, akan membutuhkan + 166% (8/3) overhead . Contoh kasus: jika string Javascript memiliki panjang maksimum 100rb karakter, Anda hanya dapat mewakili 37,5rb byte data menggunakan base64, bukan 75rb byte data. Angka-angka ini dapat menjadi penghambat di banyak bagian aplikasi, mis JSON.parse. Dll ......
Pacerier
5
@Pacerier "biasanya 2 byte memori [per karakter]" tidak akurat. v8 misalnya memiliki string OneByte dan TwoByte. String dua byte hanya digunakan jika diperlukan untuk menghindari konsumsi memori yang aneh. Base64 dikodekan dengan string satu byte.
ZachB

Jawaban:

460

Ada 94 karakter Unicode yang dapat direpresentasikan sebagai satu byte sesuai dengan spesifikasi JSON (jika JSON Anda ditransmisikan sebagai UTF-8). Dengan mengingat hal itu, saya pikir yang terbaik yang bisa Anda lakukan di luar angkasa adalah base85 yang mewakili empat byte sebagai lima karakter. Namun, ini hanya peningkatan 7% dari base64, ini lebih mahal untuk dihitung, dan implementasi lebih jarang dari pada base64 sehingga mungkin bukan kemenangan.

Anda juga bisa memetakan setiap byte input ke karakter yang sesuai di U + 0000-U + 00FF, lalu melakukan pengkodean minimum yang diperlukan oleh standar JSON untuk meneruskan karakter tersebut; keuntungan di sini adalah bahwa decoding yang diperlukan adalah nihil di luar fungsi builtin, tetapi efisiensi ruang buruk - ekspansi 105% (jika semua byte input kemungkinan sama) vs 25% untuk base85 atau 33% untuk base64.

Putusan akhir: base64 menang, menurut saya, dengan alasan bahwa itu umum, mudah, dan tidak cukup buruk untuk menjamin penggantian.

Lihat juga: Base91 dan Base122

hobbs
sumber
5
Tunggu, bagaimana hanya menggunakan byte aktual saat mengkodekan karakter kutipan ekspansi 105% dan base64 hanya 33%? Bukankah base64 133%?
jjxtra
17
Base91 adalah ide buruk untuk JSON, karena mengandung kutipan dalam alfabet. Dalam kasus terburuk (semua output kutipan) setelah pengkodean JSON, itu adalah 245% dari muatan asli.
jarnoh
25
Python 3.4 termasuk base64.b85encode()dan b85decode()sekarang. Pengkodean sederhana + pengukuran waktu dekode menunjukkan bahwa b85 lebih dari 13 kali lebih lambat daripada b64. Jadi kami memiliki 7% ukuran menang, tetapi 1300% kehilangan kinerja.
Pieter Ennes
3
@hobbs JSON menyatakan bahwa karakter kontrol harus melarikan diri. RFC20 bagian 5.2 mendefinisikan DELsebagai karakter kontrol.
Tino
2
@Tino ECMA-404 secara khusus mencantumkan karakter yang perlu diloloskan: kutipan ganda U + 0022, backslash U + 005C, dan "karakter kontrol U + 0000 hingga U + 001F".
hobbs
249

Saya mengalami masalah yang sama, dan berpikir saya akan membagikan solusi: multipart / form-data.

Dengan mengirimkan formulir multi bagian, Anda mengirim pertama sebagai string meta-data JSON Anda , dan kemudian secara terpisah mengirim sebagai biner mentah (gambar, wav, dll) yang diindeks oleh nama Content-Disposition .

Berikut ini adalah tutorial yang bagus tentang bagaimana melakukan ini di obj-c, dan di sini ada artikel blog yang menjelaskan bagaimana cara mempartisi data string dengan batas bentuk, dan memisahkannya dari data biner.

Satu-satunya perubahan yang benar-benar perlu Anda lakukan adalah di sisi server; Anda harus menangkap meta-data Anda yang seharusnya merujuk data biner POST dengan tepat (dengan menggunakan batas Disposisi Konten).

Memang itu membutuhkan kerja tambahan di sisi server, tetapi jika Anda mengirim banyak gambar atau gambar besar, ini sepadan. Kombinasikan ini dengan kompresi gzip jika Anda mau.

IMHO mengirim data yang disandikan base64 adalah hack; multipart / formulir-data RFC dibuat untuk masalah seperti ini: mengirim data biner dalam kombinasi dengan teks atau meta-data.

Ælex
sumber
4
Omong-omong, Google Drive API melakukannya dengan cara ini: developers.google.com/drive/v2/reference/files/update#examples
Mathias Conradt
2
Mengapa jawaban ini sangat rendah ketika menggunakan fitur asli alih-alih mencoba memeras pasak (biner) bundar ke dalam lubang persegi (ASCII)? ...
Mark K Cowan
5
mengirim data yang disandikan base64 adalah peretasan, begitu juga multipart / formulir-data. Bahkan artikel blog yang Anda tautkan bertuliskan bahwa Dengan menggunakan Content-Type multipart / form-data yang Anda nyatakan, bahwa apa yang Anda kirim sebenarnya adalah sebuah formulir. Tapi ternyata tidak. jadi saya pikir peretasan base64 tidak hanya lebih mudah diimplementasikan tetapi juga lebih dapat diandalkan saya telah melihat beberapa perpustakaan (misalnya Python), yang memiliki tipe konten multipart / form-data hardcoded.
t3chb0t
4
@ t3chb0t Jenis media multi-data / formulir-data lahir untuk mengangkut data formulir, tetapi sekarang ini banyak digunakan di luar dunia HTTP / HTML, terutama untuk menyandikan konten email. Hari ini diusulkan sebagai sintaksis penyandian generik. tools.ietf.org/html/rfc7578
lorenzo
3
@MarkKCowan Mungkin karena walaupun ini bermanfaat untuk tujuan pertanyaan, itu tidak menjawab pertanyaan seperti yang diajukan, yang secara efektif "Biner overhead rendah ke pengkodean teks untuk digunakan dalam JSON", jawaban ini sepenuhnya membuang JSON.
Chinoto Vokro
34

Masalah dengan UTF-8 bukanlah encoding yang paling efisien ruang. Juga, beberapa urutan byte biner acak adalah pengkodean UTF-8 yang tidak valid. Jadi Anda tidak bisa hanya menginterpretasikan urutan byte biner acak sebagai beberapa data UTF-8 karena itu akan menjadi pengkodean UTF-8 yang tidak valid. Manfaat dari batasan ini pada pengkodean UTF-8 adalah membuatnya kuat dan memungkinkan untuk menemukan karakter multi byte mulai dan mengakhiri byte apa pun yang mulai kita lihat.

Sebagai akibatnya, jika pengkodean nilai byte dalam rentang [0..127] hanya membutuhkan satu byte dalam pengkodean UTF-8, pengkodean nilai byte dalam rentang [128..255] akan membutuhkan 2 byte! Lebih buruk dari itu. Di JSON, kontrol karakter, "dan \ tidak diizinkan untuk muncul dalam sebuah string. Jadi data biner akan memerlukan beberapa transformasi untuk dikodekan dengan benar.

Biarkan melihat. Jika kita mengasumsikan nilai byte acak yang terdistribusi secara seragam dalam data biner kita, maka, rata-rata, setengah dari byte akan dikodekan dalam satu byte dan setengah lainnya dalam dua byte. Data biner yang dikodekan UTF-8 akan memiliki 150% dari ukuran awal.

Pengkodean Base64 hanya tumbuh hingga 133% dari ukuran awal. Jadi pengkodean Base64 lebih efisien.

Bagaimana dengan menggunakan pengkodean Base lain? Dalam UTF-8, penyandian nilai 128 ASCII adalah yang paling efisien dalam ruang. Dalam 8 bit Anda dapat menyimpan 7 bit. Jadi jika kita memotong data biner dalam potongan 7 bit untuk menyimpannya dalam setiap byte dari string yang dikodekan UTF-8, data yang dikodekan hanya akan tumbuh hingga 114% dari ukuran awal. Lebih baik dari Base64. Sayangnya kami tidak dapat menggunakan trik mudah ini karena JSON tidak mengizinkan beberapa karakter ASCII. 33 karakter kontrol ASCII ([0..31] dan 127) dan tanda "dan \ harus dikecualikan. Ini membuat kita hanya 128-35 = 93 karakter.

Jadi secara teori kita dapat mendefinisikan encoding Base93 yang akan menumbuhkan ukuran yang dikodekan menjadi 8 / log2 (93) = 8 * log10 (2) / log10 (93) = 122%. Tetapi pengkodean Base93 tidak akan senyaman pengkodean Base64. Base64 mengharuskan untuk memotong urutan byte input dalam potongan 6bit yang operasi bitwise sederhana bekerja dengan baik. Selain 133% tidak lebih dari 122%.

Inilah sebabnya saya sampai pada kesimpulan umum bahwa Base64 memang pilihan terbaik untuk menyandikan data biner di JSON. Jawaban saya menyajikan pembenaran untuk itu. Saya setuju itu tidak terlalu menarik dari sudut pandang kinerja, tetapi mempertimbangkan juga manfaat menggunakan JSON dengan representasi string yang dapat dibaca manusia mudah dimanipulasi dalam semua bahasa pemrograman.

Jika kinerja sangat penting daripada pengkodean biner murni harus dianggap sebagai penggantian JSON. Tetapi dengan JSON kesimpulan saya adalah bahwa Base64 adalah yang terbaik.

chmike
sumber
Bagaimana dengan Base128 tetapi kemudian membiarkan JSON serializer lolos dari "dan \? Saya pikir masuk akal untuk mengharapkan pengguna untuk menggunakan implementasi parser json.
jcalfee314
1
@ jcalfee314 sayangnya ini tidak mungkin karena karakter dengan kode ASCII di bawah 32 tidak diperbolehkan dalam string JSON. Pengkodean dengan basis antara 64 dan 128 telah ditentukan, tetapi perhitungan yang diperlukan lebih tinggi dari base64. Keuntungan dalam ukuran teks yang disandikan tidak sepadan.
chmike
Jika memuat sejumlah besar gambar dalam base64 (misalkan 1000), atau memuat melalui koneksi yang benar-benar lambat, apakah base85 atau base93 akan pernah membayar untuk lalu lintas jaringan yang berkurang (tanpa atau tanpa gzip)? Saya ingin tahu apakah ada titik di mana data yang lebih kompak akan membuat kasus untuk salah satu metode alternatif.
vol7ron
Saya menduga kecepatan perhitungan lebih penting daripada waktu transmisi. Gambar jelas harus dihitung di sisi server. Bagaimanapun, kesimpulannya adalah bahwa JSON buruk untuk data biner.
chmike
Re " Base64 encoding hanya tumbuh hingga 133% dari ukuran awal Jadi pengkodean Base64 lebih efisien ", ini sepenuhnya salah karena karakter biasanya masing-masing 2 byte. Lihat elaborasi di stackoverflow.com/questions/1443158/…
Pacerier
34

BSON (Binary JSON) dapat bekerja untuk Anda. http://en.wikipedia.org/wiki/BSON

Sunting: FYI. NET library json.net mendukung membaca dan menulis bson jika Anda mencari beberapa sisi cinta C # server.

DarcyThomas
sumber
1
"Dalam beberapa kasus, BSON akan menggunakan lebih banyak ruang daripada JSON karena awalan panjang dan indeks array eksplisit." en.wikipedia.org/wiki/BSON
Pawel Cioch
Berita bagus: BSON secara native mendukung tipe-tipe seperti Binary, Datetime, dan beberapa lainnya (khususnya berguna jika Anda menggunakan MongoDB). Berita buruk: pengodeannya adalah byte biner ... jadi ini bukan jawaban untuk OP. Namun itu akan berguna melalui saluran yang mendukung biner secara native seperti pesan RabbitMQ, pesan ZeroMQ, atau soket TCP atau UDP khusus.
Dan H
19

Jika Anda berurusan dengan masalah bandwidth, coba kompres data di sisi klien terlebih dahulu, lalu base64-it.

Contoh bagus dari sihir semacam itu ada di http://jszip.stuartk.co.uk/ dan diskusi lebih lanjut untuk topik ini adalah pada implementasi JavaScript dari Gzip

andrej
sumber
2
inilah implementasi zip JavaScript yang mengklaim kinerja yang lebih baik: zip.js
Janus Troelsen
Perhatikan bahwa Anda masih dapat (dan harus) mengompres juga (biasanya melalui Content-Encoding), karena base64 dapat dikompres dengan cukup baik.
Mahmoud Al-Qudsi
@ MahmoudAl-Qudsi Anda bermaksud bahwa Anda base64 (zip (base64 (zip (data)))))? Saya tidak yakin bahwa menambahkan zip lain dan kemudian base64 itu (untuk dapat mengirimkannya sebagai data) adalah ide yang bagus.
andrej
18

yEnc mungkin bekerja untuk Anda:

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

"yEnc adalah skema pengkodean biner-ke-teks untuk mentransfer file biner dalam [teks]. Ini mengurangi biaya overhead dari metode pengkodean berbasis AS-ASCII sebelumnya dengan menggunakan metode pengkodean ASCII Diperpanjang 8-bit. overhead yEnc sering (jika setiap nilai byte muncul kira-kira dengan frekuensi rata-rata yang sama) sesedikit 1-2%, dibandingkan dengan 33% –40% overhead untuk metode pengkodean 6-bit seperti uuencode dan Base64 .... Pada tahun 2003 yEnc menjadi standar de facto. sistem pengkodean untuk file biner di Usenet. "

Namun, yEnc adalah penyandian 8-bit, jadi menyimpannya dalam string JSON memiliki masalah yang sama dengan menyimpan data biner asli - melakukannya dengan cara naif berarti tentang ekspansi 100%, yang lebih buruk daripada base64.

richardtallent
sumber
42
Karena banyak orang tampaknya masih melihat pertanyaan ini, saya ingin menyebutkan bahwa saya tidak berpikir Anda benar-benar membantu di sini. yEnc adalah penyandian 8-bit, jadi menyimpannya dalam string JSON memiliki masalah yang sama dengan menyimpan data biner asli - melakukannya dengan cara naif berarti ekspansi 100%, yang lebih buruk daripada base64.
hobbs
Dalam kasus ketika menggunakan pengkodean seperti yEnc dengan huruf besar dengan data JSON dianggap dapat diterima, melarikan diri dapat bekerja sebagai alternatif yang baik dengan menyediakan overhead yang telah diketahui sebelumnya.
Ivan Kosarev
10

Meskipun benar bahwa base64 memiliki ~ 33% tingkat ekspansi, itu tidak selalu benar bahwa memproses overhead secara signifikan lebih dari ini: itu benar-benar tergantung pada perpustakaan / toolkit JSON yang Anda gunakan. Pengkodean dan penguraian adalah operasi langsung yang sederhana, dan mereka bahkan dapat dioptimalkan pengkodean karakter wrt (karena JSON hanya mendukung UTF-8/16/32) - karakter base64 selalu byte tunggal untuk entri String JSON. Misalnya pada platform Java ada perpustakaan yang dapat melakukan pekerjaan dengan lebih efisien, sehingga overhead sebagian besar disebabkan oleh ukuran yang diperluas.

Saya setuju dengan dua jawaban sebelumnya:

  • base64 sederhana, standar yang umum digunakan, jadi tidak mungkin untuk menemukan sesuatu yang lebih baik secara khusus untuk digunakan dengan JSON (base-85 digunakan oleh postscript dll; tetapi manfaatnya paling baik bila Anda memikirkannya)
  • kompresi sebelum encoding (dan setelah decoding) mungkin masuk akal, tergantung pada data yang Anda gunakan
StaxMan
sumber
10

Format senyum

Sangat cepat untuk menyandikan, mendekode, dan kompak

Perbandingan kecepatan (berbasis java tapi tetap berarti): https://github.com/eishay/jvm-serializers/wiki/

Juga merupakan ekstensi ke JSON yang memungkinkan Anda untuk melewatkan encoding base64 untuk array byte

Senyum yang dikodekan dengan senyuman dapat di-gzip saat ruang kritis

Stefano Fratini
sumber
3
... dan tautannya mati. Yang ini tampaknya terkini: github.com/FasterXML/smile-format-specification
Zero3
4

( Edit 7 tahun kemudian: Google Gears hilang. Abaikan jawaban ini.)


Tim Google Gears mengalami masalah kekurangan tipe data biner dan telah berupaya mengatasinya:

API gumpalan

JavaScript memiliki tipe data bawaan untuk string teks, tetapi tidak untuk data biner. Objek Blob mencoba untuk mengatasi batasan ini.

Mungkin Anda bisa menenunnya entah bagaimana.

kutu buku yang dibayar
sumber
Jadi bagaimana status gumpalan di Javascript dan json? Apakah sudah dijatuhkan?
chmike
w3.org/TR/FileAPI/#blob-section Tidak berkinerja sebagai base64 untuk ruang, jika Anda gulir ke bawah Anda menemukan bahwa itu dikodekan menggunakan peta utf8 (sebagai salah satu opsi yang ditunjukkan oleh jawaban hobbs '). Dan tidak ada dukungan json, sejauh yang saya tahu
Daniele Cruciani
3

Karena Anda mencari kemampuan untuk memilih data biner ke dalam format yang sangat berbasis teks dan sangat terbatas, saya pikir biaya overhead Base64 minimal dibandingkan dengan kenyamanan yang Anda harapkan untuk dipertahankan dengan JSON. Jika kekuatan pemrosesan dan throughput menjadi perhatian, maka Anda mungkin perlu mempertimbangkan kembali format file Anda.

jsoverson
sumber
2

Hanya untuk menambah sudut pandang sumber daya dan kompleksitas pada diskusi. Karena melakukan PUT / POST dan PATCH untuk menyimpan sumber daya baru dan mengubahnya, orang harus ingat bahwa transfer konten adalah representasi yang tepat dari konten yang disimpan dan yang diterima dengan mengeluarkan operasi GET.

Pesan multi-bagian sering digunakan sebagai penyelamat tetapi untuk alasan kesederhanaan dan untuk tugas-tugas yang lebih kompleks, saya lebih suka ide memberikan konten secara keseluruhan. Ini menjelaskan diri sendiri dan sederhana.

Dan ya JSON adalah sesuatu yang melumpuhkan tetapi pada akhirnya JSON itu sendiri adalah verbose. Dan overhead pemetaan ke BASE64 adalah cara untuk menjadi kecil.

Menggunakan pesan Multi-Bagian dengan benar kita harus membongkar objek untuk dikirim, menggunakan jalur properti sebagai nama parameter untuk kombinasi otomatis atau perlu membuat protokol / format lain untuk hanya mengekspresikan muatan.

Juga menyukai pendekatan BSON, ini tidak didukung secara luas dan mudah seperti yang diinginkan.

Pada dasarnya, kami hanya melewatkan sesuatu di sini tetapi menanamkan data biner karena base64 sudah mapan dan cara untuk pergi kecuali Anda benar-benar telah mengidentifikasi kebutuhan untuk melakukan transfer biner nyata (yang jarang terjadi).

Martin Kersten
sumber
1

Saya menggali sedikit lebih banyak (selama implementasi base128 ), dan mengekspos bahwa ketika kita mengirim karakter yang kode ascii lebih besar dari 128 maka browser (chrome) sebenarnya mengirim DUA karakter (byte) alih-alih satu :( . Alasannya adalah bahwa JSON oleh defaul gunakan utf8 karakter yang karakternya dengan kode ascii di atas 127 dikodekan oleh dua byte yang disebut oleh jawaban chmike . Saya membuat tes dengan cara ini: ketik chrome url bar chrome: // net-export / , pilih "Include raw byte ", mulailah menangkap, mengirim permintaan POST (menggunakan snipet di bagian bawah), berhenti mengambil dan menyimpan file json dengan data permintaan mentah. Lalu kita melihat ke dalam file json itu:

  • Kami dapat menemukan permintaan base64 kami dengan menemukan string yang 4142434445464748494a4b4c4d4emerupakan hex coding ABCDEFGHIJKLMNdan kami akan melihatnya"byte_count": 639 untuk itu.
  • Kita dapat menemukan permintaan di atas127 dengan menemukan string, C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38Bini adalah kode karakter hex-utf8 permintaan ¼½ÀÁÂÃÄÅÆÇÈÉÊË(namun kode hex ascii dari karakter ini adalah c1c2c3c4c5c6c7c8c9cacbcccdce). The "byte_count": 703sehingga 64bytes lebih lama dari base64 meminta karena karakter dengan kode ascii di atas 127 adalah kode dengan 2 byte dalam permintaan :(

Jadi sebenarnya kita tidak mendapat untung dengan mengirim karakter dengan kode> 127 :(. Untuk string base64 kita tidak mengamati perilaku negatif seperti itu (mungkin untuk base85 juga - saya tidak memeriksanya) - namun mungkin ada beberapa solusi untuk masalah ini adalah mengirim data dalam bagian biner dari POST multipart / formulir-data yang dijelaskan dalam Ælex answer (namun biasanya dalam hal ini kita tidak perlu menggunakan kode dasar sama sekali ...).

Pendekatan alternatif dapat mengandalkan pemetaan dua byte data bagian menjadi satu karakter utf8 yang valid dengan kode menggunakan sesuatu seperti base65280 / base65k tapi mungkin itu akan kurang efektif daripada base64 karena spesifikasi utf8 ...

Kamil Kiełczewski
sumber
0

Tipe data sangat memprihatinkan. Saya telah menguji berbagai skenario pengiriman muatan dari sumber yang tenang. Untuk pengkodean saya telah menggunakan Base64 (Apache) dan untuk kompresi GZIP (java.utils.zip. *). Muatannya berisi informasi tentang film, gambar, dan file audio. Saya telah mengompresi dan menyandikan file gambar dan audio yang secara drastis menurunkan kinerja. Pengkodean sebelum kompresi berjalan dengan baik. Konten gambar dan audio dikirim sebagai byte yang dikodekan dan dikompresi [].

Koushik
sumber
0

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

Ini menjelaskan cara untuk mentransfer data biner antara klien CDMI dan server menggunakan operasi 'tipe konten CDMI' tanpa memerlukan konversi base64 dari data biner.

Jika Anda dapat menggunakan operasi 'Jenis konten Non-CDMI', sangat ideal untuk mentransfer 'data' ke / dari objek. Metadata kemudian dapat ditambahkan / diambil ke / dari objek sebagai operasi 'tipe konten CDMI' berikutnya.

Dheeraj Sangamkar
sumber
-1

Solusi saya sekarang, XHR2 menggunakan ArrayBuffer. ArrayBuffer sebagai urutan biner berisi konten multi-bagian, video, audio, grafik, teks dan sebagainya dengan beberapa tipe konten. Semua dalam Satu Respons.

Di browser modern, memiliki DataView, StringView dan Blob untuk Komponen yang berbeda. Lihat juga: http://rolfrost.de/video.html untuk lebih jelasnya.

Rolf Rost
sumber
Anda akan membuat data Anda bertambah + 100% dengan membuat serial array byte
Sharcoux
@ Sharcoux, wot ??
Mihail Malostanidis
Serialisasi array byte di JSON adalah sesuatu seperti: [16, 2, 38, 89]yang sangat tidak efisien.
Sharcoux