ASC

What it does

ASC(text)

ASC converts full-width (double-byte) characters in a string to their half-width (single-byte) equivalents.

The concepts come from East Asian text handling and predate Unicode. In the legacy double-byte character sets used for Japanese, Korean and Chinese text, Latin letters, digits and katakana each existed in two forms: a half-width form occupying one byte and one display column, and a full-width form occupying two bytes and two display columns. Unicode preserved both, so the distinction survives as separate code points — A (U+0041) versus Ａ (U+FF21), ｱ (U+FF71) versus ア (U+30A2). ASC maps the wide forms down to the narrow ones. The mapping is not a rounding or an approximation; it is a table.

Two details make the katakana half of the mapping harder than the Latin half:

1. Voiced katakana are one character wide and two characters narrow. Full-width ガ is a single code point; its half-width form is the pair ｶ + ﾞ (a base kana and a combining-style voiced sound mark). So ASC can lengthen a string, and a naive one-to-one mapping table is wrong.
2. Not everything has a half-width form. Hiragana, kanji, and most full-width punctuation outside the ASCII-mirror block have no narrow counterpart and pass through untouched.

Now the part that matters most for this entry, and which is easy to get wrong by reading only the concept: whether ASC converts anything at all depends on the host environment. The function is part of the East Asian compatibility surface, and its behaviour is tied to the language settings of the Excel installation rather than being a fixed text transformation.

So the operational definition of ASC is two-stage: ask the environment whether width conversion is active for this function; if it is, apply the full-width-to-half-width table; if it is not, return the text unchanged. That is a genuinely unusual shape for a worksheet function, and it is the reason this page is careful.

Arguments

ASC(text)

One argument, no options — no way to ask for only the Latin part, only the katakana part, or a specific mapping table. Non-text arguments convert to text by the ordinary rules in coercion and lifting.

Try it

Quirks

Result and edge cases

The return kind is Text.

• Characters with no half-width form pass through, so ASC applied to hiragana or kanji is the identity.
• The result can be longer than the input in UTF-16 code units, because of the voiced-katakana decomposition described above. Any assumption that LEN(ASC(x)) <= LEN(x) is false in general — it is false in exactly the case the function exists for.
• On a host where width conversion is not active, ASC is the identity function on all input. This is the case the upstream replay observed. A workbook that relies on ASC therefore computes different values on different machines, which makes it unsuitable for anything auditable without pinning the environment.
• Errors propagate, and an empty referenced cell delivers Empty rather than a missing argument; see the value universe.

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.

#NAME? for an existing function is jarring, and worth explaining: it is the worksheet's answer when a name is not recognised in the current environment, which is what a compatibility function looks like on a host that does not admit it.

How to implement

Notes for implementers

• Do not implement this as a local text function without a host query. The upstream design — ask the host for the mode, then apply the transformation — is the shape that matches observed behaviour. A port that always narrows will disagree with Excel on every host where conversion is inactive, which upstream observed to include a real one.
• The mapping table must handle the voiced katakana decomposition, which is one-to-two. Build it as a table, not as an arithmetic offset, even though the Latin block is tantalisingly regular (U+FF01–U+FF5E maps to U+0021–U+007E by subtracting 0xFEE0).
• The full-width space U+3000 maps to the ordinary space U+0020, which interacts with TRIM: narrowing first can change what a later TRIM removes.
• Work in UTF-16 code units and be prepared for the output to be longer.
• Record the host profile in any test fixture. A width-conversion test with no environment recorded is not reproducible, and is arguably not evidence at all.

Rust code

9 asc_fn "ASC" (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

• DBCS — the exact inverse direction: half-width to full-width. Same host dependency, same module upstream.
• LEN versus LENB — the width distinction shows up again in the byte-counting functions, and the *B family (LEFTB, MIDB, FINDB, …) exists for the same East Asian reasons. Upstream records those as current-baseline delegates to their non-B counterparts rather than as independent byte-semantic implementations.
• UPPER and LOWER — case conversion, frequently confused with width conversion because both "change the letters". They are independent axes: Ａ and ａ differ in case, A and Ａ differ in width.
• Unicode's own NFKC normalisation performs a superset of ASC's Latin mapping. It is not a substitute — NFKC also folds ligatures, superscripts and much else.

Named variants

No named variants are recorded yet.