Well as feared it did not come through. Let me try this again: The string 'Ãf¤' would be 'Ãf'

when interpreted as bytes which encode UTF-8. In turn 'Ãf' as bytes encoding UTF-8 is 'ä' which

is what we actually want. The rest is as described below.


---


Hi Eliot,
I started looking into this. So far I could not manage to reproduce this
locally using a new trunk image and using a trunk image from May and
updating it. So far this looks like a mixture of a double encoding and a
wrong decoding issue. The character sequence 'ÃfÆ'Ã'¤' further down (in
Volker BÃfÆ'Ã'¤cker) would be Ãf¤ when interpreted as UTF-8 which in
turn when interpreted as UTF-8 is ä, which would be expected in the
string. To get to 'ÃfÆ'Ã'¤' though would require to interpret the ä in
UTF-8 as CP1252 and then encode it again in UTF-8 and decode it once
again using CP1252.
Sanity check before I continue: Does the source code in the method look
right in that image?
(I hope all these weird characters will come through to you :) )
Bests
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170719/6ed7684b/attachment.html>