Multiple Span Edit Applier
Apply nonoverlapping half-open UTF-16 edits in original coordinates; duplicate starts and overlapping spans are rejected.
Description
Apply nonoverlapping half-open UTF-16 edits in original coordinates; duplicate starts and overlapping spans are rejected.
Applying multiple edits in original coordinates avoids shifting later edit positions during validation. Right-to-left application preserves those coordinates until each edit is processed.
When to use this tool
Apply nonoverlapping half-open UTF-16 edits in original coordinates; duplicate starts and overlapping spans are rejected.
- Prepare the supplied text, editsJson 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 text, editsJson. 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.text, result.editCount. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Parse an edit array with exactly start, end and text fields. Require valid nonoverlapping half-open spans within text, reject repeated start offsets, then apply edits from the final span backward. Return the new text and edit count.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| text | text. | Text; at most 8,192 UTF-16 code units, subject to the grammar above |
| editsJson | JSON text, entered as one text field. The decoded structure is illustrated below; it is not a separate file. | Text |
For the JSON text fields, the following decoded structures show the example records before they are serialized into input strings. Keep field names, list nesting and value types as shown.
[
{
"field": "editsJson",
"decoded": [
{
"start": 1,
"end": 2,
"text": "XY"
}
]
}
]| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.text | The text value under the stated formula or text convention. |
| result.editCount | The edit count value under the stated formula or text convention. |
{
"input": {
"text": "abc",
"editsJson": "[{\"start\":1,\"end\":2,\"text\":\"XY\"}]"
},
"output": {
"result": {
"text": "aXYc",
"editCount": 1
}
}
}Limitations and assumptions
- Replacement text is literal and not rescanned. Edits are sorted internally; the tool does not validate linguistic boundaries; offsets are UTF-16 units, so a caller can deliberately or accidentally split a character sequence.
- Text offsets and lengths use UTF-16 code units unless explicitly described as bytes or code points. CRLF, CR and LF are recognized as line endings; a terminal newline creates a final empty line in the shared line model.
- Every declared top-level field is required and unexpected fields are rejected. Numeric inputs must be finite; ordinary text fields are bounded to 8,192 UTF-16 code units, with tighter operation-specific limits where stated.
- Ordinary string lists have at most 128 entries of at most 128 code units each; numeric lists and matrices have separate bounded size checks. Nonfinite results and excessively large serialized outputs are rejected.
- Indexes are zero-based and spans have an exclusive end unless explicitly stated otherwise. A valid false, null or empty-list result is distinct from malformed input.
Alternative or Complementary methods
Use a parser or language-aware editor when quoting, syntax or nested constructs matter. For plain text transforms, keep UTF-16 offsets, Unicode code points, grapheme clusters and UTF-8 byte offsets distinct; apply changes to the same source version used to calculate spans.
References
Similar or alternative tools
- edit distance
Compute the Levenshtein edit distance between two strings by Unicode code points.
- Line Span Intersection Tool
Intersect a half-open UTF-16 selection with line-content spans; exclude separators and zero-length contacts.