Description
Format one RFC 2046 multipart delimiter line with explicit closing policy and CRLF; validates the supplied boundary, does not generate a collision-safe boundary.
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
Format one RFC 2046 multipart delimiter line with explicit closing policy and CRLF; validates the supplied boundary, does not generate a collision-safe boundary.
When to use this tool
Use this tool to format one RFC 2046 multipart delimiter line with explicit closing policy and CRLF; validates the supplied boundary, does not generate a collision-safe boundary.
How to use the tool and how it works
- Enter boundary, closing using the field definitions below.
- Run the operation. Correct input errors before interpreting an output.
- Read result.line. Use the ordering, boundary rules and absence conditions described below.
Validate the boundary and format two leading hyphens, the boundary, optional closing hyphens, and 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. |
| closing | True formats the closing delimiter; false formats an opening delimiter. | A boolean true or false. |
| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.line | Formatted delimiter line including its CRLF ending. |
{
"input": {
"boundary": "abc",
"closing": true
},
"output": {
"result": {
"line": "--abc--\r\n"
}
}
} Limitations and assumptions
- The closing flag chooses the final delimiter; no MIME headers or payload are generated.
- 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 Boundary Delimiter Formatter — tool.io
Similar or alternative tools
- Multipart Boundary Payload Collision Audit
Audit complete multipart delimiter-looking lines at the start or after CRLF in an explicit payload; prefix-only non-delimiter matches do not count, no byte encoding inference.
- Multipart Delimiter Line Classifier
Classify a multipart delimiter line without its CRLF, recognizing optional closing double dash and trailing SP/HTAB only; no prefix false positives.