STRING_IS_ANSI is defined when the string type maps to AnsiString. In this situation, most encoding-aware methods have an extra IIdTextEncoding parameter to specify an AnsiString'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 extra IIdTextEncoding parameters for input strings may be redundant, and even a source for mismatches. When encoding an AnsiString to Unicode and then to charset-encoded bytes, Indy could simply use StringCodePage() to query the AnsiString's codepage, and/or let the RTL just convert AnsiString to UnicodeString without using IIdTextEncoding at all.
Alternatively, simply replace AnsiString+IIdTextEncoding parameter pairs with UnicodeString 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 handle AnsiString->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 the AnsiString to be in, so passing in an IIdTextEncoding is still useful in this case. We would just have to make sure SetCodePage() is used appropriately on the output string to match this encoding.
STRING_IS_ANSIis defined when thestringtype maps toAnsiString. In this situation, most encoding-aware methods have an extraIIdTextEncodingparameter to specify anAnsiString's input encoding, or desired output encoding.However, under FreePascal 3.0+,
AnsiStringis codepage-aware (similar to in Delphi 2009+), so passing in these extraIIdTextEncodingparameters for input strings may be redundant, and even a source for mismatches. When encoding anAnsiStringto Unicode and then to charset-encoded bytes, Indy could simply useStringCodePage()to query theAnsiString's codepage, and/or let the RTL just convertAnsiStringtoUnicodeStringwithout usingIIdTextEncodingat all.Alternatively, simply replace
AnsiString+IIdTextEncodingparameter pairs withUnicodeStringwhere appropriate.Either way, it would be the caller's responsibility to make sure an input
AnsiStringis 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
AnsiStringto a caller, the caller should still specify the encoding it wants theAnsiStringto be in, so passing in anIIdTextEncodingis still useful in this case. We would just have to make sureSetCodePage()is used appropriately on the output string to match this encoding.