home |
|
code |
|
bugs |
|
rdoc |
|
continuous integration |
|
test coverage |
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.
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
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.
I value any contribution to mime-types you can provide: a bug report, a feature request, or code contributions.
As mime-types is a mature codebase, there are a few guidelines:
Code changes will not be accepted without tests. The test suite is written with Minitest.
Match my coding style.
Use a thoughtfully-named topic branch that contains your change. Rebase your commits into logical chunks as necessary.
Do not change the version number; when your patch is accepted and a release is made, the version will be updated at that point.
Submit a GitHub pull request with your changes.
New or changed behaviours require new or updated documentation.
The mime-types registry is loaded from a JSON file in data, but this file is not considered editable and cannot be compared in a pull request. New or modified MIME types should be edited in the appropriate YAML file under type-lists. The format is as shown below for the application/xml MIME type in type-lists/application.yml.
- !ruby/object:MIME::Type content-type: application/xml encoding: 8bit extensions: - xml - xsl references: - IANA - RFC3023 xrefs: !ruby/hash:MIME::Types::Container rfc: - rfc3023 registered: true
There are other fields that can be added, matching the fields discussed in the documentation for MIME::Type. Pull requests for MIME types should just contain the changes to the YAML files for the new or modified MIME types; I will convert the YAML files to JSON prior to a new release. I would rather not have to verify that the JSON matches the YAML changes, which is why it is not necessary to convert for the pull request.
If you are making a change for a private fork, use rake convert:yaml:json to convert the YAML to JSON.
mime-types uses Ryan Davis’s Hoe to manage the release process, and it adds a number of rake tasks. You will mostly be interested in:
$ rake
which runs the tests the same way that:
$ rake test $ rake travis
will do.
To assist with the installation of the development dependencies for mime-types, I have provided the simplest possible Gemfile pointing to the (generated) mime-types.gemspec file. This will permit you to do:
$ bundle install
to get the development dependencies. If you aleady have hoe installed, you can accomplish the same thing with:
$ rake newb
This task will install any missing dependencies, run the tests/specs, and generate the RDoc.
Here’s the most direct way to get your work merged into the project:
Fork the project.
Clone down your fork (git clone git://github.com/<username>/mime-types.git).
Create a topic branch to contain your change (git checkout -b my_awesome_feature).
Hack away, add tests. Not necessarily in that order.
Make sure everything still passes by running rake.
If necessary, rebase your commits into logical chunks, without errors.
Push the branch up (git push origin my_awesome_feature).
Create a pull request against halostatue/mime-types and describe what your change does and the why you think it should be merged.
Austin Ziegler created mime-types.
Thanks to everyone else who has contributed to mime-types:
Andre Pankratz
Mauricio Linhares
Richard Hirner
Todd Carrico
Garret Alfert
Hans de Graaff
Henrik Hodne
Martin d’Allens
cgat
Greg Brockman
This software is available under three licences: the GNU GPL version 2 (or at your option, a later version), the Perl Artistic License, or the MIT License. Note that my preference for licensing is the MIT License, but the original Perl MIME::Types was dually originally licensed with the Perl Artistic Licence and the GNU GPL (“the same terms as Perl itself”) and given that the Ruby implementation hewed pretty closely to the Perl version, I must maintain the additional licensing terms.
Copyright 2003–2013 Austin Ziegler.
Adapted from MIME::Types (Perl) by Mark Overmeer.
This software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
See the file docs/artistic.txt in the main distribution.
See the file docs/COPYING.txt in the main distribution.
Generated with the Darkfish Rdoc Generator 2.