জেএসএন স্ট্রিংয়ে বাইনারি ডেটা। বেস 64 এর চেয়ে ভাল কিছু


613

JSON ফর্ম্যাটে নেটিভ বাইনারি ডেটা সমর্থন করে না। বাইনারি ডেটা এড়াতে হবে যাতে এটি স্ট্রিং উপাদান (যেমন শূন্য বা আরও ইউনিকোড অক্ষরে ডাবল উদ্ধৃতিতে ব্যাকস্ল্যাশ পলায়ন ব্যবহার করে) এ JSON এ স্থাপন করা যায়।

বাইনারি ডেটা থেকে বাঁচার একটি সুস্পষ্ট পদ্ধতি হ'ল বেস 64 ব্যবহার করা। তবে বেস 64 এর উচ্চতর প্রসেসিং ওভারহেড রয়েছে। এছাড়াও এটি 3 বাইটকে 4 টি অক্ষরে প্রসারিত করে যা প্রায় 33% দ্বারা ডেটা আকার বাড়ায়।

এর জন্য একটি ব্যবহারের ক্ষেত্রে সিডিএমআই ক্লাউড স্টোরেজ এপিআই স্পেসিফিকেশনের v0.8 খসড়া । আপনি JSON ব্যবহার করে একটি REST-Webservice এর মাধ্যমে ডেটা অবজেক্ট তৈরি করেন eg

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

জিনস স্ট্রিংগুলিতে বাইনারি ডেটা এনকোড করার আরও ভাল উপায় এবং মানক পদ্ধতি আছে?


29
আপলোডের জন্য: আপনি কেবল একবার এটি করছেন, তাই এটি এত বড় বিষয় নয়। ডাউনলোডের জন্য, আপনি অবাক হতে পারেন জিজেপের অধীনে বেস 64 কমপ্রেসগুলি কতটা ভাল , তাই যদি আপনি সার্ভারে জিজিপ সক্ষম করে থাকেন তবে আপনি সম্ভবত ঠিক আছেন OK
ক্লাউডফিট

2
হার্ড নার্দের জন্য আরেকটি উপযুক্ত সমাধান #pack.org : github.com/msgpack/msgpack/blob/master/spec.md
নিকোলালিয়াস

2
@ ক্লাউডফিট, প্রতি ব্যবহারকারী প্রতি ক্রিয়াকলাপ । খুব বড় একটি চুক্তি।
পেসারিয়ার

2
নোট করুন যে অক্ষরগুলি সাধারণত প্রতিটি মেমরির 2 বাইট হয়। সুতরাং, বেস 64 তারের উপরে ওভারহেড + 33% দিতে পারে, তবে সেই তথ্যটি তারের উপরে রাখে, এটি পুনরুদ্ধার করে এবং এটি ব্যবহার করে, একটি + 166% (8/3) ওভারহেডের প্রয়োজন হয় । দৃষ্টিতে কেস: জাভাস্ক্রিপ্ট স্ট্রিংয়ের সর্বাধিক দৈর্ঘ্য 100 ক চর থাকলে, আপনি কেবল মাত্র 64 37.৫ ক বাইট উপাত্তের সাহায্যে ডেটা 75 75 কে বাইট না করে উপস্থাপন করতে পারেন। এই সংখ্যাগুলি অ্যাপ্লিকেশনের অনেক অংশে যেমন বাধা হতে পারে, যেমন JSON.parseইত্যাদি। ......
পেসারিয়ার

5
@ পেসারিয়ার "সাধারণত 2 বাইট মেমরি [প্রতি চরিত্রে]" সঠিক নয়। উদাহরণস্বরূপ v8 এর ওয়ানবাইট এবং টুবাইট স্ট্রিং রয়েছে। ক্ষুব্ধ মেমরির খরচ এড়াতে কেবল যেখানে প্রয়োজন সেখানে দ্বি-বাইট স্ট্রিং ব্যবহার করা হয়। বেস 64 এক-বাইট স্ট্রিং সহ এনকোডেবল।
ZachB

উত্তর:


459

এখানে ৪৯ টি ইউনিকোড অক্ষর রয়েছে যা জেএসএন স্পেক অনুযায়ী এক বাইট হিসাবে উপস্থাপিত হতে পারে (যদি আপনার জেএসওএন ইউটিএফ -8 হিসাবে সংক্রমণিত হয়)। এই বিষয়টি মাথায় রেখেই আমি মনে করি যে আপনি স্থান-ভিত্তিক সবচেয়ে ভাল করতে পারেন বেস 85 is যা চারটি বাইটকে পাঁচটি অক্ষর হিসাবে উপস্থাপন করে। যাইহোক, এটি বেস64 এর তুলনায় এটি কেবল 7% উন্নতি, এটি গণনা করা আরও ব্যয়বহুল, এবং বাস্তবায়ন বেস 64 এর চেয়ে কম সাধারণ কারণ এটি সম্ভবত কোনও জয় নয়।

আপনি প্রতিটি ইনপুট বাইটটি কেবলমাত্র ইউ +0000-ইউ + 00 এফএফ-তে সংশ্লিষ্ট বর্ণটিতে ম্যাপ করতে পারেন, তারপরে সেই অক্ষরগুলি পাস করার জন্য জেএসওএন স্ট্যান্ডার্ড দ্বারা প্রয়োজনীয় ন্যূনতম এনকোডিং করুন; এখানে সুবিধাটি হ'ল প্রয়োজনীয় ডিকোডিংটি অন্তর্নির্মিত ফাংশনের বাইরে নয়, তবে স্থান দক্ষতা খারাপ - একটি 105% সম্প্রসারণ (যদি সমস্ত ইনপুট বাইট একইভাবে হয়) বনাম 85 এর জন্য 25% বা বেস 64 এর জন্য 33%।

চূড়ান্ত রায়: আমার মতামত অনুসারে বেস 64 জিতল, এটি সাধারণ, সহজ এবং যথেষ্ট খারাপ নয় s প্রতিস্থাপনের পরোয়ানা পক্ষে ।

আরও দেখুন: বেস 91 এবং বেস 122


5
অপেক্ষা করুন কীভাবে কেবল বদ্ধ অক্ষরগুলিকে 105% প্রসারণ এবং বেস 64 কেবলমাত্র 33% এনকোড করার সময় আসল বাইট ব্যবহার করছেন? বেস 64 নয় 133%?
jjxtra

17
বেস 91 জেএসএনের পক্ষে খারাপ ধারণা, কারণ এটিতে বর্ণমালায় উদ্ধৃতি রয়েছে। জেএসএন এনকোডিংয়ের পরে সবচেয়ে খারাপ ক্ষেত্রে (সমস্ত উদ্ধৃতি আউটপুট), এটি মূল পেইডের 245%।
জার্নোহ

25
পাইথন ৩.৪ এর অন্তর্ভুক্ত base64.b85encode()এবং b85decode()এখন। একটি সাধারণ এনকোড + ডিকোড সময় পরিমাপ দেখায় যে b85 বি 64 এর চেয়ে 13 গুণ বেশি ধীর। সুতরাং আমাদের কাছে 7% আকারের জয়, তবে 1300% কার্যকারিতা হ্রাস loss
পিটার এনস

3
@hobbs তাদেরকে JSON যে কন্ট্রোল- অক্ষর পলান করা আবশ্যক। আরএফসি 20 বিভাগ 5.2DEL একটি নিয়ন্ত্রণ চরিত্র হতে সংজ্ঞায়িত করে।
টিনো

2
@ টিনো ইসএমএ -404 বিশেষত যে অক্ষরগুলি পালাতে হবে তা তালিকাভুক্ত করে: ডাবল উক্তি ইউ + 0022, ব্যাকস্ল্যাশ ইউ + 005 সি, এবং "নিয়ন্ত্রণ অক্ষর ইউ + 0000 থেকে ইউ + 001 এফ"।
হোবিস

249

আমি একই সমস্যার মধ্যে দৌড়েছি, এবং ভেবেছি আমি একটি সমাধান ভাগ করব: মাল্টিপার্ট / ফর্ম-ডেটা।

একটি মাল্টিপার্ট ফর্ম প্রেরণ করে আপনি প্রথমে আপনার JSON মেটা-ডেটা স্ট্রিং হিসাবে প্রেরণ করুন এবং তারপরে পৃথকভাবে সামগ্রী-বিশৃঙ্খলা নাম অনুসারে কাঁচা বাইনারি (চিত্র (গুলি), wavs, ইত্যাদি) হিসাবে প্রেরণ করুন ।

এটি কীভাবে আপজে-সি-তে করা যায় সে সম্পর্কে একটি সুন্দর টিউটোরিয়াল এবং এখানে একটি ব্লগ নিবন্ধ রয়েছে যা ফর্মের সীমানা দিয়ে স্ট্রিং ডেটা বিভাজন করতে এবং বাইনারি ডেটা থেকে পৃথক করার ব্যাখ্যা দেয়।

আপনার কেবলমাত্র পরিবর্তনটি হ'ল সার্ভার সাইডে; আপনাকে আপনার মেটা-ডেটা ক্যাপচার করতে হবে যা পোস্টের বাইনারি ডেটা যথাযথভাবে উল্লেখ করতে হবে (একটি সামগ্রী-বিভাজন সীমানা ব্যবহার করে)।

অনুমোদিত এটির জন্য সার্ভার সাইডে অতিরিক্ত কাজ করা প্রয়োজন, তবে আপনি যদি অনেকগুলি চিত্র বা বড় ছবি পাঠাচ্ছেন তবে এটি মূল্যবান। আপনি যদি চান তবে এটি জিপিপ সংক্ষেপণের সাথে সংযুক্ত করুন।

আইএমএইচও বেস 64 এনকোডড ডেটা প্রেরণ হ্যাক; আরএফসি মাল্টিপার্ট / ফর্ম-ডেটা তৈরি করা হয়েছিল যেমন যেমনগুলির জন্য: পাঠ্য বা মেটা-ডেটার সংমিশ্রণে বাইনারি ডেটা প্রেরণ।


4
যাইহোক, গুগল ড্রাইভ এপিআই এটি এইভাবে করছে: ডেভেলপারস
ডটকম /

2
কেন এই উত্তরটি এত নীচু হয় যখন এটি কোনও বর্গক্ষেত্র (ASCII) গর্তে গোল করার (বাইনারি) খোঁচার পরিবর্তে স্থানীয় বৈশিষ্ট্যগুলি ব্যবহার করে? ...
মার্ক কে কোয়ান

5
বেস 64 এনকোডড ডেটা প্রেরণ হ্যাক তাই মাল্টিপার্ট / ফর্ম-ডেটা। এমনকি আপনি যে ব্লগ নিবন্ধটি সংযুক্ত করেছেন তা পড়তে পারে যে আপনি যে বিষয়বস্তু প্রকারের মাল্টিপার্ট / ফর্ম-ডেটা ব্যবহার করেন তা ব্যবহার করে, আপনি যা প্রেরণ করেন তা আসলে একটি ফর্ম। তবে তা নয়। সুতরাং আমি মনে করি বেস 64 হ্যাকটি কেবল প্রয়োগ করা খুব সহজ নয় তবে আরও নির্ভরযোগ্যও আমি কয়েকটি লাইব্রেরি দেখেছি (উদাহরণস্বরূপ পাইথনের জন্য), যেখানে মাল্টিপার্ট / ফর্ম-ডেটা সামগ্রীগুলির টাইপ হার্ডকোডযুক্ত ছিল।
t3chb0t

4
@ t3chb0t মাল্টিপার্ট / ফর্ম-ডেটা মিডিয়া টাইপ ফর্ম ডেটা পরিবহনের জন্য জন্মগ্রহণ করেছিল তবে আজ এটি HTTP / এইচটিএমএল বিশ্বের বাইরে ব্যাপকভাবে ব্যবহৃত হয়, বিশেষত ইমেল সামগ্রীকে এনকোড করার জন্য। আজ এটি জেনেরিক এনকোডিং সিনট্যাক্স হিসাবে প্রস্তাবিত। tools.ietf.org/html/rfc7578
Lorenzo

3
@ মারককোয়ান সম্ভবত কারণ এটি প্রশ্নের উদ্দেশ্যটির পক্ষে সহায়ক হলেও এটি জিজ্ঞাসা করা প্রশ্নের উত্তর দেয় না, যা কার্যকরভাবে "জেএসওএন-তে ব্যবহারের জন্য টেক্সট এনকোডিংয়ের লো ওভারহেড বাইনারি", এই উত্তরটি পুরোপুরি জেএসএনকে আঁকছে।
চিনোটো ভোকরো

34

ইউটিএফ -8 এর সমস্যাটি হ'ল এটি সর্বাধিক স্থান দক্ষ এনকোডিং নয়। এছাড়াও, কিছু এলোমেলো বাইনারি বাইট সিকোয়েন্সগুলি অবৈধ ইউটিএফ -8 এনকোডিং। সুতরাং আপনি কিছু ইউটিএফ -8 ডেটা হিসাবে কেবল একটি এলোমেলো বাইনারি বাইট অনুক্রমটি ব্যাখ্যা করতে পারবেন না কারণ এটি অবৈধ ইউটিএফ -8 এনকোডিং হবে। ইউটিএফ -8 এনকোডিংয়ের এই সীমাবদ্ধতার সুবিধা হ'ল মাল্টি বাইট চরগুলি শুরু করা এবং আমরা যে বাইটটি দেখতে শুরু করি তা শেষ করা এবং শেষ করা এটি শক্ত এবং সম্ভব করে তোলে।

ফলস্বরূপ, যদি পরিসরে [0..127] বাইট মান এনকোডিং করতে UTF-8 এনকোডিংয়ে কেবলমাত্র একটি বাইট প্রয়োজন হয়, [128..255] ব্রেজের মান এনকোডিং করার জন্য 2 বাইট প্রয়োজন হবে! তার চেয়েও খারাপ। জেএসএনে, নিয়ন্ত্রণের অক্ষর, "এবং a কোনও স্ট্রিংয়ের মধ্যে উপস্থিত হওয়ার অনুমতি নেই So সুতরাং বাইনারি ডেটার সঠিকভাবে এনকোড করার জন্য কিছু রূপান্তর প্রয়োজন।

চল দেখি. যদি আমরা আমাদের বাইনারি ডেটাতে অভিন্নভাবে বিতরণ করা এলোমেলো বাইট মানগুলি ধরে নিই, তবে, গড়ে, বাইটের অর্ধেকটি একটি বাইটে এবং অন্য অর্ধেকটি দুটি বাইটে এনকোড থাকে। UTF-8 এনকোডেড বাইনারি ডেটা প্রাথমিক আকারের 150% হবে।

বেস64 64 এনকোডিংটি প্রাথমিক আকারের কেবল 133% পর্যন্ত বৃদ্ধি পায়। সুতরাং বেস 64 এনকোডিং আরও দক্ষ।

অন্য বেস এনকোডিং ব্যবহার সম্পর্কে কী? ইউটিএফ -8 এ, 128 এএসসিআইআই মানগুলিকে এনকোড করা সর্বাধিক স্থান দক্ষ। 8 বিটে আপনি 7 বিট সংরক্ষণ করতে পারেন। সুতরাং আমরা যদি কোনও ইউটিএফ -8 এনকোডযুক্ত স্ট্রিংয়ের প্রতিটি বাইটে তাদের সংরক্ষণের জন্য বাইনারি ডেটাটি 7 বিট অংশগুলিতে কাটা করি তবে এনকোডযুক্ত ডেটা প্রাথমিক আকারের 114% পর্যন্ত বাড়বে। বেস 64 এর চেয়ে ভাল। দুর্ভাগ্যক্রমে আমরা এই সহজ কৌশলটি ব্যবহার করতে পারি না কারণ জেএসওন কিছু ASCII অক্ষরের অনুমতি দেয় না। এএসসিআইআই ([0..31] এবং 127) এর 33 টি নিয়ন্ত্রণ অক্ষর এবং "এবং \ অবশ্যই বাদ দিতে হবে This এটি আমাদের কেবল 128-35 = 93 অক্ষর ছেড়ে দেয়।

সুতরাং তত্ত্বে আমরা একটি বেস93 এনকোডিং সংজ্ঞায়িত করতে পারি যা এনকোডেড আকারটি 8 / লগ 2 (93) = 8 * লগ 10 (2) / লগ 10 (93) = 122% এ বাড়বে। তবে একটি বেস93 এনকোডিং বেস 64 এনকোডিংয়ের মতো সুবিধাজনক হবে না। বেস 64 কে ইনপুট বাইট সিকোয়েন্সটি 6 বিট অংশগুলিতে কাটাতে হবে যার জন্য সরল বিটওয়াইজ অপারেশন ভালভাবে কাজ করে। 133% এর পাশাপাশি 122% এর বেশি নয়।

এ কারণেই আমি স্বতন্ত্রভাবে এই সাধারণ সিদ্ধান্তে এসেছি যে জেএসএনে বাইনারি ডেটা এনকোড করার জন্য বেস 64 প্রকৃতপক্ষে সেরা পছন্দ। আমার উত্তর এটির জন্য একটি ন্যায়সঙ্গততা উপস্থাপন করে। আমি সম্মত হই যে এটি পারফরম্যান্সের দৃষ্টিকোণ থেকে খুব আকর্ষণীয় নয়, তবে JSON ব্যবহারের সুবিধাটিও বিবেচনা করুন এটির সমস্ত প্রোগ্রামিং ভাষায় মানব পাঠযোগ্য স্ট্রিং প্রতিনিধিত্ব সহজ।

খাঁটি বাইনারি এনকোডিংয়ের চেয়ে পারফরম্যান্স সমালোচনামূলক হলে জেএসএন প্রতিস্থাপন হিসাবে বিবেচনা করা উচিত। তবে জেএসনের সাথে আমার উপসংহারে বলা হয়েছে যে বেস 64 ভাল 64


বেস 128 সম্পর্কে তবে জেএসএন সিরিয়ালাইজারকে "এবং escape" থেকে বাঁচতে দেওয়া সম্পর্কে আমি কীভাবে ইউসোন পার্সার বাস্তবায়ন ব্যবহারকারীর প্রত্যাশা করা যুক্তিসঙ্গত মনে করি?
jcalfi314

1
@ jcalfi314 দুর্ভাগ্যক্রমে এটি সম্ভব নয় কারণ 32-এর নীচে ASCII কোড সহ অক্ষরগুলি JSON স্ট্রিংগুলিতে অনুমোদিত নয়। 64 এবং 128 এর মধ্যে একটি বেস সহ এনকোডিংগুলি ইতিমধ্যে সংজ্ঞায়িত করা হয়েছে, তবে প্রয়োজনীয় গণনা বেস 64 এর চেয়ে বেশি। এনকোডযুক্ত পাঠ্যের আকারের লাভটি মূল্যবান নয়।
chmike

বেস 64 এ যদি বড় পরিমাণে চিত্রগুলি লোড করা হয় (তবে 1000 বলি) বা সত্যিই ধীর সংযোগের উপর লোড করা হলে বেস 85 বা বেস 93 কি কখনও হ্রাস হওয়া নেটওয়ার্ক ট্র্যাফিকের জন্য অর্থ প্রদান করবে (ডাব্লু / বা ডাব্লু / ও জিজিপ)? আমি আগ্রহী যদি এমন কোনও পয়েন্ট আসে যেখানে আরও কমপ্যাক্ট ডেটা বিকল্প পদ্ধতির একটির জন্য কেস তৈরি করে।
ভোলআরন

আমার সন্দেহ হয় গণনার গতি সংক্রমণ সময়ের চেয়ে বেশি গুরুত্বপূর্ণ more চিত্রগুলি অবশ্যই সার্ভারের দিকে প্রাক্পম্প্ট করা উচিত। যাইহোক, উপসংহারে যে JSON বাইনারি ডেটার জন্য খারাপ।
chmike

পুনরায় " বেস64৪ এনকোডিংটি প্রাথমিক আকারের কেবল ১৩৩% পর্যন্ত বৃদ্ধি পায় সুতরাং বেস64 এনকোডিং আরও দক্ষ ", এটি সম্পূর্ণরূপে ভুল কারণ চরিত্রগুলি সাধারণত দুটি বাইট হয়। এখানে বিস্তারিত দেখুন stackoverflow.com/questions/1443158/...
Pacerier

34

BSON (বাইনারি জেএসএন) আপনার পক্ষে কাজ করতে পারে। http://en.wikipedia.org/wiki/BSON

সম্পাদনা: এফওয়াইআই। নেট লাইব্রেরি json.net আপনি যদি কিছু সি # সার্ভারের সাইড প্রেমের সন্ধান করেন তবে বিসন পড়া এবং লেখার সমর্থন করে।


1
"কিছু ক্ষেত্রে, বিএসওএন দৈর্ঘ্যের উপসর্গ এবং সুস্পষ্ট অ্যারে সূচকগুলির কারণে জেএসএন এর চেয়ে বেশি স্থান ব্যবহার করবে।" en.wikipedia.org/wiki/BSON
Pawel Cioch

সুসংবাদ: BSON স্থানীয়ভাবে বাইনারি, ডেটটাইম এবং আরও কয়েকজন (যেমন আপনি মঙ্গোডিবি ব্যবহার করছেন তবে বিশেষত দরকারী) এর মতো ধরণের সমর্থন করে। খারাপ সংবাদ: এটি এনকোডিং বাইনারি বাইটস ... সুতরাং এটি ওপি-র একটি উত্তর নয়। তবে এটি এমন চ্যানেলের পক্ষে কার্যকর হবে যা বাইনারি স্থানীয়ভাবে যেমন খরগোশকিউ বার্তা, জিরোমিকিউ বার্তা, বা একটি কাস্টম টিসিপি বা ইউডিপি সকেটের সমর্থন করে।
ড্যান এইচ

19

আপনি যদি ব্যান্ডউইথ সমস্যাগুলি নিয়ে কাজ করেন, ক্লায়েন্টের পক্ষ থেকে ডেটাটি প্রথমে সংক্ষেপে চেষ্টা করুন, তারপরে বেস 64 64

এই জাতীয় যাদুবিদ্যার চমৎকার উদাহরণটি http://jszip.stuartk.co.uk/ এ রয়েছে এবং এই বিষয়ে আরও আলোচনাটি জাজিপের জাভাস্ক্রিপ্ট বাস্তবায়নে রয়েছে


2
এখানে একটি জাভাস্ক্রিপ্ট জিপ বাস্তবায়ন যা আরও ভাল পারফরম্যান্স দাবি করে: zip.js
জানুস

নোট করুন যে আপনি এখনও (এবং হওয়া উচিত) পরে (সাধারণত মাধ্যমে Content-Encoding) সংকোচনের করতে পারেন , যেমন বেস 64 বেশ ভালভাবে সংকোচিত হয়।
মাহমুদ আল-কুদসি

@ মাহমুদআল-কুদসী আপনি বোঝাচ্ছেন যে আপনি বেস 64 (জিপ (বেস 64 (জিপ (ডেটা)))? আমি নিশ্চিত নই যে অন্য একটি জিপ যুক্ত করুন এবং তারপরে এটি বেস64 (এটি ডেটা হিসাবে প্রেরণে সক্ষম হতে) ভাল ধারণা।
andrej

18

yEnc আপনার জন্য কাজ করতে পারে:

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

"yEnc হ'ল বাইনারি ফাইলগুলি [পাঠ্য] তে স্থানান্তরিত করার জন্য বাইনারি-থেকে-পাঠ্য এনকোডিং স্কিম scheme এটি 8-বিট প্রসারিত ASCII এনকোডিং পদ্ধতি ব্যবহার করে পূর্ববর্তী মার্কিন-ASCII- ভিত্তিক এনকোডিং পদ্ধতিগুলির ওভারহেড হ্রাস করে y yEnc এর ওভারহেড প্রায়শই (যদি ইউএনকোড এবং বেস 64 এর মতো 6-বিট এনকোডিং পদ্ধতির জন্য 33% –40% ওভারহেডের তুলনায় প্রতিটি বাইট মান আনুমানিক গড় একই ফ্রিকোয়েন্সি সহ প্রদর্শিত হয়) 1 as2% এর তুলনায় সামান্য। ... 2003 এর মধ্যে yEnc ডি-ফ্যাক্টো স্ট্যান্ডার্ডে পরিণত হয়েছিল ইউজনেটে ​​বাইনারি ফাইলগুলির জন্য এনকোডিং সিস্টেম। "

যাইহোক, yEnc একটি 8-বিট এনকোডিং, সুতরাং এটি JSON স্ট্রিংয়ে সংরক্ষণ করা মূল বাইনারি ডেটা সংরক্ষণ করার মতো একই সমস্যা রয়েছে - এটি নির্বিঘ্নে করা মানে প্রায় 100% প্রসারণ, যা বেস 64 এর চেয়ে খারাপ।


42
যেহেতু অনেক লোক এখনও এই প্রশ্নটি দেখছে বলে মনে হচ্ছে, আমি উল্লেখ করতে চাই যে YEnc সত্যিই এখানে সহায়তা করে বলে আমি মনে করি না। yEnc একটি 8-বিট এনকোডিং, সুতরাং এটি JSON স্ট্রিংয়ে সংরক্ষণ করা মূল বাইনারি ডেটা সংরক্ষণ করার মতো একই সমস্যা রয়েছে - এটি নির্বিঘ্নে করা মানে প্রায় 100% সম্প্রসারণ, যা বেস 64 এর চেয়ে খারাপ।
hobbs

ক্ষেত্রে যখন JSON ডেটা সহ বড় বর্ণমালার সাথে yEnc এর মতো এনকোডিংগুলি গ্রহণযোগ্য বলে মনে করা হয়, তখন অব্যাহতিহীন স্থির-জানা-অগ্রিম ওভারহেড সরবরাহের একটি ভাল বিকল্প হিসাবে কাজ করতে পারে।
ইভান কোসারেভ

10

যদিও এটি সত্য যে বেস 64 এর expansion 33% সম্প্রসারণ হার রয়েছে, এটি অপরিহার্যভাবে সত্য নয় যে ওভারহেড প্রসেসিং এর চেয়ে উল্লেখযোগ্য পরিমাণে বেশি: এটি আপনি ব্যবহার করছেন জেএসএন লাইব্রেরি / টুলকিটের উপর নির্ভর করে। এনকোডিং এবং ডিকোডিং সহজ সরল-ফরোয়ার্ড ক্রিয়াকলাপ এবং এগুলি এমনকি আর্ট ক্যারেক্টার এনকোডিং অপ্টিমাইজ করা যেতে পারে (যেমন JSON কেবলমাত্র ইউটিএফ -8 / 16/32 সমর্থন করে) - বেস 64 অক্ষরগুলি সবসময় JSON স্ট্রিং এন্ট্রিগুলির জন্য একক-বাইট থাকে। জাভা প্ল্যাটফর্মে উদাহরণস্বরূপ এমন লাইব্রেরি রয়েছে যা কাজটি দক্ষতার চেয়ে দক্ষতার সাথে করতে পারে, যাতে ওভারহেড বেশিরভাগ প্রসারিত আকারের কারণে হয়।

আমি পূর্বের দুটি উত্তরের সাথে একমত:

  • বেস 64৪ সাধারণ, সাধারণভাবে ব্যবহৃত মানের, তাই জেএসওএন-এর সাথে বিশেষভাবে ব্যবহারের জন্য আরও ভাল কিছু আবিষ্কার করার সম্ভাবনা নেই (বেস -৫৫ পোস্টস্ক্রিপ্ট ইত্যাদির সাহায্যে ব্যবহৃত হয়; তবে আপনি যখন এটি সম্পর্কে চিন্তা করেন তখন সুবিধাগুলি সবচেয়ে ভাল হয়)
  • এনকোডিংয়ের আগে সংকোচনকরণ (এবং ডিকোডিংয়ের পরে) আপনার ব্যবহার করা ডেটার উপর নির্ভর করে প্রচুর অর্থ তৈরি করতে পারে

10

হাসি ফর্ম্যাট

এটি এনকোড, ডিকোড এবং কমপ্যাক্ট করা খুব দ্রুত

গতির তুলনা (তবে জাভা ভিত্তিক তবে তাত্পর্যপূর্ণ): https://github.com/eishay/jvm-serializer/wiki/

এছাড়াও এটি জেএসএনের একটি বর্ধন যা আপনাকে বাইট অ্যারেগুলির জন্য বেস 64 এনকোডিং এড়াতে দেয়

স্থান সঙ্কটজনক হলে হাসি এনকোডযুক্ত স্ট্রিংগুলি জিজেপ করা যায়


3
... এবং লিঙ্কটি মারা গেছে। এটি আপ টু ডেট বলে মনে হচ্ছে: github.com/FasterXML/smile-format-specifications
জিরো 3

4

( 7 বছর পরে সম্পাদনা করুন: গুগল গিয়ার্স চলে গেছে this এই উত্তরটি উপেক্ষা করুন))


গুগল গিয়ার্স টিমটি বাইনারি-ডেটা-ধরণের সমস্যার অভাবের মধ্যে পড়ে এবং এটি সমাধানের চেষ্টা করেছে:

ব্লব এপিআই

জাভাস্ক্রিপ্টটিতে টেক্সট স্ট্রিংয়ের জন্য অন্তর্নির্মিত ডেটা টাইপ রয়েছে তবে বাইনারি ডেটার জন্য কিছুই নেই। ব্লব অবজেক্ট এই সীমাবদ্ধতার সমাধান করার চেষ্টা করে।

হতে পারে আপনি এটি কোনওভাবে বুনতে পারেন।


সুতরাং জাভাস্ক্রিপ্ট এবং জসন ব্লবগুলির স্থিতি কী? এটি বাদ দেওয়া হয়েছে?
chmike

w3.org/TR/FileAPI/#blob-section স্থানের জন্য বেস 64 হিসাবে পারফরম্যান্ট নয়, আপনি যদি নীচে স্ক্রোল করে দেখেন যে এটি utf8 মানচিত্র ব্যবহার করে এনকোড করেছে (হবসের উত্তর দ্বারা প্রদর্শিত বিকল্পগুলির মধ্যে একটি হিসাবে)। এবং কোনও জাসন সমর্থন নেই, যতদূর আমি জানি
ড্যানিয়েল ক্রুসিয়ানি

3

আপনি যেহেতু বাইনারি ডেটাগুলি কঠোরভাবে পাঠ্য-ভিত্তিক এবং খুব সীমাবদ্ধ ফর্ম্যাটে জুতা দেওয়ার দক্ষতার সন্ধান করছেন, তাই আমি মনে করি যে আপনি JSON এর সাথে বজায় রাখার প্রত্যাশা করছেন সেই তুলনায় বেস 64 এর ওভারহেড ন্যূনতম। যদি প্রসেসিং পাওয়ার এবং থ্রুপুটটি উদ্বেগজনক হয় তবে আপনার ফাইল ফর্ম্যাটগুলি পুনর্বিবেচনা করতে হবে।


2

কেবল আলোচনায় সংস্থান এবং জটিলতার অবস্থান যুক্ত করতে। যেহেতু নতুন সংস্থান সংরক্ষণ এবং সেগুলি পরিবর্তনের জন্য পুট / পোস্ট এবং প্যাচচ করছেন, তাই আপনার মনে রাখা উচিত যে বিষয়বস্তু স্থানান্তর হ'ল সামগ্রীর সঠিক প্রতিনিধিত্ব এবং এটি জিইটি অপারেশন জারি করে প্রাপ্ত হয় is

বহু অংশের বার্তাটি প্রায়শই একজন ত্রাণকর্তার হিসাবে ব্যবহৃত হয় তবে সরলতার কারণে এবং আরও জটিল কাজের জন্য, সামগ্রিকভাবে সামগ্রীতে দেওয়ার ধারণাটি আমি পছন্দ করি। এটি স্ব-ব্যাখ্যাকারী এবং এটি সাধারণ।

এবং হ্যাঁ জেএসএন হ'ল পঙ্গু কিছু তবে শেষ পর্যন্ত জেএসওএন নিজেই ভার্বোজ। এবং BASE64 এ ম্যাপিংয়ের ওভারহেড ছোট করার একটি উপায়।

মাল্টি-পার্ট বার্তাগুলি সঠিকভাবে ব্যবহার করতে হয় হয় পাঠাতে অবজেক্টটি ভেঙে ফেলতে হয়, স্বয়ংক্রিয় সংমিশ্রণের জন্য প্যারামিটারের নাম হিসাবে কোনও সম্পত্তি পথ ব্যবহার করতে হবে বা কেবলমাত্র লোড প্রকাশ করার জন্য অন্য একটি প্রোটোকল / ফর্ম্যাট তৈরি করতে হবে।

এছাড়াও বিএসওএন পদ্ধতির পছন্দ করে, এটি যেমনটি হতে চায় তেমন ব্যাপক ও সহজে সমর্থনযোগ্য নয়।

মূলত, আমরা এখানে কিছু মিস করছি তবে বেস 64 হিসাবে বাইনারি ডেটা এম্বেড করা ভাল প্রতিষ্ঠিত এবং যাওয়ার উপায় যদি না আপনি সত্যিকারের বাইনারি স্থানান্তর করার প্রয়োজনীয়তাটি চিহ্নিত করেন (যা প্রায়শই ক্ষেত্রে হয়)।


1

আমি কিছুটা আরও খনন করেছি ( বেস 128 বাস্তবায়নের সময় ), এবং প্রকাশ করি যে যখন আমরা 128 এর চেয়ে বেশি এসেসি কোডগুলি অক্ষরগুলি প্রেরণ করি তখন ব্রাউজার (ক্রোম) আসলে দুটি পরিবর্তে দুটি অক্ষর (বাইট) প্রেরণ করে :( কারণটি হ'ল JSON ডিফল্ট দ্বারা utf8 টি অক্ষর ব্যবহার করা হয়েছে যার জন্য 127 এর উপরে ascii কোড সহ অক্ষর দুটি বাইট দ্বারা কোড করা হয়েছে যা chmike দ্বারা উল্লিখিত ছিল উত্তর I আমি এইভাবে পরীক্ষা করেছি: ক্রোম ইউআরএল বার টাইপ করুন ক্রোম টাইপ করুন : // নেট-এক্সপোর্ট / , "কাঁচা অন্তর্ভুক্ত করুন" নির্বাচন করুন বাইটস ", ক্যাপচারিং শুরু করুন, পোষ্ট অনুরোধগুলি প্রেরণ করুন (নীচে স্নিপেট ব্যবহার করে), ক্যাপচার অনুরোধ ডেটা সহ জেসন ফাইলটি ক্যাপচার করা এবং সংরক্ষণ করুন Then তারপরে আমরা সেই জসন ফাইলটির ভিতরে তাকাব:

  • স্ট্রিং সন্ধান করে আমরা আমাদের বেস 64 অনুরোধটি খুঁজে পেতে পারি 4142434445464748494a4b4c4d4e এটি হেক্স কোডিং ABCDEFGHIJKLMNএবং "byte_count": 639এটি দেখতে পাব ।
  • স্ট্রিং সন্ধানের মাধ্যমে আমরা আমাদের উপরের 127 অনুরোধটি খুঁজে পেতে পারি এটি হ'ল অনুরোধ C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38B-হেক্স utf8 টি অক্ষরের কোড ¼½ÀÁÂÃÄÅÆÇÈÉÊË(তবে এই অক্ষরের এসকি হেক্স কোডগুলি হ'ল c1c2c3c4c5c6c7c8c9cacbcccdce)। দ্য"byte_count": 703তাই এটি 64bytes আর করুন Base64- অনুরোধ চেয়ে কারণ 127 উপরে ASCII কোড দিয়ে অক্ষর অনুরোধ 2 বাইট কোড হয় :(

সুতরাং আসলে কোডগুলির সাথে অক্ষর প্রেরণে আমাদের লাভ নেই> 127 :( বেস 64 স্ট্রিংগুলির জন্য আমরা এই জাতীয় নেতিবাচক আচরণটি পালন করি না (সম্ভবত বেস 85 এর জন্যও - আমি এটি পরীক্ষা করে দেখি) - তবে এই সমস্যার কিছু সমাধান হতে পারে ইলেক্স উত্তরে বর্ণিত পোষ্ট মাল্টিপার্ট / ফর্ম-ডেটার বাইনারি অংশে ডেটা প্রেরণ (তবে সাধারণত এই ক্ষেত্রে আমাদের কোনও বেস কোডিং ব্যবহার করার দরকার নেই ...)।

বিকল্প পদ্ধতিটি বেস 6565280 / বেস65k এর মতো কিছু ব্যবহার করে কোডের মাধ্যমে দুটি বাইট ডেটা অংশকে একটি বৈধ utf8 চরিত্রের ম্যাপিংয়ের উপর নির্ভর করতে পারে তবে utf8 নির্দিষ্টকরণের কারণে এটি বেস 64 এর চেয়ে কম কার্যকর হবে ...


0

ডেটা টাইপ সত্যিই উদ্বেগ। আমি একটি RESTful রিসোর্স থেকে পেডলোড প্রেরণের জন্য বিভিন্ন পরিস্থিতিতে পরীক্ষা করেছি। এনকোডিংয়ের জন্য আমি বেস 64 (অ্যাপাচি) এবং সংক্ষেপণের জন্য জিজেআইপি (java.utils.zip। *) ব্যবহার করেছি পে-লোডে ফিল্ম, একটি চিত্র এবং একটি অডিও ফাইল সম্পর্কিত তথ্য রয়েছে। আমি চিত্রটি এবং অডিও ফাইলগুলি সংকুচিত এবং এনকোড করেছি যা কার্য সম্পাদনকে মারাত্মকভাবে হ্রাস করেছে। সংক্ষেপণের আগে এনকোডিং ভাল হয়ে গেছে। চিত্র এবং অডিও সামগ্রী এনকোডযুক্ত এবং সংকুচিত বাইট হিসাবে প্রেরণ করা হয়েছিল []।


0

রেফারেন্স: http://snia.org/sites/default/files/ মাল্টি- পার্ট ৯২০MIME%20 এক্সটেনশন ১০২০v1.0g.pdf

এটি বাইনারি তথ্যের বেস 64৪ রূপান্তর প্রয়োজন ছাড়াই সিডিএমআই ক্লায়েন্ট এবং সার্ভারের মধ্যে 'সিডিএমআই কনটেন্ট টাইপ' অপারেশন ব্যবহার করে বাইনারি ডেটা স্থানান্তর করার একটি উপায় বর্ণনা করে।

আপনি যদি 'নন-সিডিএমআই কনটেন্ট টাইপ' অপারেশন ব্যবহার করতে পারেন তবে কোনও অবজেক্টে / থেকে 'ডেটা' স্থানান্তর করা আদর্শ। এর পরে মেটাডেটা পরের 'সিডিএমআই কনটেন্ট টাইপ' অপারেশন হিসাবে অবজেক্টে / থেকে যোগ / পুনরুদ্ধার করা যায়।


-1

আমার সমাধান এখন, এক্সএইচআর 2 অ্যারেবফার ব্যবহার করছে। বাইনারি সিকোয়েন্স হিসাবে অ্যারেবফারটিতে একাধিক সামগ্রী-প্রকারের সাথে মাল্টিপার্ট-কন্টেন্ট, ভিডিও, অডিও, গ্রাফিক, পাঠ্য ইত্যাদি রয়েছে। সমস্ত ইন ওয়ান রেসপন্স।

আধুনিক ব্রাউজারে, বিভিন্ন উপাদানগুলির জন্য ডেটাভিউ, স্ট্রিংভিউ এবং ব্লব রয়েছে। আরও দেখুন: http://rolfrost.de/video.html আরও তথ্যের জন্য।


আপনি বাইটের অ্যারে সিরিয়াল করে আপনার ডেটা + 100% বাড়িয়ে
তুলবেন


জেএসএনে একটি বাইট অ্যারের সিরিয়ালাইজেশন এরকম কিছু: [16, 2, 38, 89]যা খুব অদক্ষ।
শার্কাক্স
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.