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. 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.
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.
The only drawback is when you pass constant string as parameter, you need to explicitly specify the code page of the
source file. Otherwise national chars will be lost.
Yuriy.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
