DBCS

What it does

DBCS(text)

DBCS converts half-width (single-byte) characters in a string to their full-width (double-byte) equivalents. It is the inverse direction of ASC, and the background there applies here unchanged: the half-width/full-width distinction comes from the legacy East Asian double-byte character sets, where Latin letters, digits and katakana each had a one-column narrow form and a two-column wide form, and Unicode preserved both as separate code points. DBCS maps narrow to wide — A (U+0041) to Ａ (U+FF21), ｱ (U+FF71) to ア (U+30A2).

The widening direction has its own asymmetries, and they are not the mirror image of the narrowing ones:

1. Widening can shorten the string. The half-width sequence ｶ + ﾞ (base kana plus voiced sound mark) widens to the single character ガ. So DBCS performs a composition, which means it must look ahead: a character-by-character map is wrong precisely where the function is most used.
2. Almost everything ASCII has a full-width form. Unlike narrowing, where much of the full-width repertoire has no counterpart, the U+0021–U+007E range maps cleanly into U+FF01–U+FF5E. That regularity makes the Latin half of DBCS deceptively easy and tempts implementers into an arithmetic offset that then mishandles the kana.
3. The space is a special case. The ordinary space U+0020 widens to the ideographic space U+3000, which is not in the arithmetic range.

So the operational definition is: ask the environment whether width conversion is active; if it is, apply the half-width-to-full-width mapping with kana composition; if it is not, return the text unchanged.

Arguments

DBCS(text)

One argument and no options. Non-text arguments convert to text by the ordinary rules in coercion and lifting — which, note, means DBCS(123) asks about the string "123" and would widen the digits if conversion were active.

Try it

Quirks

Result and edge cases

The return kind is Text.

• The result can be shorter than the input in UTF-16 code units, because of kana composition. The dual of the ASC warning: LEN(DBCS(x)) >= LEN(x) is not a safe assumption either.
• On a host where width conversion is inactive, DBCS is the identity. This is what the upstream replay observed. A workbook that depends on DBCS therefore computes different values on different machines.
• Characters with no full-width form pass through.
• Errors propagate; an empty referenced cell delivers Empty, distinct from an omitted argument (see the value universe).
• The generated battery on this page cannot dispatch DBCS — the upstream reference implementation reports it as requiring a host facility, so the standard probe rows have no outcome. That is the honest result for a function whose semantics are host-supplied.

Errors

Microsoft's page is the authority and is linked below; it was not retrievable while this entry was written, so this section states expectations rather than quoting it.

How to implement

Notes for implementers

• Query the host before transforming. A port that always widens will disagree with Excel on every host where conversion is inactive — a configuration upstream actually observed.
• Compose the kana, do not map them. The ｶ + ﾞ → ガ case requires a two-character lookahead and a composition table. An offset-based implementation over the ASCII range will pass every Latin test and fail every kana one.
• Handle the space explicitly. U+0020 → U+3000 is outside the arithmetic range and is the most common non-Latin case in real data.
• Be prepared for the output to be shorter, and do not size the output buffer from the input length without allowing for it.
• Record the host profile in every fixture. Without it, a width-conversion result is not reproducible evidence.

Rust code

10 dbcs_fn "DBCS" (1, 1) [V "text"] |s, a, sv| { width_conversion(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

• ASC — the inverse direction, same host dependency, same module upstream. They are inverses in intent but not exactly: DBCS(ASC(x)) need not be x, because narrowing loses the distinction between characters that share a half-width form and widening composes sequences that were not composed before.
• LENB, LEFTB, MIDB, FINDB, SEARCHB, REPLACEB — the byte-oriented compatibility family that exists for the same East Asian reasons. Upstream records them as current-baseline delegates to their non-B counterparts, with LENB explicitly retaining UTF-16 code-unit counting after LEN moved to Unicode-scalar counting.
• UPPER and LOWER — a different axis entirely. Width and case are independent.
• Unicode NFKC normalisation goes the other way (it narrows), so it is not a substitute for DBCS in any direction.

Named variants

No named variants are recorded yet.