[Bug]: CAD DXF/DWG TEXT and Layer attributes are mojibake for ANSI_936 / GBK drawings

[mfkj8866]

Before you start

• I searched the existing issues and did not find a duplicate.
• This is a bug report, not a usage question (questions belong in Discussions).

What happened?

Loading a local CAD drawing through Add data → CAD Layer imports geometry, but Chinese TEXT / MTEXT and layer names in the attribute table are mojibake.

The drawing is a DXF with $DWGCODEPAGE = ANSI_936 (GBK). Desktop GDAL (ogrinfo / ogr2ogr) decodes the same file correctly. In GeoLibre the attribute table shows GBK bytes interpreted as Latin-1 / Windows-1252, for example:

Field	Actual (mojibake)	Expected
Layer	¼¯µçÏß·	集电线路
Text	μ Àý	图例
Text	·ûºÅ	符号
Text	ÄÚÈÝ	内容
Text	ÊýÁ¿	数量
Text	·çµç³¡	风电场
Text	ZC-YJLV22-26/35kV-3¡Á95mm2	ZC-YJLV22-26/35kV-3×95mm2

SubClasses is AcDbEntity:AcDbMText / AcDbEntity:AcDbText:AcDbAttribute, so these rows are CAD text entities, not a separate encoding in GeoJSON.

Likely cause: CAD files are opened with DuckDB-WASM ST_Read (bundled GDAL). That build has no iconv, so it copies each file byte as a Latin-1 character instead of honouring $DWGCODEPAGE. × (GBK A1 C1) becoming ¡Á is the same pattern.

This is distinct from labels being off by default (labels.enabled is false). Even with labels enabled, the Text field is already garbled, so the map cannot show the original Chinese.

Steps to reproduce

1. Run the web app from source (npm run dev) on current main.
2. Open Add data → CAD Layer and choose a DXF whose header has $DWGCODEPAGE = ANSI_936 and whose TEXT/MTEXT is Chinese (a 192-byte sample is linked below).
3. Add the entities layer.
4. Open the attribute table and look at the Layer and Text columns.

Expected behavior

Text and Layer should be Unicode Chinese, matching desktop GDAL on the same file (工程名称, 集电线路, ×, …). Mojibake such as ¼¯µçÏß· and ¡Á should not appear.

How are you running GeoLibre?

Web build from source (npm run dev), main @ 5b89c26, v2.6.0

Operating system and browser

Ubuntu 24.04 + Chrome

Sample data

Any AutoCAD DXF with $DWGCODEPAGE = ANSI_936 and Chinese TEXT reproduces this. A minimal sample (one TEXT entity 集电线路) is here:

https://github.com/mfkj8866/GeoLibre/blob/fix/cad-text-encoding/issue/ansi936-text.dxf

The original drawing is DXF AC1018, $DWGCODEPAGE = ANSI_936, with TEXT/MTEXT such as 工程名称, 集电线路, 兴业大平山风电项目, and ZC-YJLV22-26/35kV-3×95mm2. It is larger than GitHub's issue-attachment limit, so it is not uploaded here.

Screenshots or logs

Attribute table after loading the CAD layer. Red arrows mark garbled Layer and Text values (¼¯µçÏß·, μ Àý, ¡Á, …):

[mfkj8866]

Suggested fix

Transcoding the DXF/DWG file to UTF-8 before ST_Read does not help. DuckDB-WASM’s bundled GDAL still copies each file byte as a Latin-1 / Windows-1252 character, so a UTF-8 file just becomes a different kind of mojibake (e.g. × → × instead of ¡Á).

A post-ST_Read repair at the GeoJSON boundary works for both DXF and DWG on one path:

1. Read the drawing codepage before registering the file buffer (the buffer is transferred/detached into DuckDB):
   • DXF: $DWGCODEPAGE (e.g. ANSI_936 → gb18030)
   • DWG: R2007+ (AC1021 and later) → UTF-8; older drawings via an ANSI_* token when present
2. After ST_Read, for each string property (and CAD layer names from the layer listing):
   • reverse each JS character to the original file byte (including a Windows-1252 reverse map for 0x80–0x9F)
   • decode those bytes with the drawing codepage via TextDecoder
3. Leave geometry and numeric fields alone; skip when the codepage is already UTF-8 / Latin-1 or when the header cannot be read (binary DXF, missing header).

I have a leaf module for this (kept free of the DuckDB-WASM import so node --test can cover it without pulling the engine into the coverage denominator), wired into the CAD load path in duckdb-vector-loader.ts, with unit tests for ANSI_936 TEXT / Layer recovery and the × → ¡Á case.

If this approach looks reasonable, I would be happy to open a PR.

[giswqs]

Thank you for reporting. Please feel free to submit a PR. Thanks.

[giswqs]

Fixed in #1979