Media Type Record Equality

Description

Compare case-insensitive type/subtype and exact ordered decoded parameter records separately; not semantic media-type equivalence or parameter reordering/case normalization.

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]

Compare case-insensitive type/subtype and exact ordered decoded parameter records separately; not semantic media-type equivalence or parameter reordering/case normalization.

When to use this tool

Use this tool to compare case-insensitive type/subtype and exact ordered decoded parameter records separately; not semantic media-type equivalence or parameter reordering/case normalization.

How to use the tool and how it works

Enter left, right, leftParametersJson, rightParametersJson using the field definitions below. For JSON text, serialize the explicit records in the shown shape.
Run the operation. Correct input errors before interpreting an output.
Read result.sameType, result.sameOrderedParameters. Use the ordering, boundary rules and absence conditions described below.

Compare normalized type/subtype pairs and compare normalized parameter records as ordered lists, returning separate equality flags.^[2]

Input field	Meaning and units	Accepted input
left	Left bare type/subtype spelling.	Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.
right	Right bare type/subtype spelling.	Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.
leftParametersJson	JSON text encoding array of {name: string, value: string}. Keep the record keys and value types shown in the decoded example below.	Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.
rightParametersJson	JSON text encoding array of {name: string, value: string}. Keep the record keys and value types shown in the decoded example below.	Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.

These are the decoded structures used in the example’s JSON text fields. Supply the corresponding serialized JSON strings as input.

json

{
  "leftParametersJson": [
    {
      "name": "A",
      "value": "x"
    }
  ],
  "rightParametersJson": [
    {
      "name": "a",
      "value": "x"
    }
  ]
}

Output field	Interpretation
result	Object containing the named fields below.
result.sameType	Whether normalized type and subtype match.
result.sameOrderedParameters	Whether normalized ordered parameter records match exactly.

json

{
  "input": {
    "left": "Text/HTML",
    "right": "text/html",
    "leftParametersJson": "[{\"name\":\"A\",\"value\":\"x\"}]",
    "rightParametersJson": "[{\"name\":\"a\",\"value\":\"x\"}]"
  },
  "output": {
    "result": {
      "sameType": true,
      "sameOrderedParameters": true
    }
  }
}

Limitations and assumptions

Parameter values are compared exactly and parameter order matters for sameOrderedParameters; no universal semantic equivalence is claimed.
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 Record Equality — 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.