| Previous | Next |
| ERROR_NO_MEDIA_IN_DRIVE | ERROR_DLL_INIT_FAILED |
ERROR_NO_UNICODE_TRANSLATION
no mapping for the unicode character exists in the target multi-byte code page.
ERROR_NO_UNICODE_TRANSLATION means that a Unicode-to-legacy-code-page conversion encountered one or more characters that cannot be represented. In this case, the decisive context is WideCharToMultiByte and similar conversion APIs, together with source text or escaped code points, target code page, flags, and default-character settings.
Where the result appears
- WideCharToMultiByte and similar conversion APIs.
- writing filenames, text, or protocol fields to legacy encodings.
- interop with ANSI-only applications, devices, databases, or wire formats.
- locale-sensitive import/export and command-line processing.
Typical causes
- the destination code page lacks the source character.
- strict conversion flags reject best-fit or replacement mappings.
- the wrong code page was selected for the external format.
- input contains supplementary, combining, or script characters unsupported by the legacy encoding.
Evidence to collect
- source text or escaped code points, target code page, flags, and default-character settings.
- whether the external format actually specifies UTF-8 or another encoding.
- OS locale assumptions and any prior lossy conversion.
- the first unrepresentable character and the required round-trip behavior.
For this condition, begin the investigation with source text or escaped code points, target code page, flags, and default-character settings. Correlate it with whether the external format actually specifies UTF-8 or another encoding and check whether the destination code page lacks the source character. Capture the original this result immediately after the failing call so later cleanup does not replace the thread-local error value.
Handling and recovery
Prefer UTF-8 or another Unicode encoding end to end. When a legacy format is mandatory, define whether rejection, transliteration, or an explicit replacement character is acceptable, and report the affected field to the caller. Never silently reinterpret bytes using the machine’s current ANSI code page.
Any retry policy for this Win32 error should be tied to evidence that strict conversion flags reject best-fit or replacement mappings has changed. Before another attempt, verify OS locale assumptions and any prior lossy conversion. If input contains supplementary, combining, or script characters unsupported by the legacy encoding still applies, stop the retry sequence and preserve the first diagnostic event.
Common misinterpretation
The source Unicode text is not necessarily invalid. The failure means the chosen destination encoding cannot represent it without loss.
Guidance for developers
When surfacing this result through another layer, retain its Win32 domain, numeric value, and the operation described by writing filenames, text, or protocol fields to legacy encodings. A useful telemetry record also includes the first unrepresentable character and the required round-trip behavior. For a-related handling, decisions must use the numeric value and documented API contract rather than localized wording.
A focused test should reproduce the condition in which the wrong code page was selected for the external format, assert this result, and confirm that the program releases resources associated with interop with ANSI-only applications, devices, databases, or wire formats. The recovery test should also verify that source text or escaped code points, target code page, flags, and default-character settings is refreshed before the operation resumes.
References
Looking for a different code? Search another status or error code.