RIGHTB

What it does

RIGHTB(text, [num_bytes])

RIGHTB(text, [num_bytes]) returns the last num_bytes bytes of text.

It is RIGHT with one unit changed, and the change only takes effect under one condition. Microsoft's rule for the whole B family:

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 on most installations RIGHTB is RIGHT. On a machine whose default editing language is Japanese, Chinese (Simplified or Traditional) or Korean, the same call takes a different — and generally shorter — slice of the same string. The active default language is an unlisted input to this function, and any recorded result for it that omits that setting is incomplete.

The bytes are those of the DBCS code page for the active language — Shift-JIS, GBK, Big5, EUC-KR — not UTF-8 and not UTF-16.

Arguments

The signature is RIGHT's with num_chars renamed. The count is optional here just as it is on RIGHT, and defaults to 1 — which under DBCS means "one byte", i.e. potentially half a character. That is not a hypothetical: RIGHTB(A1) on a string ending in a double-byte character is the partial-character case, reached by the shortest possible call.

Try it

Quirks

Result and edge cases

Returns Text.

The rules Microsoft documents for RIGHT are stated on the same page for RIGHTB with "characters" replaced by "bytes": the count must be non-negative, a count greater than the length of text returns all of text, and an omitted count means 1.

The distinctively RIGHTB question is undocumented: what happens when the byte window begins inside a double-byte character. Because the window is anchored at the end and measured backwards in bytes, an odd num_bytes over double-byte text lands mid-character by construction. Excel could drop the partial character, return its orphaned byte, round the boundary outward to include the whole character, or error. Microsoft's page names none of these, and the Handbook does not know which it is.

Errors

Whether a partial-character window is an error condition at all is the open question above.

How to implement

Notes for implementers

Backwards byte counting over a variable-width encoding is not a symmetric operation. Finding the byte n - k + 1 requires knowing the byte length of every character in the string, so RIGHTB cannot be implemented as a reverse scan of characters — it needs the full byte accounting that LENB computes.

The default of 1 makes the partial-character case the cheapest call to write, not the rarest, which is an argument for deciding it deliberately rather than letting it fall out of an implementation detail.

A test vector for RIGHTB that does not record the default editing language records nothing. The same inputs have two legitimately different correct answers.

Rust code

11 rightb_fn "RIGHTB" (1, 2) [V "text", V "num_bytes"] |s, a, sv| { single_byte(s)?; right(s, a) }

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

• RIGHT — the character-counting twin, documented by Microsoft on the same page. The Handbook publishes them as two entries because they count in two different units.
• LEFTB — the head-anchored byte slice, and the one place where the partial-character question can be studied from the other end of the string.
• LENB, FINDB, SEARCHB, MIDB, REPLACEB — the rest of the B family, sharing one implementing module and this page's central caveat.
• LENB is the only function that produces coordinates in the same byte space, so it is the companion for reasoning about RIGHTB at all.

Named variants

No named variants are recorded yet.