راهنمای فنی
چرا Base64 پروندهها را بزرگتر میکند؟
Base64 معمولاً دادهٔ دودویی را حدود یکسوم بزرگتر میکند. ساختار 3 بایت به 4 نویسه، پدینگ، هزینهٔ اضافهٔ Data URL و زمانی که آن اندازه میارزد را ببینید.
Base64 معمولاً دادهٔ دودویی را حدود یکسوم بزرگتر میکند چون هر 3 بایت دادهٔ دودویی را با 4 نویسهٔ قابل چاپ Base64 نشان میدهد.
اگر طول ورودی مضرب دقیق 3 نباشد، Base64 استاندارد با پدینگ ممکن است نویسهٔ = بیفزاید. طول کدشده 4 × ceil(n / 3) است، که n طول بایت اصلی است.
«حدود 33%» ورودی بزرگ را توصیف میکند. ورودی خیلی کوچک بهخاطر پدینگ ممکن است درصد بسیار بزرگتری به نظر برسد. Base64 فشردهسازی نیست. برای کدگذاری در برابر رمزنگاری، [Base64 رمزنگاری نیست: واقعاً چه میکند و چگونه رمزگشایی میشود](/fa/story/base64-is-not-encryption) را ببینید.
این مقاله توضیح میدهد چرا خروجی Base64 از بایت اصلی بزرگتر است. راهنمای امنیت نیست. اگر کدگذاری در برابر رمزنگاری میخواهید، Base64 رمزنگاری نیست: واقعاً چه میکند و چگونه رمزگشایی میشود را به کار ببرید.
چرا Base64 فضای بیشتری میخواهد؟
3 بایت برابر 24 بیت است. Base64 آن 24 بیت را به 4 گروه 6 بیتی میشکافد. هر گروه به یک نویسهٔ Base64 نگاشته میشود، پس 3 بایت ورودی 4 نویسهٔ خروجی میشود. با ذخیره بهصورت 1 بایت برای هر نویسهٔ ASCII، آن 4 / 3 ≈ 1.333 است — افزایشی حدود 33.3%.
- 3 بایت (24 بیت)
- شکافتن به 4 گروه 6 بیتی
- هر گروه → یک نویسهٔ Base64
- 4 نویسه (اغلب 4 بایت متن)
نمونهای ساده و قابل بررسی
این کدگذاریها با Base64 استاندارد با پدینگ مطابقت دارند.
Man
Man
Base64
TWFu
Man برابر 3 بایت UTF-8/ASCII است. TWFu برابر 4 نویسه است: 3 → 4.
Hello
Hello
Base64
SGVsbG8=
Hello برابر 5 بایت است. SGVsbG8= برابر 8 نویسه است، شامل یک =. روی دادهٔ کوچک، پدینگ درصد را بزرگتر از 33% نشان میدهد.
اندازهٔ Base64 را چگونه حساب میکنید؟
برای Base64 استاندارد با پدینگ، encodedLength = 4 × ceil(originalBytes / 3).
| بایت اصلی | نویسهٔ Base64 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1 یا 2 بایت همچنان 4 نویسه میسازند. از فرمول استفاده کنید، نه 33% ثابت.
پدینگ «=» یعنی چه؟
علامت = نشان میدهد آخرین بلوک 3 بایتی پر نبود. 1 بایت ورودی دو نویسهٔ = به کار میبرد؛ 2 بایت یکی؛ 3 بایت هیچ. پدینگ رمزنگاری یا ویژگی امنیتی نیست.
آیا Base64URL فضای کمتری میگیرد؟
Base64URL علامت + را به - و / را به _ بدل میکند و رمز Base64 هنگام کدگذاری = پایانی را حذف میکند. آن میتواند رشته را به اندازهٔ همان نویسههای = کوتاه کند. ساختار 3 بایت → 4 نویسه همان است، پس Base64URL قالب دودویی کمحجمتری نیست.
چرا ورودی خیلی کوچک میتواند بیش از 33% رشد کند؟
1 بایت → 4 نویسه افزایش 300% در طول است. 2 بایت → 4 برابر 100% است. 3 بایت → 4 حدود 33.3% است. با رشد n پدینگ کماهمیتتر میشود و سربار به حدود 33% نزدیک میشود. Base64 همیشه دقیقاً 33% بزرگتر نیست.
چرا Data URL با Base64 باز هم بزرگتر است؟
Data URL پیشوندی مانند data:image/png;base64, پیش از بار میافزاید. روی پروندهٔ خیلی کوچک آن پیشوند میتواند درصد را غالب کند. رمز Base64 میتواند Base64 خام یا Data URL بدهد؛ خروجی Data URL الفبای استاندارد را به کار میبرد.
Base64 در برابر دودویی: کدام کوچکتر است؟
دودویی خام برای انتقال و ذخیره کمحجمتر است. Base64 بزرگتر است، اما در JSON، نامه و مسیر فقطمتنی متنایمن است. کدگذاری دودویی به متن است، نه فشردهسازی.
آیا Base64 پرونده را فشرده میکند؟
نه. Base64 قالب فشردهسازی نیست. متن کدشده معمولاً از بایت اصلی بزرگتر است. اگر بعداً gzip یا Brotli را روی آن متن بگذارید، بخشی از تکرار ممکن است جمع شود—نتیجه به داده و فشردهساز بستگی دارد. gzip سربار Base64 را کامل برنمیدارد.
اگر Base64 با gzip فشرده شود چه میشود؟
فشردهسازی HTTP میتواند برخی الگوی تکراری در متن Base64 را کم کند. JPEG، PNG یا ZIP حتی بهصورت بایت خام اغلب بد فشرده میشوند و Base64 سپس gzip همچنان موردبهمورد است. درصد اضافهٔ جهانی پس از gzip وجود ندارد.
باید پرونده را بهصورت Base64 ذخیره کرد؟
Base64 میتواند دودویی را در میدان JSON، دارایی کوچک درونخط، API فقطمتنی، رونوشت و چسباندن، یا Data URL جا دهد. برای پروندهٔ بزرگ، ذخیره، حافظه و اندازهٔ بار همه رشد میکنند. معنایش «هرگز Base64 را برای پرونده به کار نبرید» نیست.
چرا Base64 در APIهای JSON رایج است؟
JSON نوع دودویی خام بومی ندارد، پس APIها اغلب بایت را در رشتهٔ Base64 میگذارند. برای پروندهٔ بزرگ، multipart/form-data، ذخیرهٔ شیء یا بارگذاری دودویی مستقیم ممکن است بهتر بنشیند. هیچ انتخابی همیشه بهترین نیست.
چرا Base64 در نامه به کار میرود؟
MIME میتواند Base64 را به کار ببرد تا پیوست دودویی بهصورت نویسهٔ متنایمن سفر کند. همان سربار اندازه هنوز هست. این نمایش انتقال است، نه پروندهٔ کوچکتر.
کی اندازهٔ اضافه میارزد؟
اندازهٔ اضافه وقتی میارزد که دودویی باید داخل متن بنشیند، بار کوچک باشد، API بخواهد Base64، یا Data URL لازم باشد. برای رسانهٔ بزرگ، وقتی سامانه اجازه دهد دودویی خام را ترجیح دهید.
کی باید از Base64 پرهیز کرد؟
برای پروندهٔ بزرگ، پهنای باند تنگ، انتقال مکرر، یا وقتی مسیر دودویی از پیش هست رها کنید—موقعیتی، نه «Base64 کار بد است».
طول Base64 با پدینگ که میتوانید بررسی کنید
شمار بایت اصلی و شمار نویسهٔ Base64 استاندارد با پدینگ:
| بایت اصلی | نویسهٔ Base64 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
همهٔ سطرها از 4 × ceil(n / 3) پیروی میکنند. اینها شمار نویسهٔ Base64 هستند.
نمونه: پروندهٔ 1,000 بایتی چقدر بزرگ میشود؟
4 × ceil(1000 / 3). ceil(333.333…) = 334، و 4 × 334 = 1336. پس 1,000 بایت میشود 1,336 نویسهٔ Base64. ذخیرهشده بهصورت UTF-8/ASCII، هر نویسه معمولاً 1 بایت است—1,336 را شمار دقیق بایت در حافظه ندانید.
آیا Base64 میتواند بیش از اندازهٔ پرونده حافظه بگیرد؟
بعضی زماناجرا رشته را با بیش از 1 بایت برای هر نویسه ذخیره میکنند و کد/باز کردن میتواند بافر و رشته را با هم نگه دارد. مصرف حافظه دقیقاً طول نویسه نیست.
راهنمای سادهٔ تصمیم اندازه
اگر سامانه دودویی خام بپذیرد، برای اندازه آن را ترجیح دهید. اگر فقط متن مجاز است، Base64 ممکن است بگنجد. برای بار بزرگ مسیر بارگذاری دودویی را بجویید. برای متن امن URL، Base64URL را در نظر بگیرید—گسترش 3 به 4 میماند.
- باید دادهٔ دودویی فرستاد
- دودویی خام مجاز است؟ برای اندازه دودویی را ترجیح دهید
- میدان فقطمتنی؟ Base64 ممکن است مناسب باشد
- بار بزرگ؟ مسیر بارگذاری دودویی را بجویید
- متن امن URL میخواهید؟ Base64URL را در نظر بگیرید
- روی ورودی بزرگ حدود 33% متن بیشتر انتظار داشته باشید
Base64 برای کوچک کردن داده طراحی نشده. بازنمایی دودویی را داخل سامانههای متنمحور آسان میکند و هزینه اندازهٔ اضافه است.
در مرورگر Base64 را کد یا باز کنید
NEXNARA رمز Base64 متن را کد و باز میکند و میتواند پرونده را به Base64 یا Data URL بدل کند و Base64 را به پرونده برگرداند.
متن بایت UTF-8 میگیرد، سپس Base64—نه فقط ASCII. Standard یا Base64URL را برگزینید. خروجی پرونده میتواند Base64 خام یا Data URL باشد (الفبای استاندارد). ورودی نامعتبر رد میشود. بایت غیر UTF-8 به پرونده نیاز دارد، نه باز کردن بهصورت متن.
پروندهٔ بالای 10 MB ممکن است زبانه را کند کند (هشدار). پروندهٔ بالای 32 MB مسدود میشود.
کدگذاری و باز کردن در مرورگر شما رخ میدهد. پرونده برای این ابزار به کارساز NEXNARA فرستاده نمیشود. تبلیغ و دیگر قابلیتهای سایت هنوز شبکه را به کار میبرند.
متن یا پرونده را در رمز Base64 بچسبانید و بایت اصلی را با طول کدشده بسنجید.
FAQ
چرا Base64 اندازهٔ پرونده را زیاد میکند؟
3 بایت (24 بیت) را به 4 نویسه (4 × 6 بیت) مینگارد. ذخیرهشده بهصورت متن، برای ورودی بزرگ حدود یکسوم بیشتر است.
آیا Base64 همیشه 33% بزرگتر است؟
نه. ورودی بزرگ به حدود 33.3% نزدیک میشود. ورودی خیلی کوچک بهخاطر پدینگ بیشتر رشد میکند. از 4 × ceil(n / 3) استفاده کنید.
Base64 چقدر از دودویی بزرگتر است؟
طول استاندارد با پدینگ 4 × ceil(n / 3) نویسه است. پیشوند Data URL بیشتر میافزاید.
آیا فشردهسازی Base64 اندازهٔ پرونده را کم میکند؟
Base64 فشرده نمیکند. gzip یا Brotli روی متن کدشده ممکن است بخشی را جمع کند؛ در هر مورد سربار را پاک نمیکنند.
آیا Base64URL فضای کمتری میگیرد؟
میتواند پدینگ = را بیندازد، پس رشته ممکن است 0–2 نویسه کوتاهتر شود. ساختار کدگذاری 3 به 4 همان است.
برای پروندهٔ بزرگ Base64 به کار ببرم؟
فقط اگر متن لازم باشد. برای انتقال بزرگ یا مکرر، مسیر دودویی اغلب کوچکتر است. Base64 برای API همیشه غلط نیست.