[gdal-dev] unicode support in GDAL

[Jan Heckman]

Does the shapefile have a .cpg with UTF8 as spec?
Did you open the shape (or, in fact, the .dbf) in e.g.  Qgis?
You might try open it (the .dbf) in Libre office calc and specify the
encoding as UTF8.
If there's still ? or non-Russian where it should be, you are sure that the
shapefile (dbf) is not correct.
It may be quite ok and all you need is to supply the .cpg file.


On Thu, Aug 12, 2021 at 5:54 PM Claudiu Cochior via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> Hello everybody,
>
>
>
> I have a question related to Unicode strings in GDAL
>
>
>
> We are using GDAL 3.0.4 and at some point we would like to write to
> shapefile a string that contains Russian characters. To give you some
> context, we are in C++, we created a OGRFeature and we want to set a field
> to the string that contains the Russian characters. My machine is in
> English and the language for non-unicode programs is set to English. I
> didn’t find in the GDAL doc a definitive answer if GDAL support Unicode
> strings for filed values. As a test I converted the System::String to UTF-8
> but the shape file displays only ? for the characters. If I change the
> language for non-unicode programs to Russian then I can safely extract the
> ANSI string and give it to the SetField method and the result is OK.
>
>
>
> So, does GDAL supports unicede field string values somehow?
>
>
>
> Thanks,
>
>
>
>
>
> Claudiu
>
> ------------------------------
>
>
> This email, including any attachments, may contain confidential and/or
> proprietary information intended only for the use of the recipient. If you
> are not the intended recipient, any distribution, copying, or use of this
> email or its attachments is prohibited. If you received this email in
> error, please reply to the sender immediately and delete this message and
> any copies.
>
> *Bentley Systems has taken all reasonable steps to ensure that this
> communication is free from viruses, data corruption, and unauthorized
> alteration. Bentley Systems does not accept liability for any damages that
> may be incurred as a result of this or any communication by email*
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210812/2f5849e4/attachment.html>