Skip to content

Main content

Content ID Bracket Token Parser

Parse one restricted Content-ID angle-bracket token containing exactly one nonempty local@domain without whitespace, comments or quoted local parts; no mailbox validity claim.

Loading tool…

Description

Parse one restricted Content-ID angle-bracket token containing exactly one nonempty local@domain without whitespace, comments or quoted local parts; no mailbox validity claim.

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

Parse one restricted Content-ID angle-bracket token containing exactly one nonempty local@domain without whitespace, comments or quoted local parts; no mailbox validity claim.

When to use this tool

Use this tool to parse one restricted Content-ID angle-bracket token containing exactly one nonempty local@domain without whitespace, comments or quoted local parts; no mailbox validity claim.

How to use the tool and how it works

  1. Enter token using the field definitions below.
  2. Run the operation. Correct input errors before interpreting an output.
  3. Read result.contentId. Use the ordering, boundary rules and absence conditions described below.

Require one angle-bracketed token with exactly one separating at-sign and no whitespace or nested brackets. Return its unwrapped content ID.2

Input fieldMeaning and unitsAccepted input
tokenOne bracketed content-ID token under the declared narrow grammar.Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.
Output fieldInterpretation
resultObject containing the named fields below.
result.contentIdUnwrapped content-ID text.
json
{
  "input": {
    "token": "<a@b>"
  },
  "output": {
    "result": {
      "contentId": "a@b"
    }
  }
}

Limitations and assumptions

  • This deliberately narrow syntax does not implement the complete message-ID grammar or a cid URL decoder.
  • 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: Content ID Bracket Token Parser — tool.io

Similar or alternative tools

  • Content ID Bracket Token Formatter

    Format one restricted nonempty local@domain Content-ID in angle brackets; no uniqueness, message identity or full RFC mailbox syntax inference.

  • Media Type Suffix Token Join

    Join explicit nonempty MIME subtype and structured-suffix tokens with one plus; caller verifies registration, no serialization of a complete Content-Type.