Contact

ASC Function in ONLYOFFICE Spreadsheet Editor: Syntax and Examples

Text and Data Intermediate ONLYOFFICE Spreadsheet Editor

Normalize full-width Latin letters, digits and punctuation with explicit limits for Japanese text and long strings.

Verification status: See the evidence and test scope described in this guide. How formula examples are checked

Quick answer

=ASC("ABC123") is expected to return the text ABC123. ASC can normalize full-width Latin letters, digits and punctuation before matching imported identifiers. It returns text, not character-code numbers.

Important version-specific limit: the official help describes full-width to half-width conversion broadly for double-byte character sets. The inspected 10.0.0.169 implementation converts only Unicode U+FF01 through U+FF5E. It does not convert full-width katakana or the ideographic space. Do not rely on this build’s ASC as a general Japanese width-normalization function.

Syntax and conversion rule

=ASC(text)

The single required argument is text or a reference to a cell containing it. No optional argument or language selector exists. For each UTF-16 code unit in the supported full-width interval, the implementation subtracts hexadecimal FEE0. All other code units are copied unchanged. Thus U+FF21 A becomes U+0041 A, and U+FF11 1 becomes U+0031 1.

This is a specific width mapping, not general Unicode normalization, transliteration, case conversion or an ASCII encoding operation. An output containing カ or an emoji can still contain non-ASCII characters.

Step-by-step: clean imported product keys

  1. Enter Original key in A1 and Normalized key in B1.
  2. Enter the exact text samples below in A2:A6, preserving the full-width characters.
  3. Enter =ASC(A2) in B2 and fill down.
  4. Compare column B with the destination system’s accepted character policy before using it as a key.
Row Original text Expected returned text
2 ABC123 ABC123
3 PART-07 PART-07
4 ABC123 ABC123
5 Aカ1 Aカ1
6 12.50 12.50

The expected strings come from independent Unicode code-point subtraction. Row 5 intentionally shows the limitation: katakana カ is outside U+FF01–U+FF5E and remains unchanged. Row 6 is text 12.50, not a numeric result; converting that text to a number is a separate, locale-sensitive decision.

Advanced case: normalize without silently merging identifiers

A supplier may send both ABC-12 and ABC-12. ASC maps both to ABC-12. That may be useful when they are two spellings of the same key, but it can also merge records that were previously distinct. Preserve the raw supplier key, create a separate normalized column and review duplicates before using the normalized value in a lookup or deduplication operation.

The ideographic space   (U+3000) is not the ordinary ASCII space. In =ASC("A B"), the expected result is A B, retaining that full-width space. If the receiving system requires ordinary spaces, make a separate explicit substitution after deciding that transformation is appropriate. Do not assume TRIM or CLEAN performs every Unicode-space normalization.

Length limits, errors and edge cases

Input or formula Source-derived expectation
=ASC("") Empty text
=ASC("カタカナ") Unchanged half-width katakana
=ASC("カタカナ") Unchanged full-width katakana in this implementation
=ASC("!@#") !@#
Text longer than 255 JavaScript code units #VALUE!
An input cell containing an error That error propagates

The length guard is based on JavaScript string length, which counts UTF-16 code units. A supplementary-plane character may occupy two code units, so “255 characters” is not a safe description for every Unicode string. The implementation checks length before conversion. Do not work around a failed long input by assuming it was partially converted.

For reliable batch processing, use one text cell per formula and keep the original data nearby. Range and array inputs have additional coercion and selection paths; this guide’s worked examples establish only the scalar text workflow. Cross-application functions with the same name may implement broader DBCS mappings, so compare representative characters before transferring a normalization process.

Availability, version and verification scope

The official ASC reference was checked on October 18, 2026. The implementation discussion uses official SDKJS source tagged v10.0.0.169, matching the version/build designation of Desktop Editors 10.0.0-169. Desktop Editors 10.0 was released on October 13, 2026. The first version introducing this individual function is not established by these sources. Current documentation does not mark it retired or deprecated.

Examples in this guide are expected results from documentation, source inspection and independent calculations, not results observed in the application. They have not been tested in the application or its calculation engine. The unversioned help and pinned source do not establish identical behavior in older versions, mobile clients, every server deployment or imported workbooks. Examples use English names and comma argument separators; adapt formula-entry separators to your editor settings.