UTF8 support in SecureCRT

[shell_dweller]

It seems that UTF8 support is not working properly in SecureCRT and I am surprized it wasn't fixed in v 5.

Here's my problem: the locale on my remote Linux server is set to UTF8. The UTF8 option is checked in SecureCRT for this session. When I try to display a Unicode file written in Cyrillic script I get only question marks ("?????"). When I try to input Cyrillic characters SecureCRT displays characters from Latin 1 instead, e.g., "ïðî".

The free shell client putty provides much better support for Cyrillic script encoded with UTF8, not to mention support for many single byte encodings such as Win1251, KOI8-R or KOI8-U!

[jcj]

Hi shell_dweller -

Is the input language for your system set to input in a language that uses a Cyrillic script, like "Russian" ?
(Control Panel, Regional and Language Options, Languages, Details)

Also, in SecureCRT, under Session Options, Appearance, what font is set, and which "script" is selected in the font selection dialog ?

Typically, you'd want to be using a font like "Courier New" or "Lucida Console" with the script set to "Cyrillic" .

Please let us know if this helps.

Thanks~

~JcJ

[shell_dweller]

My local machine is Win 2000 (but I had the same problem on XP). Its default locale is set to English US but the system is configured to display a number of language groups (Central/Western Europe, Cyrillic, Chinise and Korean). And I have 2 Cyrillic input locales inslatted (Russian & Ukrainian). When I try to input Cyrillic characters I obviously switch to one of those.

The SecureCRT session properties are: Under Terminal -> Appearance: Font: Courier New 10pt; Character Encoding: UTF-8.

I think the problem with inputting is that SecureCTR reads my input in Win 1251 (Cyrillic) but thinks Win 1252 (Western). E.g., when I attempt to input Cyrillic letter "a" (0xE0 in Win 1251; 0x0430 in Unicode) it outputs "à" ("a" with grave accent) whose code is also 0xE0 in Win 1252.

[shell_dweller]

It's very easy to replicate the problem:

1. Add a Cyrillic keyboad layout to your input locales (on local machine)
2. Set your locale to UTF-8 on remote machine (many if not all recent Linux distributions have UTF-8 set as default locale)
3. Change you SecureCRT session encoding to UTF-8
4. Connect to remote host
5. Shitch your local input locale to a Cyrillic one (e.g., "Russian")
6. Type something. You should see Latin accented characters

PS: I've seen this problem in other software products for Windows with broken localization when they mistakingly interpret 1251 as 1252.

[jcj]

Thanks for your feedback.

In Session Options / Appearance, if you click on "Font..." and then check the "Script" dropdown list, you should be able to select "Cyrillic" there, and I suspect you'll see the correct characters on input.

Please let us know if this helps.

Thanks~

~JcJ

[shell_dweller]

Yes, this did work. Why does it need to be so tricky? Shouldn't selecting UFT-8 be sufficient for covering all scripts?

It looks like SecureCRT converts UTF-8 characters to single byte characters according the script settings specified in session properties. This makes viewing multilingual documents during the same session quite an uneasy task.

[sinpi]

As far as I understand, this being an ancient issue, it goes like this:

- the UTF-8 support tells SecureCRT: "if specific high-ASCII characters arrive, treat them like a multibyte-encoded Unicode character".
- so the characters arrive, SecureCRT properly interprets them as a single Unicode character
- and now something insane happens: SecureCRT starts wondering in what encoding it should display the character - and here it relies on user's font settings!

Let me repeat it: SecureCRT has an Unicode character... and it now tries to squeeze it back into 8 bits, usind a pre-2000 "region encoding" concept? No wonder it proves impossible to have cyryllic, japanese and arabic scripts used simultaneously.

The answer to the third point should, obviously, be: "are you mad, SecureCRT?? DON'T use any encoding! Display the character as Unicode, the operating system has been supporting it for ages!"

Why, then, is it misconceived the way it is? (Unless something's changed since 5.0 in this matter...)

[Maureen]

SecureCRT 6.0, which is in pre-beta testing, is a Unicode build and may fix the problem you are seeing. If you'd like to try it, please send an e-mail to me at Maureen.Jett@vandyke.com.

Maureen