Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Ruby
Pull request Compare This branch is 17 commits behind mime-types:master.

README.rdoc

mime-types

home

github.com/mime-types/ruby-mime-types/

code

github.com/mime-types/ruby-mime-types/

bugs

github.com/mime-types/ruby-mime-types/issues

rdoc

rdoc.info/gems/mime-types/

continuous integration

test coverage

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 add additional type definitions (see Contributing.rdoc). The primary sources for MIME type definitions found in mime-types is the IANA Media Types registry, RFCs, and W3C recommendations. It conforms to RFCs 2045 and 2231.

This is release 2.5 with a couple of bug fixes, updating to the latest IANA type registry, and adding a user-contributed type. mime-types 2.x supports Ruby 1.9.2 or later.

mime-types 1.x End of Life

mime-types 2.0 was released in late 2013, and as of early 2015 there have been no reported security issues for mime-types 1.x. With the release of mime-types 2.5, I setting the formal End of Life for mime-types 1.x for 2015-10-27 (the second anniversary of the release of mime-types 2.0). After this date, absolutely no pull requests for mime-types 1.x will be accepted.

mime-types Future

Even though there are a number of issues open, it is clear to me that there are some fundamental changes that need to happen to both the data representation and the API provided by mime-types. This cannot happen under the current release, so all new development is focussing on an upcoming 3.0 release. The target for the release is on or before the beginning of RubyConf 2015 (2015-11-15).

When 3.0 is released, mime-types 2.x will receive regular updates of the IANA registry for two years following the release. It will also receive security updates, if needed, for the same period. There will be no further feature development on mime-types 2.x following the 3.0 release.

Coincident with the 3.0 release, I will release mime-types 2.99.0 that no longer imports the data to fields that have been deprecated. If they work because they derive data from that which is imported, they will continue to work. The quarterly updates will be against 2.99.x.

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.preferred_extension   # => 'txt'
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

# Various string representations of MIME types

qcelp = MIME::Types['audio/QCELP'].first # => audio/QCELP
puts qcelp.content_type         # => 'audio/QCELP'
puts qcelp.simplified           # => 'audio/qcelp'

xwingz = MIME::Types['application/x-Wingz'].first # => application/x-Wingz
puts xwingz.content_type        # => 'application/x-Wingz'
puts xwingz.simplified          # => 'application/wingz'

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

Something went wrong with that request. Please try again.