Gdal/OGR 1.9.0 solve the problem of getting the Chinese field value and attribute value garbled file in the SHP File

Gdal/OGR 1.9.0 was released in another new version, but a problem with Chinese support was discovered. in earlier versions of 1.8.1, gdal began to support wide bytes, or the support for various encodings, gdal in the default processing, all the path strings as UTF-8 encoding for processing, that is why the beginning of version 1.8.0, if the default compiled path does not support the Chinese path. For more information, see http://blog.csdn.net/liminlu0314/article/details/6610069. There is also a problem in opening the Chinese path using version 1.9.1. The specific solution is the same as above.

Today, another new problem is found. The SHP format of the Chinese path can be opened and the obtained geometry information is correct. However, if the attribute field or attribute value contains Chinese characters, it is a tragedy, the whole process was garbled. I thought I was still using cplsetconfigoption. I found that the setting was not complete yet:

Cplsetconfigoption ("gdal_filename_is_utf8", "no ");

However, after debugging to the gdal source code, the ogrshapelayer class constructor in ogrshapelayer. cpp has an encoding option. The constructor is as follows:

OGRShapeLayer::OGRShapeLayer( OGRShapeDataSource* poDSIn,                              const char * pszName,                              SHPHandle hSHPIn, DBFHandle hDBFIn,                               OGRSpatialReference *poSRSIn, int bSRSSetIn,                              int bUpdate,                              OGRwkbGeometryType eReqType ){    poDS = poDSIn;    poSRS = poSRSIn;    bSRSSet = bSRSSetIn;    pszFullName = CPLStrdup(pszName);        hSHP = hSHPIn;    hDBF = hDBFIn;    bUpdateAccess = bUpdate;    iNextShapeId = 0;    panMatchingFIDs = NULL;    bCheckedForQIX = FALSE;    hQIX = NULL;    bSbnSbxDeleted = FALSE;    bHeaderDirty = FALSE;    if( hSHP != NULL )    {        nTotalShapeCount = hSHP->nRecords;        if( hDBF != NULL && hDBF->nRecords != nTotalShapeCount )        {            CPLDebug("Shape", "Inconsistant record number in .shp (%d) and in .dbf (%d)",                     hSHP->nRecords, hDBF->nRecords);        }    }    else         nTotalShapeCount = hDBF->nRecords;        eRequestedGeomType = eReqType;    bTruncationWarningEmitted = FALSE;        if( hDBF != NULL && hDBF->pszCodePage != NULL )    {        CPLDebug( "Shape", "DBF Codepage = %s for %s",                   hDBF->pszCodePage, pszName );        // Not too sure about this, but it seems like better than nothing.        osEncoding = ConvertCodePage( hDBF->pszCodePage );    }        if( CPLGetConfigOption( "SHAPE_ENCODING", NULL ) != NULL )        osEncoding = CPLGetConfigOption( "SHAPE_ENCODING", "" );    if( osEncoding != "" )        CPLDebug( "Shape", "Treating as encoding '%s'.", osEncoding.c_str() );    poFeatureDefn = SHPReadOGRFeatureDefn( CPLGetBasename(pszName),                                           hSHP, hDBF, osEncoding );    /* Init info for the LRU layer mechanism */    poPrevLayer = NULL;    poNextLayer = NULL;    bHSHPWasNonNULL = hSHPIn != NULL;    bHDBFWasNonNULL = hDBFIn != NULL;    eFileDescriptorsState = FD_OPENED;    TouchLayer();}

In the above constructor, there are the following two sentences, debugging here,
If (cplgetconfigoption ("shape_encoding", null )! = NULL
)
Osencoding = cplgetconfigoption ("shape_encoding ","");

We found that osencoding = cplgetconfigoption ("shape_encoding", ""); the returned result is a code named cp936. So what is cp936, cp936 refers to the code format 936th (codepage936) in the system, that is, gb2312. This option has not been set before. It is preliminarily inferred that the value may be determined based on the user's operating system, and it is difficult to test because there is no English operating system.

That is to say, when constructing the layer, read the encoding in the DBF file and convert the DBF encoding. Note that the preceding sentence is: "// not too sure about this, but it seems like better than nothing. ", it probably means not to care too much about this thing. It seems to be better than nothing. Here, it turns Chinese into garbled characters. Why. After finding the cause, it is easier to modify it. Just as before, set the value of shape_encoding to null before opening SHP, as shown below:

Cplsetconfigoption ("shape_encoding ","");

This is fine. I don't know if setting it to this will affect other languages, but it is no problem for Chinese.