בפעם הראשונה בינארית נשכה אותי באמת, זה לא היה בשיעור מדעי המחשב - זה היה בבאג ייצור תוסף וורדפרס שאני מחזיק היה אחסון מחרוזת קצרה באופן שיבלבל כל תו שאינו אנגלי, וכדי להבין היכן קרתה השחיתות הייתי צריך להסתכל על הבתים בפועל הדבקתי את המחרוזת השבורה לתוך " טקסט לבינארי" תיבה שמצאתי באינטרנט, קיבלתי בחזרה קיר של אחדות ואפסים, ומיד הבנתי שהכלי טיפל רק בתווי ASCII ושמט בשקט את אלה המודגשים הבתים שהוא הראה לי היו שקר, ובזבזתי אחר צהריים במרדף אחר השכבה הלא נכונה של הערימה.
זה העניין בהמרה בינארית: זה נראה כמו צעצוע, ורוב הכלים החינמיים מתייחסים לזה כמו אחד מתרגם נכון צריך לקודד את כל מגוון התווים שאנשים באמת מקלידים - מבטאים, אימוג'י, סינית, ערבית - דרך UTF-8, הקידוד שהרשת המודרנית פועלת עליו, והיא צריכה לפענח אותם בחזרה בית-עבור-בית. אני בונה Toolz.dev, התוסף WP Adminify, וכמות נכבדת של Laravel ו-React, אז אני עובר בין טקסט לייצוג הבתים שלו יותר ממה שהייתי רוצה, ובניתי את מתרגם בינארי כדי לבצע את ההמרה בצורה נכונה עבור כל תו, לא רק את ה-128 הקל.
TL;DR: מתרגם בינארי הופך טקסט לאלו ואפסים שמחשב מאחסן, והופך את אלה ואפסים בחזרה לטקסט המלכוד הוא קידוד תווים: ASCII מכסה רק 128 תווים, בעוד שטקסט אמיתי צריך UTF-8, כאשר תו אחד יכול להיות אחד עד ארבעה בתים מתרגם בינארי מקודד ומפענח את המלא יוניקוד טווח - כולל אימוג'י - בבינארי, משושה, עשרוני ואוקטלי, כולו בדפדפן שלך, ואומר לך בדיוק איזה אסימון שגוי כאשר משחה לא מצליחה לפענח.
מה זה מתרגם בינארי, באמת?
מתרגם בינארי הוא ממיר בין טקסט קריא אנושי לבין הייצוג המספרי שבו משתמש מחשב כדי לאחסן את הטקסט הזה כל תו שאתה מקליד מאוחסן כבייט אחד או יותר - מספרים מ-0 עד 255 - וכל בייט יכול להיכתב בבינארי (בסיס 2), הקסדצימלי (בסיס 16), עשרוני (בסיס 10), או אוקטלי (בסיס 8) תרגום "Hi" ל-natives בינארי 01001000 01101001; שתי הקבוצות של שמונה סיביות הן שני הבתים עבור "H" ו-"i".
המילה "translate" עושה כאן עבודה אמיתית, כי יש טבלת תרגום מעורבת ערך בתים של 72 לא אומר מטבעו את האות "H" - זה אומר "H" רק בגלל שקידוד תווים אומר זאת. עבור האותיות הבסיסיות באנגלית, ספרות וסימני פיסוק נפוצים, המיפוי הזה הוא ASCII, תקן משנות ה-1960 שמקצה 128 תווים לערכים 0 עד 127. ASCII הוא הסיבה לכך "H" הוא 72 ורווח הוא 32, וזה החלק של המרה בינארית שכולם מקבלים נכון.
הבעיות מתחילות מעל ערך 127 העולם מקליד הרבה יותר מ-128 תווים נפרדים, והקידוד שמטפל בשאר - זה שהדפדפן שלך, מסד הנתונים שלך וה-JSON שלך משתמשים בו כמעט בוודאות - הוא UTF-8 מתרגם בינארי טוב הוא באמת קודק UTF-8 עם שכבת המרת בסיס למעלה מתרגם בינארי בנוי בדיוק כך, וזו הסיבה שהוא יכול להקיף מחרוזת המכילה אימוג'י ולהחזיר לך את התו הזהה.
איך בעצם עובדת המרת טקסט לבינארי?
הפיכת טקסט לבינארי היא צינור דו-שלבי, והבנת השלבים מסבירה את כל מה שהכלי עושה השלב הראשון הוא קידוד התווים לבייטים, והשני הוא כתיבת כל בייט בבסיס שבחרת.
קידוד הוא המקום שבו UTF-8 חי. UTF-8 הוא קידוד באורך משתנה: תו לוקח בית אחד אם הוא תו ASCII רגיל, שני בתים עבור רוב האותיות במבטא לטיני וסמלים רבים, שלושה בתים עבור עיקר העולם ' סקריפטים של s כולל סינית, יפנית וקוריאנית, וארבעה בתים עבור תווים ואימוג'י פחות נפוצים. אז "A" הוא בית אחד, "é" הוא שניים, "中国 " הוא שלושה, ואימוג'י פנים הוא ארבעה. המקודד עובר דרך המחרוזת, ועבור תווים מחוץ לטווח הבסיסי הוא מייצר את רצף ריבוי הבתים הנכון, עם הסיביות המובילות שמסמנות כמה בתים עוקבים.
השלב השני הוא אריתמטיקה טהורה ברגע שיש לך רשימה של ערכי בתים, כתיבתם באמצעים בינאריים המבטאים כל מספר מ-0 עד 255 כשמונה ביטים, מרופד באפס כך שכל בית הוא באותו רוחב הקסדצימלי כותב כל בית כשני תווים בדיוק (00 עד ff), וזו הסיבה שהקס הוא המועדף הקומפקטי לצפייה בנתונים גולמיים אוקטל משתמש בשלוש ספרות לכל בייט, והעשרוני רק מציג את המספר הפשוט מתרגם בינארי מאפשר לך לעבור בין כל ארבעת הבסיסים באופן מיידי מכיוון שהבתים הבסיסיים זהים - רק פורמט התצוגה משתנה.
כיצד המפענח מפענח בינארי בחזרה לטקסט?
פענוח הופך את הצינור, וזה הכיוון שבו רוב הכלים נכשלים בשקט ראשית הכלי צריך קרא את הקלט שלך לערכי בתים, אז זה חייב פענח את הבתים האלה כ-UTF-8 בחזרה לתווים.
קריאת הקלט פירושה אסימון אם אתה מדביק בינארי עם רווחים בין הבתים, כל קבוצה היא בית אחד אם אתה מדביק ריצה רציפה אחת ארוכה של ביטים, הכלי מקבץ אותם לשמיניות - מה שעובד רק אם האורך הכולל הוא כפולה של שמונה, אז אורך אי זוגי מסומן ולא נקרא בצורה שגויה בשקט. אותו היגיון חל על hex: שני תווים לכל בייט, כך שמספר אי זוגי של ספרות hex הוא שגיאה. פסיקים, רווחים, כרטיסיות ומעברי שורות כולם פועלים כמפרידים, כך שתוכל להדביק כל פורמט שממנו העתקת מבלי לעצב אותו מחדש תחילה.
השלב השני בונה מחדש תווים מבייטים, וכאן משנה מבנה UTF-8' מבנה s. בייט בטווח 0-127 הוא תו עצמאי. בייט עם תבנית ספציפית של סיביות גבוהות מסמן את תחילתו של רצף של שניים, שלושה או ארבעה בתים, ולבתים הבאים חייב להיות דפוס המשך משלהם. אם הם לא - כי חסר בייט, או שהרצף נותק, או שהנתונים מעולם לא היו חוקיים UTF-8 מלכתחילה - ה מתרגם בינארי מדווח שרצף הבתים אינו טקסט חוקי ולא פולט תווים חלופיים או זבל. הכנות הזו היא הנקודה: כאשר פענוח נכשל, אתה רוצה לדעת שהנתונים שגויים, לא לבהות במוג'יבאק ותוהה אם הכלי נשבר.
בינארי, משושה, עשרוני או אוקטלי - באיזה עלי להשתמש?
כולם מייצגים את אותם בתים, אז הבחירה היא על מי קורא ומה הם רגילים לכל בסיס יש נישה שבה הוא ההתאמה הטבעית.
| בסיס | ספרות לכל בייט | הטוב ביותר עבור | דוגמה עבור "H" (72) |
|---|---|---|---|
| בינארי (2) | 8 | למידה, עבודה ברמת סיביות, מראה מבנה מדויק | 01001000 |
| הקסדצימלי (16) | 2 | צפייה בנתונים גולמיים, איתור באגים, צבע ו-byte dump | 48 |
| עשרוני (10) | 1–3 | ערכי בתים ידידותיים לאדם, התייחסות מהירה | 72 |
| אוקטל (8) | 3 | הרשאות קובץ יוניקס, כמה מערכות מדור קודם | 110 |
בינארי הוא המפורש ביותר והטוב ביותר להוראה, כי אתה יכול לראות כל סיביות, אבל זה verbose - שמונה תווים לכל בייט מצטבר מהר. Hexadecimal הוא מה שאתה בעצם להשתמש ביותר בפועל: הוא קומפקטי, הוא ממפה בצורה נקייה לבייטים בשני תווים כל אחד, וזה הפורמט hex עורכים, dump זיכרון, וקודי צבע כל מדברים עשרוני הוא שימושי כאשר אתה רק רוצה לדעת תו & #39;s ערך מספרי. Octal הוא נישה holdover, המוכר ביותר מסיביות הרשאות Unix כמו 755, וזה כאן בעיקר אז הכלי הושלם. ה מתרגם בינארי עובר בין כל הארבעה מבלי שתזין מחדש דבר, כך שתוכל להשוות ייצוגים זה לצד זה.
מדוע UTF-8 משנה כל כך להמרה בינארית?
כי "טקסט לבינארי" חסר משמעות עד שתחליט באיזה קידוד אתה ממיר, ועבור האינטרנט המודרני התשובה הזו היא כמעט תמיד UTF-8. נראה שכלי שמטפל רק ב-ASCII עובד - הוא ימיר בשמחה טקסט באנגלית - ואז יבגוד בך ברגע שהנתונים בעולם האמיתי יופיעו.
שקול את "é" המודגש. ב-UTF-8 זה שני בתים, 11000011 10101001, או c3 a9 ב hex.כלי שמתייחס לכל תו כאל בית ASCII יחיד לא יכול לייצג אותו בכלל; במקרה הטוב הוא מפיל את התו, במקרה הרע הוא מייצר בית אחד שגוי. עכשיו שקול אימוג'י, שהוא ארבעה בתים ב-UTF-8. כלים נאיביים מעוותים את אלה לחלוטין. כי ה מתרגם בינארי האם קודק UTF-8 אמיתי, "café" מייצר את חמשת הבתים הנכונים, ומדביק את חמשת הבתים האלה בחזרה מחזיר "café" בִּדְיוּק.
זה לא אקדמי כל מי שנוגע בתוכן בינלאומי, נתונים שנוצרו על ידי משתמשים או כל דבר עם אימוג'י יפגע בתווים מרובי בתים באופן מיידי. אם אתה רוצה את הרקע העמוק יותר, ה מדריך קידוד Base64 מכסה את אותה חשיבה ברמת בתים עבור קידוד קשור, והבנת האחד גורמת לשני ללחוץ הגרסה הקצרה: בתים הם אוניברסליים, אבל המיפוי בין בתים ותווים הוא בחירה, ו-UTF-8 הוא הבחירה שהרשת עשתה.
מקרי שימוש נפוצים שבהם מתרגם בינארי מרוויח את החזקתו
למידה והוראה כיצד מחשבים מאחסנים טקסט
הסיבה הנפוצה ביותר שאנשים מחפשים מתרגם בינארי היא להבין את המושג הקלדת השם שלך וצפייה בו הופך לבייטים הופכת את ההפשטה לקונקרטית באופן שהרצאה לא יכולה. מכיוון שהכלי מציג את קבוצות שמונה הסיביות המדויקות ומאפשר לך לעבור להקס ועשרוני, הוא משמש כעזר הוראה לאופן שבו קידוד ובסיסי מספרים קשורים. תלמידים יכולים לראות את זה "A" הוא 65, 01000001, ו 41 בהקס בבת אחת.
איתור באגים בבעיות קידוד
זה המקום שבו אני מושיט יד אליו. כאשר מחרוזת פגומה - הקלאסי "é מופיע בתור é" mojibake - הדרך המהירה ביותר לאבחן אותה היא להסתכל על הבתים. קידוד המחרוזת השבורה מגלה אם הנתונים היו מקודדים כפולים, קטועים באמצע התו, או מעוותים על ידי מערכת שהניחה קידוד שגוי. לראות את הבתים הגולמיים הופך " מעורפל; התווים שגויים" לאבחנה ספציפית הניתנת לתיקון.
עבודה עם פורמטים ופרוטוקולים ברמה נמוכה
שפע של עבודה טכנית כוללת קריאת בתים ישירות: מנות רשת, כותרות קבצים, פרוטוקולים בינאריים ומערכות משובצות מדברים כולם בהקס ובינארי היכולת להפוך במהירות קטע טקסט לייצוג הבתים שלו, או לפענח מחרוזת hex שנלכדה בחזרה לטקסט קריא, שומרת החלפת הקשר מתמדת תצוגת hex בפרט מתיישרת עם מה שעורכי hex ומאתרי באגים מראים.
פאזלים, CTFs והודעות נסתרות
בינארי ומשושה הם מרכיב עיקרי בתחרויות לכידת הדגל, חדרי בריחה וחידות חנונים מחרוזת של אחדים ואפסים היא דרך נפוצה להסתיר הודעה קצרה, והיכולת להדביק אותה ולפענח אותה - בכל אחד מארבעת הבסיסים, עם קלט רציף או מרווח - עושה עבודה קצרה על אלה הודעות השגיאה הברורות עוזרות כאשר לקלט הפאזל יש שגיאת הקלדה או מפריד בלתי צפוי.
למה להמיר בדפדפן במקום בשרת?
ה מתרגם בינארי פועל לחלוטין בצד הלקוח הטקסט שאתה מקודד ומחרוזות הבתים שאתה מפענח לעולם לא עוזבים את המחשב שלך, והכלי ממשיך לעבוד כשהחיבור שלך כבוי לאחר טעינת הדף. זה חשוב יותר ממה שהוא נראה לראשונה: המחרוזות שאנשים ממירים הן לרוב אסימונים, מזהים פנימיים, קטעי נתוני משתמש או בתים של פרוטוקול שנלכדו - בדיוק מסוג הדברים שאסור להדביק לשרת אקראי. עיבוד בדפדפן אומר שאין שרת להדביק בו פרטיות נתונים בכלים מקוונים המדריך טוען את הטענה המלאה יותר להתעקשות על כך.
המרה בינארית יושבת גם לצד מקבץ של משימות קידוד קשורות. ה מקודד/מפענח Base64 מטפל בקידוד המשמש להעברת בינארי דרך ערוצי טקסט בלבד כמו כתובות דואל ונתונים. ה מקודד/מפענח כתובת URL מכסה אחוז קידוד עבור מחרוזות שאילתה. וה מְחוּגָה הופך טקסט לעיכולים באורך קבוע כאשר אתה צריך טביעת אצבע ולא ייצוג הפיך. לערכה הרחבה יותר אני שומר פתוחה בזמן הבנייה, ה ערכת כלים למפתחי אינטרנט roundup היא נקודת התחלה טובה.
שָׁוא
איך אני ממיר טקסט לבינארי?
פתח את המתרגם הבינארי, בחר "Text to Binary", שמור את הבסיס מוגדר לבינארי, והקלד את הטקסט שלך כל תו מקודד לערך UTF-8 בתים שלו ומוצג כקבוצות של 8 סיביות, כך "A" הופך ל-01000001. הפלט מתעדכן תוך כדי הקלדה וניתן להעתיק אותו בלחיצה אחת, ותוכל לעבור להקס, עשרוני או אוקטלי מבלי להזין דבר מחדש.
כיצד אוכל להמיר חזרה בינארית לטקסט?
בחר "Binary to Text" והדבק את הבינארי שלך. באפשרותך להפריד בתים עם רווחים, פסיקים או מעברי שורות, או להדביק ריצה רציפה אחת של סיביות כל עוד האורך הכולל הוא כפולה של שמונה הכלי מקבץ את הסיביות לבייטים ומפענח אותם כ-UTF-8 כדי לבנות מחדש את התווים המקוריים, והוא מדווח על שגיאה אם האורך שגוי או תו אינו חוקי.
באיזה קידוד תווים משתמש המתרגם הבינארי?
הוא משתמש ב-UTF-8, הקידוד המשמש את האינטרנט המודרני ורוב שפות התכנות. תווי ASCII לוקחים בית אחד, רוב האותיות המודגשות לוקחות שניים, וסקריפטים רבים וכל האימוג'י לוקחים שלושה או ארבעה בתים. המשמעות היא שהכלי מטפל בצורה נכונה בהרבה יותר מאנגלית פשוטה, בניגוד לכלים פשוטים שממפים רק את 128 תווי ASCII.
האם זה יכול להמיר גם להקסדצימלי, עשרוני ואוקטלי?
כן. בורר בסיס מחליף את הפלט בין בינארי, הקסדצימלי, עשרוני ואוקטלי, והפענוח מקבל כל אחד מהבסיסים הללו כקלט. הקסדצימלי מציג שני תווים לכל בייט, אוקטלי שלוש ספרות, עשרוני הערך הפשוט של 0 עד 255, ובינארי את שמונה הסיביות המלאות. כל הארבעה מייצגים את אותם בתים בסיסיים.
למה זכה 't הפענוח הבינארי שלי?
שתי הסיבות הנפוצות ביותר הן אורך סיביות שאינו כפולה של שמונה ותווים תועים שאינם תקפים עבור הבסיס הנבחר הכלי אומר לך בדיוק איזה אסימון אינו חוקי או שהאורך שגוי, כך שתוכל לתקן אותו רצף בתים שאינו חוקי UTF-8 - למשל תו מרובה בתים שנחתך - מסומן גם הוא ולא מפוענח לאשפה.
האם המתרגם הבינארי תומך באימוג'י ובטקסט שאינו באנגלית?
כן. מכיוון שהוא מקודד דרך UTF-8, תווים מחוץ לטווח ASCII מיוצגים כרצף הנכון של שניים, שלושה או ארבעה בתים, והפענוח מרכיב אותם מחדש לתו המקורי. אימוג'י הופך לארבעה בתים ונסיעות הלוך ושוב לאותו אימוג'י, וטקסט לטיני סיני, ערבי או מודגש פועל באותו אופן.
האם בטוח להמיר כאן טקסט רגיש?
כן כל המרה פועלת ב-JavaScript בתוך הדפדפן שלך, כך ששום דבר שאתה מזין לא מועלה, נרשם או מאוחסן, והכלי ממשיך לעבוד ללא חיבור לאינטרנט לאחר הטעינה. אתה יכול להמיר בבטחה אסימונים, מזהים פנימיים או הודעות פרטיות מבלי שהם יעזבו את המכשיר שלך.
מה ההבדל בין ASCII ל-UTF-8 בכלי זה?
ASCII הוא קבוצה של 7 סיביות המכסה 128 תווים באנגלית, בעוד UTF-8 הוא קידוד באורך משתנה הכולל את כל ASCII בתוספת כל תו Unicode אחר. מכיוון ש-UTF-8 הוא ערכת-על של ASCII, טקסט באנגלית מייצר בדיוק את הבתים שטבלת ASCII תחזה, בעוד שאותיות מודגשות, סקריפטים אחרים ואימוג'י מקבלים את הרצפים הנכונים של ריבוי בתים ש-ASCII פשוט לא יכול לייצג.
