Skip to Content.
Sympa Menu

freetds - Re: [freetds] Charset option

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Daniel Fazekas <fdsubs AT t-online.hu>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Charset option
  • Date: Wed, 18 May 2011 17:04:17 +0200

On May 18, 2011, at 15:50, Dalibor Kušić wrote:

> Didn't help I'm afraid :( Problem is the same. I've noticed one interesting
> thing in the dump file. A letter U+0106 (UTF8 - C4 85) is displayed in the
> dump file as 06 01. But in the end result the character is U+00C4. It's
> like this character gets converted to UTF8 correctly (C485) and then for
> some reason it is assumed this is latin-1 and latin1 representation of C4
> is the U+00C4 character and latin1 of 85 is a control character. Or
> something like that :)

U+0106 Ć LATIN CAPITAL LETTER C WITH ACUTE would be 0xC4 86 in UTF-8, not
0xC4 85 which is U+0105 ą LATIN SMALL LETTER A WITH OGONEK.

Neither ą nor Ć exists in ISO-8859-1 so it's odd that you got anything at all.

Seeing the letter Ä (U+00C4) should only happen if FreeTDS properly converted
to UTF-8, then instead of handling it as UTF-8, you interpreted it as
ISO-8859-1 (or WINDOWS-1252, or ISO-8859-2, or WINDOWS-1250, etc).
It's as if your terminal environment or programming environment isn't
properly set to use UTF-8.

That is no longer on the FreeTDS side then and your problem is later on in
the process.

> Anyway here is the dump file:
>> 15:27:37.036848 21550 (log.c:190):Starting log file for FreeTDS 0.82
>> on 2011-05-18 15:27:37 with debug flags 0xffff.
>> 15:27:37.036923 21550 (iconv.c:363):iconv to convert client-side data to
>> the "ISO-8859-1" character set
> I'm worried about these lines that mention ISO-8859-1.

If you followed the bad advice from a previous email and nuked the full iconv
support, you are now using the limited built-in iconv replacement which only
supports a few specific character sets. It's possible it drops back to
ISO-8859-1 if you are requesting an unsupported one.

UTF-8 is still supported so you could just set your client charset to that.

> Why is this here? Can the mistake be int he locales.conf file?

The locales.conf file is unimportant, ignore it.
See the manual for details: http://www.freetds.org/userguide/locales.htm

The client charset in freetds.conf is the one which matters.
Your first message on that setting is confusing:

>>> I'm having trouble using freeTDS to talk to a MS SQL database with a
>>> charset of CP1250. I can't achieve to see national characters when
>>> executing a query using iSQL.
>>> I've downloaded and built from schratch the latest stable version of
>>> FreeTDS. I've configured unixODBC and have put
>>> Client charset = ISO-8859-2
>>> in the freetds.conf file.

If you want UTF-8, use
client charset = UTF-8

If you want CP1250 then set it to CP1250 or WINDOWS-1250. You'll first have
to restore full iconv support for that though.
ISO-8859-2 is not the same.

Note that this is the client charset setting, what you wish to use here on
the client end. It's always recommended to just use Unicode, and in FreeTDS's
case that means UTF-8 as the only option. It doesn't have to match what's
used on the server side, MS SQL will always use UTF-16LE or UCS-2LE
regardless for TDS 7.x.

If you are testing with tsql, your current environment might be consulted and
override the client charset in the config file.
Make sure LANG is set properly.
eg.
export LANG=hr_HR.UTF-8
(Check "locale -a" for what is supported.)

In addition to TDSDUMP, do a TDSDUMPCONFIG to verify that your freetds.conf
file is being found and read properly.





Archive powered by MHonArc 2.6.24.

Top of Page