No subject
Thu Jun 7 16:37:16 CEST 2018
2007-04-11 Bram de Greve <bram.degreve at intec.ugent.be>
* dbflibmodule.c, pyshapelib_common.h, setup.py: attempt to add support for
Unicode and Language Driver ID (LDID) support in dbflib. Before the strings
are send to the underlying shapelib, they are encoded using the code page
specified by the database's LDID if present. To know this LDID requires
some unofficial modifications to maptools' shapelib. Backwards
compatibility is ensured by detecting if this field is present and setting
HAVE_LANGUAGE_DRIVER accordingly in setup.py. In absence of the LDID,
dbflib assumes a Windows ANSI codepage (cp1252).
New or modified functions/attributes of the DBFFile class:
- read_record(...), DBFFile.read_attribute(...): modified, now return
Unicode strings.
- write_record(...) and write_field(...): modified, now accept both regular
and Unicode strings but both are encoded.
- language_driver (read-only): new, the numerical value of the LDID (exists
only if HAVE_LANGUAGE_DRIVER == 1)
New or modified functions/constants of the dbflib module:
- language_driver_codec(...): added, translates a numerical LDID into the
string name of the Python codec used to encode/decode the strings. (exists
only if HAVE_LANGUAGE_DRIVER == 1)
- language_driver_name(...): added, translates a numerical LDID into a
string representing the corresponding constant. (exists only if
HAVE_LANGUAGE_DRIVER == 1)
- LDID_NOT_SET, LDID_DOS_USA, ...: constants representing language drivers.
(existsonly if HAVE_LANGUAGE_DRIVER == 1)
--
hi, i'm a signature viruz, plz set me as your signature and help me spread
:)
------=_Part_36388_6302209.1176249117444
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I've made an attempt to add (partial) Unicode support to dbflib. Partial, because strings still need to be encoded to a subset. But this is of course how the DBF databases are designed. The language driver ID (LDID) in the DBF header is used to specify this encoding. Unfortunately there's not UTF-8 LDID ...
<br><br>From the Changelog:<br><br>2007-04-11 Bram de Greve <<a href="mailto:bram.degreve at intec.ugent.be">bram.degreve at intec.ugent.be</a>><br><br>* dbflibmodule.c, pyshapelib_common.h, setup.py: attempt to add support for Unicode and Language Driver ID (LDID) support in dbflib. Before the strings are send to the underlying shapelib, they are encoded using the code page specified by the database's LDID if present. To know this LDID requires some unofficial modifications to maptools' shapelib. Backwards compatibility is ensured by detecting if this field is present and setting HAVE_LANGUAGE_DRIVER accordingly in
setup.py. In absence of the LDID, dbflib assumes a Windows ANSI codepage (cp1252). <br><br>New or modified functions/attributes of the DBFFile class:<br>- read_record(...), DBFFile.read_attribute(...): modified, now return Unicode strings.
<br>- write_record(...) and write_field(...): modified, now accept both regular and Unicode strings but both are encoded.<br>- language_driver (read-only): new, the numerical value of the LDID (exists only if HAVE_LANGUAGE_DRIVER == 1)
<br><br>New or modified functions/constants of the dbflib module:<br>- language_driver_codec(...): added, translates a numerical LDID into the string name of the Python codec used to encode/decode the strings. (exists only if HAVE_LANGUAGE_DRIVER == 1)
<br>- language_driver_name(...): added, translates a numerical LDID into a string representing the corresponding constant. (exists only if HAVE_LANGUAGE_DRIVER == 1)<br>- LDID_NOT_SET, LDID_DOS_USA, ...: constants representing language drivers. (existsonly if HAVE_LANGUAGE_DRIVER == 1)
<br><br><br>-- <br>hi, i'm a signature viruz, plz set me as your signature and help me spread :)
------=_Part_36388_6302209.1176249117444--
More information about the Thuban-devel
mailing list
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)