Base64 آؤٹ پٹ میرے ان پٹ سے لمبا کیوں ہوتا ہے؟

ہر 3 بائٹس 4 حروف بنتے ہیں، اس لیے آؤٹ پٹ ان پٹ کے تقریباً 4/3 کے برابر ہوتا ہے، اور اس کے ساتھ زیادہ سے زیادہ دو پیڈنگ حروف۔ غیر ASCII ٹیکسٹ اور بھی لمبا ہوتا ہے، کیونکہ UTF-8 ہر حرف کے لیے دو سے چار بائٹس استعمال کرتا ہے۔

آخر میں = کے نشان کیا ہیں؟

پیڈنگ۔ جب ان پٹ کی لمبائی تین کا ضرب نہ ہو تو یہ آؤٹ پٹ کی لمبائی کو چار کا ضرب بناتے ہیں۔ ایک = کا مطلب ہے آخری گروپ میں دو بائٹس تھے، دو = کا مطلب ہے ایک بائٹ تھا۔

ڈیکوڈنگ میں غلط حرف (invalid character) کی خرابی کیوں آتی ہے؟

ان پٹ میں حروف کے سیٹ سے باہر کچھ ہے، جیسے لفظ کے اندر اسپیس، کوٹ، یا URL انکوڈنگ کا %۔ لائن بریکس اور غائب پیڈنگ برداشت ہو جاتی ہیں؛ دوسرے حروف نہیں۔

کیا پاس ورڈ کو Base64 میں انکوڈ کرنا محفوظ ہے؟

Base64 کوئی تحفظ نہیں دیتا۔ HTTP Basic authentication user:password کو Base64 میں بھیجتی ہے، اسی لیے اسے صرف HTTPS پر استعمال کرنا چاہیے۔ رازوں کی حفاظت کے لیے حقیقی انکرپشن یا ہیشنگ استعمال کریں۔

Base64 اور Base64url میں کیا فرق ہے؟

صرف دو حروف اور پیڈنگ: Base64url میں + اور / کی جگہ - اور _ استعمال ہوتے ہیں اور عموماً = نہیں ہوتا، تاکہ نتیجہ بغیر escape کیے URLs اور فائل ناموں میں آ سکے۔

Base64 انکوڈ اور ڈیکوڈ

ٹیکسٹ یا فائل کو Base64 میں تبدیل کریں، یا Base64 کو واپس قابلِ مطالعہ ٹیکسٹ میں ڈیکوڈ کریں۔ Unicode درست طریقے سے سنبھالا جاتا ہے، URL-safe حروفِ تہجی صرف ایک کلک پر دستیاب ہے، اور ڈیکوڈنگ دونوں حروفِ تہجی کو پیڈنگ کے ساتھ یا اس کے بغیر قبول کرتی ہے۔

موڈ

انکوڈڈی کوڈ

URL-محفوظ حروف (- اور _، بغیر پیڈنگ)

ان پٹ

0 حروف · 0 الفاظ · 0 سطریں

فائل انکوڈ کریں

نتیجہ

0 حروف · 0 الفاظ · 0 سطریں

یہ مکمل طور پر اسی براؤزر ٹیب میں چلتا ہے۔ آپ کا متن کبھی اپ لوڈ یا محفوظ نہیں کیا جاتا۔

Base64 حروف کا سیٹ

RFC 4648 کے مطابق انڈیکس → حرف۔ نمایاں آخری دو URL-محفوظ صورت میں مختلف ہیں: 62 یعنی + یا -، 63 یعنی / یا _۔

0A
1B
2C
3D
4E
5F
6G
7H
8I
9J
10K
11L
12M
13N
14O
15P
16Q
17R
18S
19T
20U
21V
22W
23X
24Y
25Z
26a
27b
28c
29d
30e
31f
32g
33h
34i
35j
36k
37l
38m
39n
40o
41p
42q
43r
44s
45t
46u
47v
48w
49x
50y
51z
520
531
542
553
564
575
586
597
608
619
62+ -
63/ _

آؤٹ پٹ کتنا لمبا ہوتا ہے

ہر 3 ان پٹ بائٹس 4 حروف بنتے ہیں؛ آخری 1 یا 2 بائٹس کے گروپ کو معیاری Base64 میں = سے پُر کیا جاتا ہے اور URL-محفوظ صورت میں بغیر پیڈنگ چھوڑا جاتا ہے۔

ان پٹ	بائٹس	معیاری	URL-محفوظ	لمبائی
`U`	1	`VQ==`	`VQ`	4
`Ul`	2	`VWw=`	`VWw`	4
`Ult`	3	`VWx0`	`VWx0`	4
`UltK`	4	`VWx0Sw==`	`VWx0Sw`	8
`UltKi`	5	`VWx0S2k=`	`VWx0S2k`	8
`UltKit`	6	`VWx0S2l0`	`VWx0S2l0`	8

Base64 کیا کرتا ہے

Base64، جو RFC 4648 میں بیان کیا گیا ہے، کسی بھی بائٹس کو 64 قابلِ طباعت ASCII حروف سے لکھتا ہے: A–Z، a–z، 0–9، + اور /۔ ہر تین بائٹس (24 بٹس) کے گروپ کو چار 6 بٹ نمبروں میں تقسیم کیا جاتا ہے اور ہر نمبر حروف کی فہرست سے ایک حرف چنتا ہے۔ اگر ان پٹ کی لمبائی تین کا ضرب نہ ہو تو آخری گروپ کو ایک یا دو = علامتوں سے پُر کیا جاتا ہے۔ نتیجہ ہمیشہ ان پٹ سے تقریباً 33% بڑا ہوتا ہے: ہر 3 بائٹس کے لیے 4 حروف۔

یہ اس لیے موجود ہے کہ بہت سے چینل صرف ٹیکسٹ کے لیے بنائے گئے تھے۔ ای میل (MIME)، HTML اور CSS میں data: URLs، تصاویر یا سرٹیفکیٹ لے جانے والے JSON فیلڈز، اور HTTP Basic authentication ہیڈرز، سب بائنری ڈیٹا کو محفوظ طریقے سے منتقل کرنے کے لیے Base64 استعمال کرتے ہیں۔ یہ انکرپشن نہیں ہے اور کچھ نہیں چھپاتا؛ ڈی کوڈ کرنے کے لیے کسی کلید کی ضرورت نہیں۔

Unicode اور URL-safe قسم

Base64 حروف کو نہیں بلکہ بائٹس کو انکوڈ کرتا ہے، اس لیے ٹیکسٹ کو پہلے بائٹس میں بدلنا پڑتا ہے۔ یہ ٹول ہمیشہ UTF-8 استعمال کرتا ہے، جس پر ویب چلتا ہے: é دو بائٹس اور ایک ایموجی چار بائٹس بنتا ہے۔ براؤزر کا بلٹ اِن btoa فنکشن اکیلا U+00FF سے اوپر کے کسی بھی حرف پر ایرر دیتا ہے، اسی لیے سادہ انکوڈرز اعراب اور ایموجی پر ناکام ہو جاتے ہیں؛ یہاں ٹیکسٹ پہلے TextEncoder سے گزرتا ہے اور ڈی کوڈنگ TextDecoder سے الٹی جاتی ہے۔ اگر ڈی کوڈ شدہ بائٹس درست UTF-8 نہ ہوں (جیسے تصویر یا zip فائل) تو ٹول انہیں بگڑے ہوئے متن کے بجائے ہیکسا ڈیسیمل میں دکھاتا ہے۔

معیاری Base64 + اور / استعمال کرتا ہے، جن کے URLs اور فائل ناموں میں خاص معنی ہوتے ہیں۔ RFC 4648 کے سیکشن 5 کا URL-safe حروف کا سیٹ انہیں - اور _ سے بدل دیتا ہے اور پیڈنگ عموماً ہٹا دی جاتی ہے۔ JSON Web Tokens بالکل یہی شکل استعمال کرتے ہیں۔ ڈی کوڈر دونوں سیٹ اور غائب پیڈنگ قبول کرتا ہے، اس لیے آپ کوئی بھی پیسٹ کر سکتے ہیں۔

فائلوں اور تصاویر کی انکوڈنگ

فائل منتخب کریں تو ٹول اسے FileReader سے مقامی طور پر پڑھ کر اس کا Base64 واپس کرتا ہے، یا فائل کی MIME قسم کے ساتھ مکمل data: URL دیتا ہے جو img ٹیگ یا CSS بیک گراؤنڈ میں پیسٹ کرنے کے لیے تیار ہوتا ہے۔ ان لائن تصاویر ایک HTTP درخواست بچاتی ہیں لیکن ایک تہائی بڑی ہو جاتی ہیں اور الگ سے کیش نہیں ہو سکتیں، اس لیے یہ فوٹو کے بجائے چھوٹے آئیکنز کے لیے موزوں ہیں۔ پری ویو اور تیار HTML اور CSS اسنیپٹس کے ساتھ تصاویر کے لیے تصویر سے Base64 استعمال کریں۔

اکثر پوچھے جانے والے سوالات

Base64 آؤٹ پٹ میرے ان پٹ سے لمبا کیوں ہوتا ہے؟: ہر 3 بائٹس 4 حروف بنتے ہیں، اس لیے آؤٹ پٹ ان پٹ کے تقریباً 4/3 کے برابر ہوتا ہے، اور اس کے ساتھ زیادہ سے زیادہ دو پیڈنگ حروف۔ غیر ASCII ٹیکسٹ اور بھی لمبا ہوتا ہے، کیونکہ UTF-8 ہر حرف کے لیے دو سے چار بائٹس استعمال کرتا ہے۔
آخر میں = کے نشان کیا ہیں؟: پیڈنگ۔ جب ان پٹ کی لمبائی تین کا ضرب نہ ہو تو یہ آؤٹ پٹ کی لمبائی کو چار کا ضرب بناتے ہیں۔ ایک = کا مطلب ہے آخری گروپ میں دو بائٹس تھے، دو = کا مطلب ہے ایک بائٹ تھا۔
ڈیکوڈنگ میں غلط حرف (invalid character) کی خرابی کیوں آتی ہے؟: ان پٹ میں حروف کے سیٹ سے باہر کچھ ہے، جیسے لفظ کے اندر اسپیس، کوٹ، یا URL انکوڈنگ کا %۔ لائن بریکس اور غائب پیڈنگ برداشت ہو جاتی ہیں؛ دوسرے حروف نہیں۔
کیا پاس ورڈ کو Base64 میں انکوڈ کرنا محفوظ ہے؟: Base64 کوئی تحفظ نہیں دیتا۔ HTTP Basic authentication user:password کو Base64 میں بھیجتی ہے، اسی لیے اسے صرف HTTPS پر استعمال کرنا چاہیے۔ رازوں کی حفاظت کے لیے حقیقی انکرپشن یا ہیشنگ استعمال کریں۔
Base64 اور Base64url میں کیا فرق ہے؟: صرف دو حروف اور پیڈنگ: Base64url میں + اور / کی جگہ - اور _ استعمال ہوتے ہیں اور عموماً = نہیں ہوتا، تاکہ نتیجہ بغیر escape کیے URLs اور فائل ناموں میں آ سکے۔