Changes between Version 6 and Version 13 of Ticket #882


Ignore:
Timestamp:
Apr 17, 2011, 8:28:26 AM (13 years ago)
Author:
bishop
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #882

    • Property Status assignedclosed
    • Property Cc alexbruy gislab Jeff McKenna added
    • Property Resolutionfixed
    • Property Summary Unicode support in OGRUnicode support in OGR Shape/DBF
    • Property Milestone1.9.0
    • Property Keywords Shape added
  • Ticket #882 – Description

    v6 v13  
    1 A function to return/set the encoding in a shapefiles .dbf is wanted. See URL for an ESRI view of how it can be done. Alternatively/Also, the functions should be able to support Unicode in all places where char * are used.
    2 
    3 Background:
    4 I'm working on qgis, and it uses Qt with QStrings. They are unicode, and when using a non-unicode library one can chose between mystring.latin1(), mystring.ascii(), mystring.utf8() msytring.unicode() and mystring.local8Bit() for converting from unicode. So far, filenames use .local8Bit(), but attributes
    5 use .ascii().
    6 
    7 I'm thinking I might change it to .local(Bit() too.
    8 The ideal(?) soultion would be if we could set the encoding to utf-8 for instance, and also note that in the .dbf header somewhere. Reverse on reading.
    9 
    10 References:
    11 http://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT
    12 Discussion on irc #gdal 2005-07-06
    13 Search "gdal org unicode" on google reveals discussion in gdal-dev on "Shapelib and unicode".
     1The CPG file is a last chance for user to set needed encoding. Because if the producer set encoding to default (LDID/87), but data is in other encoding (some local data), it's much easier to create simple CPG file, than encode whole dbf. So the CPG file should be preferable encoding on others (internal ones).