CODE

What it does

CODE(text)

CODE takes a text value, looks at its first character only, and returns the numeric code of that character in the host's character set. Microsoft's article says exactly that the returned code "corresponds to the character set used by your computer", and names the Macintosh character set on Macintosh and ANSI on Windows.

Everything after the first character is discarded. CODE is therefore not a hash, not a checksum and not a length-sensitive function: CODE("A") and CODE("Alphabet") are the same call as far as the result is concerned.

The function is the intended inverse of CHAR, and inherits the same open question in the same place: for characters inside ASCII every candidate encoding agrees, and above 127 they do not. See CHAR for the statement of that question; it is one question, not two.

Arguments

text — required, the text whose first character is to be coded. The argument is a text argument, so the ordinary to-text conversion applies: a number arrives as its General-formatted rendering and a logical as TRUE or FALSE, which means CODE of a number is the code of the first digit character of that number's rendering, and CODE(TRUE) is the code of T. This is the argument position readers most often misread — the function looks numeric and behaves textually.

There is no second argument, no index, and no way to ask for the code of the n-th character; compose with MID for that.

Try it

Quirks

Result and edge cases

The return kind is Number, and it is a small non-negative integer whenever the call succeeds.

• Empty text. CODE("") has no first character, so the function has nothing to return. What Excel does here is not stated in Microsoft's article text and has not been checked for this Handbook.
• Surrogate pairs. A character outside the Basic Multilingual Plane is two UTF-16 code units. Whether Excel's CODE reports the leading surrogate, some replacement, or an error is an open question, and it is a live one now that Microsoft has begun changing surrogate handling under the Compatibility Version feature — see LEN, whose documentation records exactly such a change.
• Empty cells, omitted arguments and arrays follow the shared call model in chapter 03; nothing here is function-specific.

Errors

Error inputs propagate rather than convert (chapter 02).

How to implement

Notes for implementers

Three decisions are load-bearing and none of them is settled by the documentation:

1. Which encoding. "The character set used by your computer" is an instruction to be host-dependent. A single-encoding implementation is making a choice; it should say which.
2. First character or first code unit. These differ exactly for astral characters. An implementation that reads the first UTF-16 code unit will report a lone surrogate value for an emoji; one that decodes first will report either a code point above 0xFFFF (which cannot be a byte-set index) or an error.
3. Round-tripping. CODE(CHAR(n)) = n is the property users assume. It holds for whatever subrange the two functions agree on, and any implementation should test the round trip across the entire 1–255 range rather than on ASCII samples, because ASCII is precisely where the interesting disagreements are absent.

Rust code

2 code_fn "CODE" (1, 1) [V "text"] |s, a, sv| {
    let text = text_arg(s, a, 0)?;
    out(s, k::code_of_text(&text))
}

/// CODE: the code page 1252 code of the first character, 63 (`?`) for a character outside it;
/// empty text is #VALUE!.
pub(crate) fn code_of_text(text: &ExcelText) -> Result<f64, WorksheetErrorCode> {
    let Some(&unit) = text.utf16_code_units().first() else {
        return Err(WorksheetErrorCode::Value);
    };
    if unit < 0x80 || (0xA0..=0xFF).contains(&unit) {
        return Ok(f64::from(unit));
    }
    match CP1252_HIGH.iter().position(|&mapped| mapped == unit) {
        Some(at) => Ok((0x80 + at) as f64),
        None => Ok(63.0),
    }
}

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

• CHAR — the inverse direction, sharing the host-character-set dependency.
• UNICODE — the Unicode-explicit counterpart, returning the code point rather than a host-encoding index. Where a formula must be portable across hosts and locales, UNICODE is the function that means what it says.
• UNICHAR — inverse of UNICODE, and thus the modern counterpart of CHAR.
• Neither CODE nor CHAR is a Compatibility-category function; Microsoft has not superseded either. The Unicode pair was added alongside them, not in place of them.

Named variants

No named variants are recorded yet.