<div dir="ltr"><div>Hi,<br>I've stumbled upon an issue related to the encoding of OGR field names.<br>Assuming OGR uses UTF8 encoding internally for not only field values but also for field names, there is a problem with SetAttributeFilter.</div>
<div> </div><div>I haven't found a definitive statement that UTF8 encoding is also used for field names, but in my opinion this would only make sense and it seems to work correctly when assuming UTF8 encoding for field names.</div>
<div> </div><div>But there is an issue with SetAttributeFilter at least with the shapefile driver. </div><div>I have created both an ANSI and an UTF8 encoded shapefile.</div><div> </div><div>The shapefiles have the text fields ‘Name’ and ‘Äüß’ (Note that the byte codes for ‘Äüß’ are different in ANSI and UTF8). In each shapefile I created two features. One has set the text values to ‘vÄüß’ and the other to ‘other’. The field names and field values are correctly returned (both times assuming that OGR returns UTF8 encoded strings for field names and field values). If I would use ANSI encoding for the field names I would not get the correct field names in neither case.<br>
So everything seems fine so far.</div><div> </div><div>So next I tried setting different attribute filters, again assuming that I need to provide the filter UTF8 encoded:</div><div>Name = ‘vÄüß’ -> no error, correctly filtered<br>
Äüß = ‘vÄüß’ -> error (SQL Expression Parsing Error: syntax error)</div><div> </div><div>The error is probably because it seems to think that no field with the name "Äüß" exists.<br>Trying to set the attribute filter ANSI encoded does not work either.</div>
<div> </div><div>I realize that using non-ASCII characters for fieldnames probably isn’t a good idea at all, but still it would be nice if it would work.</div><div><br>While I was doing this test I noticed another problem with the attribute filter. It seems when coincidently filtering by “FieldName1 = ‘FieldName2’” it actually does “FieldName1 = FieldName2” instead. In my opinion this is not correct.</div>
<div> </div><div>Now it gets really weird:<br>Although the filter “Name = Äüß” produces a SQL Expression Parsing Error (which is to be expected because the filter “Äüß = ..” also did), using the filter “Name = ‘Äüß’” will work but it actually does “Name = Äüß”.</div>
<div> </div><div>I have attached the two shapefiles.</div><div> </div><div>Another small issue:<br>I just realized that when REPACKing a shapefile that has a non-default encoding and therefor there is a *.cpg file, a *_repack.cpg file gets created and is not deleted.</div>
<div><br>Although I normally use the C# wrapper I have done these tests using the OGR C API directly, so that I had full control of the used string encodings.</div><div> </div><div>Best regards,<br>Dennis</div></div>