আমার ইমেলটির আকার এর সংযুক্ত ফাইলের আকারের চেয়ে তৃতীয়াংশ বড় কেন?

Question

আমার ইমেলগুলিতে ডেটা সংযুক্ত করার সময়, আমি লক্ষ্য করেছি যে থান্ডারবার্ড আমার সংযুক্ত ফাইলগুলির চেয়ে ফলাফলের ইমেলের মোট আকার গণনা করে।

এখানে একটি সাম্প্রতিক উদাহরণ রয়েছে: দুটি চিত্র, একটি 13MB এ এবং একটিতে 3.6MB মোট মোটামুটি 17MB হওয়া উচিত। পাঠ্য চারটি লাইন ছিল। থান্ডারবার্ড তখন আমাকে জিজ্ঞাসা করেছিল যে আমি সত্যিই মোট ২২ এমবি আকারের ইমেল পাঠাতে চাইছি কিনা।

এই পার্থক্যটি কোথা থেকে আসছে? 5MB পাঠ্য কিছুটা মনে হচ্ছে।

Comments

নোট করুন যে এটি প্রায়শই সর্বোচ্চ আকারের মতো জিনিসগুলিকে প্রভাবিত করে। যদি আমি ভুল না হয়ে থাকি তবে গুগল মেলটি সাধারণত সর্বাধিক 25MB এর ইমেলের অনুমতি দেয় তবে 25MB এনকোডিংয়ের পরে গণনা করা হয় , সুতরাং আপনি কোনও ইমেল সহ একটি 25 এমবি চিত্র পাঠাতে পারবেন না, কারণ এনকোড করা থাকলে এটি আসলে খুব বড়।

— বাকুরিউ

@ বাকুরির মন্তব্য আউটলুক + এক্সচেঞ্জ সার্ভারেও প্রযোজ্য। আমি প্রস্তাব দিচ্ছি যে অন্তর্নিহিত প্রশ্নটি আসলে মেল ক্লায়েন্টগুলি (প্রায়শই - টিবার্ড আবার দৃষ্টিভঙ্গির চেয়ে ভাল বলে মনে হয়) যখন বেস 64-এনকোড আকারের বিষয়টি গুরুত্বপূর্ণ তখন কেবল স্থানীয় ফাইলের আকারের প্রতিবেদন করবে কেন?

— ক্রিস এইচ

@ মার্কস থমাস কেবলমাত্র সমস্ত জ্ঞান সহজেই সন্ধানযোগ্য থাকার বিপরীতে সহজেই সন্ধানযোগ্য জ্ঞানের উত্স থাকার আবেদন করার বিরুদ্ধে আমি তর্ক করতে চাই না। তবে এটা কি দরকার? আমি তাই মনে করি না. - আমি মনে করি না যে প্রশ্নটি মোটেই কার্যকর নয়, আমি কেবলমাত্র এটি মনে করি যে এটি সাইটকে অপ্রয়োজনীয় প্রশ্ন থেকে মুক্ত রাখার মৌলিক প্রয়োজনীয়তা পূরণ করে না এবং সত্যিকারের গুরুত্বপূর্ণ জিনিসগুলি খুঁজে পাওয়া আরও শক্ত করে তোলে, এটি নয় অন্য কোথাও উত্তর। আমাদের কি করা উচিত! - অর্ক_লুপাস, যেমন আমি কেবল এই সাইটে লুকিয়ে থাকি, সাধারণত, আমার ডাউনভোটটি এখনও কাটছে না। তবে যেমন রয়েছে তেমনি দাঁড়িয়ে আছে।

— আলেকজান্ডার কোসুবেেক

সম্পর্কিত: superuser.com/questions/568506/…

— glenneroo

Answer 1

আপনার ডেটা 17 মাইবি ছিল। একটি এমআইবিতে 1024 কিবি রয়েছে। একটি কিবিতে 1024 বি রয়েছে। একটি বাইটে 8 টি বিট রয়েছে। সুতরাং এটি 142,606,336 বিট।

বেস 64 এনকোডিং পৃথক বাইট হিসাবে প্রতি ছয় বিট এনকোডিং। সুতরাং আমাদের প্রায় 23,767,722 বাইট দরকার। 1024 দ্বিগুণ দ্বারা ভাগ করা আমাদের 22.67 মাইবি পায়। 22 মাইবিটি এখান থেকেই আসে।

ইমেল একটি দুর্দান্ত পুরানো প্রযুক্তি এবং একটি 8-বিট পরিষ্কার পাইপ ধরে না।

Comments

শেষ লাইনটিকে কিছুটা ডিকোড করার জন্য: বেস-64৪ হল "গ্যারান্টিযুক্ত নিরাপদ অক্ষরের" সীমাবদ্ধ সেট ব্যবহার করে টেক্সট হিসাবে সংযুক্তিগুলি এনকোড করার একটি উপায় যা এজে, এজেড, ০-৯

— ইয়োরিক

এবং, আপনি একবার ডেভিডের দুর্দান্ত উত্তরের গণিতটি বুঝতে পারলে, আপনাকে যে মেল বার্তা প্রেরণ করা হবে তার আকার পেতে (সংযুক্তি প্রকৃত পাঠ্য) কেবলমাত্র সংযুক্তিগুলির আকার 4/3 দিয়ে গুণ করতে পারেন plus

— কেন্ট

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

— লরেইন পেচটেল ২16

@ লরেনপেকটেল আপনি মাইম বার্তায় আনন্দের সাথে একটি অ্যাপ্লিকেশন / অক্টেট-স্ট্রিম অংশ রাখতে পারেন। আপনাকে যা করতে হবে তা হ'ল একটি বাউন্ডারি নির্বাচন করা যা ডেটাতে ঘটে না।

— অরেঞ্জডগ

বেস 64 আসলে কি করে, প্রতি 3 আসল বাইটের জন্য 4 বাইট ব্যবহার করছে। যদিও এটি একইরকম মনে হচ্ছে, এটি গুরুত্বপূর্ণ কারণ দৈর্ঘ্যটি সর্বদা 4 এর একাধিক এবং বিট স্তরের কোনও কারণ নেই বলেও।

— njzk2

Answer 2

ইমেলটি বড় কেন?

কারণ ডেটা এনকোড করা হয়েছে base64যাতে চারটি মুদ্রণযোগ্য এএসসিআইআই অক্ষরের গোষ্ঠী হিসাবে তিনটি বাইট পর্যন্ত গ্রুপকে এনকোড করে। সাধারণত, মুদ্রণযোগ্য অক্ষরের এই গোষ্ঠীগুলি তখন লাইনে বিভক্ত হয়।

ফলাফলটি হ'ল এনকোডড ডেটা মূল ডেটার আকারের চেয়ে 1⅓ গুণ বেশি।

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

ইমেলের একটি দীর্ঘ ইতিহাস রয়েছে এবং এটি মূলত পাঠ্য বহন করার জন্য তৈরি করা হয়েছিল। কেবলমাত্র ASCII মুদ্রণযোগ্য অক্ষরের প্রতিনিধিত্বকারী বাইট মানগুলি নির্ভরযোগ্যভাবে গ্রহের বিভিন্ন ইমেল সিস্টেমের মধ্য দিয়ে যেতে পারে।

সুতরাং মাইম ASCII পাঠ্য হিসাবে অন্যান্য ডেটা এনকোড করার জন্য দুটি স্কিম বিভক্ত করেছে - বেশ কয়েকটি অন্যান্য বিটের সাহায্যে বেশিরভাগ ASCII পাঠ্যের জন্য ডিজাইন করা "কোটেড-প্রিন্টেবল" এবং স্বেচ্ছাসেবী বাইনারি ডেটার জন্য "BASE64"।

এসএমটিপি প্রোটোকলটিতে এই বিধিনিষেধগুলি চেষ্টা করার এবং অপসারণের জন্য এক্সটেনশান হয়েছে। প্রথমত, ১৯৯৪ সালে 8 বিটমাইম, যা উচ্চতর অক্টেট মানগুলিকে অনুমতি দেয় তবে দুর্ভাগ্যক্রমে লাইন দৈর্ঘ্য এবং লাইন সমাপ্তির সাথে সীমাবদ্ধতা সরিয়ে দেয় না, তাই স্বেচ্ছাচারী বাইনারি ডেটার জন্য উপযুক্ত ছিল না; এবং তারপরে ১৯৯৯ সালে বিন্যারিমেম, যা স্বেচ্ছাসেবী বাইনারি ডেটাযুক্ত বার্তাগুলি স্থানান্তর করার অনুমতি দেয়।

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

Comments

আমি ভাবছি অন্যদিকে, ইয়েনক কেন ইউইউইউ স্থানান্তরিত করতে ইউসনেটে বেশ সফল হয়েছিল। সম্ভবত বাইনারি নিউজগ্রুপগুলি মাঝে মধ্যে বাইনারি ইমেলের চেয়ে আইএসপিগুলিতে অনেক বেশি চাপ ফেলেছে বলে?

— igorsk

@ আইগর্স্ক: প্লাস ইউজনেট / এনএন উপস্থাপিত এবং ক্ষতির হিসাবে বোঝা গেছে, যেখানে আপনি একটি নিবন্ধ প্রকাশ করতে পারেন এবং সমস্ত সার্ভারে থাকা সমস্ত গ্রাহকরা এটি প্রয়োজনীয়ভাবে গ্রহণ করবে না। পূর্ববর্তী নিবন্ধ (গুলি) এর 'পর্যাপ্ত' ফলোআপে উদ্ধৃতি দেওয়ার বিষয়ে (এবং বেশিরভাগ অবশেষে) রীতিনীতি ছিল যে আপনার ফলোআপটি এমন কোনও ব্যক্তির দ্বারা বুঝতে পারে যে পূর্ববর্তী নিবন্ধ (গুলি) পায়নি । বিপরীতে বেশিরভাগ (ননস্প্যামার) ইমেল প্রেরকরা প্রত্যাশা করেছিলেন যে 'সিস্টেম' নামক প্রাপককে তাদের বার্তাটি পাবেন, যদিও মাঝে মাঝে কয়েক ঘন্টা বা দিনের পরে থাকে; আজ লোকেরা এমনকি স্বল্প বিলম্বের বিষয়েও অভিযোগ করে।

— dave_thompson_085