[fpc-devel] TRegistry and Unicode

[Marco van de Voort]

Op 3/3/2019 om 11:17 AM schreef Yuriy Sydorov:
> On 02.03.2019 18:53, Bart wrote:
>> On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis <joost at cnoc.nl> 
>> wrote:
>>
>>> The utf8encode should go, just like the utf8decode's that we fixed 
>>> already.
>>
>> Shall I post a patch in the bugtracker?
>> If so: instead of
>> SomeAnsiString := UTf8Encode(SomeUnicodeString) do I make it an
>> implicit conversion (SomeAnsiString := SomeUnicodeString), or an
>> explicit typecast (suppressing warnings: SomeAnsiString =
>> String(SomeUnicodeString))?
>
> This is good if you assign the result of ReadString() to a regular 
> ansistring var. 

(which is the case here)


> But if you assign it to a utf8string,unicodestring,widestring var - it 
> will not return correct result for chars that are missing in the 
> current system code page. This is bad for a user app which is using 
> unicodestring everywhere and don't bother with ansistrings and their 
> default code page.
>
Yes, but this is a feature of the language. String conversions go over 
the default stringtype, and if that can't harbor all characters, there 
will be loss.

> The proper solution is to make string params and the result to be 
> utf8string. This way proper conversion to regular ansistring will be 
> done for the result and unicodestring/widestring will be properly 
> handled as params.

We already have two and an half options:

- Delphi 2009+  everything unicodestring

- Delphi old      everything locale windows encoding

- Lazarus hack    set default encoding to utf8.

On *nix the last two are usually the same, and in time, the last two 
might also merge on windows, since Windows has options to set the 
default codepage to utf8 since 2018 april update (though I have not seen 
testreports yet).

There is no need to further change interfaces to provide yet another 
option which does yet another option which is useful for only a limited 
time.