# export
LANG=ko
If the user have an environment variable of LANG=ko, then Korean characters are displayed incorrectly.
From Andy:
Emilian seems to force utf-8 encoding in the SshTerminalWrapper. One solution is to add an option, or ask the user to configure his setup to use utf-8.
"SshTerminalWrapper : Line 38"
There are three parts that compose the LANG env variable's value: language (java system property user.language), country (java system propertyuser.country) and encoding. (e.g. en_US.UTF-8 ).
SSH Terminal can propagate the language and encoding settings from the guest machine (where ADS is running) to the remote ssh session. This is done insideSshTerminalWrapper.setupEnvVariables() by setting the LANG and LC_ALL env variables on the remote ssh session. This operation might not be allowed by the remote host as it exposes a security risk (see the PermitUserEnvironment directive from sshd_config file ). If the remote host rejects this operation, the JSch library throws an exception and the ssh session is dropped.
In order to provide compatibility with such hosts (i.e. to be able to establish ssh sessions to them), the SshTerminalWrapper.setupEnvVariables() method is currently disabled (see the SshTerminalWrapper.setEnvVarsOnStartup flag). There is one inconvenience that results from this: the SSH Terminal I/O streams' encoding are no more kept in sync with the remote host setting. The SSH Terminal assumes that the remote host "speaks" the UTF-8 character encoding and this is correct in most cases.
Terminal.app has two additional features: the "Character encoding" drop-down list (so that the user can choose the encoding) and the "Set locale environment variable on startup" checkbox (so that the user can still establish ssh sessions to restrictive servers that disallow user env variables). The SSH Terminal can provide this flexibility by adding a combobox (binded to SshTerminalWrapper.ENCODING ) and a checkbox (binded to SshTerminalWrapper.setEnvVarsOnStartup ) to the GUI and let the user choose his preference.
There are three parts that compose the LANG env variable's value: language (java system property user.language), country (java system propertyuser.country) and encoding. (e.g. en_US.UTF-8 ).
SSH Terminal can propagate the language and encoding settings from the guest machine (where ADS is running) to the remote ssh session. This is done insideSshTerminalWrapper.setupEnvVariables() by setting the LANG and LC_ALL env variables on the remote ssh session. This operation might not be allowed by the remote host as it exposes a security risk (see the PermitUserEnvironment directive from sshd_config file ). If the remote host rejects this operation, the JSch library throws an exception and the ssh session is dropped.
In order to provide compatibility with such hosts (i.e. to be able to establish ssh sessions to them), the SshTerminalWrapper.setupEnvVariables() method is currently disabled (see the SshTerminalWrapper.setEnvVarsOnStartup flag). There is one inconvenience that results from this: the SSH Terminal I/O streams' encoding are no more kept in sync with the remote host setting. The SSH Terminal assumes that the remote host "speaks" the UTF-8 character encoding and this is correct in most cases.
Terminal.app has two additional features: the "Character encoding" drop-down list (so that the user can choose the encoding) and the "Set locale environment variable on startup" checkbox (so that the user can still establish ssh sessions to restrictive servers that disallow user env variables). The SSH Terminal can provide this flexibility by adding a combobox (binded to SshTerminalWrapper.ENCODING ) and a checkbox (binded to SshTerminalWrapper.setEnvVarsOnStartup ) to the GUI and let the user choose his preference.
added Character Encoding option to the SSH terminal config dialog.
added Character Encoding option to the SSH terminal config dialog.
I don't see any Korean encoding. Where are you getting the list?
http://en.wikipedia.org/wiki/Character_encoding
Korean
KS X 1001 is a Korean double-byte character encoding standard
EUC-KR
ISO-2022-KR
I don't see any Korean encoding. Where are you getting the list?
http://en.wikipedia.org/wiki/Character_encoding
Korean
KS X 1001 is a Korean double-byte character encoding standard
EUC-KR
ISO-2022-KR
EUC_KR is in the list.
I have no information about what charsets are supported on the remote terminals. They may or may not coincide with encodings supported by java.
There is a long list in http://www.iana.org/assignments/character-sets
Since this option is more about an (unknown) remote system rather than something well defined, perhaps the charset option should allow the user to enter custom encoding and given that, offer a shorter list.
EUC_KR is in the list.
I have no information about what charsets are supported on the remote terminals. They may or may not coincide with encodings supported by java.
There is a long list in http://www.iana.org/assignments/character-sets
Since this option is more about an (unknown) remote system rather than something well defined, perhaps the charset option should allow the user to enter custom encoding and given that, offer a shorter list.
Issue #6046 |
Closed |
Fixed |
Resolved |
Completion |
No due date |
No fixed build |
No time estimate |
From Andy:
Emilian seems to force utf-8 encoding in the SshTerminalWrapper. One solution is to add an option, or ask the user to configure his setup to use utf-8.
"SshTerminalWrapper : Line 38"