“foob” का Base64 (दो पैडिंग चिह्न)
- एन्कोडिंग
- Base64
- दिशा
- एन्कोड करें
- पाठ
- foob
- परिणाम
- Zm9vYg==
- UTF-8 बाइट
- 4
- परिणाम की लंबाई
- 8 अक्षर
जाँच का स्रोत: उदाहरण जाँच: RFC 4648 §10 परीक्षण मान
Base64, URL और HTML एनकोडर व डीकोडर
Base64, URL-सुरक्षित Base64, URL प्रतिशत-एनकोडिंग, HTML एंटिटी, हेक्स बाइट और Unicode कोड पॉइंट एनकोड या डीकोड करें; UTF-8 और UTF-16 बाइट गिनती भी देखें।
लेखक: AdminAI लेखन टूल से मसौदा तैयारअपडेट किया गया जाँचे गए उदाहरण: 17
परिणाम
Q2Fmw6kgJiBjcsOobWUsIDUg4oKs
परिणाम: Q2Fmw6kgJiBjcsOobWUsIDUg4oKs
- अक्षर (कोड पॉइंट)
- 17
- UTF-8 बाइट
- 21
- UTF-16 कोड यूनिट
- 17
- परिणाम की लंबाई
- 28अक्षर
17 अक्षर से 21 UTF-8 बाइट बनते हैं; Base64 में ये 28 अक्षर लेते हैं, यानी प्रति बाइट 1.33।
आकार
शुरुआती अक्षरों के UTF-8 बिट
“C” U+0043 → 43
0
1
0
0
0
0
1
1
“a” U+0061 → 61
0
1
1
0
0
0
0
1
“f” U+0066 → 66
0
1
1
0
0
1
1
0
“é” U+00E9 → c3 a9
1
1
0
0
0
0
1
1
1
0
1
0
1
0
0
1
गणना कैसे होती है S
पाठ को UTF-8 में बदलें
17 अक्षर → 21 बाइट।
8-बिट बाइट को 6-बिट इंडेक्स में बाँटें
पहला समूह: 43 61 66 → 010000 110110 000101 100110 → 16, 54, 5, 38 → “Q2Fm”।
परिणाम की लंबाई
Base64, URL और HTML एनकोडर व डीकोडर के बारे में
यहाँ हर एन्कोडिंग पाठ के UTF-8 बाइट से शुरू होती है। Base64 हर 3 बाइट को 64-अक्षर वाली वर्णमाला के चार 6-बिट मान में बाँटता है (RFC 4648), इसलिए परिणाम की लंबाई 4 × ⌈n ÷ 3⌉ अक्षर होती है। प्रतिशत एन्कोडिंग A–Z, a–z, 0–9 और - . _ ~ के बाहर हर बाइट को %XX में लिखती है (RFC 3986)। HTML एस्केपिंग & < > " और ' को कैरेक्टर रेफ़रेंस से बदलती है; हेक्स हर बाइट के दो अंक लिखता है।
डेवलपर इसका उपयोग बाइनरी डेटा को JSON या ईमेल में रखने, क्वेरी स्ट्रिंग बनाने, JWT पढ़ने और अक्षर-समूह की समस्याएँ ढूँढ़ने में करते हैं। डिफ़ॉल्ट पाठ "Café & crème, 5 €" में 17 अक्षर लेकिन 21 UTF-8 बाइट हैं: é और è के 2-2 बाइट, और € के 3 बाइट। इसका Base64 रूप 28 अक्षर का है।
डिकोडिंग त्रुटि गलत अक्षर और उसकी स्थिति बताती है। जो बाइट मान्य UTF-8 नहीं हैं, वे U+FFFD (�) के रूप में दिखते हैं।
Base64, URL और HTML एन्कोडिंग कैसे समझें
पहले तय करें कि पाठ किस संदर्भ में जाएगा। Base64 बाइट को सामान्य पाठ में ले जाता है; URL प्रतिशत एन्कोडिंग क्वेरी के एक मान को सुरक्षित लिखती है; HTML एस्केपिंग मार्कअप अक्षरों को कैरेक्टर रेफ़रेंस बनाती है। हेक्स और कोड पॉइंट वाले विकल्प समस्या के पीछे के बाइट या अक्षर दिखाते हैं। इनमें से कोई एन्क्रिप्शन नहीं है।
यह टूल एन्कोड करते समय UTF-8 बाइट लेता है। डिफ़ॉल्ट Café & crème, 5 € में 17 कोड पॉइंट, 21 UTF-8 बाइट और 17 UTF-16 यूनिट हैं। इसलिए पाठ की अक्षर-संख्या को भेजे जाने वाले बाइट का आकार न मानें।
हाथ से Base64 बनाएँ
Man के बाइट 4D 61 6E हैं। बिट में 01001101 01100001 01101110 को चार 6-बिट समूह में बाँटें: 010011 010110 000101 101110। इनके मान 19, 22, 5 और 46 हैं, जो Base64 वर्णमाला में T, W, F और u बनते हैं। परिणाम TWFu है।
हर 3 बाइट से 4 अक्षर बनते हैं। अंतिम समूह छोटा हो तो शून्य बिट और = पैडिंग लगती है: Ma → TWE=, M → TQ==। RFC 4648 वर्णमाला और पैडिंग तय करता है। लगभग 33% बड़ा आकार इसी 4:3 अनुपात से आता है।
URL-सुरक्षित Base64 में + और / की जगह - और _ आते हैं; अक्सर पैडिंग हटती है। <<???>> सामान्य रूप में PDw/Pz8+Pg== और URL-सुरक्षित रूप में PDw_Pz8-Pg है। JWT के भाग पढ़ने पर भी याद रखें कि डिकोड करना हस्ताक्षर की जाँच नहीं करता।
URL के एक मान को एन्कोड करें
RFC 3986 के अनारक्षित अक्षर A–Z, a–z, 0–9 और - . _ ~ हैं। बाकी बाइट %XX बनते हैं। क्वेरी का मान a b&c=d/é? बनता है a%20b%26c%3Dd%2F%C3%A9%3F। पूरा URL इसी तरह एन्कोड करने से उसके विभाजक भी बदल जाएँगे; घटक अलग-अलग एन्कोड करें।
फ़ॉर्म एन्कोडिंग में स्पेस + होता है। इसलिए फ़ॉर्म की क्वेरी का a+b, a b पढ़ा जाता है; URL पथ में + वास्तविक प्लस है। JavaScript का encodeURIComponent स्पेस को %20 लिखता है, लेकिन ! ' ( ) * को छोड़ देता है। %20 को दोबारा एन्कोड करने पर %2520 बनता है।
HTML एस्केपिंग और Unicode
HTML के पाँच मुख्य बदलाव हैं: & → &, < → <, > → >, " → " और ' → '। यह एलिमेंट के पाठ और उद्धरण वाले एट्रिब्यूट में मदद करता है; JavaScript कोड, CSS या URL के लिए वही नियम पर्याप्त नहीं हैं।
हेक्स हर UTF-8 बाइट के दो अंक लिखता है: é€ → c3 a9 e2 82 ac। कोड पॉइंट अक्षर बताते हैं: A€😀 → U+0041 U+20AC U+1F600। UTF-8 मानक में एक कोड पॉइंट 1 से 4 बाइट लेता है; UTF-16 में 1 या 2 यूनिट। JavaScript में "😀".length इसी कारण 2 है।
| उदाहरण | कोड पॉइंट | UTF-8 बाइट | UTF-16 यूनिट |
|---|---|---|---|
| डिफ़ॉल्ट | 17 | 21 | 17 |
| A€😀 | 3 | 8 | 4 |
| अलग संयोजक चिह्न | 2 | 3 | 2 |
| इमोजी क्रम | 7 | 25 | 11 |
| अमान्य UTF-8 हेक्स | 2 | 2 | 2 |
संयोजक चिह्न वाला उदाहरण e और U+0301 है। परिवार 👨👩👧👦 एक चित्र की तरह दिखता है, पर उसमें चार व्यक्ति और तीन ज़ीरो-विथ जॉइनर हैं। अंतिम पंक्ति में c3 28 अमान्य UTF-8 है और �( बनता है।
डिकोडिंग में क्या जाँचें
Base64 और हेक्स के बीच खाली स्थान अनदेखा होता है; बिना पैडिंग का Base64 भी स्वीकार है। हेक्स में स्पेस, कोलन और 0x उपसर्ग चल सकते हैं। कोड पॉइंट U+1F600, \u{1F600}, 0x1F600 या 😀 लिख सकते हैं। अमान्य बाइट U+FFFD (�) बनते हैं और चेतावनी में स्थान मिलता है; इससे मूल डेटा की सही एन्कोडिंग सिद्ध नहीं होती।
ब्राउज़र का btoa('é'), UTF-8 का w6k= देने के बजाय Latin-1 का 6Q== देता है; btoa('€') त्रुटि करता है। Unicode के लिए पहले TextEncoder से UTF-8 बाइट लें। पाठ पृष्ठ के पते और डिवाइस के इतिहास में जा सकता है, इसलिए असली टोकन या कुंजी न डालें। डेटा की पहचान जाँचनी हो तो हैश कैलकुलेटर लें।
हल किए गए उदाहरण
खाली स्ट्रिंग का Base64
- एन्कोडिंग
- Base64
- दिशा
- एन्कोड करें
- परिणाम
- UTF-8 बाइट
- 0
- परिणाम की लंबाई
- 0 अक्षर
जाँच का स्रोत: स्वतंत्र गणना
बिना पैडिंग का URL-सुरक्षित Base64
- एन्कोडिंग
- Base64 (URL-सुरक्षित)
- दिशा
- एन्कोड करें
- पाठ
- <<???>>
- परिणाम
- PDw_Pz8-Pg
- परिणाम की लंबाई
- 10 अक्षर
जाँच का स्रोत: सामान्य वर्णमाला में PDw/Pz8+Pg==
Base64 से चीनी पाठ डिकोड करें
- एन्कोडिंग
- Base64
- दिशा
- डिकोड करें
- एन्कोड किया पाठ
- 5L2g5aW9IOS4lueVjA==
- परिणाम
- 你好 世界
- अक्षर (कोड पॉइंट)
- 5
- UTF-8 बाइट
- 13
- UTF-16 कोड यूनिट
- 5
जाँच का स्रोत: स्वतंत्र गणना
सवाल
Base64 डेटा को लगभग 33% बड़ा क्यों करता है?
Base64 का हर परिणाम अक्षर 6 बिट ले जाता है, जबकि इनपुट के हर बाइट में 8 बिट होते हैं। इसलिए 3 बाइट से 4 अक्षर बनते हैं, यानी 4:3 अनुपात; अंत में अधिकतम दो = पैडिंग चिह्न जुड़ते हैं। 21 बाइट से 28 अक्षर और 1 MB बाइनरी से लगभग 1.33 MB बनते हैं। MIME ईमेल (RFC 2045) अधिकतम 76 अक्षर की पंक्तियाँ भी बनाता है, जिससे आकार थोड़ा और बढ़ता है।
Base64 और Base64URL में क्या अंतर है?
Base64URL (RFC 4648 §5) URL और फ़ाइल नाम से टकराने वाले + और / की जगह - और _ लेता है; अक्सर = पैडिंग भी हटा देता है। JSON Web Token (RFC 7519) के तीनों भाग इसी में लिखे जाते हैं। <<???>> का सामान्य Base64 PDw/Pz8+Pg== है, जबकि URL-सुरक्षित रूप PDw_Pz8-Pg है: 12 के बजाय 10 अक्षर।
क्या Base64 एक तरह का एन्क्रिप्शन है?
नहीं। Base64 बिना कुंजी की उलटी जा सकने वाली एन्कोडिंग है; कोई भी इसे एक चरण में डिकोड कर सकता है। यह केवल बाइनरी डेटा को पाठ के रूप में ले जाने योग्य बनाती है। उदाहरण के लिए HTTP Basic authentication (RFC 7617) user:password को Base64 में भेजता है, इसलिए उसके लिए HTTPS आवश्यक है। डेटा बचाने के लिए पहले उसे AES-256 जैसे तरीके से एन्क्रिप्ट करें, फिर पाठ में भेजना हो तो एन्क्रिप्टेड बाइट का Base64 बनाएँ।
URL में स्पेस को %20 लिखें या +?
दोनों अलग संदर्भों में मिलते हैं। URL के RFC 3986 में स्पेस %20 है, जबकि HTML फ़ॉर्म (application/x-www-form-urlencoded) उसे + लिखते हैं। इसलिए फ़ॉर्म की क्वेरी में a+b का अर्थ a b है, पर URL पथ में + का अर्थ वास्तविक प्लस चिह्न है। JavaScript का encodeURIComponent %20 देता है; Python का urllib.parse.quote_plus + देता है।
UTF-8 में एक अक्षर कितने बाइट लेता है?
एक से चार। U+0080 से नीचे ASCII कोड पॉइंट 1 बाइट, U+07FF तक 2 बाइट (é, ñ, ग्रीक, सिरिलिक), U+FFFF तक 3 बाइट (€ और अधिकांश चीनी अक्षर), और बाकी 4 बाइट लेते हैं। अंतिम समूह में 😀 (U+1F600) जैसे इमोजी हैं। A€😀 में 3 अक्षर, 8 UTF-8 बाइट और 4 UTF-16 कोड यूनिट हैं, क्योंकि UTF-16 में 😀 को सरोगेट जोड़ी चाहिए (RFC 3629)।
इस कैलकुलेटर के बारे में
स्रोत
संदर्भों से जाँच की गई
इस कैलकुलेटर में स्वतंत्र स्रोतों के उत्तरों वाले 17 हल किए गए उदाहरण शामिल हैं। ये परीक्षण समूह में चलते हैं और आप इन्हें यहाँ भी चला सकते हैं।