# 22P05 — untranslatable_character

> Source-backed reference for PostgreSQL SQLSTATE 22P05.
---

# 22P05

## At a glance {#at-a-glance}
PostgreSQL could identify a source character but could not represent it in the destination encoding. The fixed helper reports the offending bytes and both encoding names with primary `character with byte sequence %s in encoding "%s" has no equivalent in encoding "%s"` at `ERROR` severity.

<!-- BEGIN SQLSTATE FACTS: generated by scripts/generate.py; do not edit -->

| Field | Value |
| --- | --- |
| SQLSTATE | `22P05` |
| Condition | `untranslatable_character` |
| Status | `active` |
| Known present by | `7.4` |
| Locked snapshots | `9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3` |
| Macros | `ERRCODE_UNTRANSLATABLE_CHARACTER` |
| Aliases | `—` |

<!-- source facts: data/errcodes/22P05.json -->
<!-- END SQLSTATE FACTS -->

## Meaning {#meaning}
`report_untranslatable_char(src_encoding, dest_encoding, ...)` determines the source multibyte length, formats the offending bytes as `0x..`, and raises `22P05` when the destination conversion table has no equivalent character. This means the source character is valid enough to identify, but the target representation cannot carry it. It is different from malformed source bytes: the fixed conversion loop can call `report_invalid_encoding`, which uses `22021` instead.

## Messages {#messages}
- `ERROR` primary: `character with byte sequence %s in encoding "%s" has no equivalent in encoding "%s"`
- The fixed call supplies no DETAIL or HINT.

## Diagnosis {#diagnosis}
Read the exact byte sequence, source encoding, destination encoding, and conversion direction from the primary. Check `client_encoding`, server/database encoding, import or COPY file encoding, and the actual conversion boundary. Do not treat the presence of a non-ASCII character as proof of `22P05`; malformed source bytes and ordinary type-input failures have different paths.

## Response {#response}
Choose a destination encoding that represents the data, or correct the producer and conversion boundary while preserving the character. Do not silently replace or discard it unless loss is an explicit data policy. Because the cited path is `ERROR`, an explicit transaction needs `ROLLBACK` or `ROLLBACK TO SAVEPOINT` before retrying; in autocommit, correct the encoding or input and submit again. This source path does not imply a connection reset or a `FATAL` session end.

## Versions {#versions}
The locked catalogue records this condition from PostgreSQL `7.4`. The reporting helper and representative conversion branch cited here are from PostgreSQL 18.6 `REL_18_6`; no encoding runtime was executed.

## Related {#related}
[`22021`](../22021/), [`22P02`](../22p02/)

## Sources {#sources}
[`src/backend/utils/mb/mbutils.c#L1862-L1902`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/mb/mbutils.c#L1862)

[`src/backend/utils/mb/conv.c#L674-L684`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/mb/conv.c#L674)

The structured [evidence record](../data/evidence/22p05.json) records the exact primary and the valid-character versus malformed-byte boundary.