Remove IIdTextEncoding parameters for AnsiString input on FreePascal 3.0+ #507
Labels
Element: Compiler/IDE
Issues related to a particular Compiler and/or IDE
Status: Review Needed
Issue needs further review to decide next status
Type: Enhancement
Issue is proposing a new feature/enhancement
Milestone
STRING_IS_ANSI
is defined when thestring
type maps toAnsiString
. In this situation, most encoding-aware methods have an extraIIdTextEncoding
parameter to specify anAnsiString
's input encoding, or desired output encoding.However, under FreePascal 3.0+,
AnsiString
is codepage-aware (similar to in Delphi 2009+), so passing in these extraIIdTextEncoding
parameters for input strings may be redundant, and even a source for mismatches. When encoding anAnsiString
to Unicode and then to charset-encoded bytes, Indy could simply useStringCodePage()
to query theAnsiString
's codepage, and/or let the RTL just convertAnsiString
toUnicodeString
without usingIIdTextEncoding
at all.Alternatively, simply replace
AnsiString
+IIdTextEncoding
parameter pairs withUnicodeString
where appropriate.Either way, it would be the caller's responsibility to make sure an input
AnsiString
is assigned the correct codepage before passing it into Indy.By default, Lazarus uses UTF-8 encoded
AnsiString
's, so we should let the RTL handleAnsiString
->Unicode conversions as much as possible to accommodate this.However, for the reverse situation, when Indy returns an
AnsiString
to a caller, the caller should still specify the encoding it wants theAnsiString
to be in, so passing in anIIdTextEncoding
is still useful in this case. We would just have to make sureSetCodePage()
is used appropriately on the output string to match this encoding.The text was updated successfully, but these errors were encountered: