Skip to content

Main content

Multipart Boundary Delimiter Formatter

Format one RFC 2046 multipart delimiter line with explicit closing policy and CRLF; validates the supplied boundary, does not generate a collision-safe boundary.

Loading tool…

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

  1. Enter boundary, closing using the field definitions below.
  2. Run the operation. Correct input errors before interpreting an output.
  3. 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 fieldMeaning and unitsAccepted input
boundaryBoundary 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.
closingTrue formats the closing delimiter; false formats an opening delimiter.A boolean true or false.
Output fieldInterpretation
resultObject containing the named fields below.
result.lineFormatted delimiter line including its CRLF ending.
json
{
  "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

  1. RFC 2046: MIME Media Types — RFC Editor

  2. 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.