|Subject:||Re: Indy 10.6.0 - IndyTextEncoding(1252)|
|Posted by:||Remy Lebeau (re…@lebeausoftware.org)|
|Date:||Wed, 22 May 2013|
> IOHandler.DefStringEncoding := TEncoding.GetEncoding(1252) => TMBCSEncoding
> replaced with
> IOHandler.DefStringEncoding := IndyTextEncoding(1252); => TIdASCIIEncoding
> But AFAICT this results in a different encodingthe before
You are right. I have changed IndyTextEncoding(Word) to now use TIdMBCSEncoding
internally for 1252 and 437 like earlier Indy 10 versions did.
> unless TIdASCIIEncoding produces the same results as TMBCSEncoding
It does not.
> not yet sure what TIdASCIIEncoding does under the hood, but the name
> suggest a wrong encoding
It does exactly what its name suggests. It implements the 7bit ASCII range
(#0 - #127) only, whereas 1252 has some 8bit values above #127.
> Should IndyTextEncoding really return IndyTextEncoding_ASCII for
> codepage 1252?
20127 is the official codepage for ASCII, but not all OSes support 20127,
so Indy falls back to 1252 and even 437 when 20127 is not available. It
was a mistake going the other way, though - behaving like 20127 when 1252
or 437 is requested. A fix has been checked in.
Remy Lebeau (Indy Team)
Indy 10.6.0 - IndyTextEncoding(1252) posted by Marius on Wed, 22 May 2013