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