Description
Budget one MIME part as opening delimiter, supplied Latin-1 header lines plus blank line, explicit payload byte count and trailing CRLF; excludes final closing delimiter.
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
Budget one MIME part as opening delimiter, supplied Latin-1 header lines plus blank line, explicit payload byte count and trailing CRLF; excludes final closing delimiter.
When to use this tool
Use this tool to budget one MIME part as opening delimiter, supplied Latin-1 header lines plus blank line, explicit payload byte count and trailing CRLF; excludes final closing delimiter.
How to use the tool and how it works
- Enter boundary, headerLines, payloadBytes using the field definitions below.
- Run the operation. Correct input errors before interpreting an output.
- Read result.openingBytes, result.headerBytes, result.payloadBytes, result.total. Use the ordering, boundary rules and absence conditions described below.
Count an opening boundary line, single-byte header characters plus CRLF endings and the separating blank line, supplied payload bytes, and a trailing CRLF.2
| Input field | Meaning and units | Accepted input |
|---|---|---|
| boundary | Boundary text without the two delimiter-prefix hyphens; 1–70 supported characters. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
| headerLines | Header-line texts without CRLF, each using single-byte-compatible characters. | Dense list of at most 128 strings, each at most 8,192 UTF-16 code units. |
| payloadBytes | Supplied nonnegative payload byte count. | A finite safe integer within the operation’s stated bounds. |
| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.openingBytes | Byte count of opening delimiter including its CRLF. |
| result.headerBytes | Byte count of supplied header lines, their CRLF endings and the separating blank line. |
| result.payloadBytes | Supplied payload byte count, echoed unchanged. |
| result.total | Total bytes under the envelope convention stated above. |
{
"input": {
"boundary": "abc",
"headerLines": [
"X: y"
],
"payloadBytes": 10
},
"output": {
"result": {
"openingBytes": 7,
"headerBytes": 8,
"payloadBytes": 10,
"total": 27
}
}
} Limitations and assumptions
- This estimates one part envelope, excluding a closing boundary and other parts; header syntax is not fully validated.
- 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: Multipart Part Envelope Byte Budget — tool.io
Similar or alternative tools
- Multipart Part Length Consistency Audit
Compare explicit declared and observed part byte counts with signed discrepancies; does not parse Content-Length headers, bodies or transfer encodings.
- MIME Parameter Byte Order Profile
Profile byte-order source spans in canonical Latin-1 MIME parameter serialization, retaining occurrence order; not machine endianness or Unicode encoding detection.