Line and Column to UTF-16 Offset
Map one-based logical line/UTF-16 content column to offset; columns inside separators are intentionally not accepted.
Description
Map one-based logical line/UTF-16 content column to offset; columns inside separators are intentionally not accepted.
Editor-style line and column coordinates need a declared counting unit. Here both are one-based, while columns count UTF-16 code units within line content.
When to use this tool
Map one-based logical line/UTF-16 content column to offset; columns inside separators are intentionally not accepted.
- Prepare the supplied text, line, column 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, line, column. 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.offset. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Split CRLF, CR and LF endings. Validate line within the parsed list and column from one through content length plus one, then return lineStart+column-1 as the zero-based offset.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| text | text. | Text; at most 8,192 UTF-16 code units, subject to the grammar above |
| line | line. | Integer from 1 to a.length inclusive |
| column | column. | Integer from 1 to r.text.length + 1 inclusive |
| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.offset | Zero-based UTF-16 offset in the supplied source text. |
{
"input": {
"text": "a\r\nb",
"line": 2,
"column": 1
},
"output": {
"result": {
"offset": 3
}
}
} Limitations and assumptions
- The final column denotes the content-end boundary, not the interior of CRLF. Tabs count as one code unit and surrogate pairs as two; visual columns and grapheme columns need another method.
- 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
- UTF-16 Offset to Line and Column
Map a UTF-16 offset to one-based line/column with CRLF treated as one line separator; offsets inside CRLF retain their physical column.
- Code Point Index to UTF-8 Byte Offset
Convert zero-based Unicode scalar index to UTF-8 byte offset; reject unpaired surrogates and count scalars rather than grapheme clusters.