Description
Profile byte-order source spans in canonical Latin-1 MIME parameter serialization, retaining occurrence order; not machine endianness or Unicode encoding detection.
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
Profile byte-order source spans in canonical Latin-1 MIME parameter serialization, retaining occurrence order; not machine endianness or Unicode encoding detection.
When to use this tool
Use this tool to profile byte-order source spans in canonical Latin-1 MIME parameter serialization, retaining occurrence order; not machine endianness or Unicode encoding detection.
How to use the tool and how it works
- Enter parametersJson 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.text, result.spans. Use the ordering, boundary rules and absence conditions described below.
Normalize parameter names, preserve record order and duplicates, serialize with semicolon-space separators, and report each parameter’s half-open span in that text.2
| Input field | Meaning and units | Accepted input |
|---|---|---|
| parametersJson | 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.
{
"parametersJson": [
{
"name": "a",
"value": "x"
},
{
"name": "b",
"value": "y"
}
]
}| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.text | Serialized parameter text in supplied record order. |
| result.spans | Half-open parameter spans in the generated text. |
{
"input": {
"parametersJson": "[{\"name\":\"a\",\"value\":\"x\"},{\"name\":\"b\",\"value\":\"y\"}]"
},
"output": {
"result": {
"text": "a=x; b=y",
"spans": [
{
"name": "a",
"start": 0,
"end": 3
},
{
"name": "b",
"start": 5,
"end": 8
}
]
}
}
}Limitations and assumptions
- Spans refer to the generated single-byte-compatible text, not the original input JSON or a UTF-8 byte expansion.
- 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: MIME Parameter Byte Order Profile — tool.io
Similar or alternative tools
- MIME Parameter Quotedness Plan
Plan MIME parameter value token versus quoted-string spelling, including empty strings and escaped quotes; not a charset/extended-parameter encoder.
- Media Type Offer Specificity Order
Stable-order bare MIME ranges by exact/type-wildcard/all-wildcard specificity only; excludes qualities, parameters and offer preference.