mime-types

Description

The mime-types library provides a library and registry for information
about MIME content type definitions. It can be used to determine defined
filename extensions for MIME types, or to use filename extensions to look
up the likely MIME type definitions.

MIME content types are used in MIME-compliant communications, as in e-mail
or HTTP traffic, to indicate the type of content which is transmitted. The
mime-types library provides the ability for detailed information about MIME
entities (provided as an enumerable collection of MIME::Type objects) to be
determined and used programmatically. There are many types defined by RFCs
and vendors, so the list is long but by definition incomplete; don't
hesitate to to add additional type definitions (see Contributing.rdoc). The
primary sources for MIME type definitions found in mime-types is the IANA
collection of registrations (see below for the link), RFCs, and W3C
recommendations.

This is release 2.4.3, restoring full compatibility with Ruby 1.9.2 (which
will be dropped in mime-types 3.0). It also includes the performance
improvements from mime-types 2.4.2 (since yanked because of the broken Ruby
1.9.2 support) and the 2.4.1 fix of a bug in observed use of the mime-types
library where extensions were not previously sorted, such that

MIME::Types.of('image.jpg').first.extensions.first

returned a value of jpeg in mime-types 1, but jpe in
mime-types 2. This was introduced because extensions were sorted during
assignment (MIME::Type#extensions=). This behaviour has been reverted to
protect clients that work as noted above. The preferred way to express this
is the new method:

MIME::Type.of('image.jpg').first.preferred_extension

Łukasz Śliwa created the friendly_mime gem,
which offers friendly descriptive names for MIME types. This functionality
and English-language data has been added to mime-types as
MIME::Type#friendly. To make it easy for internationalization,
MIME::Type#i18n_key has been added, which will return a key suitable for
use with the I18n library.

As a reminder, mime-types 2.x is no longer compatible with Ruby 1.8 and
mime-types 1.x is only being maintained for security issues. No new MIME
types or features will be added.

mime-types (previously called MIME::Types for Ruby) was originally based on
MIME::Types for Perl by Mark Overmeer, copyright 2001 - 2009. It is built
to conform to the MIME types of RFCs 2045 and 2231. It tracks the IANA
Media Types registry with some types added by the users of mime-types.

Synopsis

MIME types are used in MIME entities, as in email or HTTP traffic. It is
useful at times to have information available about MIME types (or,
inversely, about files). A MIME::Type stores the known information about
one MIME type.

mime-types Modified Semantic Versioning

The mime-types library has one version number, but this single version
number tracks both API changes and registry data changes; this is not
wholly compatible with all aspects of Semantic
Versioning; removing a MIME type from the registry could be
considered a breaking change under some interpretations of semantic
versioning (as lookups for that particular type would no longer work by
default).

mime-types uses a modified semantic versioning scheme. Given the version
MAJOR.MINOR:

If an incompatible API (code) change is made, the MAJOR version will be
incremented, MINOR will be set to zero, and PATCH will be reset to the
implied zero.

If an API (code) feature is added that does not break compatibilty OR if
there are MIME types added, removed, or changed in the registry, the MINOR
version will be incremented and PATCH will be reset to the implied zero.

If there is a bugfix to a feature added in the most recent MAJOR.MINOR
release, OR if purely typographical errors are fixed in MIME types, the
implied PATCH value will be incremented resulting in MAJOR.MINOR.PATCH.

In practical terms, there should be a MINOR release roughly monthly to
track updated or changed MIME types from the official IANA registry. This
does not indicate when new API features have been added, but all minor
versions of mime-types 2.x will be backwards compatible; the interfaces
marked deprecated will not be removed until at least mime-types 3.x or
possibly later.