Collabora Office SEARCHB: Case-Insensitive Byte Positions
Find literal text using source-defined byte positions, explicit starting offsets and document-dependent pattern settings. Scoped to the new Linux desktop source build.
Verification status: See the evidence and test scope described in this guide. How formula examples are checked
SEARCHB finds text without case sensitivity and reports a one-based byte-style position. In this source, “byte” is a compatibility counting convention, not the number of UTF-8 bytes in a saved file or the number of displayed glyphs.
Syntax and starting position
=SEARCHB(Find Text; Text [; Position])
Find Text is what to locate; Text is where to search. Position defaults to 1. The return value remains an absolute position in the original text, rather than a position relative to the searched suffix.
The evaluator constructs a case-insensitive search and chooses literal, wildcard or regular-expression handling from the document’s formula-search settings and the search text. Therefore wildcard or regex behavior is not unconditional. The examples below contain no pattern metacharacters and use ordinary literal searches.
Step by step: case and repeated matches
Enter A2 as text Banana and B2 as text a, then calculate =SEARCHB(B2;A2). The independent/source-derived result is 2, the position of the first a.
=SEARCHB("A";"Banana";3)
This starts at position 3 and finds the next a at absolute position 4. The uppercase A still matches lowercase a. Returning 2 here would incorrectly report an offset within the suffix rather than within the original text.
For =SEARCHB("beta";"Alpha BETA"), the expected result is 7. The space after Alpha occupies position 6. These literal ASCII controls do not establish every language’s case-folding or normalization behavior.
Byte positions differ from character positions
Consider the text 甲乙A乙. The checked helper counts each of these BMP CJK characters as two units and the ASCII A as one:
| Character | Starting byte-style position |
|---|---|
| 甲 | 1 |
| first 乙 | 3 |
| A | 5 |
| second 乙 | 6 |
Thus =SEARCHB("A";"甲乙A乙") has expected result 5, even though A is the third character in this example. =SEARCHB("乙";"甲乙A乙";5) starts at the ASCII A and finds the second 乙 at 6.
These are source-derived counts, not application observations. The specific characters avoid supplementary-plane and combining-character ambiguities.
What the source means by bytes
The helper assigns one or two units to UTF-16 code units using a listed set of Unicode blocks. It also treats backslash and the euro sign specially under a Japanese configured system language. This is not a general UTF-8 or UTF-16 file-offset API.
A start position can fall inside a two-unit character. The source’s suffix helper can replace a partially selected character with a space. For predictable searches, use known character-aligned byte positions rather than assuming every integer offset is a character boundary. No universal grapheme-cluster or locale-invariant result is promised.
Advanced: locate a second occurrence without losing the coordinate system
In the Banana example, the first a is at 2 and the second is at 4. Starting the next search after the first match is straightforward for a one-unit ASCII search token. For a multi-unit token, advancing by one is not automatically the same as advancing past the whole token; its byte-style length matters.
Keep SEARCHB positions paired with compatible byte-oriented operations when extracting substrings. Feeding the number 5 from the CJK example into a character-oriented operation would mean something different. A position is meaningful only together with its counting convention and the exact original text.
Search settings also matter for punctuation. A literal asterisk in source text should not be assumed to be a wildcard or an ordinary character in every document. Verify the document’s configured search mode and escaping rules before constructing pattern searches; this guide’s controls intentionally remain literal.
Errors and limits
=SEARCHB("z";"Banana") reaches internal NoValue because no match is found. Position 0 reaches internal IllegalArgument. Position 7 is beyond this six-unit string and reaches NoValue. These are exact-source branch predictions; localized error displays were not tested.
Do not confuse a failed search with position zero: successful positions are one-based. Empty search text, fractional positions, locale-specific case equivalence and arbitrary Unicode normalization are outside the validated controls. SEARCHB’s case-insensitive contract differs from a case-sensitive search, while its coordinate system differs from ordinary character positions.
Product scope and evidence
This guide concerns the new Collabora Office desktop for Linux, source tag coda-26.04.4.3-1, commit 81339d176148d0d5c81ff05d82540f58f8aaa117. The 26.04 SEARCHB help and exact evaluator source were checked October 18, 2026. The Linux package manifest supplies the recorded product mapping; its mutable publication is not an installed-binary attestation.
No Collabora runtime or spreadsheet calculation engine was executed. Examples are source-derived expectations and independent mathematical controls. No screenshots or interface tests are claimed. This evidence does not establish Classic, Online, CODE, mobile, Windows or macOS parity.
The first Collabora release introducing this function is unknown from the checked evidence. Current documentation and registration do not establish retirement or deprecation, and upstream release history is not substituted for product-specific introduction. Import/export behavior in other products was not tested.