[GRASS-dev] Re: [GRASS GIS] #1488: v.in.dxf wrapper not working

[GRASS GIS]

#1488: v.in.dxf wrapper not working
-------------------------+--------------------------------------------------
 Reporter:  cmbarton     |       Owner:  grass-dev@…              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:  v.in.dxf     |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by glynn):

 Replying to [comment:2 cmbarton]:
 {{{
 'utf8' codec can't decode byte 0xc1 in position 77: invalid start byte
 }}}

 0xc1 is in the range used for start bytes. However, a start byte of 0xc1
 implies that the top two bits of the resulting character are "01", which
 would mean that it was in the range 0x40-0x7F (64-127), so it should be
 encoded as a single-byte character. "Strict" UTF-8 decoders disallow the
 use of over-long encodings (i.e. encoding a character using more bytes
 than is strictly necessary), requiring encoded representations to be
 unique (i.e. character 0x40 must be encoded as '\x40', and not as e.g.
 '\xc1\x00').

 However, it's far more likely that command is outputting non-UTF-8 data,
 which the GUI is then attempting to parse as UTF-8. In general, GRASS
 doesn't care about encodings; it just deals with bytes. Unfortunately,
 this isn't something which can readily be fixed. GRASS often has to deal
 with textual data which has no associated encoding, so there's no way it
 can convert it to the locale's encoding (the wx GUI assumes that all text
 is in the locale's encoding).

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1488#comment:5>
GRASS GIS <http://grass.osgeo.org>