Skip to Content.
Sympa Menu

freetds - RE: [freetds] RE: Charset conversion with Sybase ASE 12.0

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] RE: Charset conversion with Sybase ASE 12.0
  • Date: Tue, 26 Nov 2002 17:20:15 -0500

> From: Maxim V Rayevskiy [mailto:ra-max AT yandex.ru]
> Sent: November 25, 2002 12:09 PM
>
> I have set the locale for my login according to
> the FreeBSD
> handbook as you suggested. So, the environment variables are now as
> follows:
>
> LANG=ru_RU.KOI8-R
> MM_CHARSET=KOI8-R
>
> I tried setting the codepage in both locales.conf and freetds.conf to
> either KOI8-R (which is the UNIX codepage for cyrillic) or cp1251
> (windows cyrillic). In either case the freetds requests iso_1 from the
> server as you can see from the log.
>
> I have built FreeTDS from the FreeBSD port. Therefore, I
> believe I have
> 0.60 release. I am not using unixODBC yet and I am not quite sure what
> you mean by asking whether I use ctlib or dblib. I am trying
> to connect
> with tsql on the client side: tsql -S main -U ramax -P *******

Maxim,

I see in the source that tsql hard-codes the client charset to "iso_1". I
don't know how to fetch the client charset (apart from parsing the
environment strings, which can't be right). I'll look into it.

--jkl

> > From: Maxim V Rayevskiy [mailto:ra-max AT yandex.ru]
> > Sent: November 14, 2002 2:53 AM
> >
> > I have set up freetds 0.60 on my FreeBSD system to connect
> to Sybase
> > ASE 12.0 running on a Windows server. The character set on Sybase
> > is set to be
> > cp 1251 (Windows cyrillic). I have edited the locales.conf to
> > include char
> > set = cp1251. Yet, when I connect to the server I get
> >
> > Character set conversion is not available between client
> character set
> > 'iso_1' and server character set 'cp1251'.
>
> Maxim,
>
> Thank you for your message. It's clear to me that the documentation,
> and maybe the code, needs some revision on this score.
>
> Short answer: Use the "client charset" option in freetds.conf, not in
> locales.conf, if you want to use a nonstandard server
> encoding for your
> locale.
>
> Medium answer: Set your LOCALE properly and add an entry to
> locales.conf:
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/usin
> g-localiza
> tion
> .html
> [ru_RU]
> date format = %b %d %Y %I:%M%p # may want to
> change this
> language = us_english # may want "russian"?
> char set = cp1251 # I think
>
> and of course "export LANG=ru_RU".
>
> If that doesn't work, please provide:
>
> * 0.60 release, or date of snapshot?
> * Are you using db-lib, ct-lib, or ODBC?
> * TDSDUMPCONFIG log
> * TDSDUMP log
>
> Although you should remove the password from your log, please don't
> munge the log too much, because the login packet is what we're looking
> for.
>
> Long answer follows.
>
> locales.conf maps locale information found in the environment to
> FreeTDS's settings. That is, if your LANG environment variable is set
> to "en_US", FreeTDS will know to tell the server that you
> want an ISO-1
> character set, US English messages, and a US date format.
> It's meant to
> be static, not site-specific. The notion is to take cues from the
> client's LOCALE settings to make not-stupid assumptions about the
> default settings. Each language-country combination will get
> appropriate date, language, and character set defaults.
>
> I realize Russian is represented by more than one character
> set; I don't
> know how the LOCALE system deals with that. If you would send a
> four-line patch for locales.conf suitable to your LOCALE
> settings, I'll
> include it in our distributed file from now on.
>
> freetds.conf overrides the character set inferred from locales.conf.
> (It should be possible, on reflection, to override the date format and
> language, too, but that'll have to wait.) That's why I think
> the Short
> Answer will solve your immediate problem.
>
> I don't think the documentation is terribly clear on this
> point, and may
> even be misleading. And I'm not positive the code is right, but it
> looks it, at least in cvs.
>
> Background to the long answer follows.
>
> When a connection to the server is established, the TDSLOGIN record
> includes a "char_set" field.
>
> Sybase servers (TDS 5.0) transmit in 8-bit format, normally ASCII but
> also other charsets including CP1251 and UTF-8. Any
> conversion from the
> server's charset to the client's is done by the server, in accordance
> with what was requested at login time.
>
> Microsoft servers (TDS 7.0) have a charset too, but they send
> their data
> in Unicode (UCS-2 ). Because most applications using FreeTDS aren't
> prepared to deal with 16-bit characters, FreeTDS employs libiconv to
> convert from UCS-2 to the client's character set. To the best of my
> knowledge, the conversion of server_charset<->USC-2 is
> performed by the
> server, and any conversion of USC-2<->client_charset is
> performed by the
> client libary (that's us). The server ignores the TDSLOGIN "char_set"
> field (unless it's a TDS 4.2) login.
>
> The cascading effects of locales.conf and freetds.conf to set the
> charset are not well-tested. It may be that the system does
> not work as
> described, because most of the developers don't depend on it.
> However,
> it's important to us that it does work, and I at least would
> be glad to
> correct anything we can isolate.


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.






Archive powered by MHonArc 2.6.24.

Top of Page