Il 16/07/2021 11:51, Andreas Neumann ha scritto:
Hi all and thanks for the discussion,
Even and I discovered that the .xls files are loading with correct
encoding in Linux but not on Windows which leads to the assumption that
freexl on Windows might not have been correctly compiled/linked against
iconv.
Hi Andreas,
usually on GNU/Linux distributions the "system" encoding is UTF-8, while
on Windows is the "ANSI" encoding (e.g. Windows-1252 for Western Europe
locales).
So I think that since XLS layers are imported in QGIS using the "system"
encoding, and since FreeXL translates the strings values to UTF-8 and
GDAL/OGR exposes such strings values as they are passed by FreeXL, then
XLS tables are correctly displayed in QGIS on GNU/Linux systems, while
are incorrectly displayed in QGIS on Windows systems.
You can test your xls files on Windows using ogrinfo in the OSGeo4W Shell:
ogrinfo path\to\file.xls sheet_name > path\to\file.txt
then you can check if file.txt will contain the string cell values UTF-8
encoded.
Or you can use the ogr module from osgeo in the QGIS Python Console on
Windows to open the XLS datasource and output the features fields
(cells) values as strings: the cells values are correctly read by ogr
(via FreeXL) from the XLS file and correctly displayed as UTF-8 strings.
AFAIK FreeXL depends by iconv libary and cannot be compiled and cannot
work at all without it.
In fact, in my QGIS installations via OSGeo4W (old and new repository)
both the FreeXL and iconv DLLs (FreeXL 1.0.2 / iconv 1.14 - FreeXL 1.0.6
/ iconv 1.16) are present, with the former linked to the latter as
dependency.
Regards.
Andrea
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
