标准媒体类型（以前称为MIME类型）是application/pdf。该分配在RFC 3778“应用程序/pdf媒体类型”中定义，从媒体类型注册表中引用。

媒体类型由一个标准机构，互联网号码分配机构（IANA）控制。这是管理根名称服务器和IP地址空间的同一组织。

x-pdf的使用早于pdf媒体类型的标准化。x命名空间中的媒体类型被认为是实验性的，就像vnd中的媒体一样。命名空间被认为是特定于供应商的。x-pdf可能用于与旧软件兼容。

这是RFC 2045-多用途Internet邮件扩展（MIME）第1部分：Internet消息体格式中定义的约定。

可以定义私有[子类型]值（以“X-”开头）在没有外部注册或标准化。此类值无法注册或标准化。新的标准值应向IANA注册，如RFC 2048所述。

类似的限制适用于顶级类型。从同一来源，

如果出于任何原因要使用另一个顶级类型，则必须以“X-”开头的名称表示其非标准状态避免与未来的官方名称发生潜在冲突。

（请注意，根据RFC 2045，“媒体类型和子类型的匹配始终不区分大小写”，因此“X-”和“X-”的解释没有区别。）

因此，可以公平地猜测，在IANA定义“application/foo”之前使用了“application/x-foo”。它仍然可能被那些不知道IANA令牌分配的人使用。

正如Chris Hanson所说，MIME类型由IANA控制。这在RFC 2048-多用途Internet邮件扩展（MIME）第四部分：注册过程中有详细介绍。根据IANA引用的RFC 3778作为“application/pdf”的定义，

应用程序/pdf媒体类型于1993年由Paul Lindner首次注册，供gopher协议使用；该注册随后于1994年由Steve Zilles更新。

“application/pdf”已经存在了十多年。因此，在我看来，无论新应用程序中使用了什么“application/x-pdf”，这个决定都可能不是故意的。

从维基百科媒体类型，

媒体类型由类型、子类型和可选参数。例如，HTML文件可以指定为text/HTML；charset=UTF-8。媒体类型由顶级类型名称和子类型名称组成，即进一步构造成所谓的“树”。

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

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

所有媒体类型都应使用IANA注册程序进行注册。目前已创建以下树：标准树、供应商树、个人树或虚荣树、未注册的x树。

标准：

标准树中的媒体类型不使用任何树方面（前缀）。

type / media type name [+suffix]

示例：“application/xhtml+xml”、“image/png”

小贩：

供应商树用于与公开可用的媒体类型关联产品。它使用vnd。方面

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

个人或虚荣树：

个人或虚荣树包括通过实验或作为非商业销售产品的一部分。它使用公关部。方面

type / prs. media type name [+suffix]

未注册的x.树：

“x”树可用于专用的媒体类型在私人、本地环境中，只有在双方交换它们。无法注册此树中的类型。根据先前版本的RFC 6838-废弃的RFC 2048（1996年11月出版）如果有必要的话，应该很少使用未注册的实验类型，因此使用“x-”不鼓励使用“x”形式。该RFC的先前版本-RFC1590和RFC 1521规定子类型名称可以用于未注册的和私有的子类型，但是这项建议于1996年11月被废除。

type / x. media type name [+suffix]

因此，很明显，标准类型MIME类型application/pdf是合适的，而您应该避免使用RFC 2048和RFC 6838中所述的过时和未注册的x媒体类型。