Michael Schnell schrieb:
On 10/21/2011 10:24 PM, Hans-Peter Diettrich wrote:
The bad news about new Delphi strings is the addition (overload) of
functions with RawByteString arguments, which *take* strings of any
encoding, but then *ignore* that encoding. These versions certainly
must fail for all MBCS encodings :-(
Is there an agreement on how this should work ?
function parameter type .... Unicode string type coming in ... actual
encoding ID of string coming in -> conversion
I'm not sure what you mean. Whenever a UnicodeString is passed as an
argument, the UnicodeString version is called, not the RawByteString
version.
When only AnsiString types are passed as parameters, the RawByteString
version is called, and has to deal with possibly different encodings.
The Delphi implementations simply ignore any encoding, so that the
results are almost unusable :-(
In the AnsiStrings and StrUtils units another set of overloaded
procedures is provided, for native AnsiString(CP_ACP) arguments. These
versions are called only for all-native AnsiString arguments, so that no
conversions are required.
1) RawByte ... any .. any -> supposedly no, supposedly keeping the
encoding ID
2) not Raw ... Raw ... $FFFF (="RAW") -> ???
3) not Raw ... same ... matching -> obviously No
4) not Raw ... same ... not matching (maybe $FFFF) -> this is an
intersexual String what to do ?
[...]
Please note that the RawByteString type is not an intended type for
variables, only for subroutine arguments. Strings of that type are
either empty, with no encoding, or they hold the last assigned string,
including its encoding.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
