לדלג לתוכן

Base64

מתוך ויקיפדיה, האנציקלופדיה החופשית
Base64
סוג binary-to-text encoding, positional numeral system עריכת הנתון בוויקינתונים
שימוש Data URI scheme, Multipurpose Internet Mail Extensions עריכת הנתון בוויקינתונים
מקור
  • RFC 4648: The Base16, Base32, and Base64 Data Encodings
  • RFC 3548: The Base16, Base32, and Base64 Data Encodings עריכת הנתון בוויקינתונים
לעריכה בוויקינתונים שמשמש מקור לחלק מהמידע בתבנית

Base64 היא שיטת קידוד נתונים המייצגת נתונים בינאריים בפורמט טקסטואלי. כל רצף של שש סיביות מיוצג על ידי תו ASCII אחד מתוך קבוצה של 64 תווים אפשריים. המונח Base64 מקורו בקידוד מסוים של MIME.

את הקידוד בשיטה זו ניתן לראות כהעברה מבסיס בינארי (שבו שתי ספרות, 0 ו-1) לבסיס 64 (שבו 64 ספרות). שלושה בתים של 8 סיביות כל אחד (שבהם 24 סיביות בסך הכל) מיוצגים על ידי ארבע ספרות של Base64.

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

בחירת 64 התווים המשמשים לייצוג 64 הספרות של Base64 משתנה בין מימושים שונים של שיטה זו. העיקרון הוא בחירה של 64 תווים הניתנים להדפסה ומשותפים למרבית השיטות לקידוד תווים. בחירה זו מבטיחה שתווים אלה לא ישתנו במעברם בין מערכות שונות. קידוד MIME של Base64 משתמש בתווים 0-9, a-z, A-Z (סה"כ 62 תווים) בתוספת שני התווים '/', '+'. מימושים אחרים בוחרים שני תווים אחרים להשלמת הסדרה של 64 התווים. שיטת uuencode של UNIX משתמשת בתווים 0-9, A-Z, אך במקום התווים a-z משתמשת בשלל סימני פיסוק ותווים אחרים.

Base64 - טבלת ערכים

[עריכת קוד מקור | עריכה]

רצף של שישה ביטים נותן 64 = 26 אפשרויות שונות, ולכן טבלת ההמרה של Base64 כוללת 64 ערכים כדלקמן:

ערך בייצוג
עשרוני
ערך בייצוג
בינארי
תו בקידוד
Base64
ערך בייצוג
עשרוני
ערך בייצוג
בינארי
תו בקידוד
Base64
ערך בייצוג
עשרוני
ערך בייצוג
בינארי
תו בקידוד
Base64
ערך בייצוג
עשרוני
ערך בייצוג
בינארי
תו בקידוד
Base64
0000000A 16010000Q 32100000g 48110000w
1000001B 17010001R 33100001h 49110001x
2000010C 18010010S 34100010i 50110010y
3000011D 19010011T 35100011j 51110011z
4000100E 20010100U 36100100k 521101000
5000101F 21010101V 37100101l 531101011
6000110G 22010110W 38100110m 541101102
7000111H 23010111X 39100111n 551101113
8001000I 24011000Y 40101000o 561110004
9001001J 25011001Z 41101001p 571110015
10001010K 26011010a 42101010q 581110106
11001011L 27011011b 43101011r 591110117
12001100M 28011100c 44101100s 601111008
13001101N 29011101d 45101101t 611111019
14001110O 30011110e 46101110u 62111110+
15001111P 31011111f 47101111v 63111111/

אישורים דיגיטליים (סרטיפיקטים) נפוצים כגון תעודות X.509 בפורמט PEM[1] נשמרים בפורמט Base64 עקב קריאותם הרבה. באופן דומה, תוצאות של פונקציות גיבוב (Hash functions) מוצגות בדרך כלל ב-Base64 מפני שהתוצר הגולמי שלהן עלול להכיל תווים לא קריאים.

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

<data encoding="base64">TextEncodedInBase64ComesHere</data>

הדוגמה הנפוצה ביותר לשימוש יום יומי בפורמט Base64 היא העברת קבצים בדואר אלקטרוני. פרוטוקול SMTP שעליו עובר הדואר האלקטרוני מאפשר העברת תווים רגילים בלבד. כיוון שקובץ הרצה (EXE) או קובץ אופיס מכיל תווים רבים שאינם רגילים, מבצעת תוכנת שליחת הדואר המרה של הקובץ לפורמט Base64 כלומר Encode, ובצד המקבל מבצעת תוכנת הדואר Decode של הקובץ כלומר המרה מפורמט Base64 חזרה למבנה הקובץ המקורי. להמרה זו תוצאת לוואי הגורמת לכך שמערכות דואר "מסרבות" להעביר קבצים גם כשגודלם קטן מהגודל המקסימלי שהמערכת מאפשרת, לדוגמה מערכת המאפשרת העברת דואר עד גודל של עשרה מגהבייט, לא תאפשר שליחת קובץ בגודל שמונה מגהבייט. תופעה זו נגרמת כתוצאה מכך ששלושה בתים מיוצגים בפועל על ידי ארבעה בתים כלומר "ניפוח" של כ-33%.

OpenPGP[2], המתואר ב-RFC 4880 מגדיר קידוד Radix-64 (מכונה גם ASCII Armor). Radix-64 הוא למעשה זהה ל Base64, בתוספת (אופציונלית) של 24 סיביות CRC. ה-Checksum, מחושב על המידע לפני הקידוד ואחר כך עובר בעצמו קידוד Base64, בתוספת תחילית של = המשמשת כתו מפריד, ומשורשר למידע המקודד.

המתודות atob() ו btoa() של שפת JavaScript, המוגדרות במפרט של HTML5[3] נותנות שירות קידוד ל-Base64 עבור קוד JS שרץ בדף אינטרנט. btoa() מוציאה את תווי הריפוד, אך אלו אופציונאליים בקלט של atob()

פרוטוקול LDAP עושה שימוש בפורמט LDIF כדי להציג תוכן ספריות LDAP ולעדכן נתונים. קידוד המחרוזות המועברות בפרוטוקול נעשה באמצעות Base64.

Base64 בעולם התקיפה

[עריכת קוד מקור | עריכה]

השימוש ב-base64 מקובל מאוד בעולם התקיפה:

העברת קבצים

[עריכת קוד מקור | עריכה]

נתוני base64 הם טקסטואליים ולכן קל יחסית להעביר אותם דרך מערכות בדיקה בהשוואה להעברת קבצים בפורמטים אחרים.

CertUtil הוא כלי שבאופן רשמי נועד לניהול אישורים (סרטיפיקטים), אבל כיוון שהוא מותקן על כל מערכת מסוג "חלונות" כברירת מחדל, ניתן להשתמש בו על מנת לפתוח קבצים שנשלחו בפורמט Base64, פעולה החביבה על תוקפי מחשבים, לצורך מעקף תוכנות סינון.

DNS tunneling היא טכניקה להוצאת קבצים מארגונים, כאשר הפיכת מידע ל-Base64 מאשר בניית בקשות DNS שיוציאו את שורות Base64 מהארגון כאשר בסוף התהליך הקובץ נבנה מחדש ומומר לפורמט המקורי.

הטקסט"War @ Peace+" יוצג בקידוד ASCII הקסדצימלי כך: 57 61 72 20 40 20 50 65 61 63 65 2B, ובקידוד ASCII בינארי כך:01010111 01100001 01110010 00100000 01000000 00100000 01010000 01100101 01100001 01100011 01100101 00101011. כל 8 סיביות ברצף זה של 96 סיביות מייצגות תו אחד של הטקסט המקורי. הרצף הראשון 01010111, למשל, מייצג את האות 'W'.

רצף סיביות זה יופרד לקטעים של 6 סיביות כל אחד, וכל קטע של 6 סיביות יוצג באמצעות תו ASCII המתאים לו, לפי הטבלה דלעיל, ובכך יקודד למחרוזת הבאה Base64 של תווי ASCII: V2FyIEAgUGVhY2Ur

כיוון שכל 3 בתים (24 סיביות) ממופים ל-4 תווי Base64, יכול להיות במקרה בו הרצף המקורי אינו מתחלק ב-3 וחייב להתבצע "ריפוד" המשלים את הבתים החסרים בקבוצה האחרונה. בציטוט שבדוגמה יש 12 תווים, שהם 96 סיביות, שאותם ניתן לחלק בדיוק ל-16 קטעים של 6 סיביות. אם נגדיל את הטקסט, בתוספת תו אחד בסופו, כך: War @ Peace+- נקבל מחרוזת של 13 תווים, שהם 104 סיביות, מספר שבחלוקתו לקטעים של 6 סיביות נותן 17 קטעים שלמים, ועוד קטע שבו שתי סיביות בלבד. הקידוד ל-Base64 של טקסט זה נותן את המחרוזת הבאה: V2FyIEAgUGVhY2UrLQ==

תחילתו של קידוד זה זהה לקידוד של המחרוזת בת 12 התווים, ובסופו נוסף הקידוד LQ== של התו הנוסף. בדוגמה שלנו, תו זה (מקף -), מקודד למחרוזת LQ שאינה ממלאת את כל המקום ב"קבוצה" האחרונה. לכן אנו רואים את הסיומת LQ==, כאשר התוספת של הרצף == מצביעה על כך שהקבוצה האחרונה (של 3 תווים) הכילה רק תו אחד במקור ולכן התווסף "ריפוד" של שני תווי = נוספים. במקרים בהם הקבוצה האחרונה מכילה שני תווים, ידרש ריפוד של = בודד.

קישורים חיצוניים

[עריכת קוד מקור | עריכה]

הערות שוליים

[עריכת קוד מקור | עריכה]
  1. PEM Files, באתר How2SSL
  2. קוד פתוח פופולרי להצפנה המבוסס על הסטנדרט PGP
  3. "7.3. Base64 utility methods". HTML 5.2 Editor's Draft. World Wide Web Consortium. {{cite web}}: (עזרה) Introduced by changeset 5814, 2011-02-01.