Medientyp

A Medientyp (auch bekannt als a Mime Typ)[1] ist eine zweiteilige Kennung für Dateiformate und Formatinhalte, die auf dem übertragen werden Internet. Das Internet zugewiesene Zahlen Autorität (IANA) ist die offizielle Behörde für die Standardisierung und Veröffentlichung dieser Klassifikationen. Medientypen wurden ursprünglich in definiert in Anfrage für Kommentare RFC 2045 (MIME) Teil eins: Format der Internet -Nachrichtenkörper (November 1996) im November 1996 als Teil von MIME (Mehrzweck -Internet -Mail -Erweiterungen) Spezifikation zur Bezeichnung von Art von Email Nachrichteninhalt und Anhänge;[2] Daher der ursprüngliche Name, Mime Typ. Medientypen werden auch von anderen Internetprotokollen verwendet, wie z. Http[3] und Dokumentdateiformate wie z. Html,[4] für ähnliche Zwecke.

Benennung

Ein Medientyp besteht aus a Typ und ein Subtyp, was weiter in a strukturiert ist Baum. Ein Medientyp kann optional a definieren Suffix und Parameter:

type "/" [tree "."] subtype ["+" suffix]* [";" parameter]

Ab November 1996 waren die registrierten Typen: application, audio, image, message, multipart, text und video.[2] Bis Dezember 2020 enthielt die registrierten Typen das Vorstehende plus font, example, und model.[5]

Ein inoffizieller Name der oberen Ebene in der gemeinsamen Nutzung ist chemical.[6][7][8]

Als Beispiel kann eine HTML -Datei benannt werden text/html; charset=UTF-8. In diesem Beispiel, text ist der Typ, html ist der Subtyp und charset=UTF-8 ist ein optionaler Parameter, der die Zeichenkodierung angibt.

Ein Subtyp besteht in der Regel aus einem Medienformat, kann jedoch auch andere Inhalte enthalten, z. B. ein Baumpräfix, Produzent, Produkt oder Suffix gemäß den verschiedenen Regeln in Registrierungsbäumen.

Typen, Subtypen und Parameternamen sind von Fall unempfindlich. Parameterwerte sind in der Regel Fallempfindlichkeit, können jedoch in Abhängigkeit von der beabsichtigten Verwendung in Fall-unempfindlicher Weise interpretiert werden.[9]

Häufige Beispiele [10]

  • application/javascript
  • application/json
  • application/ld+json
  • application/msword (.doc)
  • application/pdf
  • application/sql
  • application/vnd.api+json
  • application/vnd.ms-excel (.xls)
  • application/vnd.ms-powerpoint (.ppt)
  • application/vnd.oasis.opendocument.text (.odt)
  • application/vnd.openxmlformats-officedocument.presentationml.presentation (.pptx)
  • application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (.xlsx)
  • application/vnd.openxmlformats-officedocument.wordprocessingml.document (.docx)
  • application/x-www-form-urlencoded
  • application/xml
  • application/zip
  • application/zstd (.zst)
  • audio/mpeg
  • audio/ogg
  • image/avif
  • image/jpeg (.jpg, .jpeg, .jfif, .pjpeg, .pjp) [11]
  • image/png
  • image/svg+xml (.svg)
  • multipart/form-data
  • text/css
  • text/csv
  • text/html
  • text/xml

Registrierungsbäume

Alle Medientypen sollten unter Verwendung der IANA -Registrierungsverfahren registriert werden. Für die Effizienz und Flexibilität des Registrierungsprozesses des Medientyps können verschiedene Strukturen von Subtypen in Registrierungsbäumen registriert werden, die durch die Verwendung von Baumpräfixen unterschieden werden. Derzeit werden die folgenden Bäume erstellt: Standard (kein Präfix), Lieferanten (vnd. Präfix), persönlich oder Eitelkeit (prs. Präfix), nicht registriert (x. Präfix). Diese Registrierungsbäume wurden erstmals im November 1996 definiert (veraltet RFC 2048 - derzeit RFC 6838). Neue Registrierungsbäume können von erstellt werden von Ietf Standards Maßnahmen zur externen Registrierung und Verwaltung durch bekannte ständige Organisationen (z. B. wissenschaftliche Gesellschaften).

Standardbaum

Der Standardbaum verwendet kein Baumpräfix:[12]

type "/" subtype ["+" suffix] *[";" parameter]

Beispiele: application/javascript, image/png.

Registrierungen im Standardbaum müssen entweder mit IETF-Spezifikationen in Verbindung gebracht werden, die direkt von der IESG genehmigt wurden oder von einer IANA-anerkannten Organisation für Standards registriert sind.

Verkäuferbaum

Der Verkäuferbaum enthält Medientypen, die mit öffentlich verfügbaren Produkten verbunden sind. Es verwendet das vnd. Baumpräfix:[12]

type "/" "vnd." subtype ["+" suffix] *[";" parameter]

Beispiele: application/vnd.ms-excel, application/vnd.oasis.opendocument.text.

Die Begriffe "Anbieter" und "Produzent" werden im Kontext als gleichwertig angesehen. Industriekonsortien sowie nichtkommerzielle Unternehmen können Medientypen im Anbieterbaum registrieren. Eine Registrierung im Anbieterbaum kann von jedem erstellt werden, der Dateien austauschen muss, die mit einem Softwareprodukt oder einer Reihe von Produkten verknüpft werden müssen. Die Registrierung gehört jedoch zum Anbieter oder der Organisation, die die Software produziert, die den registrierten Typ verwendet, und dieser Anbieter oder die Organisation kann jederzeit dafür entscheiden, das Eigentum an einer von einem Dritten durchgeführten Registrierung geltend zu machen.

Persönlicher oder Eitelkeitsbaum

Der persönliche oder Vanity -Baum enthält Medientypen, die mit nicht öffentlich verfügbaren Produkten oder experimentellen Medientypen verbunden sind. Es verwendet das prs. Baumpräfix:

type "/" "prs." subtype ["+" suffix] *[";" parameter]

Beispiele: audio/prs.sid, image/prs.btif.

Nicht registrierter Baum

Der nicht registrierte Baum enthält Medientypen, die ausschließlich für die Verwendung in privaten Umgebungen vorgesehen sind, und nur mit der aktiven Vereinbarung der Parteien, die sie austauschen. Es verwendet das x. Baumpräfix:

type "/" "x." subtype ["+" suffix] *[";" parameter]

Beispiele: application/x.foo, video/x.bar.

Medientypen in diesem Baum können nicht registriert werden. Laut RFC 6838 (veröffentlicht im Januar 2013) wird jede Verwendung von Typen im nicht registrierten Baum stark entmutigt. Darüber hinaus sind Subtypen vorangestellt mit x- oder X- werden nicht mehr als Mitglieder dieses Baumes angesehen.

Gemäß der veralteten RFC 2048 (veröffentlicht im November 1996) - es sollte selten, wenn überhaupt, erforderlich sein, nicht registrierte Typen zu verwenden, und als solche Verwendung von irgendeiner Verwendung x., x- oder X- Präfixe sind entmutigt. Obsoleted RFC 1590 (veröffentlicht im September 1993) stellte fest, dass die Verwendung des x- oder X- Präfix kann für nicht registrierte Subtypen verwendet werden.

Medikamenttypen, die weit verbreitet sind (mit einem Subtyp, der mit vorangestellt ist x- oder X-) ohne registriert zu werden, sollte, wenn möglich, mit einem ordnungsgemäßen vorangestellten Subtyp wieder registriert werden. Wenn dies nicht möglich ist, kann der Medientyp nach einer Genehmigung sowohl durch den Medietyp -Rezensent als auch durch den IESG im Standardbaum mit seinem nicht fixierten Subtyp registriert werden.

Suffix

Suffix ist eine Erweiterung der Definition von Medientypen, um zusätzlich die zugrunde liegende Struktur dieses Medientyps anzugeben, wodurch eine generische Verarbeitung basierend auf dieser Struktur und unabhängig von der besonderen Semantik des genauen Typs ermöglicht wird. Medientypen, die eine benannte strukturierte Syntax verwenden, sollten die entsprechende IANA -Registrierung verwenden "+"suffix für diese strukturierte Syntax, wenn sie registriert sind. Nicht registrierte Suffixe dürfen nicht verwendet werden (seit Januar 2013). Strukturierte Syntax -Suffix -Registrierungsverfahren sind in RFC 6838 definiert.[12]

Das +xml Suffix ist seit Januar 2001 definiert (RFC 3023[13]) und wurde formell in den Anfangsinhalt des strukturierten Syntax -Suffix -Registers zusammen mit enthalten +json, +ber, +der, +fastinfoset, +wbxml, und +zip Im Januar 2013 (RFC 6839). Nachfolgende Ergänzungen umfassen +gzip, +cbor, +json-seq, und +cbor-seq.[14]

Mailcap

MailCAP (abgeleitet aus der Phrase "Mail-Fähigkeit") ist eine Art von Meta-Datei, mit der konfiguriert werden, wie MIME-bewusstes Anwendungen wie E-Mail-Clients und Webbrowser Dateien unterschiedlicher MIME-Typen richten. Das MailCap -Format ist durch RFC 1524 "Ein Benutzeragent -Konfigurationsmechanismus für Multimedia -Mail -Formatinformatinformates" definiert, wird jedoch nicht als Internetstandard definiert. Es wird von den meisten Unix -Systemen unterstützt.

Zeilen können Kommentare sein, die mit dem # Charakter beginnen, oder mit einem MIME-Typ, gefolgt von dem Umgang mit diesem MIME-Typ.

Mime.types

Eine zugehörige Datei ist die mime.types Datei, die Dateiname -Erweiterungen mit a assoziiert Mime Typ. Wenn der MIME -Typ ordnungsgemäß eingestellt ist, ist dies unnötig, aber MIME -Typen können falsch eingestellt oder auf einen generischen Typ wie z. application/octet-stream, und mime.types ermöglicht es, in diesen Fällen auf die Erweiterung zurückzukehren. In ähnlicher Weise speichern viele Dateisysteme keine MIME -Informationen, sondern stützt sich stattdessen auf die Dateiname -Erweiterung, eine mime.types -Datei wird häufig von Webservern verwendet, um den MIME -Typ zu bestimmen.

Wann Betrachtung Eine Datei, diese beiden arbeiten wie folgt zusammen: mime.types assoziiert eine Erweiterung mit einem MIME -Typ, während Mailcap assoziiert einen MIME -Typ mit einem Programm.

In Unix-Typ-Systemen befindet sich die Datei mime.types normalerweise unter /etc/mime.types und/oder $ Home/.mime.types Und das Format ist einfach, dass jede Zeile eine von der Space Delimitierte Liste eines MIME-Typs ist, gefolgt von Null oder mehr Erweiterungen. Zum Beispiel kann der HTML -Typ den Erweiterungen zugeordnet werden .htm und .html durch die folgende Zeile:

Text/HTML HTM HTML

Netscape -Verwendung

Die Datei mime.types stammt aus Netscape, wo es ein anderes Format verwendete;[15] es wurde verwendet Schlüssel -Wert -Paare und eine von Kommas getrennte Liste von Erweiterungen zusammen mit a Standard -Header bestehend aus einem bestimmten Kommentar, der die Datei als mime.types -Datei identifiziert, wie folgt.

#-Netscape Communications Corporation MIME-Informationen # Löschen Sie die obige Zeile nicht. Es wird verwendet, um den Dateityp zu identifizieren. Typ = text/html exts = htm, html

Siehe auch

Verweise

  1. ^ "Medientypen". Iana. Iana. 4. Juni 2018. Abgerufen 5. Juni 2018.
  2. ^ a b Freed, N.; Borenstein, N. (November 1996). "Mehrzweck -Internet -Mail -Erweiterungen (MIME) Teil eins: Format von Internet -Nachrichtenkörpern". Internettechnik-Arbeitsgruppe. Abgerufen 15. Juli 2015. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  3. ^ Nielsen, Henrik; Fielding, Roy T.; Berners-Lee, Tim (Mai 1996). "Hypertext -Transferprotokoll - HTTP/1.0". Abgerufen 2. Februar 2017. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  4. ^ "HTML 4.01 -Spezifikation". 24. Dezember 1999. Abgerufen 2. Februar 2017.
  5. ^ "Medientypen". Iana. 2020-12-09. Abgerufen 2020-12-15.
  6. ^ Daniel Leidert, Egon Willighagen (2007). "Das Projekt Chemical-Mime-Daten". Archiviert von das Original am 2016-10-08. Abgerufen 2016-04-28.
  7. ^ "Chemische Mime -Homepage". 22. Dezember 1998. Abgerufen 11. Mai 2019.
  8. ^ S. Rzepa, Henry; Murray-Rust, Peter; J. Whitaker, Benjamin (14. August 1998). "Die Anwendung chemischer Mehrzweck -Internet -Mail -Erweiterungen (Chemical MIME) Internet -Standards auf elektronische Post und World Wide Web Information Exchange". Journal of Chemical Information and Modeling. American Chemical Society. 38 (6): 976–982. doi:10.1021/ci9803233.
  9. ^ Befreit, Ned; Borenstein, Nathaniel S. (November 1996). "Mehrzweck -Internet -Mail -Erweiterungen (MIME) Teil eins: Format von Internet -Nachrichtenkörpern". Abgerufen 20. September 2018. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  10. ^ "Medientypen".
  11. ^ "MIME -Typen (IANA -Medientypen) - http | mdn".
  12. ^ a b c Freed, N. (Januar 2013). "Medientypspezifikationen und Registrierungsverfahren". IETF -Anfrage nach Kommentaren (RFC) Seiten - Test. Internet Engineering Task Force (IETF). RFC6838. ISSN 2070-1721. Abgerufen 15. Juli 2015.
  13. ^ Kohn <[email protected]>, Dan (Januar 2001). "XML -Medientypen". Tools.ietf.org. Abgerufen 2021-03-05.
  14. ^ "Strukturiertes Syntax -Suffixregister" (Xml). Iana. 2012-07-20. Abgerufen 2019-11-08.
  15. ^ Webmaster: Mime -Typen Archiviert 2000-12-07 at Archive.Today, John McAnally, Thu, 22. Januar 1998 15:29:29 -0600 (CST)

Externe Links