আমরা বেস 64 কেন ব্যবহার করব?


275

উইকিপিডিয়া বলেছেন

পাঠ্য ডেটা নিয়ে কাজ করার জন্য ডিজাইন করা মিডিয়াতে বাইনারি ডেটা সংরক্ষণ এবং স্থানান্তরিত করা দরকার এমন বাইনারি ডেটা এনকোড করার প্রয়োজন হয় তখন বেস 64 এনকোডিং স্কিমগুলি সাধারণত ব্যবহৃত হয়। এটি পরিবহনের সময় সংশোধন ছাড়াই ডেটা অক্ষত থাকে তা নিশ্চিত করা।

তবে এটি কি নয় যে ডেটা সবসময় বাইনারিতে সঞ্চিত / প্রেরণ করা হয় কারণ আমাদের মেশিনগুলিতে বাইনারি রয়েছে এমন মেমরিটি এটি নির্ভর করে যে আপনি এটি কীভাবে ব্যাখ্যা করবেন? সুতরাং, আপনি ASCII হিসাবে বা বেস 64 এর 010011010110000101101110মতো বিট প্যাটার্নটি এনকোড করুন , আপনি শেষ পর্যন্ত একই বিট প্যাটার্নটি সঞ্চয় করতে যাচ্ছেন।ManTWFu

যদি চূড়ান্ত এনকোডিংটি শূন্যগুলির সাথে থাকে এবং প্রতিটি মেশিন এবং মিডিয়া তাদের সাথে ডিল করতে পারে তবে ডেটা ASCII বা বেস 64 হিসাবে উপস্থাপন করা থাকলে কীভাবে আসে?

এর অর্থ কী "" মিডিয়াগুলি পাঠ্য সংক্রান্ত ডেটা নিয়ে কাজ করার জন্য ডিজাইন করা হয়েছে "? তারা বাইনারি সাথে ডিল করতে পারে => তারা যে কোনও কিছুতে ডিল করতে পারে।


সবাইকে ধন্যবাদ, আমি মনে করি আমি এখন বুঝতে পেরেছি।

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

থেকে মার্ক Byers উদাহরণ

আমি যদি পাঠাতে চাই

Hello
world!

একটি উপায় এটি ASCII তে পাঠানো

72 101 108 108 111 10 119 111 114 108 100 33

তবে বাইট 10 অন্য প্রান্তে একটি নিউলাইন হিসাবে সঠিকভাবে ব্যাখ্যা করা যাবে না। সুতরাং, আমরা এটির মতো এনকোড করতে ASCII এর একটি উপসেট ব্যবহার করি

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

যা একই পরিমাণ তথ্যের জন্য হস্তান্তরিত আরও ডেটা ব্যয়ে নিশ্চিত করে যে রিসিভারটি বর্ণনামূলক বাকী অংশের জন্য পৃথক ব্যাখ্যার পরেও রিসিভারটিকে ডেটা ডিকোড করতে পারে।


6
Backgroundতিহাসিক পটভূমি: ইমেল সার্ভারগুলি 7-বিট ASCII ব্যবহৃত হত। তাদের মধ্যে অনেকগুলি উচ্চ বিট 0 তে সেট করবে তাই আপনাকে কেবল 7-বিট মান পাঠাতে হবে। দেখুন en.wikipedia.org/wiki/Email#Content_encoding
হ্যারল্ড এল

53
আমরা বেস use৪ ব্যবহার করি কারণ এটি পার্লের চেয়ে বেশি পঠনযোগ্য
মার্টিন

2
@ মার্টিন, আপনি মজা করছেন পার্ল পড়া শক্ত, তবে বেস 64 মোটেই অপঠনযোগ্য।
পিটার লং

1
@ লেজার আপনার চিত্র অনুপস্থিত
মিক

2
@ লেজার, "তবে 10 টি বাইটের অন্য প্রান্তে একটি নিউলাইন হিসাবে সঠিকভাবে ব্যাখ্যা করা যায় না।" কেন? দুই পক্ষই ASCII এ একমত হয়েছে এবং তাদের অবশ্যই এটির সঠিক ব্যাখ্যা করতে হবে!
প্রোগ্রামপ্পে

উত্তর:


298

আপনার প্রথম ভুলটি ভাবছে যে এএসসিআইআই এনকোডিং এবং বেস 64 এনকোডিংটি বিনিময়যোগ্য। তারা না. এগুলি বিভিন্ন কাজে ব্যবহৃত হয়।

  • আপনি যখন পাঠ্যটিকে ASCII এ এনকোড করবেন তখন আপনি একটি পাঠ্য স্ট্রিং দিয়ে শুরু করেন এবং এটিকে বাইটের ক্রমে রূপান্তর করেন।
  • আপনি বেস 64 এ ডেটা এনকোড করার সময়, আপনি বাইটের ক্রম দিয়ে শুরু করেন এবং এটিকে কোনও পাঠ্য স্ট্রিংয়ে রূপান্তর করেন।

বেস 64 কেন প্রথম স্থানে প্রয়োজনীয় ছিল তা বোঝার জন্য আমাদের কম্পিউটিংয়ের একটু ইতিহাস প্রয়োজন need


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

মূলত প্রচুর বিভিন্ন এনকোডিং তৈরি হয়েছিল (যেমন বাউডট কোড ) যা চরিত্র অনুযায়ী বিটগুলির বিভিন্ন সংখ্যা ব্যবহার করে অবশেষে এএসসিআইআই প্রতিটি চরিত্রের জন্য b টি বিট সহ একটি স্ট্যান্ডার্ড হয়ে যায়। তবে বেশিরভাগ কম্পিউটারগুলিতে বাইনারি ডেটা সংরক্ষণ করে 8 টি বিট সমন্বিত বাইটে যাতে ASCII এই ধরণের ডেটা ট্র্যানফার করার জন্য অনুপযুক্ত। কিছু সিস্টেম এমনকি সর্বাধিক উল্লেখযোগ্য বিট মুছতে পারে। তদ্ব্যতীত সিস্টেমগুলিতে লাইন শেষ এনকোডিংয়ের পার্থক্যের অর্থ ASCII অক্ষর 10 এবং 13 কখনও কখনও সংশোধন করা হত।

এই সমস্যাগুলি সমাধান করার জন্য বেস 64 এনকোডিং চালু হয়েছিল। এটি আপনাকে অ্যারিবট্রি বাইটগুলি বাইটগুলিতে এনকোড করার অনুমতি দেয় যা দূষিত না হয়ে প্রেরণে নিরাপদ বলে পরিচিত (এএসসিআইআই বর্ণানুক্রমিক অক্ষর এবং কয়েকটি চিহ্ন)। অসুবিধাটি হ'ল বেস 64 ব্যবহার করে বার্তাটি এনকোডিং করা তার দৈর্ঘ্য বৃদ্ধি করে - প্রতি 3 বাইট ডেটা 4 এএসসিআইআই অক্ষরকে এনকোড করা হয়।

টেক্সট পাঠাতে নির্ভরযোগ্যভাবে আপনি যা করতে পারেন প্রথম আপনার পছন্দের এবং তারপর (উদাহরণস্বরূপ হল UTF-8 এর জন্য) একটি টেক্সট এনকোডিং ব্যবহার বাইট সঙ্কেতাক্ষরে লিখা পরে করুন Base64- একটি টেক্সট স্ট্রিং, যাতে হওয়া ASCII হিসাবে এনকোডেড পাঠান নিরাপদ মধ্যে ফলে বাইনারি ডেটা সঙ্কেতাক্ষরে লিখা। আসল বার্তাটি পুনরুদ্ধার করতে রিসিভারকে এই প্রক্রিয়াটি বিপরীত করতে হবে। এটি অবশ্যই প্রয়োজন যে প্রাপক জানেন যে কোন এনকডিংগুলি ব্যবহৃত হয়েছিল এবং এই তথ্যটি প্রায়শই পৃথকভাবে প্রেরণ করা প্রয়োজন।

Orতিহাসিকভাবে এটি ইমেল বার্তাগুলিতে বাইনারি ডেটা এনকোড করতে ব্যবহৃত হয়েছে যেখানে ইমেল সার্ভারটি লাইন-এন্ডিংগুলি সংশোধন করতে পারে। আরও আধুনিক উদাহরণ হ'ল এইচটিএমএল সোর্স কোডে চিত্র ডেটা এম্বেড করতে বেস 64 এনকোডিং ব্যবহার । '<' এবং '>' এর মতো অক্ষরগুলি ট্যাগ হিসাবে ব্যাখ্যা করা এড়াতে এখানে ডেটা এনকোড করা দরকার।


এখানে একটি কার্যকারী উদাহরণ:

আমি দুটি লাইন সহ একটি পাঠ্য বার্তা প্রেরণ করতে চাই:

হ্যালো
বিশ্ব!

যদি আমি এএসসিআইআই (বা ইউটিএফ -8) হিসাবে এটি প্রেরণ করি তবে এটি দেখতে এই জাতীয় দেখাচ্ছে:

72 101 108 108 111 10 119 111 114 108 100 33

বাইট 10 কিছু সিস্টেমে দূষিত হয় তাই আমরা এই বাইটগুলিকে বেস 64 স্ট্রিং হিসাবে 64 এনকোড করতে পারি:

SGVsbG8sCndvcmxkIQ ==

এএসসিআইআই ব্যবহার করে এনকোড করা হলে যা দেখতে এটির মতো দেখাচ্ছে:

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

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


4
"বেশিরভাগ আধুনিক যোগাযোগের প্রোটোকলগুলি ডেটাটিকে দূষিত করবে না" - যদিও উদাহরণস্বরূপ ইমেলটি ডেলিভারি এজেন্টের সাথে "From n> থেকে" অক্ষরের স্ট্রিং প্রতিস্থাপন করে যখন এটি কোনও বার্তা মেইলবক্সে সংরক্ষণ করে। অথবা এইচটিটিপি শিরোনামগুলি ডেটাতে নিউলাইনগুলি এড়াতে কোনও পুনর্বারযোগ্য উপায় ছাড়াই নিউলাইনটি সমাপ্ত করা হয় (লাইন ধারাবাহিকতা হোয়াইটস্পেসে আবদ্ধ হয়), সুতরাং আপনি কেবল তাদের মধ্যে নির্বিচারে ASCII ফেলে দিতে পারবেন না। বেস64 মাত্র 7-বিট সুরক্ষার চেয়ে ভাল , এটি আলফা-সংখ্যাসূচক এবং - = + / নিরাপদ।
স্টিভ জেসোপ

1
"অসুবিধাটি হ'ল বেস 64 ব্যবহার করে বার্তাটি এনকোডিংয়ের দৈর্ঘ্য বৃদ্ধি পায় - প্রতিটি 3 বাইট ডেটা 4 বাইটে এনকোড করা হয়।" এটি কীভাবে 4 বাইটে বাড়বে? এটি কি কেবল 3 * 8 = 24 বিট হবে না?
লেজার

4
@ লেজার: না। আপনার নিজস্ব উদাহরণটি দেখুন - "ম্যান" বেস-64৪ "টিডাব্লুএফু" হিসাবে এনকোডেড। 3 বাইট -> 4 বাইট। এর কারণ ইনপুটটিকে সম্ভাব্য বাইটগুলির মধ্যে 2 ^ 8 = 256 হওয়ার কোনও অনুমতি দেওয়া হয়, তবে আউটপুট কেবল তাদের মধ্যে 2 ^ 6 = 64 ব্যবহার করে (এবং =, ডেটার দৈর্ঘ্য নির্দেশ করতে সহায়তা করে)। আউটপুটটির প্রতি চতুর্থাংশে 8 বিটগুলি "নষ্ট" হয়, যাতে ইনপুটটি কোনও "উত্তেজনাপূর্ণ" অক্ষর ধারণ করতে না পারে।
স্টিভ জেসপ

2
এটি পুনরুদ্ধার করতে সহায়ক হতে পারে "আপনি যখন বেস64 এ ডেটা এনকোড করবেন, আপনি বাইটের ক্রম দিয়ে শুরু করুন এবং এটি একটি পাঠ্য স্ট্রিংয়ে রূপান্তর করুন" যখন আপনি বেস64 এ ডেটা এনকোড করেন, আপনি বাইটের ক্রম দিয়ে শুরু করে এটি একটিতে রূপান্তর করেন কেবলমাত্র ASCII মান সমন্বিত বাইটের ক্রম "। কেবলমাত্র এসকিআইআই অক্ষর সমন্বিত বাইটের ক্রম এসএমটিপি দ্বারা প্রয়োজনীয় যা সেজন্য বেস 64 (এবং উদ্ধৃত-মুদ্রণযোগ্য) সামগ্রী-স্থানান্তর-এনকোডিং হিসাবে ব্যবহৃত হয়। দুর্দান্ত ওভারভিউ!
এএলএক্সিন্টলসোস

1
আমি ভোট দেব, তবে 64৪ টি ভোট রয়েছে। দুঃখিত এটি নিখুঁত।
জেসি ক্যাটরিংক

61

এক্সএমএলে বাইনারি ডেটা এনকোডিং

ধরুন আপনি কোনও এক্সএমএল ডকুমেন্টের মধ্যে কয়েকটি ছবি ইমেড করতে চান। চিত্রগুলি বাইনারি ডেটা, এবং এক্সএমএল ডকুমেন্টটি পাঠ্য। তবে এক্সএমএল এম্বেডড বাইনারি ডেটা পরিচালনা করতে পারে না। তাহলে তুমি কিভাবে এটা করেছ?

একটি বিকল্প হ'ল এক্স 64 হ্যান্ডেল করতে পারে এমন বাইনারি ডেটাটিকে পাঠ্যে রূপান্তরিত করে বেস 64৪ তে চিত্রগুলি এনকোড করা।

পরিবর্তে:

<images>
  <image name="Sally">{binary gibberish that breaks XML parsers}</image>
  <image name="Bobby">{binary gibberish that breaks XML parsers}</image>
</images>

তুমি কর:

<images>
  <image name="Sally" encoding="base64">j23894uaiAJSD3234kljasjkSD...</image>
  <image name="Bobby" encoding="base64">Ja3k23JKasil3452AsdfjlksKsasKD...</image>
</images>

এবং এক্সএমএল পার্সার সঠিকভাবে এক্সএমএল নথি পার্স করতে এবং চিত্রের ডেটা বের করতে সক্ষম হবে।


এটি মাইক্রোসফ্টের পুরানো .mhtফর্ম্যাট কীভাবে কাজ করে (একক ফাইলে এইচটিএমএল ফাইল + চিত্রগুলি)।
শ্রীধর সারনোবাত

38

বর্তমানে বেস 64 সংজ্ঞায়িত আরএফসির দিকে তাকাবেন না কেন ?

ডেটা বেজ এনকোডিং অনেক পরিস্থিতিতে
পরিবেশে ডেটা সংরক্ষণ বা স্থানান্তর করতে ব্যবহার করা হয় যা সম্ভবত উত্তরাধিকারগত কারণে ইউএস-এএসসিআইআই [1] ডেটাতে সীমাবদ্ধ ছিল B বেস এনকোডিং নতুন অ্যাপ্লিকেশনগুলিতেও ব্যবহার করা যেতে পারে যা উত্তরাধিকারের সীমাবদ্ধতা নেই, কেবল কারণ এটি পাঠ্য সম্পাদকগণের সাহায্যে অবজেক্টগুলি ম্যানিপুলেট করা সম্ভব করে।

অতীতে, বিভিন্ন অ্যাপ্লিকেশনগুলির বিভিন্ন প্রয়োজনীয়তা ছিল এবং এভাবে মাঝে মাঝে কিছুটা ভিন্ন উপায়ে বেস এনকোডিংগুলি প্রয়োগ করা হয়। আজ, প্রোটোকল স্পেসিফিকেশনগুলি কখনও কখনও সাধারণভাবে বেস এনকোডিংগুলি এবং বিশেষত "বেস64" ব্যবহার করে, কোনও নির্দিষ্ট বিবরণ বা রেফারেন্স ছাড়াই। মাল্টিপারপাস ইন্টারনেট মেল এক্সটেনশানস (এমআইএমআই) [৪] প্রায়শই লাইন-মোড়ানো বা বর্ণমালাবিহীন অক্ষরের পরিণতি বিবেচনা না করে বেস 64 এর রেফারেন্স হিসাবে ব্যবহৃত হয়। এই বর্ণনার উদ্দেশ্য সাধারণ বর্ণমালা এবং এনকোডিং বিবেচনা স্থাপন করা। এটি আশা করি অন্যান্য নথিতে অস্পষ্টতা হ্রাস করবে, যা আরও ভাল আন্তঃব্যবহারের দিকে পরিচালিত করবে।

বেস64 origin মূলত বহুমুখী ইন্টারনেট মেল এক্সটেনশনের অংশ হিসাবে বাইনারি ডেটা ইমেলগুলিতে সংযুক্ত করার মঞ্জুরি দেওয়ার উপায় হিসাবে তৈরি হয়েছিল।


26

পাঠ্যগত ডেটাগুলির জন্য তৈরি করা মিডিয়া অবশ্যই অবশেষে বাইনারি হয় তবে পাঠ্য মিডিয়া প্রায়শই নিয়ন্ত্রণের অক্ষরের জন্য কিছু বাইনারি মান ব্যবহার করে। এছাড়াও, পাঠ্য মিডিয়া নির্দিষ্ট কিছু বাইনারি মানকে নন-পাঠ্য হিসাবে প্রত্যাখ্যান করতে পারে।

বেস 64 এনকোডিংটি বাইনারি ডেটাগুলিকে মান হিসাবে এনকোড করে যা কেবল পাঠ্য মিডিয়াতে পাঠ্য হিসাবে ব্যাখ্যা করা যায় এবং কোনও বিশেষ অক্ষর এবং / বা নিয়ন্ত্রণ অক্ষর থেকে মুক্ত থাকে, যাতে ডেটা পাঠ্য মিডিয়া জুড়েও সংরক্ষণ করা যায়।


সুতরাং বেস 64 এর মত এটি, বেশিরভাগ উত্স এবং গন্তব্য উভয়ই ডেটা একইভাবে ব্যাখ্যা করবে কারণ সম্ভবত তারা এই 64 টি অক্ষরকে একইভাবে ব্যাখ্যা করবে, এমনকি যদি তারা নিয়ন্ত্রণের অক্ষরগুলি বিভিন্ন উপায়ে ব্যাখ্যা করে। এটা কি সঠিক?
Lazer

6
তারা ডেটা ট্রানজিট এমনকি ধ্বংস হতে পারে। উদাহরণস্বরূপ অনেক সার্ভার এবং ক্লায়েন্টের অপারেটিং সিস্টেমটি মেলে না এবং ট্রান্সফারটিকে টেক্সট মোড হিসাবে চিহ্নিত করা হয় তবে অনেকগুলি এফটিপি প্রোগ্রামগুলি 13,10 থেকে 10 পর্যন্ত বিপরীতে লাইন সমাপ্তি লিখন করে। এফটিপি হ'ল প্রথম উদাহরণ যা আমার মনে এসেছিল, এটি ভাল নয় কারণ এফটিপি বাইনারি মোড সমর্থন করে।
হেন্ডরিক ব্রুমারম্যান

@ এনএনএনবি: আমার মনে হয় এফটিপি একটি দুর্দান্ত উদাহরণ, যেহেতু এটি দেখায় যে বাইনারি ডেটা চায় এমন জিনিসগুলির জন্য পাঠ্য-মোড অনুপযুক্ত।
জেমসডলিন

একটি পাঠ্য মিডিয়া কি?
Koray Tugay

18

এটি আরও বেশি যে মিডিয়া স্ট্রিং এনকোডিংকে বৈধতা দেয়, তাই আমরা হ্যান্ডলিং অ্যাপ্লিকেশন দ্বারা ডেটা গ্রহণযোগ্য কিনা তা নিশ্চিত করতে চাই (এবং উদাহরণস্বরূপ ইওলকে উপস্থাপন করার ক্ষেত্রে বাইনারি ক্রম নেই)

কল করুন আপনি ইউটিএফ -8 এনকোডিং সহ কোনও ইমেলটিতে বাইনারি ডেটা প্রেরণ করতে চান - যদি ইউটিএফ -8 এনকোডিংয়ে ইউনিকোড বৈধ নয় এমন একটি ক্রম তৈরি করে তবে ইমেলটি সঠিকভাবে প্রদর্শিত হতে পারে না ।

একই ধরণের জিনিসটি ইউআরএলগুলিতে ঘটে যখন আমরা URL টি নিজেই কোনও URL এর জন্য বৈধ নয় এমন অক্ষরগুলি এনকোড করতে চাই:

http://www.foo.com/hello আমার বন্ধু -> http://www.foo.com/hello%20my%20 বান্ধবী

এটি কারণ আমরা এমন একটি সিস্টেমের উপরে একটি স্থান পাঠাতে চাই যা মনে করবে যে স্থানটি গন্ধযুক্ত।

আমরা যা করছি তা নিশ্চিত করেই বিটগুলির আরেকটি আক্ষরিক অনুক্রমের জন্য বিটগুলির জ্ঞাত, গ্রহণযোগ্য এবং অ-ক্ষতিকারক ক্রমগুলির মধ্যে 1-থেকে -1 ম্যাপিং রয়েছে এবং হ্যান্ডলিং অ্যাপ্লিকেশনটি এনকোডিংটিকে আলাদা করে না

আপনার উদাহরণে, manপ্রথম আকারে বৈধ এএসসিআইআই হতে পারে; তবে প্রায়শই আপনি এলোমেলো বাইনারি (যেমন ইমেলটিতে একটি চিত্র প্রেরণ) মান সঞ্চার করতে পারেন:

মাইম-সংস্করণ: 1.0
সামগ্রী-বিবরণ: "a.gif এর বেস 64 এনকোড"
বিষয়বস্তুর ধরণ: চিত্র / gif; নাম = "a.gif"
সামগ্রী-স্থানান্তর-এনকোডিং: বেস 64
সামগ্রী-বিভাজন: সংযুক্তি; ফাইলের নাম = "a.gif"

এখানে আমরা দেখতে পাচ্ছি যে একটি জিআইএফ চিত্রটি ইমেলটির একটি অংশ হিসাবে বেস 64 এ এনকোড করা থাকে। ইমেল ক্লায়েন্ট শিরোনাম পড়ে এবং এটি ডিকোড করে। এনকোডিংয়ের কারণে, আমরা নিশ্চিত হতে পারি যে জিআইএফ-তে প্রোটোকল হিসাবে ব্যাখ্যা করা যায় এমন কিছু নেই এবং আমরা এসএমটিপি বা পিওপি গুরুত্বপূর্ণ খুঁজে পেতে পারে এমন ডেটা inোকানো এড়াতে পারি।


1
এটি দুর্দান্ত। এই ব্যাখ্যাটি এটি ক্লিক করে। এটি ডেটা অবলম্বন বা সংকোচনের জন্য নয়, কেবল প্রোটোকল হিসাবে ব্যাখ্যা করা যায় এমন বিশেষ ক্রমগুলি ব্যবহার এড়াতে।
প্যাট্রিক মাইকেলসেন

13

বেস 64 এর পরিবর্তে বিশেষ অক্ষরগুলি পালানোর পরিবর্তে

আমি আপনাকে একটি খুব আলাদা কিন্তু বাস্তব উদাহরণ দেব: আমি ব্রাউজারে চালানোর জন্য জাভাস্ক্রিপ্ট কোডটি লিখি। এইচটিএমএল ট্যাগগুলির আইডি মান রয়েছে তবে কোনও আইডিতে অক্ষরগুলি বৈধ কিনা তা নিয়ে বাধা রয়েছে।

তবে আমি চাই আমার আইডিটি নিখরচায়ভাবে আমার ফাইল সিস্টেমের ফাইলগুলিতে উল্লেখ করা হোক। বাস্তবে ফাইলগুলির মধ্যে বিস্ময়কর চিহ্ন, উচ্চারণযুক্ত অক্ষর, টিলডে, এমনকি ইমোজি থেকে সমস্ত ধরণের অদ্ভুত এবং দুর্দান্ত চরিত্র থাকতে পারে! আমি এটা করতে পারব না:

<div id="/path/to/my_strangely_named_file!@().jpg">
    <img src="http://myserver.com/path/to/my_strangely_named_file!@().jpg">
    Here's a pic I took in Moscow.
</div>

ধরুন আমি এর মতো কিছু কোড চালাতে চাই:

# ERROR
document.getElementById("/path/to/my_strangely_named_file!@().jpg");

আমি মনে করি কার্যকর করা হলে এই কোডটি ব্যর্থ হবে।

বেস 64 এর সাহায্যে কোন ভাষা কোন বিশেষ অক্ষরগুলিকে অনুমতি দেয় এবং কোনটি পালানোর দরকার তা ভেবে উদ্বেগ ছাড়াই জটিল কিছু উল্লেখ করতে পারি:

document.getElementById("18GerPD8fY4iTbNpC9hHNXNHyrDMampPLA");

এমডি 5 বা অন্য কোনও হ্যাশিং ফাংশন ব্যবহার করার মতো নয়, ডেটা আসলে কী দরকারী তা আবিষ্কার করার জন্য আপনি এনকোডিংটি বিপরীত করতে পারেন।

আমি আশা করি আমি বেস 64 সম্পর্কে আগে জানতাম। আমি ' encodeURIComponent' এবং দিয়ে আমার চুল ছিঁড়ে এড়ানো উচিত হতstr.replace(‘\n’,’\\n’)

পাঠ্যের এসএসএইচ স্থানান্তর:

যদি আপনি ssh এর উপর জটিল ডেটা পাস করার চেষ্টা করছেন (উদাহরণস্বরূপ একটি ডটফাইল যাতে আপনি নিজের শেল ব্যক্তিগতকরণ পেতে পারেন), বেস 64 না করে এটি করা ভাল ভাগ্য base৪ বেসের সাহায্যে আপনি এটি করবেন (আমি জানি আপনি এসসিপি ব্যবহার করতে পারেন, তবে এটি একাধিক কমান্ড গ্রহণ করতে পারে - যা সার্ভারে ছাঁটাইয়ের জন্য মূল বাইন্ডিংগুলিকে জটিল করে তোলে:


12

এক্সএমএলে বাইনারি ডেটা এম্বেড করার চেষ্টা করার সময় যখন আমি এটি সুবিধাজনক পেয়েছি তার একটি উদাহরণ । স্যাক্স পার্সার দ্বারা বাইনারি কিছু ডেটা ভুল ব্যাখ্যা করা হচ্ছিল কারণ এটি ডেটা এক্সএমএল বিশেষ অক্ষর সহ আক্ষরিক কিছু হতে পারে। বেস 64 প্রেরণকারী প্রান্তে ডেটা এনকোডিং এবং প্রাপ্তির শেষে এটিকে ডিকোডিং করা সমস্যার সমাধান করে।


1
+1 - তবে এটি কোনওভাবেই স্যাক্স নির্দিষ্ট নয়। এটি যে কোনও এক্সএমএল পার্সার, অর্থাৎ ডিওএম বা এক্সলিংক-এর ক্ষেত্রে ঘটবে।
বিলি ওনিল

1
@ বিলি: হ্যাঁ, একেবারে। আমি কেবলমাত্র সেই অ্যাপ্লিকেশনটির জন্য একটি স্যাক্স পার্সার ব্যবহার করার কথা বলেছি।
বিল

বিভিন্ন ইঞ্জিন, উদাহরণস্বরূপ SAX পার্সার কিছু ASCII মানকে বিভিন্ন উপায়ে (বিভিন্ন নিয়ন্ত্রণের অক্ষর) ব্যাখ্যা করতে পারে। সুতরাং, এখানে ধারণাটি হ'ল ASCII এর সাবসেটটি ব্যবহার করা যা সর্বজনীনভাবে সাধারণ অর্থ রয়েছে। রাইট?
Lazer

1
@ লেজার: ঠিক আছে। যখন আপনি এএসসিআইআই (যা এই ক্ষেত্রে এটি ছিল না) হিসাবে এটি ব্যাখ্যা করার চেষ্টা করবেন তখন বিন্যাসবিহীন বাইনারি ডেটাতে সুযোগের সাথে নিয়ন্ত্রণের অক্ষর থাকবে।
বিল

10

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


3
7 বিটের পরে স্ট্রিম বিঘ্নিত হলে এটি কেন সমস্যা? শেষে, অন্য মেশিনটির স্ট্রিমের মধ্যে প্রাপ্ত সমস্ত ডেটা থাকবে, এটি এরপরে এটি প্রদর্শনের জন্য 8 টি বিট ফর্ম্যাট চয়ন করতে পারে? আমার মনে কি দোষ!
মল্লাউদ্দিন

6

অন্যান্য (কিছুটা দীর্ঘ) উত্তর ছাড়াও: এমনকি 7-বিট ASCII সমর্থন করে এমন পুরানো সিস্টেমগুলি উপেক্ষা করেও, পাঠ্য-মোডে বাইনারি ডেটা সরবরাহ করার ক্ষেত্রে প্রাথমিক সমস্যাগুলি হ'ল:

  • নিউলাইনগুলি সাধারণত পাঠ্য-মোডে রূপান্তরিত হয়।
  • পাঠ্য স্ট্রিংয়ের সমাপ্তি হিসাবে কোনও এনওএল বাইটকে চিকিত্সা না করা সম্পর্কে সতর্ক থাকতে হবে, যা সি বংশের সাথে কোনও প্রোগ্রামে করা খুব সহজ।

Control C, ^ D, এবং ^ Z এর মতো নিয়ন্ত্রণের অক্ষরও রয়েছে যা কিছু প্ল্যাটফর্মগুলিতে ফাইলের শেষে ফাইল হিসাবে ব্যাখ্যা করা হয়।
dan04

5

এর অর্থ কী "" মিডিয়াগুলি পাঠ্য সংক্রান্ত ডেটা নিয়ে কাজ করার জন্য ডিজাইন করা হয়েছে "?

এই প্রোটোকলগুলি বাইনারি ডেটার (যেমন .png এবং .jpg চিত্রগুলির) পরিবর্তে পাঠ্য (প্রায়শই কেবলমাত্র ইংরেজী পাঠ্য) হ্যান্ডেল করার জন্য তৈরি করা হয়েছিল ।

তারা বাইনারি সাথে ডিল করতে পারে => তারা যে কোনও কিছুতে ডিল করতে পারে।

তবে কনভার্সটি সত্য নয়। পাঠ্য উপস্থাপনের জন্য ডিজাইন করা একটি প্রোটোকল বাইনারি ডেটাগুলিকে ভুলভাবে চিকিত্সা করতে পারে যা এতে ঘটে:

  • লাইন শেষের জন্য ব্যবহৃত বাইট 0x0A এবং 0x0D, যা প্ল্যাটফর্মের দ্বারা পৃথক হয়।
  • অন্যান্য নিয়ন্ত্রণের অক্ষর যেমন 0x00 (NULL = C স্ট্রিং টার্মিনেটর), 0x03 (পাঠ্যের সমাপ্তি), 0x04 (ট্রান্সমিশনের সমাপ্তি), বা 0x1A (ফাইলের ডস-এন্ড-অফ ফাইল) যা অকাল সময়ের আগে ডেটার সমাপ্তির সংকেত দিতে পারে।
  • 0x7F এর উপরে বাইটস (যদি প্রোটোকল যা ASCII এর জন্য ডিজাইন করা হয়েছিল)।
  • বাইট সিকোয়েন্সগুলি যা অবৈধ ইউটিএফ -8।

সুতরাং আপনি কেবল একটি পাঠ্য-ভিত্তিক প্রোটোকলের মাধ্যমে বাইনারি ডেটা প্রেরণ করতে পারবেন না। আপনি অবকাশহীন অ-নিয়ন্ত্রণ ASCII অক্ষরগুলির প্রতিনিধিত্বকারী বাইটগুলির মধ্যে সীমাবদ্ধ রয়েছেন যার মধ্যে 94 রয়েছে Base ।

যদিও একটি প্রশ্ন। কীভাবে সিস্টেমগুলি এখনও এত সাধারণ ইউটিএফ -8 এর মতো একটি সাধারণ এনকোডিং কৌশলটিতে একমত হয় না?

ওয়েবে, কমপক্ষে, তাদের বেশিরভাগই থাকে। বেশিরভাগ সাইট ইউটিএফ -8 ব্যবহার করে

পশ্চিমে সমস্যাটি হ'ল প্রচুর পুরানো সফটওয়্যার রয়েছে যা গায়ে-উ-মে-এস যে 1 বাইট = 1 অক্ষর এবং ইউটিএফ -8 এর সাথে কাজ করতে পারে না।

পূর্বের সমস্যাটি তাদের জিবি 2312 এবং শিফট_জেআইএসের মতো এনকোডিংগুলির সাথে সংযুক্তি।

মাইক্রোসফ্ট মনে হয় যে এখনও ইউটিএফের ভুল এনকোডিংটি বেছে নিয়েছে। আপনি যদি উইন্ডোজ এপিআই বা মাইক্রোসফ্ট সি রানটাইম লাইব্রেরিটি ব্যবহার করতে চান তবে আপনি ইউটিএফ -16 বা লোকেলের "এএনএসআই" এনকোডিংয়ের মধ্যে সীমাবদ্ধ। এটি ইউটিএফ -8 ব্যবহার করা কষ্টদায়ক করে তোলে কারণ আপনাকে সর্বদা রূপান্তর করতে হবে।


5

কেন / আমরা বেস 64 এনকোডিংটি ব্যবহার করব?

বেস 64-এর মধ্যে বাইনারি-টু-টেক্সট এনকোডিং স্কিমের মধ্যে 75% দক্ষতা রয়েছে। এটি ব্যবহার করা হয় যাতে সাধারণ বাইনারি ডেটা (যেমন চিত্রগুলি) সুরক্ষিতভাবে "8-বিট পরিষ্কার নয়" চ্যানেলগুলির মাধ্যমে প্রেরণ করা যেতে পারে। পূর্ববর্তী ইমেল নেটওয়ার্কগুলিতে (1990-এর দশক পর্যন্ত), বেশিরভাগ ইমেল বার্তাগুলি 7-বিট ইউএস-এএসসিআইআই অক্ষর সেটটিতে সরল পাঠ্য ছিল। অনেক প্রাথমিক কম প্রোটোকল মান "7-বিট" কম লিঙ্কগুলি "8-বিট পরিষ্কার নয়" এর উপর কাজ করার জন্য ডিজাইন করা হয়েছিল were স্কিম দক্ষতা ইনপুটগুলিতে বিটের সংখ্যা এবং এনকোডড আউটপুটটিতে বিটের সংখ্যার মধ্যে অনুপাত। হেক্সাডেসিমাল (বেস 16) 50% দক্ষতার সাথে বাইনারি-থেকে-পাঠ্য এনকোডিং স্কিমগুলির মধ্যে একটি।

বেস 64 এনকোডিং পদক্ষেপ (সরলীকৃত):

  1. বাইনারি ডেটা প্রতিটি 24 বিট (3 বাইট) এর অবিচ্ছিন্ন অংশে সাজানো হয়।
  2. প্রতিটি 24 বিট খণ্ডকে প্রতিটি 6 টি বিটের চার ভাগে ভাগ করা হয়।
  3. প্রতিটি 6 বিট গ্রুপ তাদের সংশ্লিষ্ট বেস 64 অক্ষরের মানগুলিতে রূপান্তরিত হয়, যেমন বেস 64 এনকোডিংটি তিনটি অক্টেটকে চারটি এনকোডড অক্ষরে রূপান্তর করে। ইনপুট বাইটের আউটপুট বাইটের অনুপাত 4: 3 (33% ওভারহেড)।
  4. মজার বিষয় হল, তিনটি-অক্টেট গ্রুপের মধ্যে তাদের অবস্থানের উপর নির্ভর করে একই অক্ষরগুলি আলাদাভাবে এনকোড করা হবে যা চারটি অক্ষর তৈরি করতে এনকোড করা হয়েছে।
  5. আসল বার্তাটি পুনরুদ্ধার করতে রিসিভারকে এই প্রক্রিয়াটি বিপরীত করতে হবে।

3

এর অর্থ কী "" মিডিয়াগুলি পাঠ্য সংক্রান্ত ডেটা নিয়ে কাজ করার জন্য ডিজাইন করা হয়েছে "?

সেদিন ফিরে যখন ASCII বিশ্বকে শাসন করত যে অ-এএসসিআইআই মূল্যবোধগুলি নিয়ে কাজ করছিল তা মাথা ব্যথার কারণ ছিল। তথ্য হারাতে না পেরে এগুলি তারের উপর দিয়ে স্থানান্তরিত করতে লোকেরা বিভিন্ন ধরণের হুপের মধ্য দিয়ে ঝাঁপিয়ে পড়ে।


3
আসলে, আগের দিন, এএসসিআইআই এমনকি সর্বত্র ব্যবহৃত হয়নি। অনেকগুলি প্রোটোকলের ডেটা স্থানান্তর করার জন্য একটি পৃথক পাঠ্য-মোড এবং বাইনারি-মোড ছিল, দুর্ভাগ্যক্রমে ইমেলটি তখন ফিরে আসে নি। পাঠ্য-মোডটি অবশ্যই স্পষ্টভাবে প্রয়োজনীয় কারণ কোনও একক পাঠ্য এনকোডিং বিশ্বকে শাসন করে না, ASCII নয়; প্রতিটি কম্পিউটার নেটওয়ার্কের নিজস্ব পছন্দসই এনকোডিং রয়েছে, সুতরাং এমন গেটওয়ে রয়েছে যাদের কাজ হচ্ছে এক্সচেঞ্জ করা টেক্সটকে স্থানীয় এনকোডিংয়ে রূপান্তর করা যাতে কোনও জাপানি সংস্থা মোজিবাকে ছাড়াই আমেরিকান ব্যবসায় পরামর্শদাতাকে ইমেল প্রেরণ করতে পারে। বাইনারি ডেটা প্রেরণ করার সময় এই রূপান্তরটি স্পষ্টতই অনাকাঙ্ক্ষিত।
মিথ্যা রায়ান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.