קידוד Base64 מוסבר: קידוד ופענוח כמו מקצוען

בגרסה הראשונה של ממיר Base64 ששלחתי ב-Toolz.dev היה באג I' אני עדיין קצת נבוך לגבי זה. זה עבד בצורה מושלמת בכל בדיקה שכתבתי - מקודד, מפוענח, הלוך ושוב, בוצע. ואז מישהו הדביק טקסט המכיל אימוג'י וקיבל את זה:

Uncaught DOMException: InvalidCharacterError:
Failed to execute 'btoa' on 'Window': The string to be
encoded contains characters outside of the Latin1 range.

I'd בנה כלי קידוד טקסט ושכח שטקסט כולל, אתה יודע, ביותר טקסט. כל תסריט לא לטיני, כל דמות מודגשת, כל אימוג'י - שבור. המבחנים שלי היו כולם ASCII כי אני חושב ב-ASCII. הבאג הזה לימד אותי יותר על Base64 מאשר כל קריאת מפרט, ו-I' יראה לך את התיקון מאוחר יותר כי הוא מכשיל כמעט את כל מי שנוגע btoa().

Base64 הוא אחד הדברים האלה שמפתחים משתמשים בהם מדי יום - בתוך כל JWT, כל קובץ מצורף לאימייל, כל אחד data: URI - תוך כדי הסתכלות נדירה מתחת למכסה המנוע. Let's מסתכלים מתחת למכסה המנוע.

TL;DR: קידוד Base64 ממיר נתונים בינאריים ל-64 תווי ASCII בטוחים כך שהוא יכול לעבור דרך ערוצי טקסט בלבד כמו JSON, כתובות URL ודואל - בעלות של ~33% תקורה בגודל. זה לא הַצפָּנָה; כל אחד יכול להפוך אותו באופן מיידי. כדי לקודד או לפענח כבר עכשיו, השתמש בצד הלקוח החינמי ממיר Base64 ב-Toolz.dev - הנתונים שלך לעולם לא עוזבים את הדפדפן, מה שחשוב כאשר אתה 're פענוח אסימונים.

מהו קידוד Base64?

Base64 היא סכימת קידוד בינארי לטקסט: היא מייצגת בתים שרירותיים באמצעות 64 תווים בלבד ששורדים כל מערכת טקסט שנבנתה אי פעם. המפרט הסמכותי הוא RFC 4648 (2006), אם כי הקידוד חוזר ל-RFC 1421 ו-Privacy Enhanced Mail בשנת 1993 - Base64 ישן יותר מדפדפן האינטרנט.

האלפבית:

• A–Z → ערכים 0–25
• a–z → ערכים 26–51
• 0–9 → ערכים 52–61
• + → 62, / → 63
• = → ריפוד (לא ערך, רק חומר מילוי)

למה 64 אלה? כי הם שורדים ללא ערבוב ב-ASCII, EBCDIC ובכל שער אימייל שנבנה אי פעם. Base64 הוא הסכם שלום עם עשרות שנים של תשתית טקסט בלבד.

עלות האמנה: כל 3 בתים קלט הופכים ל-4 תווי פלט - מס גודל קבוע של 33%. שמור את המספר הזה בראש שלך; זה מחליט בשאלות ארכיטקטורה אמיתיות.

כיצד פועל אלגוריתם Base64?

תשובה קצרה יותר ממה שאתה 'd מצפה: לקבץ מחדש ביטים משנות ה-8 ל-6, ואז לחפש אותם בטבלה. 26 = 64 - that's מאיפה השם בא.

קִדוּד Hi!:

שלב 1 - בתים לביטים.

משורשר: 010010000110100100100001- 24 סיביות.

שלב 2 - התארגן מחדש לנתחים של 6 סיביות.

010010 | 000110 | 100100 | 100001
  18   |   6    |   36   |   33

שלב 3 - חפש כל ערך באלפבית.

18 → S, 6 → G, 36 → k, 33 → h. כך Hi! מקודד ל SGkh.

That's האלגוריתם כולו. אין מתמטיקה מעבר לטבלת חיפוש.

ריפוד מטפל בכניסות שהן't כפולות של 3 בתים. מקודד רק Hi (2 בתים = 16 סיביות) ותוכל למלא רק קבוצות של 6 סיביות של שניים וסיביות; המקודד מאפס את הסיביות ומצרף = לאותת כמה עולה חומר מילוי:

Hi  → SGk=    (2 bytes remaining → one '=')
H   → SA==    (1 byte remaining  → two '==')
Hi! → SGkh    (multiple of 3     → no padding)

כאשר יישמתי את זה עבור ממיר Toolz.dev, ריפוד היה המקום שבו כל הבאגים שלי off-by-one חי אם אי פעם לגלגל ביד Base64 - לראיון קידוד, נניח - לכתוב את בדיקות הריפוד הראשון.

פענוח הוא תמונת המראה: תווים חוזרים לערכי 6 סיביות, מתקבצים מחדש לבייטים של 8 סיביות, מפילים את הריפוד.

לאן אתה בעצם רץ לתוך Base64?

JWTs - הגדול

כל אסימון אינטרנט של JSON הוא שלושה מקטעים מקודדים Base64URL שמצטרפים אליהם נקודות: כותרת, מטען, חתימה. אישור ניפוי באגים הוא 50% פענוח אלה.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

פענח את הקטע הראשון ותקבל {"alg":"HS256","typ":"JWT"}. השני נותן לך את הטענות. זרימת העבודה שלי כאשר אסימון מתנהג בצורה לא נכונה: פיצול בנקודות, פענח כל חלק ב- ממיר Base64לאחר מכן הדבק את ה-JSON לתוך פורמט JSON לקרוא אותו כמו שצריך שתי משחות, ואתה יודע אם ה exp טענה היא הבעיה שלך.

שווה לומר בפשטות: מטענים של JWT הם קריא על ידי כל מי שמחזיק את האסימון. החתימה מפסיקה להתעסק, לא לקרוא. I' סקרתי בסיסי קוד שדחסו נתונים רגישים לתביעות מכיוון שמראה הג'יבריש מרמז על פרטיות. זה עושה 't.

URI נתונים

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />

הטמעת נכסים קטנים בשורה שומרת בקשת HTTP. כלל האצבע שלי מבניית UIs מנהל מערכת וורדפרס כבד תמונה: שווה את זה תחת ~5 KB, עבר 10 KB you're נפוח המסמך ב 33% כדי לשמור בקשה HTTP/2 multiplexes בכל מקרה.

סודות קוברנטס - והתלהמות

apiVersion: v1
kind: Secret
data:
  password: cGFzc3dvcmQ=   # decodes to "password"

סודות Kubernetes הם Base64-מקודד, ואת האבטחה הכוזבת זה מרמז הוא מדאיג.That ערך מפענח בהדבקה אחת.Base64 כאן קיים כך ערכים בינאריים לשרוד YAML - א עיצוב החלטה, לא אבטחה. אם סיפור הסודות שלך מסתיים ב-"they're Base64 ב-etcd," זה התחיל 't.

שאר הרשימה

כותרות HTTP Basic Auth (Authorization: Basic dXNlcjpwYXNz מפענח לפשוט user:pass- ומכאן HTTPS בלבד). קבצים מצורפים לדואל באמצעות MIME. כתמים בינאריים בתוך מטענים של JSON, מכיוון של-JSON אין סוג בינארי.

האם Base64 הצפנה? (לא. בבקשה, לא.)

שווה קטע משלה כי התפיסה המוטעית מסרבת למות.

Base64 הוא א ייצוג, כמו כתיבת מספר בהקסדצימלי אין מפתח אין סוד פענוח אינו דורש דבר מלבד טבלת האלפבית המודפסת בפומבי ב-RFC 4648. כל דבר Base64-"protected" מוגן באופן שבו אות מוגנת על ידי כתיבה בכתב.

אם הנתונים זקוקים לסודיות: הצפין כראוי (AES-GCM, או libsodium), ואז Base64-לקודד את טקסט צופן אם הערוץ צריך טקסט.Encoding והצפנה compose fine - they just aren't substitutes. And if you need integrity ver מאשר secretary, that's a hash's job - the מְחוּגָה מכסה SHA-256 וחברים.

כיצד Base64 משווה ל-Hex, קידוד URL ו-Base85?

איך אני בוחר: hex כאשר בני אדם יקראו או ישוו את הפלט - סכומי בדיקה, עיכול, כל דבר שנפה באגים על ידי גלגל העין. קידוד אחוז עבור טקסט כתובת URL, לעולם לא בינארי. בסיס 64 לחציית ערוץ טקסט בינארית - רוב המקרים האמיתיים. ASCII85 לעולם לא מרצון; החיסכון של 8% עדיין לא הצדיק את שאלות התאימות.

מהו URL-Safe Base64 ומדוע הוא קיים?

ל-Standard Base64 יש בעיה: + פירושו "space" במחרוזות שאילתות, / האם מפריד הנתיבים, = תוחם פרמטרים שים אסימון סטנדרטי-Base64 בכתובת URL ותוכנה כלשהי, איפשהו, תבלבל אותו - לסירוגין, ורק בייצור שאל אותי איך אני יודע.

RFC 4648 סעיף 5 מגדיר את התיקון, הנקרא בדרך כלל Base64URL:

אותו אלגוריתם, שני תווים הוחלפו, ריפוד ירד. JWTs להשתמש Base64URL באופן בלעדי - וזו בדיוק הסיבה הדבקת קטע JWT לתוך תקן קפדני-Base64 מפענח לפעמים נכשל על תועה - או _. ה Toolz.dev ממיר מטפל בשתי הגרסאות, מכיוון שמפענח שדוחה מחצית מ-Base64 בעולם האמיתי הוא ' לא הרבה מפענח.

כלל אצבע: אם המחרוזת המקודדת אי פעם תיגע בכתובת URL, שם קובץ או כותרת HTTP, השתמש בגרסה הבטוחה לכתובת URL מההתחלה. התאמה מחדש היא חיפוש והחלפה בתוספת תפילה.

כיצד מקודדים ומפענחים בקוד?

JavaScript - המלכודת אליה נפלתי

Here' היא הגרסה הנאיבית, זו ששלחתי:

btoa('Hello')      // "SGVsbG8=" — great!
btoa('café ☕')    // InvalidCharacterError — the bug from my intro

btoa קדם לטיפול מודרני ב-Unicode ומקבל רק לטינית-1. הגישה המודרנית הנכונה עוברת דרך UTF-8 בתים במפורש:

// Encode: string → UTF-8 bytes → Base64
const bytes = new TextEncoder().encode('café ☕');
const encoded = btoa(String.fromCharCode(...bytes));   // "Y2Fmw6kg4piV"

// Decode: Base64 → bytes → string
const decoded = new TextDecoder().decode(
  Uint8Array.from(atob(encoded), c => c.charCodeAt(0))
); // "café ☕"

(ב-Node.js, דלג על הטקס: Buffer.from(str, 'utf8').toString('base64').)

פייתון

import base64

encoded = base64.b64encode('café ☕'.encode('utf-8')).decode('ascii')
decoded = base64.b64decode(encoded).decode('utf-8')

# URL-safe variant — note -_ instead of +/
token = base64.urlsafe_b64encode(b'binary\xfb\xff').decode('ascii')

פייתון הופך את הדבר הנכון לברור: אתה חייב העבר בתים, כך ששלב הקידוד ל-UTF-8 יכול 't להישכח. הלוואי btoa עוצב עם אותו עמוד שדרה.

PHP

$encoded = base64_encode('café ☕');   // handles bytes as-is — PHP strings ARE bytes
$decoded = base64_decode($encoded);

// URL-safe requires manual translation — a WordPress-plugin-developer classic:
$urlSafe = rtrim(strtr($encoded, '+/', '-_'), '=');

שֶׁז strtr/rtrim שורה הופיעה בכל בסיס קוד PHP I' אי פעם עבד על, כולל WP Adminify. PHP מעולם לא קיבלה גרסה מובנית בטוחה לכתובת URL, אז כולנו ממשיכים לכתוב את אותן שתי שורות.

שאלות נפוצות

למה משמש קידוד Base64?

הוא ממיר נתונים בינאריים לטקסט ASCII כך שהוא יכול לעבור דרך מערכות המטפלות רק בטקסט: מטענים של JSON, כתובות URL, דואר אלקטרוני (MIME), כותרות HTTP. אתה פוגש את זה לרוב באסימוני JWT, data: URIs עבור תמונות מוטבעות, סודות Kubernetes, ומטענים API הנושאים קבצים. It's פורמט תעבורה, לא פורמט אחסון או אבטחה.

האם Base64 זהה להצפנה?

לא, ובלבול בין השניים גורם לאירועי אבטחה אמיתיים ל-Base64 אין מפתח - פענוח דורש רק את טבלת האלפבית הציבורי, ולוקח משחה אחת לכל אחת מפענח. הצפן תחילה עם אלגוריתם אמיתי (AES-GCM), ולאחר מכן מקודד את טקסט ההצפנה אם הערוץ זקוק לטקסט.

מדוע Base64 הופך את הנתונים לגדולים ב-33%?

כל תו Base64 נושא 6 סיביות של מידע אבל תופס בייט מלא של 8 סיביות, כך ש-3 בתים של קלט תמיד הופכים ל-4 תווים של פלט - 4/3 → 1.33. It's עלות קבועה של הפורמט, בלתי נמנעת בתכנון אם הגודל קובע, דחוס לפני הקידוד, לעולם לא אחרי - פלט מקודד נראה אקראי ודוחס נורא.

מה's ההבדל בין Base64 ל-Base64URL?

Base64URL החלפות + עבור - ו / עבור _, ובדרך כלל מפיל את = ריפוד, כך הפלט שורד כתובות URL, שמות קבצים, וכותרות מבלי לברוח.Same אלגוריתם אחרת, מוגדר RFC 4648 סעיף 5. JWTs להשתמש Base64URL באופן בלעדי - וזו הסיבה תקן קפדנית-Base64 מפענחים לפעמים לחנוק עליהם.

מדוע btoa () זורק את InvalidCharacterError?

המחרוזת שלך מכילה תווים מחוץ ללטינית-1 - אימוג'י, תו מודגש, כל כתב לא מערבי. btoa הוא API 1990s שקדם טיפול Unicode הגיוני.קוד ל UTF-8 בתים הראשון עם TextEncoder, ואז Base64 הבתים; שלחתי את הבאג הזה בדיוק בכלי ייצור, אז אין שיפוט.

איך אני יכול לדעת אם מחרוזת היא Base64?

Base64 חוקי משתמש בלבד A–Z, a–z, 0–9, +, / (או -, _ עבור URL-בטוח), נגרר אופציונלי =, עם אורך ש' הוא כפולה של 4 כאשר הוא מרופד. אבל הרבה מילים רגילות תואמות גם את הדפוס הזה - cafe תקף Base64 שמפענח לאשפה בתים הבדיקה האמיתית היא פענוחו ובדיקה האם הפלט הוא בעל משמעות.

למה למחרוזת Base64 שלי יש קו חדש תועה בסוף?

בגלל echo מוסיף אחד לפני base64 אי פעם רואה את זה, אז echo "hunter2" | base64 מקודד שמונה בתים, לא שבעה. להשתמש printf או echo -n במקום זאת. זוהי הסיבה מספר אחת לסודות Kubernetes שנראים ממש במניפסט ונכשלים בזמן ריצה: הסיסמה המפוענחת נושאת נגרר בלתי נראה \n. ה base64 הפקודה גם עוטפת פלט ב-76 עמודות במערכות מסוימות - מעבר -w 0 על Coreutils גנו לדכא אותו.

כיצד אוכל לפענח אסימון JWT ביד?

פצל את האסימון בשתי הנקודות שלו, קח את הקטע הראשון (כותרת) והשני (מטען), והפעל כל אחד דרך א מפענח Base64- they're Base64URL, אז השתמש בכלי שמקבל - ו _. לאחר מכן פרמט את ה-JSON שנוצר ב-a פורמט JSON לקריאת הטענות לעולם אל תדביק אסימוני ייצור בכלים בצד השרת; בצד הלקוח בלבד.

כיצד אוכל לקודד תמונה או קובץ ל-Base64?

קרא את הקובץ בתור בתים, ואז Base64 את הבתים האלה והכנס כותרת נתונים-URI כמו data:image/png;base64, אז דפדפן יכול לעבד אותו בשורה. ב-JavaScript, FileReader.readAsDataURL() עושה עבורך את שני השלבים; בשורת הפקודה, base64 logo.png מדפיס את הקידוד הגולמי שמור אותו לנכסים קטנים - מס הגודל של 33% הופך את Base64 להתאמה גרועה לכל דבר גדול, ו-URI של ביג דאטה מנפחים את ה-HTML או ה-CSS שלך.

כיצד אוכל לפענח את Base64 ב-JavaScript, Python או במסוף?

ב-JavaScript מודרני, פענח Unicode בבטחה עם new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))) במקום חשוף atob. בפייתון, base64.b64decode(str) מחזירה בתים - שיחה .decode('utf-8') לטקסט. בטרמינל, echo "aGk=" | base64 -d (או --decode). שלושתם מצפים ל-Base64 סטנדרטי, אז תרגם -/_ בחזרה ל +// ראשית אם אתה 're טיפול מחרוזת Base64URL.

הטייקאווי

Base64 הוא טריק בן 30 שנה של ערבוב סיביות שמחזיק בשקט חצי מהרשת המודרנית - אסימוני אישור, קבצים מצורפים, נכסים מוטבעים, סודות-שזה-aren't-secret. להבין את ההתארגנות מחדש של 6 סיביות, לכבד את המס של 33%, לעולם אל תטעה בכך בהצפנה, ולהגיע לגרסה בטוחה לכתובת URL בכל מקום שבו מעורבת כתובת URL. That's 95% מהשליטה המעשית של Base64.

עבור החלק המעשית, ה ממיר Base64 ב-Toolz.dev האם קידוד סטנדרטי ובטוח לכתובת URL כולו בדפדפן שלך - נבנה על ידי מישהו שלמד את שיעור Unicode בדרך הקשה, אז אתה עושה ' לא צריך.

עוד בסדרה זו: המלא מדריך כלי קידוד מכסה את שאר כלי השירות לנהג היומי, ה מדריך בונה Regex מתמודד עם מפתחי המיומנויות האחרים מעמידים פנים שיש להם, ומכיוון שמחצית מניפוי הבאגים של Base64 מסתיים ב-JSON, ה מדריך כלים אולטימטיבי JSON האם הטבעי הבא לקרוא.

מאמרים קשורים:

• המדריך המלא לכלי קידוד
• המדריך האולטימטיבי לכלי JSON (2026)
• כיצד לעצב JSON באינטרנט
• מדריך בונה Regex