MeridianMERIDIAN

MIME Type

representation.file.mime_type

MIME type (media type) for files and HTTP content (e.g., text/plain, application/json, image/png).

Worked samples

DuckDB 1.5.5 · finetype 0.6.64

ValueAs VARCHARcharsetsubtypetype
text/plaintext/plainplaintext
application/jsonapplication/jsonjsonapplication
image/pngimage/pngpngimage
text/html; charset=utf-8text/html; charset=utf-8utf-8htmltext
application/vnd.ms-excelapplication/vnd.ms-excelvnd.ms-excelapplication

Shape

Pattern
^[a-zA-Z]+/[a-zA-Z0-9.+\-]+(;.*)?$
ValueLengthShape
text/plain10matches
application/json16matches
image/png9matches
text/html; charset=utf-824matches
application/vnd.ms-excel24matches
text-plain10rejected: separator swapped

Told apart

1 of the 3 other file types accept every one of these samples on shape alone.

Background

Origin

RFC 1341, written by N. Borenstein and N. Freed, is dated June 1992.[1] RFC 1341 introduced a Content-Type header field, generalised from RFC 1049, to specify the type and subtype of data in the body of a message.[1] RFC 1341 defined an initial set of seven Content-Types.[1] RFC 2045, dated November 1996, obsoletes RFCs 1521, 1522 and 1590.[2] RFC 2045 defines the Content-Type value as a type and a subtype separated by a slash, followed by optional semicolon-separated parameters.[2] RFC 2045 says the initial seven top-level media types are defined in RFC 2046.[2] RFC 2045 states that a subtype is mandatory and that there are no default subtypes.[2]

The IANA registry notes that media types were formerly known as MIME types.[3] Wikipedia lists the registered top-level types as of November 1996 as application, audio, image, message, multipart, text and video.[4] RFC 6838, published as BCP 13 in January 2013, sets out how media types are specified and registered.[5] RFC 6838 formalises structured syntax suffixes such as +xml and +json appended to the base subtype name.[5]

Use

HTTP carries media types in its Content-Type and Accept header fields.[6] RFC 9110 gives text/html;charset=utf-8 and Text/HTML;Charset="utf-8" as equivalent ways of describing UTF-8 HTML.[6] RFC 9110 says type and subtype tokens are case-insensitive.[6]

RFC 2046 says the charset parameter values are not case sensitive.[7] RFC 2046 makes US-ASCII the default character set for text/plain when no charset parameter is given.[7] RFC 2046 uses the octet-stream subtype for arbitrary binary data.[7] RFC 9110 says a recipient of a message without Content-Type may assume application/octet-stream or examine the data to determine its type.[6] Read application/octet-stream in a column as unknown binary rather than as a real description of the file. (Meridian's view)

MDN warns that browsers use the MIME type, not the file extension, to decide how to process a URL.[8] RFC 9110 notes that resource owners do not always configure their servers to send the correct Content-Type.[6] Split a value at the first slash and the first semicolon to get type, subtype and parameters, and keep the full original string alongside. (Meridian's view)

Where you'll meet it

Common Crawl's index table schema has a content_mime_type column holding the Content-Type sent in the HTTP response header.[9] Common Crawl's index table schema also has a content_mime_detected column, a type detected from the content itself.[9] Common Crawl's cc-index-table repository includes an example query comparing the HTTP Content-Type with the MIME type detected by Tika.[10]

Detection notes

v1 migration: Was file.mime_type marked broad_characters. Standard format: type/subtype[+suffix];param=value. Decompose extracts type, subtype, charset.

Use it

CLI · DuckDB
$ finetype infer -i "text/plain" --mode column
→ representation.file.mime_type

SELECT ft_infer('text/plain');
-- → 'representation.file.mime_type'
Cast expression
LOWER(CAST({col} AS VARCHAR))

Schema

https://meridian.online/schemas/representation.file.mime_type · Frictionless type string

finetype taxonomy representation.file.mime_type -o json-schema

Aliases

content_typemedia_type

Type Registry