[fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"
mschnell at lumino.de
Fri Nov 28 14:43:34 CET 2014
On 11/27/2014 07:29 PM, Hans-Peter Diettrich wrote:
> Michael Schnell schrieb:
>> E.g. there are (are least two "Code pages" for UTF-16 ("LE", and
>> "BE"), that would be worth supporting.
> You are confusing codepages and encodings :-(
That is why I put "goose-feet" around "Code pages". I used this wording
because fpc (and Delphi ?) uses it abbreviated as "CP" in the constant
name "CP_UTF-8", "CP_UTF16" and "CP_UTF16BE) [ see Jonas post:
"CP_UTF16 and CP_UTF16BE can be returned by StringCodePage() when called
on a unicodestring, and that's it." ]
> See it as a multi-level protocol for text processing. ....
Yep. I see that is is workable and I understand the (supposedly mostly
historical) reasons. But IMHO not a good (i.e. crafted from ground up)
> It's known that the Delphi AnsiString implementation is flawed,...
And hence it's frustrating to see that fpc needs to follow for
compatibility reasons. That is why I suggested an improved
implementation (see ->
While the seriously flawed Delphi compatible use of the dynamic
encoding-brand (and bytes-per element) information (only implemented
with RawByteString) can be left at it is and a decent implementation
with a new DynmicString Type (CP_ANY) should be crafted.
> I see no problem in using the same names and values. Delphi documents
> clearly state: ...
I fear that there will be code that relies on the "flawed" behavior of
RawByteString ("it's a feature, not a bug") and using the same name with
different behavior would brake same. And a really usable DynmicString
would not adhere to that description.
More information about the fpc-devel