Ticket #22 (closed enhancement: fixed)

Opened 10 years ago

Last modified 10 years ago

Charset encoding for the session

Reported by: zxalexis Owned by: alamaison
Priority: critical (affects core workflow) Milestone: 0.4.0 Encodings
Component: i18n Version:
Keywords: charset Cc:

Description (last modified by alamaison) (diff)

Here is the quote from the putty manual

-cs charset
This option specifies the character set in which putty should assume the session is operating. This character set will be used to interpret all the data received from the session, and all input you type or paste into putty will be converted into this character set before being sent to the session.

Any character set name which is valid in a MIME header (and supported by putty) should be valid here (examples are 'ISO-8859-1', 'windows-1252' or 'UTF-8'). Also, any character encoding which is valid in an X logical font description should be valid ('ibm-cp437', for example).

putty's default behaviour is to use the same character encoding as its primary font. If you supply a Unicode (iso10646-1) font, it will default to the UTF-8 character set.

Character set names are case-insensitive.

I think it is done with the iconv lib and is needed to convert remote filenames from the remote charset to local Win charset.

The screenshot shows it more clearly :)


swish_sh.png Download (32.4 KB) - added by zxalexis 10 years ago.
Charset converting
names_good.PNG Download (166.7 KB) - added by zxalexis 10 years ago.
bug 22 resolved)

Change History

Changed 10 years ago by zxalexis

Charset converting

comment:1 Changed 10 years ago by alamaison

  • Owner alamaison deleted
  • Priority changed from major to critical
  • Component changed from frontend to i18n
  • Milestone set to Internationalisation

comment:2 Changed 10 years ago by alamaison

  • Owner set to alamaison
  • Status changed from new to accepted

comment:3 Changed 10 years ago by alamaison

  • Description modified (diff)
  • Milestone changed from Internationalisation to 0.3.4 Encodings

comment:4 Changed 10 years ago by alamaison

Could you test whether filenames display correctly in  build 0.3.5? I don't expect any other functions, such as renaming, to work with non-Latin Unicode yet, but it's a start.

The problem was not that Swish didn't support Unicode but that it failed to interpret the incoming data as UTF-8 when converting it to UTF-16.

Changed 10 years ago by zxalexis

bug 22 resolved)

comment:5 Changed 10 years ago by zxalexis

Tested ok - all filenames seem to be correct now). See attachment above.

comment:6 Changed 10 years ago by alamaison

  • Status changed from accepted to closed
  • Resolution set to fixed

Fixed in  version 0.4.0. All operations should now work with non-Latin characters in file and directory names.

Note: See TracTickets for help on using tickets.