Subject | Re: [IBO] UTF-8 handling |
---|---|
Author | Martijn Tonies |
Post date | 2008-09-30T15:05:24Z |
How about IBO UTF8 handling for text blobs?
A customer reported saying UTF8 is displaying fine for VARCHAR, but is
messed up for text blobs.
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB,
Oracle & MS SQL Server
Upscene Productions
http://www.upscene.com
--- In IBObjects@yahoogroups.com, "Daniel Albuschat" <d.albuschat@...>
wrote:
A customer reported saying UTF8 is displaying fine for VARCHAR, but is
messed up for text blobs.
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB,
Oracle & MS SQL Server
Upscene Productions
http://www.upscene.com
--- In IBObjects@yahoogroups.com, "Daniel Albuschat" <d.albuschat@...>
wrote:
>database is
> 2007/11/14, Stefan Heymann <lists@...>:
> >
> > > Hence, the UTF-8 will already be the correct character set for the
> > > data-bound controls, provided that the developer has set it
> > > correctly.
> >
> > IMHO this should be "Provided that the developer has set the Client
> > Character Set property correctly, fbclient.dll will already deliver
> > the correct character set".
>
> Obviously.
>
> > > This means that IBO does not play a role in this game, because the
> > > conversion is already done by the fbclient-API.
> >
> > No. The fbclient doesn't have to convert anything when the
> > in UTF-8 and the client connection is in UTF-8.these
>
> I meant to say "because the conversion, if necessary, is already done
> [...]", of course.
>
> > > There's one pitfall, though: If the fbclient-API finds characters
> > > that it was unable to transcode, it'll signal an error and the
> > > current operation will be aborted.
> >
> > But only if the Client Character Set is not UTF8.
>
> If the client's character-set is utf-8, there can not be a
> transliteration-problem.
>
> > > That's why I would prefer, in the case that I'm using
> > > unicode-unaware controls and a unicode database, for IBO to do a
> > > 'soft' conversion with loose error handling.
> >
> > I can understand what you mean. But having everything go through
> > events would be quite time-consuming.
>
> No. If those events are not set, there'll be only a simple 'cmp' added
> to the runtime. If the event is set to a trivial function, it'll be a
> 'cmp', a 'call' and a 'ret', basically.
> And this is not a time-critical section of code, anyways. Thinking
> about how the string arrived where it is now, a little cmp can
> definitely be considered harmless. Remember that it had to be located
> and read from the db, shipped over a network-layer and put into the
> client-buffer and (if necessary) has been transcoded, already.
>
> > However, I don't care as long as I can have unmodified UTF-8 ;-)
>
> I, too, think that this has a high priority to make IBObjects usable
> for more 'advanced' applications.
>
> --
> eat(this); // delicious suicide
>