Byte Frame Payload Slice Map
Map explicit byte-frame header, payload and trailer half-open spans; zero-width regions remain explicit and impossible lengths are rejected.
Description
Map explicit byte-frame header, payload and trailer half-open spans; zero-width regions remain explicit and impossible lengths are rejected.
A declared header and trailer partition a frame into three contiguous regions. The payload may have zero length.
When to use this tool
Map explicit byte-frame header, payload and trailer half-open spans; zero-width regions remain explicit and impossible lengths are rejected.
- Prepare the supplied frameBytes, headerBytes, trailerBytes fields for this operation.
- Compare the complete example with the representation used by your own input before carrying the result into another step.
How to use the tool and how it works
- Enter frameBytes, headerBytes, trailerBytes. Use the exact text syntax, units and index conventions explained below.
- Run the tool. If input validation fails, correct the supplied fields before interpreting any result.
- Read result.header, result.payload, result.trailer. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Validate frameBytes up to 128, headerBytes within it and trailerBytes within the remaining length. Return half-open spans for header [0, header), payload [header, frame minus trailer) and trailer [frame minus trailer, frame).1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| frameBytes | frame bytes. | Integer from 0 to 128 inclusive |
| headerBytes | header bytes. | Integer from 0 to frameBytes inclusive |
| trailerBytes | trailer bytes. | Integer from 0 to frameBytes - headerBytes inclusive |
| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.header | The header list in the ordering and representation described above. |
| result.payload | The payload list in the ordering and representation described above. |
| result.trailer | The trailer list in the ordering and representation described above. |
{
"input": {
"frameBytes": 10,
"headerBytes": 2,
"trailerBytes": 3
},
"output": {
"result": {
"header": [
0,
2
],
"payload": [
2,
7
],
"trailer": [
7,
10
]
}
}
}Limitations and assumptions
- This is a position map rather than a packet parser. It does not infer lengths, fields or checksums.
- All declared input fields are required and unexpected top-level fields are rejected. Numbers must be finite; lists are limited to 128 entries and ordinary text fields to 8,192 UTF-16 code units, with tighter limits where stated.
- JSON text inputs must parse within bounded nesting and size limits. Numeric outputs outside the safe finite range are rejected; large exact integer results use decimal strings. Indexes and half-open spans are zero-based unless a rank is explicitly described as one-based.
Alternative or Complementary methods
Use a stateful protocol parser when processing partial streams or validating complete packets. Retain the declared prefix width, byte order and payload-versus-frame boundary convention when composing these operations.
References
Similar or alternative tools
- Byte Frame Chunk Carry Tool
Advance one fixed-byte streaming frame chunk with explicit incomplete carry, emitting complete frames and retaining the new tail; no sync search.
- Byte Frame Chunk Rejoin Tool
Rejoin explicit bounded byte chunks and report each chunk’s half-open source span, preserving empty-chunk provenance.