On 04/05/2016 05:07 PM, Wols Lists wrote:
> On 05/04/16 14:53, Alex Peshkoff wrote:
>> On 04/05/2016 04:43 PM, Dimitry Sibiryakov wrote:
>>> 05.04.2016 15:22, Alex Peshkoff wrote:
>>>> Yes currently all keys are ASCII but it's
>>>> used also for plugins configuration and I see no reasons why national
>>>> characters can't arrive there.
>>>      Because they won't work if written in utf-8 or any encoding different 
>>> from current locale.
>>>
>> OK, for them we can use that limitation - be ascii. But as far as I
>> remember we were initially going to make all config files to be utf8.
>> But there are a lot of other places where NoCaseString is used. And it's
>> very efficient when case-insensitive strings are needed. It will be not
>> good to loose such class.
>>
>> What prevents from (for example) making them always utf-16 and
>> performing case-insensitive comparison for them?
>>
> Because utf-16 is a horror? Because utf-16 is pretty much non-existent
> on linux?

# iconv -l|grep 16
..... // skipped
UTF-16//
UTF-16BE//
UTF-16LE//
UTF16//
UTF16BE//
UTF16LE//
.........

I.e. it exists but typically not used.

> (Yup, you have the other problem in that utf-8 is pretty much
> non-existent on Windows :-) But as I understand it, utf-8 is actually
> guaranteed to work pretty much anywhere, while there are utf characters
> that will not fit in a 16-bit word so utf-16 gets hairy when you start
> dealing with far-east character sets.

That's really a problem. Yes, I do not see for example Thailand letters 
in IBM tables.

> And that "current locale" thing is a pita for servers - what do you do
> if one client is ASCII and another is KOI-8, for example :-)

Fbclient since FB3 always sends data to server in utf-8.

> imho, if it depends on local settings (such as for filenames) you just
> have to have platform-specific code that says "convert to the local
> character set and go from there" :-( Whatever that local character set is.
>
> (Oh, and isn't utf-16 pretty much guaranteed to give you invalid linux
> file names with embedded nulls?)
>

Certainly they should be converted to current locale before use. And yes 
- no idea what will open() do with that NULLs.


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

Reply via email to