מדריך סוגי MIME

מהו סוג MIME בעצם

סוג MIME, הנקרא גם סוג מדיה, הוא תווית קצרה המספרת לתוכנה איזה סוג נתונים מכיל קובץ או גוף הודעה. הוא נולד בדוא"ל (השם מייצג Multipurpose Internet Mail Extensions) אך כיום הוא מופיע בכל מקום ברשת. הפורמט הוא תמיד type/subtype: קטגוריה רחבה, קו נטוי, ופורמט ספציפי. כך ש-text/html משמעו "טקסט, בצורת HTML", image/png משמעו "תמונה, בצורת PNG", ו-application/json משמעו "נתוני יישום, מקודדים כ-JSON".

הtype העליון מגיע מקבוצה קבועה המתוחזקת על ידי IANA, המרשם הרשמי: text, image, audio, video, application, font, model, multipart, וכמה חדשים יותר כמו haptics. הsubtype הוא הפורמט הספציפי. ספקים יכולים להוסיף משלהם בעזרת קידומת vnd. (לדוגמה application/vnd.ms-excel), וסוגים ניסיוניים השתמשו היסטורית בקידומת x-, אם כי מוסכמה זו כיום אינה מומלצת.

היכן חשוב סוג MIME

המקום החשוב ביותר שבו מופיע סוג MIME הוא כותרת התגובה של HTTP‏ Content-Type. כאשר שרת שולח דף, תמונה או מטען API, כותרת זו מספרת לדפדפן איך לפרש את הבתים. אם הכותרת אומרת text/html, הדפדפן מרנדר סימון; אם היא אומרת application/json, קריאת fetch() יכולה לנתח אותו; אם היא אומרת application/pdf, המציג המובנה נפתח. אותה כותרת נוסעת גם בצד הבקשה: כשאתם שולחים טופס או גוף API ב-POST, Content-Type מספר לשרת איך לקרוא את מה ששלחתם.

מעבר ל-HTTP, סוגי MIME מניעים מספר מערכות נוספות. תוכנות דוא"ל משתמשות בהם כדי להחליט האם קובץ מצורף הוא תמונה שאפשר להציג בתצוגה מקדימה או קובץ בינארי שיש לשמור. מטפלי העלאת קבצים בודקים את הסוג המוצהר כדי לקבל או לדחות קבצים. ומערכת ההפעלה או הדפדפן משתמשים בסוג, לא רק בסיומת הקובץ, כדי לבחור יישום ברירת מחדל. אותו רעיון עומד בבסיס האופן שבו שרתים מדווחים על תוצאות ושגיאות לצד קודי סטטוס HTTP — תגובת 200 עם הסוג השגוי יכולה להיות שבורה בדיוק כמו 404.

אלה שתשתמשו בהם כל יום

קומץ סוגים מכסה את רוב התעבורה האמיתית:

• text/html — דפי אינטרנט (סיומת .html)
• text/css — גיליונות סגנון (.css)
• text/javascript — הסוג המומלץ עבור JavaScript (.js,‏ .mjs)
• application/json — סוג ה-JSON הרשמי היחיד, המוגדר ב-RFC 8259 (.json)
• image/png,‏ image/jpeg,‏ image/webp,‏ image/svg+xml — פורמטי תמונה נפוצים
• application/pdf — מסמכי PDF (.pdf)
• application/octet-stream — קטגוריית הכל-כלול עבור נתונים בינאריים לא ידועים או שרירותיים
• text/plain — ברירת המחדל עבור טקסט פשוט ללא סוג עשיר יותר

ל-JSON מגיעה הערה מיוחדת כי הוא מבלבל אנשים. הסוג הנכון היחיד הוא application/json. קוד ישן לפעמים השתמש ב-text/json,‏ text/plain או application/x-javascript, אך אלה מיושנים וחלק מהלקוחות יסרבו לנתח אותם. אין גם פרמטר charset עבור JSON — המפרט מחייב UTF-8, כך שכתיבת application/json; charset=utf-8 מיותרת אך לא מזיקה. לטבלה מלאה יותר של פורמטים וסיומות, ראו את טבלאות העזר שלנו.

מדוע Content-Type שגוי שובר דברים

דפדפנים ולקוחות סומכים על הסוג המוצהר, כך שטעות בו יש לה השלכות מוחשיות. הגישו תגובת API של JSON כ-text/html והדפדפן עשוי לנסות לרנדר אותה, או שלקוח מחמיר יזרוק שגיאת ניתוח לפני שהקוד שלכם בכלל רץ. הגישו קובץ CSS או JavaScript עם הסוג השגוי, ותכונת אבטחה בשם X-Content-Type-Options: nosniff תגרום לדפדפן לסרב להחיל אותו, ותשבור בשקט את עיצוב הדף או את הסקריפטים שלכם.

הורדות הן הכשל הקלאסי האחר. אם אתם רוצים שקובץ יורד ולא יוצג, הסוג חשוב יחד עם כותרת Content-Disposition. קובץ PDF שנשלח כ-application/octet-stream יורד כקובץ גנרי במקום להיפתח במציג; תמונה שנשלחת כ-text/plain מוצגת כתווים חסרי משמעות. בצד ההעלאה, קובץ שתויג בטעות יכול לעבור בדיקת סיומת נאיבית, וזו הסיבה שמאמתים חזקים בודקים את הבתים האמיתיים ("המספר הקסום") במקום לסמוך על הסוג שסופק על ידי הלקוח.

היסטורית, דפדפנים ניסו לנחש, או "להריח" (sniff), את הסוג האמיתי כשהכותרת נראתה שגויה. התנהגות זו גרמה לפרצות אבטחה, כך שהנוהג המומלץ המודרני הוא תמיד לשלוח Content-Type מדויק ולנטרל הרחה עם nosniff. בקצרה: הגדירו את הסוג בכוונה בכל תגובה, ורוב באגי הרינדור, ההורדה והניתוח נעלמים.

שאלות נפוצות