Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Alex Peshkoff via Firebird-devel

On 2/4/22 16:44, Dimitry Sibiryakov wrote:

Alex Peshkoff via Firebird-devel wrote 04.02.2022 14:37:
What to do with values of tags that are unknown (other version or 
provider-specific)? I see no way to tell on destination side if they 
arrived as is or were transliterated.


Take a look at checkTag() functions in IntlParametersBlock.cpp. It's 
clear that items unknown to client library remain not transliterated.


  And thus two problems:

1. Client library is required to match server version while original 
design allowed a variety of back- and forward compatibility.


As long as one does not use new string-items in DPB with non-ascii data, 
known to server but not known to client library, it's OK.
In described bad case if one does not want to upgrade fbclient UTF8 
should be used.



2. Provider-defined string items are in troubles.



Yep, it's really a problem. They will be delivered to provider in client 
encoding.




Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Dimitry Sibiryakov

Alex Peshkoff via Firebird-devel wrote 04.02.2022 14:37:
What to do with values of tags that are unknown (other version or 
provider-specific)? I see no way to tell on destination side if they arrived 
as is or were transliterated.


Take a look at checkTag() functions in IntlParametersBlock.cpp. It's clear that 
items unknown to client library remain not transliterated.


  And thus two problems:

1. Client library is required to match server version while original design 
allowed a variety of back- and forward compatibility.

2. Provider-defined string items are in troubles.

--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Alex Peshkoff via Firebird-devel

On 2/4/22 15:17, Dimitry Sibiryakov wrote:

Alex Peshkoff via Firebird-devel wrote 04.02.2022 12:59:
I suppose you suggest to fallback to existing way when there is no 
isc_dpb_lc_ctype in DPB?


  I suggest nothing but wonder what to do if there is no isc_dpb_utf8 
tag in DPB but isc_dpb_lc_ctype is.

  Is it right to still consider values to be in ANSI encoding?


You know yourself that client may push any sheet in DPB. For client use 
of default ANSI codepage is good guess, not more.


What to do with values of tags that are unknown (other version or 
provider-specific)? I see no way to tell on destination side if they 
arrived as is or were transliterated.


Take a look at checkTag() functions in IntlParametersBlock.cpp. It's 
clear that items unknown to client library remain not transliterated.





Host name is not sent over the wire.
I doubt names resolver in system using (for example) cp1251 will 
accept host name in utf8.


  It is actually contrary: 
https://www.sql.ru/forum/actualthread.aspx?tid=1341790




According to documentation gethostbyname() & Co should work with current 
locale. But not sure what does it mean for windows.





Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Adriano dos Santos Fernandes
On 03/02/2022 12:39, Dimitry Sibiryakov wrote:
>   Hello All.
> 
>   Remember me please why isc_lc_ctype isn't used to determine encoding
> of database name and DPB values?
>   BTW, service name during service attach isn't converted into UTF-8 at
> all.
> 

Character set discovery from name requires opening a database to match
100% what happens after database is open.

There is aliases inside database (both iso8859_1 and iso88591 are valid).

So chicken and egg problem.

These creates others problems, for example to convert server codepage of
exceptions to client.

I plan to change some of these things in the future so all charset names
could be discovered independent of a database connection.


Adriano


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Dimitry Sibiryakov

Alex Peshkoff via Firebird-devel wrote 04.02.2022 12:59:
I suppose you suggest to fallback to existing way when there is no 
isc_dpb_lc_ctype in DPB?


  I suggest nothing but wonder what to do if there is no isc_dpb_utf8 tag in 
DPB but isc_dpb_lc_ctype is.

  Is it right to still consider values to be in ANSI encoding?
  What to do with values of tags that are unknown (other version or 
provider-specific)? I see no way to tell on destination side if they arrived as 
is or were transliterated.



Host name is not sent over the wire.
I doubt names resolver in system using (for example) cp1251 will accept host 
name in utf8.


  It is actually contrary: 
https://www.sql.ru/forum/actualthread.aspx?tid=1341790

--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Alex Peshkoff via Firebird-devel

On 2/4/22 13:41, Dimitry Sibiryakov wrote:

Alex Peshkoff via Firebird-devel wrote 04.02.2022 9:53:
  Remember me please why isc_lc_ctype isn't used to determine 
encoding of database name and DPB values?


Due to limitations of WideCharToMultiByte API. (with posix iconv this 
cabe easily done) 


  Do you mean that client would have to have a table matching Firebird 
charset names and Windows codepages?




Sorry, windows-specific part was implemented not by me. As gar as I know 
there were more serious problems.

Table will certainly be needed, but IMO it's not too big deal.
I suppose you suggest to fallback to existing way when there is no 
isc_dpb_lc_ctype in DPB?


BTW, service name during service attach isn't converted into UTF-8 
at all.


It was always ascii :D


  Except host name part.



Host name is not sent over the wire.
I doubt names resolver in system using (for example) cp1251 will accept 
host name in utf8.





Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Dimitry Sibiryakov

Alex Peshkoff via Firebird-devel wrote 04.02.2022 9:53:

  Remember me please why isc_lc_ctype isn't used to determine encoding of 
database name and DPB values?


Due to limitations of WideCharToMultiByte API. (with posix iconv this cabe easily done) 


  Do you mean that client would have to have a table matching Firebird charset 
names and Windows codepages?



BTW, service name during service attach isn't converted into UTF-8 at all.


It was always ascii :D


  Except host name part.

--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Parameter block and database/service name encoding

2022-02-04 Thread Alex Peshkoff via Firebird-devel

On 2/3/22 18:39, Dimitry Sibiryakov wrote:

Hello All.

  Remember me please why isc_lc_ctype isn't used to determine encoding 
of database name and DPB values?


Due to limitations of WideCharToMultiByte API. (with posix iconv this 
cabe easily done)


BTW, service name during service attach isn't converted into UTF-8 at 
all.




It was always ascii :D



Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel