Unicode, UTF-8, and Greek

James K. Lowden jklowden at speakeasy.org
Fri Jul 13 22:57:34 EDT 2001


All, 

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.  

--jkl


Jim,

 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.

Greek DOS applications simply use codepage 437 and depend on the user or
graphics card to have a Greek typeface. This is officially known as 737,
but there is no real support for 737 in any OS.

Macs use a prioprietary standard of their own.

Your Greek correspondent most certainly has a CP 928 or 1532
application.
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...

Cheers,

Michael



More information about the FreeTDS mailing list