Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wIqQq-008Wv6-0n for pgsql-bugs@arkaria.postgresql.org; Fri, 01 May 2026 16:09:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wIqQp-00BWrL-1m for pgsql-bugs@arkaria.postgresql.org; Fri, 01 May 2026 16:09:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wIqQp-00BWrD-0t for pgsql-bugs@lists.postgresql.org; Fri, 01 May 2026 16:09:35 +0000 Received: from mail-vk1-xa2a.google.com ([2607:f8b0:4864:20::a2a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wIqQn-00000004I83-1Bzj for pgsql-bugs@lists.postgresql.org; Fri, 01 May 2026 16:09:35 +0000 Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-56a9c5cb48bso745691e0c.0 for ; Fri, 01 May 2026 09:09:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777651771; cv=none; d=google.com; s=arc-20240605; b=Sc+szIY2AZoMsby9M6fcVdRrHqLP4IdcHidZZT4o+kir0j6Z6fZch7999u20VMZDCR oBMagu6gyX25GKfh55UCzWNH91FsXZbwsodMabZAQ6M7dMUqEg8fwyhvI/ugbZ9H50II hITTfnunU1uXXQ9I2eWAQTRFzfeUT7yP9Ip5sc3obkNEgOYliFTBE7zKGNCI+Ullep3v ckDf6BDArYz9DiqO0oSsHo1KFUkHNgDwCrxSavI/l264MgqO9anIs2myV5y10zPkeTZU 79bd8puT7Vm+SPY0+g9gRuKirKsfuLrHS1Uw6rrUmbbQuEPNgYkVlH8f7a9BIdHVDa5N F3wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=z9p2Lfc+32JSuMGkv3ghZLPW00jpuru1bQwYKyo4mMk=; fh=W51hU6Nz0q6hP/4jH2clw4Ts8yC7LdH3ZbBMGz7wllw=; b=H6hKbO4mNSFsh51Y8FUpb8PgZ46CBN0Ufxa3TOYvX/WRYyvV740e9B2od9OvYTkynM 0IC+GgoP7LWvgnb0R1CYSlJSAURDKwANSOZDASc+kQqmt9jKlAnMZ0kePLNcqsuWgfaL yv9Q5oOpTyvEhrj+wFcBJsCD5phvo797iGkJ0RDi7tq3EUEIFGeBZyvOB3o6LRbZI4w8 wZSwAtkAg1kmnPVl+y+9C+rv2M/mN/gzhxWp1qqZDfmSJNCPKcPm9MYDEw1s+h0pP2BZ vp6+Tp5p/u3DNNmGEUklKKxmoOm9cRmuE7E83mKdwC10F6j+ENJNZZ93oceYIvbFdpZW XF5g==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777651771; x=1778256571; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=z9p2Lfc+32JSuMGkv3ghZLPW00jpuru1bQwYKyo4mMk=; b=U1gnEvoEa7tYUMT6zyXQWr81ML8xqEI9+gB83oi+t93kLzRIGrk1Y3ppSakAxSB7e2 utfACJXLj+X1nHzjWvJxY8jxyQVSLXDSLWOQ2cWwJzGT40jT0jc26p2mHwhMy7nBv0bS tda+iWJN3f69QzKJpYdNNmfTgdhpqa5NR7jYLkjIWH2AaM8MfVA4OSZy8SG7ZDSR6pNz MBcdUJCVgZbIcOK0yeYJFvxjvr63UmEHOZd5M5/aQbWHCUIAS1dVCdUuir+NNM953zC9 5KTH/P+Oq4RPnl63biC/+RQM0H33h3nThMBs2ykIrRcCjP6fe6HmxMAfP/KAM866oTOS GARw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777651771; x=1778256571; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=z9p2Lfc+32JSuMGkv3ghZLPW00jpuru1bQwYKyo4mMk=; b=i7Ci9h3Bh9PbgJvuD2qJvfjrM6OwWuJUd+O3P4oE2VBQ7pwIPuvwOkE0g80Gwmb9qa Kyl1wf2iGDD1vKvFC96t9w2SI9ujAHhOxUtX056rvgMd313z1fb+yr9CXSK9m2U5zUx7 rUqU4vE4Gt4vMPgrnnHObOQPBdZ6ALnF6E2g+eTAzeIDYjTRYKO0ft8JEit1hoyXwBlE WbBSnRD7cMrVGP0lqxao6uejIZnpmO9D3h8XaGrPHfLsHezl7HKW1CJEMwqdi/7jyiFH sX9V+fE1oXiYzzLIigTdjZSv0Skm+lp4+HVxLZGDJQqZx+xzM+aZ/99j9Zp2gQaWrnWZ 5IvQ== X-Gm-Message-State: AOJu0YxbsQzK+zPI3KLEgE4zsmp3690ypBNCGApmZ0ct7wY+HB2vshF/ Y6WQeuZSudpUSOEoIMAXVtA5ni+gL429f3H1hu186rQ8hU8WgPBxd/3/NhByqgm+IV5O61QlAwz TXKjuXdaY3DzTWkLdtIx2DWFS9JH7Ufk= X-Gm-Gg: AeBDiettL4BxeGQcs8qpC7fgvIZbA6Ls8UpR8f8OT0UaQV0RUzfQRRPiuTj2mvu7lqt Z9X+VOEqs3l5/iAqSVtKDruOvLZGvyAPV4R4X6tbFfZqnlnn4HE3riEOrQ1R7avheHoKM7wnyQk jFVRSqT18EDbHy506I2P+uYuIkx7fA8k9cNr8yj6dh6gEYdrwhsuqsTygwwaI+UhVIXjlG1eVyg pKkTo40wpPPLZykH8XlLf7dvYQvEcpLII+6xftNnaf9aqLDS9B00pocgtAp2Xf7HBuVAILvWTyS h3PnyXiZzrNaZ21L6UM= X-Received: by 2002:a05:6102:5f03:b0:62b:148e:9d0e with SMTP id ada2fe7eead31-62c33319d0amr1972534137.9.1777651771462; Fri, 01 May 2026 09:09:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zhongpu Chen Date: Sat, 2 May 2026 00:09:19 +0800 X-Gm-Features: AVHnY4LI3Se3n0VYvR6ZTYHVII9nQ7Cy9hwIoApQslJTEDdZDI5AhDB_YlaImi8 Message-ID: Subject: Re: Character with byte sequence 0xa2 0xa3 in encoding "EUC_CN" has no equivalent in encoding "UTF8" To: Junwang Zhao Cc: pgsql-bugs@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000005f574f0650c3ce03" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005f574f0650c3ce03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ``` demo_euc_cn_db=3D# SET client_encoding TO 'EUC_CN'; SET demo_euc_cn_db=3D# SELECT * FROM t WHERE id =3D 1; id | s ----+---- 1 | =EF=BF=BD=EF=BF=BD (1 row) ``` Since 0xA2A3 is invalid in EUC-CN, it cannot be mapped to any meaningful character. Currently, EUC-CN allows all 2-byte within A1-EF, but this coarse-grained approach is flawed. On Fri, May 1, 2026 at 11:07=E2=80=AFPM Junwang Zhao wr= ote: > On Fri, May 1, 2026 at 9:59=E2=80=AFPM Zhongpu Chen wrote: > > > > ## Description > > > > The legacy encodings allow some invalid bytes, which will cause errors > during SELECT operations. > > > > ## How to reproduce > > > > ```shell > > createdb -E EUC_CN -T template0 --locale=3DC demo_euc_cn_db > > ``` > > > > ```sql > > demo_euc_cn_db=3D# CREATE TABLE t(id int, s varchar(10)); > > > > demo_euc_cn_db=3D# INSERT INTO t VALUES(1, E'\xA2\xA3'); > > INSERT 0 1 > > demo_euc_cn_db=3D# SELECT * FROM t WHERE id =3D 1; > > ERROR: character with byte sequence 0xa2 0xa3 in encoding "EUC_CN" has > no equivalent in encoding "UTF8" > > Can you try the following statement before select? > SET client_encoding TO 'EUC_CN'; > > > ``` > > > > -- > > Zhongpu Chen > > > > -- > Regards > Junwang Zhao > --=20 Zhongpu Chen --0000000000005f574f0650c3ce03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

```
demo_euc_cn_db=3D# SET c= lient_encoding TO 'EUC_CN';
SET
demo_euc_cn_db=3D# SELECT * F= ROM t WHERE id =3D 1;
=C2=A0id | s
----+----
=C2=A0 1 | =EF=BF=BD= =EF=BF=BD
(1 row)
```

Since 0xA2A3 is= invalid in EUC-CN, it cannot be mapped to any meaningful character. Curren= tly, EUC-CN allows all 2-byte within A1-EF, but this coarse-grained approac= h is flawed.

On Fri, May 1, 2026 at 11:07=E2=80= =AFPM Junwang Zhao <zhjwpku@gmail.c= om> wrote:
chenloveit@gmail.com> wrote= :
>
> ## Description
>
> The legacy encodings allow some invalid bytes, which will cause errors= during SELECT operations.
>
> ## How to reproduce
>
> ```shell
> createdb -E EUC_CN -T template0 --locale=3DC demo_euc_cn_db
> ```
>
> ```sql
> demo_euc_cn_db=3D# CREATE TABLE t(id int, s varchar(10));
>
> demo_euc_cn_db=3D# INSERT INTO t VALUES(1, E'\xA2\xA3');
> INSERT 0 1
> demo_euc_cn_db=3D# SELECT * FROM t WHERE id =3D 1;
> ERROR:=C2=A0 character with byte sequence 0xa2 0xa3 in encoding "= EUC_CN" has no equivalent in encoding "UTF8"

Can you try the following statement before select?
SET client_encoding TO 'EUC_CN';

> ```
>
> --
> Zhongpu Chen



--
Regards
Junwang Zhao


--
Zhongpu Chen
--0000000000005f574f0650c3ce03--