Multipurpose Internet Mail Extensions eller MIME (på spansk "multipurpose internet mail extensions") er en serie konvensjoner eller spesifikasjoner som tar sikte på å utveksle alle typer filer (tekst, lyd, video, etc.) over Internett på en gjennomsiktig måte. bruker. En viktig del av MIME er dedikert til å forbedre mulighetene for å overføre tekst på forskjellige språk og alfabeter. I en generell forstand er MIME-utvidelsene rettet mot å innrømme:
Så godt som alle e-postmeldinger skrevet av folk på Internett og en betydelig andel av disse automatisk genererte meldingene blir overført i MIME-format via SMTP . E-postmeldinger på Internett er så nært knyttet til SMTP og MIME at de ofte kalles SMTP/MIME- meldinger . [ 1 ]
I 1991 begynte IETF å utvikle denne standarden, og siden 1994 er alle MIME-utvidelser spesifisert i detalj i forskjellige offisielle dokumenter tilgjengelig på Internett.
MIME er spesifisert i seks forespørsler om kommentarer ( RFCer ): RFC 2045 , RFC 2046 , RFC 2047 , RFC 4288 , RFC 4289 og RFC 2077 .
Innholdstypene definert av MIME-standarden er av stor betydning også utenfor sammenheng med elektroniske meldinger. Eksempler på dette er noen nettverksprotokoller som HTTP of the Web . HTTP krever at dataene overføres i sammenheng med e-postmeldinger, selv om dataene kanskje ikke er en e-postmelding i seg selv.
Foreløpig kan ingen e-postprogram eller nettleser betraktes som komplett hvis den ikke aksepterer MIME i sine forskjellige fasetter (tekst og filformater).
Internetts grunnleggende elektroniske meldingsoverføringsprotokoll støtter kun 7-bits ASCII -tegn (se også 8BITMIME ). Dette begrenser e-postmeldinger siden de bare inneholder nok tegn til å skrive på et lite antall språk, hovedsakelig engelsk. Andre språk basert på det latinske alfabetet er i tillegg en grunnleggende komponent i kommunikasjonsprotokoller som HTTP , som krever at data overføres som en e-postmelding selv om dataene kanskje ikke er en e-postmelding i seg selv. E-postklienter og e- postservere konverterer automatisk fra og til MIME-format når de sender eller mottar (SMTP/MIME) e-poster.
MIME tildeler et navn til hver datatype. Navnene følger følgende format:
type/undertype (type og undertype er tegnstrenger)
Typen definerer den generelle kategorien til dataene, og undertypen definerer en mer spesifikk type data. Typen kan inneholde følgende verdier:
Tilstedeværelsen av denne overskriften indikerer at meldingen bruker MIME-formatet. Verdien er vanligvis lik "1.0", så denne overskriften vises som:
MIME-versjon: 1.0Det skal bemerkes at implementere har forsøkt å endre versjonsnummeret tidligere, og endringen har gitt uventede resultater. På et IETF- møte i juli 2007 ble det besluttet å beholde versjonsnummeret på "1.0" selv om det er gjort mange oppdateringer til MIME-versjonen.
Denne overskriften angir typen media som representerer innholdet i meldingen, den består av en type: type og en undertype: subtype , for eksempel:
Innholdstype: tekst/vanligGjennom bruk av flerdelt type ( multipart ), gir MIME muligheten til å lage meldinger som har deler og underdeler organisert i en trestruktur der bladnoder kan være en hvilken som helst ikke-flerdelt innholdstype og ikke - bladnoder kan være ikke-flerdelte. være av en hvilken som helst variant av flerdelte typer. Denne mekanismen støtter:
I juni 1992 definerer MIME ( RFC 1341 er gjort foreldet av den nye RFC 2045 ) et sett med metoder for å representere binære data ved å bruke ASCII-tekst. Content-transfer-encoding: MIME-overskriften indikerer metoden som har blitt brukt. RFC- og IANA -listen definerer følgende verdier, som ikke skiller mellom store og små bokstaver:
Det er ingen eksplisitt definert koding for å sende vilkårlige binære data over en SMTP-transport med 8BITMIME-utvidelsene. Derfor må base64 eller quoted-printable (med tilhørende ineffektivitet) fortsatt brukes. Disse begrensningene gjelder ikke for annen bruk av MIME, for eksempel webtjenester med MIME- eller MTOM -vedlegg.
Siden RFC 2822 er navnene og verdiene på meldings-MIME-hodene alltid ASCII-tegn; verdier som inneholder andre typer tegn må bruke kodet ord- syntaks ( RFC 2047 ) i stedet for bokstavelig tekst. Denne syntaksen bruker en streng med ASCII-tegn som indikerer det opprinnelige tegnsettet (" tegnsettet ") og innholdsoverføringskodingen som brukes til å kartlegge bytene til det originale settet til ASCII-tegn.
Dens generelle form er:
=?tegnsett - ?koding kodet ?tekst?=ASCII-kodene til spørsmålstegnet (?) og likhetstegnet (=) kan ikke representeres direkte siden de brukes som skilletegn for det kodede ordet. ASCII-koden reservert for plass kan ikke representeres direkte fordi den kan føre til at eldre tolker utilsiktet splitter det kodede ordet. For å gjøre kodingen mindre og lettere å lese, brukes understrekingssymbolet (_) i stedet for mellomrommet, og skaper bivirkningen at dette symbolet ikke kan representeres direkte. Bruken av kodet ord i visse deler av overskrifter pålegger ytterligere begrensninger på hvilke tegn som kan eller ikke kan representeres direkte.
For eksempel:
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=tolkes som:
Emne: Hei, sir!Det kodede ordformatet brukes ikke for overskriftsnavn (for eksempel Subject). Disse overskriftsnavnene er alltid på engelsk. Når meldingen leses med en e-postklient på et annet språk enn engelsk, oversettes navnene på overskriftene av klienten.
En flerdelt MIME-melding inneholder en kantlinje i "Content-type:"-overskriften; denne grensen, som ikke kan vises i noen av delene, er plassert mellom hver av dem, og på begynnelsen og slutten av meldingsteksten, som vist nedenfor:
MIME-versjon: 1.0 Innholdstype: flerdelt/blandet; boundary="border" Dette er en flerdelt melding i MIME-format. --grense Innholdstype: tekst/vanlig Dette er innholdet i meldingen --grense Innholdstype: applikasjon/oktettstrøm Innholdsoverføringskoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+RXN0ZSBlcyBlbCBjdWVy cG8gZGVsIG1lbnNhamU8L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cic=\ --grense--Hver del består av sin egen innholdsoverskrift (null eller flere innholdsoverskriftsfelt ) og en kropp. Flerdelt innhold kan nestes. Innholdsoverførings-kodingshodet for en flerdelt type må alltid være "7bit", "8bit" eller "binært" for å unngå komplikasjonene pålagt av tilstedeværelsen av flere dekodingsnivåer. Den flerdelte blokken, som helhet, har ingen spesifikasjoner om tegnsettet ( tegnsett ); ikke-ASCII-tegn i deloverskrifter håndteres via Encoded-Word , og deltekster kan ha spesifiserte tegnsett hvis det er aktuelt for deres innholdstype.
Karakterer:
MIME-standarden definerer flere undertyper for flerdelte meldinger, disse spesifiserer typen av meldingsdelen og dens forhold til andre deler. Undertypen er spesifisert i "Content-type"-overskriften for hele meldingen. For eksempel vil en flerdelt MIME-melding som bruker sammendragsundertypen ha en "Content-Type": "multipart/digest".
RFC definerer i utgangspunktet 4 undertyper: blandet, fordøyd, alternativ og parallell. En minimalt kompatibel applikasjon må støtte minst blandet og fordøye; alle andre undertyper er valgfrie. Andre RFC-er definerer tilleggsundertyper som: signert og skjemadata.
Følgende er en liste over de mest brukte undertypene:
BlandetMultipart/mixed brukes til å sende meldinger eller filer med forskjellige "Content-Type"-overskrifter enten inline eller som vedlegg. Hvis bilder eller andre lett lesbare filer sendes, vil de fleste e-postklienter vise dem som en del av meldingen (med mindre "Content-disposition"-overskriften er spesifisert annerledes). Ellers vil de bli tilbudt som vedlegg. Den implisitte innholdstypen for hver del er "tekst/ren".
Definert i RFC 2046, avsnitt 5.1.3
MeldingEn melding/rfc822-del inneholder en e-postmelding, inkludert eventuelle overskrifter . Rfc822 er en feilbetegnelse, siden meldingen kan være en fullstendig MIME-melding. Den brukes også til sammendrag for å videresende meldinger.
Definert i RFC 2046 .
fordøyeMultipart/digest er en enkel måte å sende flere tekstmeldinger på. Den implisitte innholdstypen for hver del er "message/rfc822".
Definert i RFC 2046, avsnitt 5.1.5 .
AlternativDen flerdelte/alternative undertypen indikerer at hver del er en "alternativ" versjon av det samme (eller lignende) innholdet, hver i forskjellige formater angitt med "Content-Type"-overskriften. Formatene er ordnet etter hvor trofaste de er mot originalen, med de minst trofaste i begynnelsen. Systemer kan velge den "beste" representasjonen de er i stand til å behandle; generelt vil dette være den siste delen som systemet forstår, med mindre andre faktorer kan påvirke denne oppførselen.
Siden det er usannsynlig at en klient vil sende en versjon som ikke er sann til rentekstversjonen, plasserer denne strukturen rentekstversjonen (hvis noen) først. Dette gjør det lettere for brukere av klienter som ikke forstår flerdelte meldinger å lese meldingene.
Det som oftest skjer er å bruke flerdelt/alternativ for meldinger med to deler, en ren tekst (tekst/ren) og en HTML (tekst/html). Rentekstdelen gir kompatibilitet med gamle klienter som ikke er i stand til å forstå andre formater, mens HTML-delen lar deg bruke tekstformatering og lenker. Mange e-postklienter gir brukeren muligheten til å foretrekke ren tekst fremfor HTML; dette er et eksempel på hvordan lokale faktorer kan påvirke hvordan en applikasjon velger den "beste" delen av meldingen som skal vises.
Selv om hver del er ment å representere det samme innholdet, er dette ikke nødvendig. Noen spamfiltre undersøker kun teksten/ren del av en melding fordi den er lettere å analysere enn tekst/html-delene. Men spammere , som la merke til dette, begynte å lage meldinger med en tekst/ren del som ser ut til å være ufarlig og inkluderer propagandaen i tekst/html-delen. Vedlikeholderne av anti-spam-programmer har modifisert sine filtre, og straffer meldinger med svært forskjellige tekster i en flerdelt/alternativ melding.
Definert i RFC 2046, avsnitt 5.1.4
RelatertMultipart/relatert undertype brukes til å indikere at meldingsdeler ikke bør betraktes individuelt, men snarere som aggregater av en helhet. Meldingen består av en rotdel (implisitt den første) som refererer til andre deler, som igjen kan referere til andre deler. Deler refereres ofte til med overskriften: "Content-ID". Syntaksen til referansen er ikke spesifisert, men dikteres av kodingen eller protokollen som brukes i delen som inneholder referansen.
En vanlig bruk av denne undertypen er å sende hele nettsider med bilder i en enkelt melding. Rotdelen vil inneholde HTML -dokumentet , som vil bruke HTML-bildekoder for å referere til bilder som er lagret i påfølgende deler.
Definert i RFC 2387
RapporterMultipart/rapport er en type melding som inneholder data formatert for en e-postserver å tolke. Det er mellom en tekst/vanlig (eller en annen lett lesbar innholdstype) og en melding/leveringsstatus.
Definert i RFC 3462
signertDen flerdelte/signerte undertypen brukes til å legge ved en digital signatur til meldingen. Den har to deler, en kroppsdel og en signaturdel . Hele kroppsdelen, inkludert MIME-overskriftene, brukes til å lage signaturdelen. Det finnes mange typer signaturer, for eksempel applikasjon/pgp-signatur og applikasjon/x-pkcs7-signatur.
Definert i RFC 1847, avsnitt 2.1
KryptertEn flerdelt/kryptert melding har to deler. Den første inneholder kontrollinformasjon som er nødvendig for å dekryptere den andre delen, av typen applikasjon/oktettstrøm.
Definert i RFC 1847, avsnitt 2.2
FormDataSom navnet tilsier, brukes multipart/form-data for å uttrykke verdier som sendes inn via et skjema. Opprinnelig definert som en del av HTML 4.0, brukes det mest til å sende filer via HTTP .
Definert i RFC 2388
Blandet-erstatt (eksperimentell)Innholdstypen multipart/x-mixed-replace ble utviklet som en del av en teknologi for å emulere server-push og streaming over HTTP.
Alle deler av en blandet-erstatt melding har samme semantiske betydning. Hver del ugyldiggjør imidlertid - "erstatter" - den forrige delen så snart den er fullt mottatt. Kunder bør behandle den enkelte delen ved ankomst og bør ikke vente på at hele meldingen er ferdig.
Opprinnelig utviklet av Netscape, støttes den fortsatt av Mozilla , Firefox , Safari (men ikke Safari for iPhone ) og Opera , men tradisjonelt ignorert av Microsoft .