LazUtils.LConvEncoding can convert utf8 to codepage (not many codepages) and vice versa.
FPC 3 can convert utf8 to codepage - via SetCodePage(s, codepage, true). But how can FPC convert back - codepage to utf8? Does such way exist?

Mailing lists / fpc-pascal / 2019-05
8 messages · 4 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
LazUtils.LConvEncoding can convert utf8 to codepage (not many codepages) and vice versa.
FPC 3 can convert utf8 to codepage - via SetCodePage(s, codepage, true). But how can FPC convert back - codepage to utf8? Does such way exist?
Alexey Tor. schrieb am Mo., 27. Mai 2019, 13:15:
Use CP_UTF8 as code page for SetCodePage or assign the string to a UTF8String variable.
Regards,
Sven
Although be advised that if your SystemCodePage is not a Unicode codepage, there will be data loss due to (sometimes unexpected) internal conversions, regardless of the current dynamic string code page.
Martok wrotethere will be data loss due to (sometimes unexpected) internal conversions,
Surely that must be a bug then. Converting anything to a UTF-x encoding should be lossless as Unicode is the only standard that supports ALL languages.
Regards,
Graeme
Although be advised that if your SystemCodePage is not a Unicode codepage, there will be…
Martok schrieb am Mo., 27. Mai 2019, 15:14:
As Graeme wrote that shouldn't be the case when converting to UTF-8. And for everything else you need to either use string variables with the correct static encoding or RawByteString to avoid conversions.
Regards,
Sven
Ok, I got it. But I wonder: if my code changes codepage of a "string" to e.g. 1250, will all Lazarus string functions work ok with such changed string? For ex, will Pos('Петя', s) work?
Martok schrieb am Mo., 27. Mai 2019, 15:14: As Graeme wrote that shouldn't be the case…
As I wrote: "if your SystemCodePage is not a Unicode codepage". If it is, everything mostly works.
And even RawByteString gets unexpected roundtrip-conversions on some operations, which breaks in funny ways if the SystemCodePage can't represent some characters in the RBS. I once spent most of a day debugging seemingly random data corruption until I realized the corrupted bytes were #$81, #$90 etc and the non-LCL program used CP 1252.
More interesting for Alexey regarding the followup question: the result of any string operation is in the DefaultSystemCodepage, such as:
s:= 'abc';
SetCodePage(RawByteString(s), CP_UTF8, true);
WriteLn(s, ' ',StringCodePage(s)); // abc 65001
s:= s + 'd';
WriteLn(s, ' ',StringCodePage(s)); // abcd 1252Ok, I got it. But I wonder: if my code changes codepage of a "string" to e.g. 1250, will…
Alexey Tor. schrieb am Di., 28. Mai 2019, 14:44:
Ok, I got it. But I wonder: if my code changes codepage of a "string" to e.g. 1250, will all Lazarus string functions work ok with such changed string? For ex, will Pos('Петя', s) work?
Depends on what you do with the returned value. Lazarus uses UTF-8 by default, thus the constant would be in UTF-8 as well and Pos() takes two AnsiString parameters, thus CP_ACP. So the constant is passed along as is and s is converted to UTF-8. Depending on the encoding of the characters you might get a different position, thus you should ensure that both of your strings have the same type (not tested) or you should work simply in UTF-8 and only convert for input/output purposes.
Regards,
Sven