stijns / mime-types

Ruby MIME::Types implementation

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.2, mostly changing how the MIME type registry is updated from the IANA registry (the format of which was incompatibly changed shortly before this release) and taking advantage of the extra data available from IANA registry in the form of MIME::Type#xrefs. In addition, the LTSW list has been dropped as a supported list.

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']
# returns [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.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 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