Description
Inventory every plus-separated subtype segment, including empty segments, after token grammar validation; final structured suffix is not a registry claim.
A media type has a type/subtype token and may carry named parameters. Multipart content uses explicit boundary delimiter lines around its parts. Token case rules, parameter quoting, repeated records and exact line endings affect how a representation is interpreted; a lexical check is narrower than parsing a complete message.1
Inventory every plus-separated subtype segment, including empty segments, after token grammar validation; final structured suffix is not a registry claim.
When to use this tool
Use this tool to inventory every plus-separated subtype segment, including empty segments, after token grammar validation; final structured suffix is not a registry claim.
How to use the tool and how it works
- Enter mediaType using the field definitions below.
- Run the operation. Correct input errors before interpreting an output.
- Read result.subtype, result.segments, result.finalSuffix. Use the ordering, boundary rules and absence conditions described below.
Normalize and split the subtype at each plus. Return the subtype, all segments and the final suffix, or null if no plus exists.2
| Input field | Meaning and units | Accepted input |
|---|---|---|
| mediaType | Bare type/subtype text without a parameter suffix. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.subtype | Normalized subtype or constructed base-plus-suffix token. |
| result.segments | Subtype segments split at every plus sign. |
| result.finalSuffix | Text following the final plus, or null when no plus exists. |
{
"input": {
"mediaType": "application/vnd.a+zip+json"
},
"output": {
"result": {
"subtype": "vnd.a+zip+json",
"segments": [
"vnd.a",
"zip",
"json"
],
"finalSuffix": "json"
}
}
}Limitations and assumptions
- This is a lexical inventory; it does not validate an IANA registration or decode content.
- Supported boundary strings contain 1–70 characters from the declared MIME boundary subset and cannot end in a space. Single-byte envelope budgets are distinct from UTF-8 text byte counts and from a complete MIME transport.
- Every declared top-level input field is required and unexpected fields are rejected. Ordinary strings are limited to 8,192 UTF-16 code units and lists to 128 entries, with tighter operation-specific bounds where stated. JSON text has bounded nesting and node counts.
- Numeric outputs must be finite and no larger in absolute magnitude than the safe-integer limit; operations returning exact large integers use decimal text. Positions are zero-based and spans end exclusively unless the operation explicitly states a different convention.
Alternative or Complementary methods
Choose the target media-type and multipart conventions explicitly. Use a complete MIME parser for nested messages and encodings; these record and delimiter tools handle only their stated representations.
References
-
RFC 2046: MIME Media Types — RFC Editor
-
Tool behavior and example: Media Type Subtype Plus Segment Inventory — tool.io
Similar or alternative tools
- Media Type Offer Specificity Order
Stable-order bare MIME ranges by exact/type-wildcard/all-wildcard specificity only; excludes qualities, parameters and offer preference.
- Media Type Parameter Conflict Table
Audit conflicting decoded MIME parameter values under case-insensitive names and case-sensitive literal values; no registered-parameter equivalence inference.