J
John Finnan
This is a real puzzler. Has our entire office and IT
department stumped.
We have two machines (M1 / M2) which are equal spec/
operating system, applications, versions, etc...
The only difference that we can see between the two
machines is that one (M1) has Internet Explorer encoding
set to "UTF-8" with "Automatic" selected.
The other (M2) has "Western European ISO" with no automatic
selected.
Now, when the machines log into a web application and
choose to download a German Excel file, M1 and M2 get the
file correctly if they have their encoding settings as
above.
However, if M1 has it's encoding set to "Windows European
ISO" then all the characters which should have an umlaut
appear as an accented "y".
And if M2 has it's encoding set to "UTF-8" with "Automatic"
selected then all the characters which should have an
umlaut appear as an accented "y". (00FD in unicode hex)
This is really bizarre behaviour, and the only reason we're
even looking into it is that our German customers are
having the same issue. Some machines in their office are
seeing a problem with umlaut characters, and some are not.
We don't think it's a codepage issue or anything like that,
because code page corruption would involve changes of a 1:1
mapping. But we're seeing a-umlaut and u-umlaut both being
transformed to the 00FD character.
We think the encoding setting has to be involved somehow,
since changing it and only it, influences the results.
But we don't see how it can possibly effect it on it's own.
There has to be something else. And it has to be something
that would also exist on our German customers machines.
(We use English regional settings by the way.)
Does anyone have any idea what the heck could be causing
this?
department stumped.
We have two machines (M1 / M2) which are equal spec/
operating system, applications, versions, etc...
The only difference that we can see between the two
machines is that one (M1) has Internet Explorer encoding
set to "UTF-8" with "Automatic" selected.
The other (M2) has "Western European ISO" with no automatic
selected.
Now, when the machines log into a web application and
choose to download a German Excel file, M1 and M2 get the
file correctly if they have their encoding settings as
above.
However, if M1 has it's encoding set to "Windows European
ISO" then all the characters which should have an umlaut
appear as an accented "y".
And if M2 has it's encoding set to "UTF-8" with "Automatic"
selected then all the characters which should have an
umlaut appear as an accented "y". (00FD in unicode hex)
This is really bizarre behaviour, and the only reason we're
even looking into it is that our German customers are
having the same issue. Some machines in their office are
seeing a problem with umlaut characters, and some are not.
We don't think it's a codepage issue or anything like that,
because code page corruption would involve changes of a 1:1
mapping. But we're seeing a-umlaut and u-umlaut both being
transformed to the 00FD character.
We think the encoding setting has to be involved somehow,
since changing it and only it, influences the results.
But we don't see how it can possibly effect it on it's own.
There has to be something else. And it has to be something
that would also exist on our German customers machines.
(We use English regional settings by the way.)
Does anyone have any idea what the heck could be causing
this?