Character set conversion (through ssh)

Hi all,

I have a server with Mandriva 2007, which is set up to use utf-8 as a
default charset, that means the shell uses utf-8 and text files are created
as utf-8 by default.

My home computer is a little bit older and uses iso-8859-15. When I connect
with ssh to the server, I get non-ASCII characters in the terminal all
messed up, and it's even worse if I want to edit a text file, because I
don't even know what I'm writing.

I once had the reverse problem: a server with iso-8859-15 and a client with
utf-8, and I could solve it by using "luit ssh server.address". However,
luit does not seem to do the inverse conversion.

Does anyone have any idea for solving this? I'm sure many others have
already suffered this same problem (but I couldn't find a solution in
google). I tried with something like this in my ~/.bashrc file (in the
server):

if [ -n "SSH_CLIENT" ]; then
export LANG=es_ES.ISO-8859-15
export LC_ALL=es_ES.ISO-8859-15
fi

and this does solve the problem with the terminal messages (or so it seems),
but the text files are still mangled with vi, for instance.

I've seen that, if I don't include the above code, I can get the right
behaviour with vi by setting "termencoding=iso-8859-15". With the code
in .bashrc I have to set "encoding=utf-8" as well. This would be OK if I
could set this in a configuration file, but I dont want it to be permanent,
since I will be using the server itself too (no remote connection) and I
could also use other clients with utf-8 configuration.

So, this is all a mess, I guess it could be solved if there was some kind of
"charset" option in .ssh/config, but there isn't. Or if there was something
like an inverse luit, but I didn't find it. Do you have any other
suggestion?

Thanks in advance.

--
Ignacio __ Fernández Galván
/ /\
Linux user / / \ PGP Pub Key
#289967 / / /\ \ 0x01A95F99
/ / /\ \ \
http://djelibeibi.unex.es
/________\ \ \
jellby \___________\/ yahoo.com
.

Relevant Pages

  • Re: Understanding simplest HTML page
    ... though I believed that particular charset was considered a default value ... UTF-8 seems the default and it does handle foreign characters. ... Rather set the HTTP ... I had read Alan's page about setting that in the server options, ...
    (comp.infosystems.www.authoring.html)
  • Re: Prototype, Safari and Japanese problems?
    ... >> The charset for the entire page itself is correct already. ... > page served in UTF-8 including any further server interchange? ... But with Safari the Japanese seems to get corrupted. ...
    (comp.lang.javascript)
  • Re: mime charset problem
    ... This simply instructs the server to announce the ISO-8859-1 encoding for any page in a file with a name ending with ".htm". ... Try finding an authoring tool that can save data in UTF-8 encoding. ... In UTF-8, you can enter _any_ character as such, provided of course that your authoring tool offers some way of typing it. ... By the specs, and by actual practice, browsers will ignore the Ersatz when they get a real HTTP header from a server, with conflicting content. ...
    (alt.html)
  • Re: UTF8 beim FTP-Protokoll
    ... solchen Client gleich in UTF8 antwortet, dann liegt in meinen Augen undefiniertes Verhalten vor. ... IRL passiert aber genau das bei der Mehrheit der Server, ... Der von Dir gelinkte Draft vom RFC ist doch ganz eindeutig ... oder wahlweise auch "OPTS UTF-8 NLST". ...
    (de.comp.lang.c)
  • Re: mime charset problem
    ... now we can check that the _server_ announces the page as UTF-8 ... actual encoding, so that they match. ... This will be trumped by HTTP headers, ...
    (alt.html)