Tipo di supporto MIME corretto per i file PDF


1285

Quando lavoro con i PDF, ho incontrato i tipi MIME application/pdfe application/x-pdftra gli altri.

C'è una differenza tra questi due tipi e, in caso affermativo, che cos'è? L'uno è preferito all'altro?

Sto lavorando a un'app Web che deve fornire enormi quantità di PDF e voglio farlo nel modo corretto, se ce n'è uno.

Risposte:


1705

Il tipo MIME standard è application/pdf. L'assegnazione è definita in RFC 3778, Il tipo di supporto application / pdf , a cui si fa riferimento dal registro dei tipi di supporto MIME .

I tipi MIME sono controllati da un organismo di standard, IANA ( Internet Assigned Numbers Authority ). Questa è la stessa organizzazione che gestisce i server dei nomi radice e lo spazio degli indirizzi IP.

L'uso di x-pdfprecede la standardizzazione del tipo MIME per PDF. I tipi MIME nello x-spazio dei nomi sono considerati sperimentali, così come quelli nello vnd.spazio dei nomi sono considerati specifici del fornitore. x-pdfpotrebbe essere utilizzato per la compatibilità con il vecchio software.


6
Aggiornamento 2020: A questo punto, il application/pdftipo dovrebbe essere usato - a meno che non sia necessario essere compatibili con software molto vecchi non usare x-pdf...
Janniks

156

Questa è una convenzione definita in RFC 2045 - MIME (Multipurpose Internet Mail Extensions) Parte prima: formato degli organismi di messaggi Internet .

  1. I valori [sottotipo] privati (che iniziano con "X-") possono essere definiti bilateralmente tra due agenti cooperanti senza registrazione esterna o standardizzazione. Tali valori non possono essere registrati o standardizzati.

  2. I nuovi valori standard devono essere registrati con IANA come descritto in RFC 2048 .

Una restrizione simile si applica al tipo di livello superiore. Dalla stessa fonte,

Se un altro tipo di livello superiore deve essere utilizzato per qualsiasi motivo, deve essere assegnato un nome che inizia con "X-" per indicare il suo stato non standard ed evitare un potenziale conflitto con un futuro nome ufficiale.

(Si noti che per RFC 2045, "[m] l'attacco del tipo di supporto e del sottotipo è SEMPRE sensibile al maiuscolo / minuscolo", quindi non c'è differenza tra l'interpretazione di 'X-' e 'x-'.)

Quindi è giusto indovinare che "application / x-foo" è stato usato prima che IANA definisse "application / foo". E potrebbe ancora essere utilizzato da persone che non sono a conoscenza dell'assegnazione dei token IANA.

Come ha affermato Chris Hanson, i tipi MIME sono controllati dalla IANA. Questo è dettagliato in RFC 2048 - MIME (Multipurpose Internet Mail Extensions) Parte Quarta: Procedure di registrazione . Secondo la RFC 3778 , citata dalla IANA come definizione di "application / pdf",

Il tipo di supporto application / pdf è stato registrato per la prima volta nel 1993 da Paul Lindner per l'uso con il protocollo gopher; la registrazione fu successivamente aggiornata nel 1994 da Steve Zilles.

Il tipo "application / pdf" esiste da oltre un decennio. Quindi mi sembra che ovunque "application / x-pdf" sia stato usato in nuove app, la decisione potrebbe non essere stata deliberata.


28

Da Wikipedia Tipo di media,

Un tipo di supporto è composto da un tipo, un sottotipo e parametri opzionali. Ad esempio, un file HTML potrebbe essere designato text / html; charset = UTF-8.

Il tipo di supporto è costituito dal nome del tipo di livello superiore e dal nome del sottotipo, che è ulteriormente strutturato in cosiddetti "alberi".

top-level type name / subtype name [ ; parameters ]

top-level type name / [ tree. ] subtype name [ +suffix ] [ ; parameters ]

Tutti i tipi di supporto devono essere registrati utilizzando le procedure di registrazione IANA. Attualmente vengono creati i seguenti alberi: standard, vendor, personalo vanity, non registratix.

Standard:

I tipi di media nella struttura standard non utilizzano alcun aspetto dell'albero (prefisso).

type / media type name [+suffix]

Esempi: "application / xhtml + xml", "image / png"

venditore:

L'albero dei fornitori viene utilizzato per i tipi di media associati ai prodotti disponibili pubblicamente. Usa le vnd.faccette.

type / vnd. media type name [+suffix] - used in the case of well-known producer

type / vnd. producer's name followed by media type name [+suffix] - producer's name must be approved by IANA

type / vnd. producer's name followed by product's name [+suffix] - producer's name must be approved by IANA

Albero personale o di vanità:

L'albero personale o di vanità include i tipi di media creati sperimentalmente o come parte di prodotti che non sono distribuiti commercialmente. Usa le prs.faccette.

type / prs. media type name [+suffix]

Non registrato x. albero:

La "x". tree può essere utilizzato per tipi di media destinati esclusivamente all'uso in ambienti privati ​​e locali e solo con l'accordo attivo delle parti che li scambiano. I tipi in questo albero non possono essere registrati.

Secondo la versione precedente di RFC 6838 - obsoleto RFC 2048 (pubblicato nel novembre 1996) , raramente, se mai, dovrebbe essere necessario utilizzare tipi sperimentali non registrati e come tale utilizzare sia "x-" che "x". le forme sono scoraggiate . Versioni precedenti di tale RFC - RFC 1590 e RFC 1521 affermavano che l'uso della notazione "x-" per il nome del sottotipo poteva essere usato per sottotipi non registrati e privati, ma questa raccomandazione era obsoleta nel novembre 1996.

type / x. media type name [+suffix]

Quindi è chiaro che il tipo MIME di tipo standard application/pdfè quello appropriato da usare mentre si dovrebbe evitare di utilizzare il x-tipo di supporto obsoleto e non registrato come indicato in RFC 2048 e RFC 6838 .


3
@TNguyen: nessun danno. :) Penso che sia utile avere altre versioni di risposte, in modo che fornisca alcune informazioni aggiuntive per chi cerca l'argomento. Inoltre, ha citato alcune informazioni aggiuntive, rispetto ad altre risposte.
domenica
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.