[GRASS-dev] [GRASS GIS] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--------------------------+---------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.2.3
 Component:  Temporal     |    Version:  svn-trunk
Resolution:               |   Keywords:  t.register encoding
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+---------------------------------

Comment (by glynn):

 Replying to [comment:36 mlennert]:

 > One example: I always thought that unicode was an abstract
 representation, but that in practice a unicode string was always encoded
 in some encoding, with Python 3 using UTF-8 by default. Or does Python 3
 really store the actual unicode code points ?

 In Python, a unicode string is an array of wide characters. Typically 16
 bits on Windows, 32 bits on Unix, to match the platform's wchar_t type.
 This allows strings to be passed directly to the platform's APIs without
 conversion.

 > And what would it take for our C code to be converted to unicode ?

 Re-writing almost everything that uses strings. Also, anything arriving as
 a byte string would need an associated encoding or it may as well be
 discarded.

 Internally, strings could be stored either as wchar_t[] or as char[] using
 UTF-8. But whichever representation was used, you would need to perform
 conversions for some platforms: Unix uses char[] and doesn't much care
 about encoding, Windows uses wchar_t[] (char[]-based APIs such as fopen()
 are considered "legacy" and can't be used with e.g. filenames which aren't
 valid in the current codepage).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3392#comment:37>
GRASS GIS <https://grass.osgeo.org>