MIDB

What it does

MIDB(text, start_num, num_bytes)

MIDB(text, start_num, num_bytes) returns the run of text that begins at byte position start_num and is num_bytes bytes long, where byte positions are counted from 1.

The whole content of this function is the word "byte", and Microsoft states precisely when it means anything:

The B functions count each double-byte character as 2 only when a DBCS language has been enabled for editing and set as the default language. Otherwise they count each character as 1.

So MIDB has two behaviours and which one you get is a property of the machine, not of the formula. On a default-English installation MIDB(text, s, k) and MID(text, s, k) are the same function. On an installation whose default language is Japanese, Chinese (Simplified or Traditional), or Korean, every character in a double-byte range costs two positions.

The byte count is against the DBCS code page for the active language, not UTF-8 and not UTF-16. That distinction matters for anyone implementing this: a UTF-8 byte count would make a Latin-1 accented character cost two bytes and a CJK character cost three, and neither matches the DBCS rule.

Arguments

All three are required. The argument name is the only signature difference from MID; the arity and positions are identical.

Try it

Quirks

Result and edge cases

Returns Text.

The boundary rules Microsoft documents for MID are stated on the same page for MIDB with "characters" replaced by "bytes": a start_num past the end of text yields the empty string, and a window running past the end yields the bytes to the end of text.

The genuinely MIDB-specific question — what happens when start_num or start_num + num_bytes lands inside a double-byte character rather than on its boundary — is not answered by Microsoft's page. There are several defensible behaviours (return the half byte as a replacement character, drop the partial character, round the boundary outward, round it inward) and the Handbook does not know which one Excel implements. This is the single most important open question about this function and it is not a corner case: any offset arithmetic over mixed-width text hits it immediately.

Empty, missing and error arguments follow the shared call model; see Coercion and lifting.

Errors

As documented on Microsoft's MID, MIDB page:

Non-numeric text in a numeric argument slot and incoming error values behave as the shared coercion rules describe. The Handbook has not verified any of this against Excel.

How to implement

Notes for implementers

Three things make this function harder than it looks.

1. It is host-state dependent. The active default editing language is an input to the function that does not appear in its argument list. Any implementation that wants to match Excel needs that state threaded in, and any test vector for MIDB is meaningless without recording it.
2. The code page is per-language. Shift-JIS, GBK, Big5 and EUC-KR assign different byte widths to different characters. "Two bytes for CJK" is a summary, not a specification.
3. Partial-character windows are reachable and undefined here. Pick a behaviour, document it, and mark it as unverified — do not present a guess as the rule.

Rust code

12 midb_fn "MIDB" (3, 3) [V "text", V "start_num", V "num_bytes"] |s, a, sv| { single_byte(s)?; mid(s, a, true) }

No implementation has been published with a Handbook test suite for this function.

Version differences

No comparison between specific Excel builds is recorded here yet. This does not establish that all builds behave alike.

Alternatives

Relationships

• MID is the character-counting twin. Microsoft documents the two on a single page, MID, MIDB; the Handbook publishes them as two entries because they are two functions with two different addressing units.
• LENB is the function you need to reason about MIDB offsets at all, because MIDB positions are LENB positions, not LEN positions.

Named variants

No named variants are recorded yet.