PDF 文件的正确 MIME 媒体类型

发布于 2024-07-09 11:04:03 字数 205 浏览 5 评论 0原文

在处理 PDF 时,我遇到过 MIME 类型 application/pdfapplication/x-pdf 等。

这两种类型之间有区别吗?如果有的话,区别是什么? 其中一个比另一个更受青睐吗?

我正在开发一款网络应用程序,它必须提供大量 PDF,并且我想以正确的方式(如果有的话)来完成它。

When working with PDFs, I've run across the MIME types application/pdf and application/x-pdf among others.

Is there a difference between these two types, and if so what is it? Is one preferred over the other?

I'm working on a web app which must deliver huge amounts of PDFs and I want to do it the correct way, if there is one.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

涙—继续流 2024-07-16 11:04:03

标准媒体类型(以前称为 MIME 类型)是 application/pdf。 该分配在 RFC 3778, The application/pdf Media Type< 中定义/a>,引用自媒体类型注册表

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

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

The standard Media Type (formerly known as MIME types) is application/pdf. The assignment is defined in RFC 3778, The application/pdf Media Type, referenced from the Media Types registry.

Media Types are controlled by a standards body, The Internet Assigned Numbers Authority (IANA). This is the same organization that manages the root name servers and the IP address space.

The use of x-pdf predates the standardization of the Media Type for PDF. Media Types in the x- namespace are considered experimental, just as those in the vnd. namespace are considered vendor-specific. x-pdf might be used for compatibility with old software.

暗地喜欢 2024-07-16 11:04:03

这是 RFC 2045 - 多用途互联网邮件扩展 (MIME) 第一部分:互联网消息正文的格式

  1. 可以定义私有[子类型]值(以“X-”开头)
    两个合作主体之间的双边合作,无需
    外部注册或标准化。 这样的价值观
    无法注册或标准化。

  2. 新标准值应按照 RFC 2048 中的说明向 IANA 注册.

类似的限制也适用于顶级类型。 来自同一源头,

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

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

因此可以合理猜测“application/x-foo”是在 IANA 定义的“application/foo”之前使用的。 不了解 IANA 令牌分配的人们仍然可能会使用它。

正如 Chris Hanson 所说,MIME 类型由 IANA 控制。 RFC 中有详细说明2048 - 多用途互联网邮件扩展 (MIME) 第四部分:注册程序。 根据 RFC 3778引用由 IANA 作为“application/pdf”的定义,

application/pdf 媒体类型由 Paul Lindner 于 1993 年首次注册,供 gopher 协议使用; 随后 Steve Zilles 于 1994 年更新了注册信息。

“application/pdf”类型已经存在十多年了。 因此,在我看来,无论在新应用程序中使用“application/x-pdf”,这个决定可能都不是经过深思熟虑的。

This is a convention defined in RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.

  1. Private [subtype] values (starting with "X-") may be defined
    bilaterally between two cooperating agents without
    outside registration or standardization. Such values
    cannot be registered or standardized.

  2. New standard values should be registered with IANA as described in RFC 2048.

A similar restriction applies to the top-level type. From the same source,

If another top-level type is to be used for any reason, it must be
given a name starting with "X-" to indicate its non-standard status
and to avoid a potential conflict with a future official name.

(Note that per RFC 2045, "[m]atching of media type and subtype is ALWAYS case-insensitive", so there's no difference between the interpretation of 'X-' and 'x-'.)

So it's fair to guess that "application/x-foo" was used before the IANA defined "application/foo". And it still might be used by folks who aren't aware of the IANA token assignment.

As Chris Hanson said MIME types are controlled by the IANA. This is detailed in RFC 2048 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. According to RFC 3778, which is cited by the IANA as the definition for "application/pdf",

The application/pdf media type was first registered in 1993 by Paul Lindner for use by the gopher protocol; the registration was subsequently updated in 1994 by Steve Zilles.

The type "application/pdf" has been around for well over a decade. So it seems to me that wherever "application/x-pdf" has been used in new apps, the decision may not have been deliberate.

花桑 2024-07-16 11:04:03

从维基百科媒体类型来看,

媒体类型由类型、子类型和可选组成
参数。 例如,HTML 文件可能被指定为 text/html; 字符集=UTF-8。

媒体类型由顶级类型名称和子类型名称组成,即
进一步构造成所谓的“树”。

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

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

所有媒体类型均应使用 IANA 注册程序进行注册。 目前创建了以下树:standardvendorpersonalvanity、未注册的x.< /code>

标准:

标准树中的媒体类型不使用任何树面(前缀)。

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

个人树或虚荣树:

个人或虚荣树包括通过实验或创建的媒体类型
作为非商业分销产品的一部分。 它用
prs. 方面。

type / prs. media type name [+suffix]

未注册 x。 树:

“x”。 树可用于专门用于使用的媒体类型
在私人的、当地的环境中,并且只有在得到以下各方的积极同意的情况下
双方交换它们。 此树中的类型无法注册。

根据之前版本的 RFC 6838 - 已废弃的 RFC 2048
(1996 年 11 月出版)很少有必要(如果有的话)
使用未注册的实验类型,因此同时使用“x-”
和“x”。 不鼓励使用表单
。 该 RFC 的先前版本 - RFC
1590 和 RFC 1521 指出使用“x-”表示法
子类型名称可用于未注册和私有子类型,但是
该建议已于 1996 年 11 月废弃。

type / x. media type name [+suffix]

因此,很明显,标准类型 MIME 类型 application/pdf 是适合使用的类型,而您应该避免使用过时且未注册的 x- RFC 2048RFC 6838

From Wikipedia Media type,

A media type is composed of a type, a subtype, and optional
parameters. As an example, an HTML file might be designated text/html; charset=UTF-8.

Media type consists of top-level type name and sub-type name, which is
further structured into so-called "trees".

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

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

All media types should be registered using the IANA registration procedures. Currently the following trees are created: standard, vendor, personal or vanity, unregistered x.

Standard:

Media types in the standards tree do not use any tree facet (prefix).

type / media type name [+suffix]

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

Vendor:

Vendor tree is used for media types associated with publicly available
products. It uses vnd. facet.

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

Personal or Vanity tree:

Personal or Vanity tree includes media types created experimentally or
as part of products that are not distributed commercially. It uses
prs. facet.

type / prs. media type name [+suffix]

Unregistered x. tree:

The "x." tree may be used for media types intended exclusively for use
in private, local environments and only with the active agreement of
the parties exchanging them. Types in this tree cannot be registered.

According to the previous version of RFC 6838 - obsoleted RFC 2048
(published in November 1996) it should rarely, if ever, be necessary
to use unregistered experimental types, and as such use of both "x-"
and "x." forms is discouraged
. Previous versions of that RFC - RFC
1590 and RFC 1521 stated that the use of "x-" notation for the
sub-type name may be used for unregistered and private sub-types, but
this recommendation was obsoleted in November 1996.

type / x. media type name [+suffix]

So its clear that the standard type MIME type application/pdf is the appropriate one to use while you should avoid using the obsolete and unregistered x- media type as stated in RFC 2048 and RFC 6838.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文