mime-types

home

github.com/halostatue/mime-types/

code

github.com/halostatue/mime-types/

bugs

github.com/halostatue/mime-types/issues

rdoc

rdoc.info/gems/mime-types/

continuous integration

<img src=“https://travis-ci.org/halostatue/mime-types.png” />

test coverage

<img src=“https://coveralls.io/repos/halostatue/mime-types/badge.png” alt=“Coverage Status” />

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.1 (2.4 was pulled), fixing 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.

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; 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