Base64 फ़ाइलें बड़ी क्यों करता है?

यह लेख बताता है कि 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 तीन UTF-8/ASCII बाइट हैं। TWFu चार वर्ण हैं: 3 → 4।

Hello

Hello

Base64

SGVsbG8=

Hello पाँच बाइट है। SGVsbG8= आठ वर्ण है, एक = सहित। छोटे डेटा पर पैडिंग प्रतिशत को 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 एन्कोड या डिकोड करें

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 हमेशा गलत नहीं है।