Collabora Office FINDB: Search using the engine’s weighted text positions
Find literal text with Collabora byte-style positions, understand CJK/fullwidth weighting and avoid treating the result as a UTF-8 byte offset.
Verification status: See the evidence and test scope described in this guide. How formula examples are checked
Quick answer: if A1 contains A中B, =FINDB("B";A1) predicts 4 in the pinned source. A weighs one position and 中 weighs two, so B begins at weighted position 4. This is the engine’s byte-style convention, not a UTF-8 file-byte offset.
Syntax and exact matching
=FINDB(Find_Text; Text [; Position])
Find_Text is the literal substring to locate. Text is the string being searched. Optional Position is the 1-based weighted starting position, defaulting to 1. Matching is case-sensitive. Official FINDB help.
The evaluator performs a literal substring search. Wildcards and regular expressions are not enabled by this function, and fullwidth letters are distinct from ordinary ASCII letters. Use positive integer positions rather than relying on fractional-position conversion.
What “byte” means in this source
The ByteLen and getLengthB helpers iterate UTF-16 code units and assign synthetic weights based on Unicode blocks. Selected Asian/CJK/fullwidth blocks weigh two; other units generally weigh one. Backslash and the euro sign have a special weight of two under the configured Japanese system language.
This is not a request to encode the string as UTF-8, Shift-JIS or another file encoding, and it is not a visual column-width measurement. Do not use a FINDB result directly to cut bytes from an external file. Supplementary characters and language-specific exceptions need separate scrutiny; the examples below use a small explicit ASCII/CJK/fullwidth set with unambiguous weights.
Worked example: three characters, four weighted positions
Enter the exact text A中B in A1. Its layout is:
| Character | Weight | Starting position |
|---|---|---|
| A | 1 | 1 |
| 中 | 2 | 2 |
| B | 1 | 4 |
The independently predicted expressions are:
| Formula | Result |
|---|---|
=FINDB("中";A1) |
2 |
=FINDB("B";A1) |
4 |
A character-counting search would place B third. FINDB places it fourth because the preceding Chinese character contributes two weighted units. The original text remains unchanged; the function returns a number, not the matching substring.
For =FINDB("Ｂ";"abＡＢc"), the expected position is 5: ASCII a and b contribute two units, then fullwidth Ａ contributes another two. The search character is fullwidth Ｂ, not ASCII B.
Advanced use: locate a field for a compatible replacement
A weighted position from FINDB can be used with REPLACEB when the text and replacement length follow the same weighting rules. For A1 = A中B, locating 中 gives position 2, and replacing its complete two-unit span with X produces AXB under the inspected replacement helper.
Keep the source string fixed between locating and replacing. A position found before inserting or deleting text may no longer identify the same field. Also keep the match length in the same weighted units; using one character as if it were one byte-style unit can cut a two-unit character.
Starting inside a weighted character
The search first constructs a suffix with the byte-style right-slice helper. If Position cuts through a two-unit character, that helper inserts a space for the partial character. This leads to a subtle source-derived result:
=FINDB("B";"A中B";3)still predicts 4.=FINDB(" ";"A中B";3)predicts 3, even though the original text contains no space.
The second result searches a synthetic partial-character buffer, not the untouched original string. Prefer positions aligned with complete character boundaries. Do not use arbitrary weighted starts to prove that a space exists in the original data.
Errors and compatibility limits
=FINDB("b";"AB") has no case-sensitive match and follows internal NoValue. The source validates the start against weighted_length(Text)−weighted_length(Find_Text)+1; =FINDB("B";"A中B";5) therefore follows IllegalArgument. These are distinct internal paths; their localized native UI presentation has not been tested.
The ScFindB implementation calculates the answer from the weighted prefix plus Position. It is not the character-index contract of FIND, and different spreadsheet engines’ DBCS behavior should not be assumed identical. Preserve the exact text, configured language and intended indexing convention when exchanging formulas.
Product scope, compatibility and evidence
This guide covers the new Collabora Office desktop for Linux, using the Flathub source tag coda-26.04.4.3-1 and commit 81339d176148d0d5c81ff05d82540f58f8aaa117. The official desktop release notes and Linux package manifest identify that product/build. The package manifest is a dated observation from October 18, 2026, rather than an installed-binary check.
The 26.04 function help and exact evaluator source were inspected on October 18, 2026. Expected examples were independently calculated; no Collabora application was run. Expected scalar results were derived from the documented contracts, inspected source and independent calculations; native output formatting and error localization have not been tested. Classic, Online/CODE, other operating systems and file-format round trips require their own checks.
Availability here is established from the function-specific help and the mapped package source. Related functions may have different arguments or boundary rules. The first Collabora release introducing this function is not established by the reviewed sources. No cited retirement or deprecation notice was found. Unknown introduction dates do not imply that the function is deprecated. File-format round trips require separate verification.