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 <jo...@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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
