> The default encoding in Firebird, when nothing is specified, is NONE.
> It applies to every client library regardless of language.

So if i read it right, it is allowed for client libraries to connect to core w/o specifiyng charset ???

To me it is wrong.
I think there is two possible ways:
Less reliable: server core should document assumed encoding if nothing specified and EVERY client library MUST blindly obey.

More reliable: server should disallow connection (or any data stream passing) until client library specifies the connection. Library can specify "NONE" but it MUST specify anything before server core would allow single byte of data to be transfered.

This latter variant may have some exception for pre-defined system table.

Say, client established charset-less connenction.
Then it reads DB default connections from RDB$something - reading of system tables is permitted.
Then it switches the connection to that charset, finishing connection establishing.
Then core allows non-system tables read/write and system tables write.

By tables i meant any relations including SPs.

> setting, on Linux it might be anything). One possibility would be to
> specify system's default encoding as a connection encoding, however
> that would for sure break setups where database default encoding is NONE.

So those databases that are anyway prone to be broken after any environment change? Those that are merely waiting for their doom bel rang ? "Crash early". Let them fix their DB before it gathered even more data to loose.
Also if i understand you, all they would have to do is to change database and data charsets to some really used value. There were scripts published here and there. Nasty work, yet feasible.

> We cannot assume UTF-16 for raw data because of heterogenity.

Hey, none is none! Use client-side transcoding. In Delphi sources or in Java sources. You told as to disable safety checks - so here you are, trusted and mighty. It's like enforcing type casts. Code is unsafe but we hope you know what you do.

> As far as
> I know, almost every Delphi or C++ library uses one-byte strings,

Since Delphi 2009 string is now USC-2 or UTF16, ain't sure.
So all recompiled libraries would use them.
And data access components would transcode as necessary between fbclient.ddl and app sources.

> Unicode ones. Java applications account for about 6% of Firebird
> market, so we have to obey their rules.

Why that ?
You should enforce your rules for Java applications.
And "do not use NONE until you intend to get raw binary" is a sensible rule. Just don't make it implicit.

> So, maybe we should really deny the connection, when nothing is specified...

I think that default, bare connection should still work, but should have some default other than NONE and reported to server.

> Am 29. Juni 2012 10:01:13 schrieb "the_a_rioch" <ariochthe@...>:
> > > The problem is that defaulting to UTF8 will not always work fine,
> > > especially not if the database connected to is not UTF8.
> >
> > why ? doesn't server know what charset of connection is ?
> > FB 1.x would just refuse.
> > FB 2.x would transcode to UTF-8 server-side, won't it ?
> >
> > Or is this dependent upon use fbclient.dll vs direct internal protocol?
> >
> > > However maybe a more intelligent algorithm for deciding on the
> > > characterset is possible (eg when NONE is used, try to use the
> >
> > I still think that as 0-vs-NULL.
> > * If "NONE" is *specified* - then obey and do NO transcoding at all.
> > Raw UTF-16. There is no situation we would think it is reasonable, but
> > we don;t have all the world's wisdom. So if there is some braindead
> > geek wanting to shoot his feet - he is warned and given the gun.
> > If (sorry for pun) *none* was specified - just no that property at all
> > - then do most flexible or most adaptable thing as heuristics OR deny
> > connection and ask user to read documentation, sine that setting is
> > important and incorrectly set might corrupt his database in long run.
> >
> > > encoding). I created http://tracker.firebirdsql.org/browse/JDBC-257 to
> > > look into this.
> >
> > i don't have tracker password here, maybe would later.
> > I just think link to this discussion is to be added there, so that
> > people could follow why the question was started and what different
> > opinions to be there.
> >
> > Thanks for clarifying those things to me.
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>