Tech Help
Base64 ફાઇલો મોટી કેમ કરે છે?
Base64 સામાન્ય રીતે બાઇનરી ડેટાને લગભગ એક તૃતીયાંશ મોટો કરે છે. 3 બાઇટથી 4 અક્ષરની રચના, પેડિંગ, Data URLનો વધારાનો ભાર, અને તે કદ ક્યારે ફાયદાકારક છે તે જુઓ.
Base64 સામાન્ય રીતે બાઇનરી ડેટાને લગભગ એક તૃતીયાંશ મોટો કરે છે કારણ કે તે દરેક 3 બાઇનરી બાઇટને 4 છપાય તેવા Base64 અક્ષરોથી દર્શાવે છે.
ઇનપુટ લંબાઈ 3ની ચોક્કસ ગુણિત ન હોય તો પ્રમાણિત પેડેડ Base64 = અક્ષરો ઉમેરી શકે. એન્કોડ લંબાઈ 4 × ceil(n / 3) છે, જ્યાં n મૂળ બાઇટ લંબાઈ.
«લગભગ 33%» મોટા ઇનપુટનું વર્ણન કરે છે. ખૂબ નાના ઇનપુટ પર પેડિંગથી ટકાવારી ઘણી મોટી દેખાઈ શકે. Base64 સંકોચન નથી. એન્કોડિંગ વિરુદ્ધ એન્ક્રિપ્શન માટે [Base64 એન્ક્રિપ્શન નથી: તે ખરે શુ કરે ચે](/gu/story/base64-is-not-encryption) જુઓ.
આ લેખ સમજાવે છે કે Base64 આઉટપુટ મૂળ બાઇટ કરતાં મોટું કેમ છે. આ સુરક્ષા માર્ગદર્શિકા નથી. એન્કોડિંગ વિરુદ્ધ એન્ક્રિપ્શન જોઈએ તો Base64 એન્ક્રિપ્શન નથી: તે ખરે શુ કરે ચે વાપરો.
Base64ને વધુ જગ્યા કેમ જોઈએ?
3 બાઇટ એ 24 બિટ છે. Base64 તે 24 બિટને 6 બિટના 4 જૂથમાં વહેંચે છે. દરેક જૂથ એક Base64 અક્ષર સાથે જોડાય છે, તેથી 3 ઇનપુટ બાઇટ 4 આઉટપુટ અક્ષર બને. ASCII અક્ષર દીઠ 1 બાઇટ તરીકે સંગ્રહાય તો તે 4 / 3 ≈ 1.333 — લગભગ 33.3% વધારો.
- 3 બાઇટ (24 બિટ)
- 6 બિટના 4 જૂથમાં વહેંચો
- દરેક જૂથ → એક 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 ક્યારેય ન વાપરો» નથી.
JSON APIમાં Base64 સામાન્ય કેમ છે?
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 વાપરવું?
માત્ર લખાણ જોઈએ ત્યારે. મોટા કે વારંવાર ટ્રાન્સફર પર બાઇનરી માર્ગ ઘણી વખત નાનો હોય. API માટે Base64 હંમેશા ખોટું નથી.