এই সম্পর্কে একটি ভাল উইকিপিডিয়া নিবন্ধ আছে।
এআরপিএনেটের হিসাবে এনসিপির প্রথম দিকের পুনরাবৃত্তিগুলি বাইট স্ট্রিমের চেয়ে বিট স্ট্রিমের মতো বা সুবিধাজনক বাইট আকারের জন্য আলোচনার চেষ্টা ছিল; 8-বিট বাইট কেবলমাত্র পরে মানক করা হয়েছিল। ফাইল ট্রান্সফার প্রোটোকল তৈরি করার বিভিন্ন প্রচেষ্টা ছিল যা বিভিন্ন মেশিনে কাজ করবে (মেল প্রাথমিকভাবে এফটিপি প্রোটোকলের একটি ফাংশন ছিল, প্রাথমিকভাবে MAILএবংMLFL কমান্ড হিসাবে , তারপরে এমটিপি , পরে এসএমটিপিতে বিভক্ত ।) এই মেশিনগুলিতে প্রায়শই পৃথক পৃথক চরিত্রের এনকোডিং থাকে - ASCII বনাম EBCDIC - বা এমনকি বিভিন্ন বাইট আকার , 8-বিট বাইট বনাম 6-বিট বনাম ...
অতএব, মেল স্থানান্তর ফাংশনগুলি প্রাথমিকভাবে সরল পাঠ্যে অপেক্ষাকৃত সংক্ষিপ্ত বার্তা স্থানান্তর করার জন্য সংজ্ঞায়িত করা হয়েছিল; বিশেষত, "এনভিটি-এএসসিআইআই"। উদাহরণস্বরূপ, আরএফসি 772 বলেছেন:
মেল প্রতিনিধিত্ব এবং সঞ্চয়
মেল প্রেরণ হোস্টের স্টোরেজ ডিভাইস থেকে গ্রহণ হোস্টের স্টোরেজ ডিভাইসে স্থানান্তরিত হয়। মেলটিতে কিছু নির্দিষ্ট রূপান্তর করা প্রয়োজন হতে পারে কারণ দুটি সিস্টেমে ডেটা স্টোরেজ উপস্থাপনা আলাদা। উদাহরণস্বরূপ, এনভিটি-এএসসিআইআইয়ের বিভিন্ন সিস্টেমে ডেটা সঞ্চয় করার বিভিন্ন উপস্থাপনা রয়েছে। PDP-10 এর সাধারণভাবে NVT-ASCII কে পাঁচটি 7-বিট ASCII অক্ষর হিসাবে সংরক্ষণ করে, 36-বিট শব্দে বাম-ন্যায়সঙ্গত। ৩'s-বিট শব্দে চারটি 8-বিট ইবিসিডিআইসি কোড হিসাবে 360 এর স্টোর এনভিটি-এএসসিআইআই। মাল্টিক্সগুলি NVT-ASCII কে একটি 36-বিট শব্দের মধ্যে চারটি 9-বিট অক্ষর হিসাবে সঞ্চয় করে।
সরলতার স্বার্থে, সমস্ত ডেটা এমটিপিতে এনভিটি-এএসসিআইআই হিসাবে উপস্থাপন করতে হবে। এর অর্থ হ'ল প্রেরণ ও গ্রহণযোগ্য হোস্টগুলি পৃথক কিনা তা বিবেচনা না করে পাঠ্য প্রেরণ করার সময় অক্ষরগুলিকে মানক এনভিটি-এএসসিআইআই উপস্থাপনায় রূপান্তর করতে হবে। প্রেরক তার অভ্যন্তরীণ চরিত্র উপস্থাপনা থেকে ডেটাটিকে স্ট্যান্ডার্ড 8-বিট এনভিটি-এএসসিআইআই উপস্থাপনায় রূপান্তর করে (টেলনেট স্পেসিফিকেশন দেখুন)। গ্রহীতা স্ট্যান্ডার্ড ফর্ম থেকে ডেটাটিকে তার নিজস্ব অভ্যন্তরীণ ফর্মে রূপান্তর করে। এই মান অনুসারে, অনুক্রমটি পাঠ্যের একটি লাইনের শেষ বোঝাতে ব্যবহার করা উচিত।
আটটি বিট তারের উপর দিয়ে সঞ্চারিত হলেও, 8 তম বিটটি প্রায়শই ফেলে দেওয়া বা ম্যাঙ্গাল হয়ে যেত, কারণ এটি সংরক্ষণের কোনও প্রয়োজন ছিল না; আসলে, কিছু প্রোটোকল প্রয়োজনীয় 8th বিট যেমন প্রাথমিক হিসাবে শূন্যতে সেট করতে হবে, SMTP এর জন্য RFC নীচে উদ্ধৃত। অন্য কথায়, সফ্টওয়্যারটি 8-বিট পরিষ্কার ছিল না ।
তথ্য স্থানান্তর
টিসিপি সংযোগটি 8-বিট বাইটের সংক্রমণকে সমর্থন করে। এসএমটিপি ডেটা 7 বিট এএসসিআইআই অক্ষর। প্রতিটি অক্ষর একটি 8-বিট বাইট হিসাবে সঞ্চারিত হয় উচ্চ-অর্ডার বিট শূন্যে সাফ হয়ে।
8-বিট আইএসও -8859- # চরিত্রের এনকোডিংগুলি ব্যাপক আকার ধারণ করার পরেও এটি দীর্ঘকাল স্থায়ী ছিল। যদিও কিছু সার্ভার ইতিমধ্যে 8-বিট পরিষ্কার ছিল, অন্য অনেকগুলি ছিল না, এবং অন্ধভাবে 8 বিট ডেটা প্রেরণের ফলে ম্যাঙ্গেল বার্তাগুলির ফল ঘটতে পারে।
পরে, "বর্ধিত এসএমটিপি" প্রকাশিত হয়েছিল, মেল সার্ভারগুলিকে তারা সমর্থিত এসএমটিপি এক্সটেনশনগুলি ঘোষণা করার অনুমতি দেয়; এর মধ্যে একটি হ'ল 8BITMIMEএটি ইঙ্গিত করে যে গ্রহণকারী সার্ভারটি নিরাপদে 8-বিট ডেটা গ্রহণ করতে পারে। মাইম মেসেজের অংশগুলিতে " বিষয়বস্তু স্থানান্তর-এনকোডিং : 8 বিট" থাকতে পারে, তা বোঝায় যে এগুলি কোনওভাবেই এনকোড করা হয়নি।
যাইহোক, এসএমটিপি প্রোটোকল লাইন-ভিত্তিক রয়ে গেছে এবং এর মধ্যে 998 অক্টেট লাইন সীমা রয়েছে, পাশাপাশি একটি .বার্তা "0D 0A 2E 0D 0A)" বার্তার শেষ "সূচক হিসাবে ব্যবহার করা হচ্ছে। এর অর্থ হ'ল যদিও বেশিরভাগ বাইনারি ফাইলগুলি আনল্যাটার্টে প্রেরণ করা যায়, তবুও এটি সম্ভব যে এই অকটেট সিকোয়েন্সযুক্ত ফাইলগুলি স্থানান্তরিত বার্তার শেষে এবং বাকী ফাইলটি একটি এসএমটিপি কমান্ড হিসাবে ব্যাখ্যা করা হবে, সম্ভবত ক্ষতি হতে পারে। একইভাবে, 998 অক্টেটের চেয়ে দীর্ঘ একটি "লাইন" গ্রাহক সার্ভারের মাধ্যমে কেটে যেতে পারে।
2000 সালে, "BINARYMIME" ESMTP এক্সটেনশনটি আরএফসি 3030 হিসাবে প্রকাশিত হয়েছিল , এসএমটিপি-র মাধ্যমে কাঁচা বাইনারি ডেটা স্থানান্তর করার অনুমতি দেয়। বার্তাটি এখন পূর্ব-নির্দেশিত দৈর্ঘ্যের অংশগুলিতে স্থানান্তরিত হয়, শূন্য-দৈর্ঘ্যের অংশটি টার্মিনেটর হিসাবে ব্যবহৃত হয় এবং বেস 64 এবং অনুরূপ এনকোডিংগুলির আর প্রয়োজন হয় না। দুর্ভাগ্যক্রমে, কয়েকটি এসএমটিপি সার্ভার এই এক্সটেনশানটিকে সমর্থন করে; উদাহরণস্বরূপ, পোস্টএফিক্স বা এক্সিম 4 এএইচএলওর CHUNKINGউত্তরে বিজ্ঞাপন দেয় না। BINARYMIME এর সুবিধা নেওয়ার জন্য, এটি বার্তার পথে সমস্ত সার্ভার দ্বারা সমর্থিত হতে হবে , যা কেবল এক বা দু'জনের চেয়ে বেশি হতে পারে।
আরো দেখুন: