= mime-types
home :: https://github.com/halostatue/mime-types/
code :: https://github.com/halostatue/mime-types/
bugs :: https://github.com/halostatue/mime-types/issues
rdoc :: http://rdoc.info/gems/mime-types/
continuous integration :: {
}[https://travis-ci.org/halostatue/mime-types]
test coverage :: {
}[https://coveralls.io/r/halostatue/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}[https://github.com/lukaszsliwa/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}[https://github.com/svenfuchs/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}[https://www.iana.org/assignments/media-types/media-types.xhtml]
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.
require 'mime/types'
plaintext = MIME::Types['text/plain'] # => [ text/plain ]
text = plaintext.first
puts text.media_type # => 'text'
puts text.sub_type # => 'plain'
puts text.extensions.join(" ") # => 'txt asc c cc h hh cpp hpp dat hlp'
puts text.friendly # => 'Text Document'
puts text.i18n_key # => 'text.plain'
puts text.encoding # => quoted-printable
puts text.binary? # => false
puts text.ascii? # => true
puts text.obsolete? # => false
puts text.registered? # => true
puts text == 'text/plain' # => true
puts 'text/plain' == text # => true
puts MIME::Type.simplified('x-appl/x-zip')
# => 'appl/zip'
puts MIME::Types.any? { |type|
type.content_type == 'text/plain'
} # => true
puts MIME::Types.all?(&:registered?)
# => false
== 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}[http://semver.org/];
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:
1. 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.
2. 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.
3. 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.
:include: Contributing.rdoc
:include: Licence.rdoc