Changes between Initial Version and Version 1 of Ticket #4808


Ignore:
Timestamp:
Sep 8, 2012, 1:32:55 AM (12 years ago)
Author:
akaginch
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #4808 – Description

    initial v1  
    1 What does LDID/87 means? The page cited in the source code (ogrshapelayer.cpp) says LDID/87 is "Current ANSI Codepage", but the Shapefile Driver treats it as ISO-8859-1.[[BR]]
     1What does LDID/87 means? The page cited in the source code ([https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/shape/ogrshapelayer.cpp#L184 ogrshapelayer.cpp]) says LDID/87 is "Current ANSI Codepage", but the Shapefile Driver treats it as ISO-8859-1.[[BR]]
    22http://www.autopark.ru/ASBProgrammerGuide/DBFSTRUC.HTM
    33
    … …  
    66Encoding conversion ability of OGR is useful, but a problem arises because many applications using GDAL have not adapted to the imporovement of the ability. So attribute strings output from such applications are garbled.
    77
    8 Now, I would like to propose that Shapefile driver should interpret LDID/87 as no codepage specified. If it does so, without specifying ENCODING option, the driver doesn't covert character encodings. Additionally it makes ability to handle a Shapefile that has "87" in the LDID field and attribute strings in the encoding other than ISO-8859-1, without any problem.
     8Now, I would like to propose that Shapefile driver should interpret LDID/87 as no codepage specified. If it does so, without specifying ENCODING option, the driver doesn't convert character encodings. Additionally it makes ability to handle a Shapefile that has "87" in the LDID field and attribute strings in the encoding other than ISO-8859-1, without any problem.
    99
    1010{{{