DBCS

Quirk found

Category: Text · Last tested 2026-09-01

Real compatibility results for the DBCS function: executed in Excel for the web, Google Sheets and LibreOffice Calc, with desktop Excel behavior from Microsoft’s official documentation (we do not run desktop Excel — Excel for the web is a different application and is executed separately). Syntax and links to that documentation are below.

Support matrix

Engine	Documented	Live-tested	Verdict
Excel (desktop)	Yes	No — documented only	n/a
Excel for the web	—	Yes (recalc, 2026-09-01)	Quirk found
Google Sheets	No	Yes (Drive import, 2026-08-31)	Unsupported (not recognized)
LibreOffice Calc	No	Yes (25.8.7.3, 2026-08-31)	Unsupported (not recognized)

LibreOffice version history

We executed the same test cases under each LibreOffice release to show exactly when DBCS’s support changed — not documentation claims, real results.

LibreOffice version	Verdict	Tested
24.2.0.3	Unsupported (not recognized)	2026-08-31
24.8.7.2	Unsupported (not recognized)	2026-08-31
25.2.0.3	Unsupported (not recognized)	2026-08-31
25.8.7.3	Unsupported (not recognized)	2026-08-31

Why isn't DBCS working in LibreOffice?

LibreOffice Calc does not implement DBCS as of 25.8.7.3 — in our executed tests it returns a #NAME? (unrecognized function) error. This is not a typo or a settings problem, and saving the file as .xlsx does not change it: the function simply isn’t available yet. The same formula is documented for Excel. Watch the LibreOffice version support page — we re-run every test on each new release, so it will flip to Supported here as soon as it lands.

Why isn’t DBCS working in Google Sheets?

Google Sheets does not implement DBCS: we imported the formula into Sheets on 2026-08-31 and every case came back #NAME? (unrecognized function). Sheets is a rolling service with no version to pin, so this is a statement about the service on that date, and Google’s own function list does not document it either. Rewrite the formula with a documented Sheets equivalent — see the Excel ↔ Sheets equivalents table.

Discovered quirks

=DBCS("EXCEL") on Excel for the web returned EXCEL, but the documented/expected result is ＥＸＣＥＬ.
Provenance
Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got 'EXCEL'
=DBCS("EXCEL") on Google Sheets returned #NAME?, but the documented/expected result is ＥＸＣＥＬ.
Provenance
Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
=DBCS("ＥＸＣＥＬ") on Google Sheets returned #NAME?, but the documented/expected result is ＥＸＣＥＬ.
Provenance
Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. This case is unambiguous under either reading of the page: the argument contains no half-width English letters or katakana, so the documented no-change clause applies and the result is the argument itself. EXECUTED RESULT: #NAME? on all four LibreOffice builds; see DBCS_halfwidth_latin_to_fullwidth for the three-spelling probe and for LibreOffice's JIS equivalent.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
=ASC(DBCS("EXCEL")) on Google Sheets returned #NAME?, but the documented/expected result is EXCEL.
Provenance
Deliberately locale-independent, and the reason this case exists. If DBCS converts (the documented rule), ASC converts back and the result is "EXCEL"; if DBCS is a no-op under a non-DBCS default language, ASC leaves the already-half-width text alone and the result is still "EXCEL". Both readings of Microsoft's page agree here, so a failure of this case cannot be blamed on the harness locale -- it can only mean the engine lacks one of the two functions or mangles the text. EXECUTED RESULT: #NAME? on all four LibreOffice builds. Because ASC itself is supported there (batch A executed it), the failure is entirely DBCS's, which is what this locale-independent case was built to establish.; MISMATCH vs expected: expected 'EXCEL', got '#NAME?'
=LEN(DBCS("EXCEL")) on Google Sheets returned #NAME?, but the documented/expected result is 5.
Provenance
Microsoft documents DBCS as changing half-width characters to full-width characters -- a one-for-one character mapping, not an encoding change -- so a five-character input yields a five-character result whether or not the mapping fires. This is the mirror of batch A's ASC_length_preserved case and separates a genuine width conversion from a byte-level reinterpretation. EXECUTED RESULT: #NAME? on all four LibreOffice builds -- LEN is supported, so the unrecognized name is DBCS.; MISMATCH vs expected: expected 5, got '#NAME?'
=DBCS("EXCEL") on LibreOffice Calc returned #NAME?, but the documented/expected result is ＥＸＣＥＬ.
Provenance
Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
=DBCS("ＥＸＣＥＬ") on LibreOffice Calc returned #NAME?, but the documented/expected result is ＥＸＣＥＬ.
Provenance
Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. This case is unambiguous under either reading of the page: the argument contains no half-width English letters or katakana, so the documented no-change clause applies and the result is the argument itself. EXECUTED RESULT: #NAME? on all four LibreOffice builds; see DBCS_halfwidth_latin_to_fullwidth for the three-spelling probe and for LibreOffice's JIS equivalent.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
=ASC(DBCS("EXCEL")) on LibreOffice Calc returned #NAME?, but the documented/expected result is EXCEL.
Provenance
Deliberately locale-independent, and the reason this case exists. If DBCS converts (the documented rule), ASC converts back and the result is "EXCEL"; if DBCS is a no-op under a non-DBCS default language, ASC leaves the already-half-width text alone and the result is still "EXCEL". Both readings of Microsoft's page agree here, so a failure of this case cannot be blamed on the harness locale -- it can only mean the engine lacks one of the two functions or mangles the text. EXECUTED RESULT: #NAME? on all four LibreOffice builds. Because ASC itself is supported there (batch A executed it), the failure is entirely DBCS's, which is what this locale-independent case was built to establish.; MISMATCH vs expected: expected 'EXCEL', got '#NAME?'
=LEN(DBCS("EXCEL")) on LibreOffice Calc returned #NAME?, but the documented/expected result is 5.
Provenance
Microsoft documents DBCS as changing half-width characters to full-width characters -- a one-for-one character mapping, not an encoding change -- so a five-character input yields a five-character result whether or not the mapping fires. This is the mirror of batch A's ASC_length_preserved case and separates a genuine width conversion from a byte-level reinterpretation. EXECUTED RESULT: #NAME? on all four LibreOffice builds -- LEN is supported, so the unrecognized name is DBCS.; MISMATCH vs expected: expected 5, got '#NAME?'

Executed test cases

Excel for the web (executed 2026-09-01 via OneDrive recalculation)

These values come from Excel for the web, not from desktop Excel. They are two different implementations of the calculation engine, and this run measured only the web one: the corpus was uploaded to OneDrive as .xlsx, recalculated by Excel for the web on open, and downloaded again for readback. Excel for the web is a rolling service with no pinnable version, so the run is identified by its date. Where a value here disagrees with the Expected column — which is Microsoft’s documentation of the desktop product — we cannot tell you whether the web engine diverges from the desktop one or the documentation is wrong about both, because we do not run desktop Excel.

Formula	Description	Result	Expected	Verdict
=DBCS("EXCEL")	Half-width (single-byte) Latin letters converted to full-width	EXCEL	ＥＸＣＥＬ Provenance Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.	Mismatch
=DBCS("ＥＸＣＥＬ")	Text that is already full-width is returned unchanged	ＥＸＣＥＬ	ＥＸＣＥＬ Provenance Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. This case is unambiguous under either reading of the page: the argument contains no half-width English letters or katakana, so the documented no-change clause applies and the result is the argument itself. EXECUTED RESULT: #NAME? on all four LibreOffice builds; see DBCS_halfwidth_latin_to_fullwidth for the three-spelling probe and for LibreOffice's JIS equivalent.	Matched
=ASC(DBCS("EXCEL"))	Round trip: converting to full-width and back to half-width	EXCEL	EXCEL Provenance Deliberately locale-independent, and the reason this case exists. If DBCS converts (the documented rule), ASC converts back and the result is "EXCEL"; if DBCS is a no-op under a non-DBCS default language, ASC leaves the already-half-width text alone and the result is still "EXCEL". Both readings of Microsoft's page agree here, so a failure of this case cannot be blamed on the harness locale -- it can only mean the engine lacks one of the two functions or mangles the text. EXECUTED RESULT: #NAME? on all four LibreOffice builds. Because ASC itself is supported there (batch A executed it), the failure is entirely DBCS's, which is what this locale-independent case was built to establish.	Matched
=LEN(DBCS("EXCEL"))	The conversion is character-for-character, so the length is unchanged	5	5 Provenance Microsoft documents DBCS as changing half-width characters to full-width characters -- a one-for-one character mapping, not an encoding change -- so a five-character input yields a five-character result whether or not the mapping fires. This is the mirror of batch A's ASC_length_preserved case and separates a genuine width conversion from a byte-level reinterpretation. EXECUTED RESULT: #NAME? on all four LibreOffice builds -- LEN is supported, so the unrecognized name is DBCS.	Matched

Google Sheets (executed 2026-08-31 via Drive import)

Google Sheets is a rolling service with no pinnable version, so this run is identified by its date. The corpus was imported to Drive as .xlsx, recalculated by Sheets, and exported back for readback.

Formula	Description	Result	Expected	Verdict
=DBCS("EXCEL")	Half-width (single-byte) Latin letters converted to full-width	#NAME?	ＥＸＣＥＬ Provenance Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.	Mismatch
=DBCS("ＥＸＣＥＬ")	Text that is already full-width is returned unchanged	#NAME?	ＥＸＣＥＬ Provenance Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. This case is unambiguous under either reading of the page: the argument contains no half-width English letters or katakana, so the documented no-change clause applies and the result is the argument itself. EXECUTED RESULT: #NAME? on all four LibreOffice builds; see DBCS_halfwidth_latin_to_fullwidth for the three-spelling probe and for LibreOffice's JIS equivalent.	Mismatch
=ASC(DBCS("EXCEL"))	Round trip: converting to full-width and back to half-width	#NAME?	EXCEL Provenance Deliberately locale-independent, and the reason this case exists. If DBCS converts (the documented rule), ASC converts back and the result is "EXCEL"; if DBCS is a no-op under a non-DBCS default language, ASC leaves the already-half-width text alone and the result is still "EXCEL". Both readings of Microsoft's page agree here, so a failure of this case cannot be blamed on the harness locale -- it can only mean the engine lacks one of the two functions or mangles the text. EXECUTED RESULT: #NAME? on all four LibreOffice builds. Because ASC itself is supported there (batch A executed it), the failure is entirely DBCS's, which is what this locale-independent case was built to establish.	Mismatch
=LEN(DBCS("EXCEL"))	The conversion is character-for-character, so the length is unchanged	#NAME?	5 Provenance Microsoft documents DBCS as changing half-width characters to full-width characters -- a one-for-one character mapping, not an encoding change -- so a five-character input yields a five-character result whether or not the mapping fires. This is the mirror of batch A's ASC_length_preserved case and separates a genuine width conversion from a byte-level reinterpretation. EXECUTED RESULT: #NAME? on all four LibreOffice builds -- LEN is supported, so the unrecognized name is DBCS.	Mismatch

LibreOffice Calc 25.8.7.3 (tested 2026-08-31)

Formula	Description	Result	Expected	Verdict
=DBCS("EXCEL")	Half-width (single-byte) Latin letters converted to full-width	#NAME?	ＥＸＣＥＬ Provenance Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.	Mismatch
=DBCS("ＥＸＣＥＬ")	Text that is already full-width is returned unchanged	#NAME?	ＥＸＣＥＬ Provenance Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. This case is unambiguous under either reading of the page: the argument contains no half-width English letters or katakana, so the documented no-change clause applies and the result is the argument itself. EXECUTED RESULT: #NAME? on all four LibreOffice builds; see DBCS_halfwidth_latin_to_fullwidth for the three-spelling probe and for LibreOffice's JIS equivalent.	Mismatch
=ASC(DBCS("EXCEL"))	Round trip: converting to full-width and back to half-width	#NAME?	EXCEL Provenance Deliberately locale-independent, and the reason this case exists. If DBCS converts (the documented rule), ASC converts back and the result is "EXCEL"; if DBCS is a no-op under a non-DBCS default language, ASC leaves the already-half-width text alone and the result is still "EXCEL". Both readings of Microsoft's page agree here, so a failure of this case cannot be blamed on the harness locale -- it can only mean the engine lacks one of the two functions or mangles the text. EXECUTED RESULT: #NAME? on all four LibreOffice builds. Because ASC itself is supported there (batch A executed it), the failure is entirely DBCS's, which is what this locale-independent case was built to establish.	Mismatch
=LEN(DBCS("EXCEL"))	The conversion is character-for-character, so the length is unchanged	#NAME?	5 Provenance Microsoft documents DBCS as changing half-width characters to full-width characters -- a one-for-one character mapping, not an encoding change -- so a five-character input yields a five-character result whether or not the mapping fires. This is the mirror of batch A's ASC_length_preserved case and separates a genuine width conversion from a byte-level reinterpretation. EXECUTED RESULT: #NAME? on all four LibreOffice builds -- LEN is supported, so the unrecognized name is DBCS.	Mismatch

Docs & syntax

Excel (desktop): official documentation

Where DBCS behaves differently

When the documentation is wrong: 29 vendor doc defects found by execution
Independent derivation across 586 executed functions found 29 places where a vendor's own page is contradicted by its own inputs, its own table, or the live engine: 23 Microsoft, 5 Google, 1 LibreOffice. Includes T.INV.2T's doubly-wrong Remark, DISC's stale figure, ISDATE's page against the live engine, and RAWSUBTRACT's help against LibreOffice's own result.