FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Fri, 13 Jul 2001, James K. Lowden wrote:

> For those whose eyes didn't glaze over when last we talked about Greek
> characters and UTF-8 and Unicode and etc., I'm forwarding a message from
> my friend Michael, who was born in Greece and is much too smart for his
> own good.

> I don't remember how our discussion was resolved, or even if indeed it
> had a useful conclusion, but I found Michael's explication helpful.  I
> hope you do, too.

FWIW, I don't expect it to be necessary to directly support many of the
encodings mentioned below.  On Linux, the only two encodings you can expect
client apps to use for Greek are ISO-8859-7 and UTF-8.  It's very much not our
problem what encodings other client apps use when talking to the server -- our
only concern is being able to provide our calling app with data in one of
these two character sets, either by requesting this encoding from the server
or by using iconv to convert the data on the client side.

The problem, incidentally, applies to other *Latin*-based character sets as
well; only latin1 (Western Europe) is safe, having the privilege of being
codepoint-compatible with Unicode.

Steve Langasek
postmodern programmer

>  Unicode, UTF-8, different chinese encodings - we will soon long for the
> days when all we had to worry about was ASCII to EBCDIC.

>  Most greek applications, win9x, NT, mac, unix etc, do not use unicode;
> rather an 8 bit representation using characters 128-255 to map Greek.
> The
> problem is there are many such representations.

> The most official one is ISO-8859-7 which is also known as ELOT 928 or
> codepage 928. (ELOT is a Greek body similar to ANSI. Unix and Linux
> systems almost always use that (According to the greek linux how-to
> http://home.ichannel.gr/faq/Linux-greek-howto which you may find a bit
> hard to read, but I'll be glad to translate the relevant portions)
>
> M$ had to do things a bit different, ofcourse. Windows uses a set that is
> about 99% identical to 928, but the 1% difference is a frequently used
> character (upper case A, punctuated). Argh. This is code page 1253.

> If he is using NTEXT fields, then there should be an automatic
> 928->Unicode and Unicode->928 conversion, which may not be taking place
> correctly due to a badly configured client (server configuration should
> not be a problem). If he is using TEXT fields, then both client and
> server
> configuration is an issue; if the client is configured for a greek
> codepage and the server defaulted to us-ascii, or v.v., things will
> break,
> since such a conversion would be lossy (characters 128-255 would get
> junked, which appears to be the exact problem here).

> Or, it could simply be a bug in the conversion routines.

> I cannot imagine that this is a greek-only problem, these issues should
> apply to all non-latin alphabet based languages...