تخنیکي مرسته
ولې Base64 فایلونه لویوي؟
Base64 معمولاً دوه اړخیز معلومات شاوخوا یوه درېیمه برخه لویوي. د 3 بایټ څخه 4 تورو جوړښت، ډکول، د Data URL اضافه لګښت، او دا اندازه کله ارزښت لري وګورئ.
Base64 معمولاً دوه اړخیز معلومات شاوخوا یوه درېیمه برخه لویوي ځکه چې د دوه اړخیزو معلوماتو هر 3 بایټ د 4 چاپېدونکو Base64 تورو سره ښيي.
که د ننوتلو اوږدوالی د 3 دقیق ضریب نه وي، معیاري ډک Base64 کېدای شي = توري اضافه کړي. کوډ شوې اوږدوالی 4 × ceil(n / 3) دی، چې n د اصلي بایټ اوږدوالی دی.
«شاوخوا 33%» لوی ننوتنې بیانوي. په ډېرو کوچنیو ننوتنو کې سلنه د ډکولو له امله ډېره لویه ښکاري. Base64 فشار نه دی. د کوډولو په وړاندې د کوډ پټولو لپاره [ایا Base64 کوډول دي؟ Base64 څه دی؟](/ps/story/base64-is-not-encryption) وګورئ.
دا مقاله تشریح کوي چې ولې د Base64 محصول د اصلي بایټونو څخه لوی دی. دا د امنیت لارښود نه دی. که کوډول د کوډ پټولو په وړاندې اړین وي، ایا Base64 کوډول دي؟ Base64 څه دی؟ وکاروئ.
ولې Base64 ډېر ځای ته اړتیا لري؟
3 بایټ 24 بټ دي. Base64 هغه 24 بټ په 4 ډلو د 6 بټ ویشي. هره ډله یوه Base64 توري ته نقشه کېږي، نو 3 د ننوتلو بایټ 4 د محصول توري کېږي. د ASCII توري په سر 1 بایټ ساتل شوي، دا 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% لوی نه دی.
ولې د Base64 Data URL لا لویه ده؟
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 په JSON API کې عام دی؟
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 کې تل غلط نه دی.