Encoding problem

[MarkMurphy]

Hi,

I'm trying to read in a file written in French.

StreamReader sr = new StreamReader(fn,System.Text.Encoding.UTF8);
string s = sr.ReadToEnd();

I can edit the file fn in VS and it looks fine. The variable s
receives all the data except characters with accents.

"Déclaration" appears with out the accented e. (may not display on
your browser)


Same thing with umlauted chars in a German file.

If I use the form:

StreamReader sr = new StreamReader(fn);

I can break after the statement and see that sr.CurrentEncoding is
UTF8. Still no luck with getting all of the string.

Must be missing something, but what?

Thanks!

 

[Jon Skeet]

I'm trying to read in a file written in French.

But in which encoding? You can't just assume it's UTF-8 if it's not -
do you have any reason to believe the file is in UTF-8?

If I use the form:

StreamReader sr = new StreamReader(fn);

I can break after the statement and see that sr.CurrentEncoding is
UTF8.

That's because that's the default encoding if you don't specify one.

See http://www.pobox.com/~skeet/csharp/unicode.html for more
information about this kind of thing.

 

[john farrow]

If you open the file in VS7 and do select File | Adanced Save Options it
will tell you what the real encoding is.

 

[Jon Skeet]

If you open the file in VS7 and do select File | Adanced Save Options it
will tell you what the real encoding is.

I don't see how it can, to be honest. It can make a *guess* as to what
the encoding is, but surely it can't tell the difference between two
identical files representing different content in different encodings.

 

[Jon Skeet]

How could I have "identical files representing different content in
different encodings".

The files would contain the same bytes, but represent different content
in different encodings.

If the encoding was different they would not be identical.

Not if they have different content.

Here's an example. Two files, first is utf8.txt, which represents
characters ab (Unicode 0x0123, latin small letter g with cedilla) cd
That file is encoded in UTF-8 (without BOM) and the bytes in it are (in
hex):

61 62 C4 A3 63 64

The second file is called cp1252.txt, which contains "abģcd" with an
encoding of code page 1252. (The middle two characters are a capital A
with an umlaut and a pounds-sterling sign, in case it doesn't show up
on your newsreader.) That file (in hex) is:

61 62 C4 A3 63 64

There we have it: identical files (same binary content) representing
different content (the two different strings) in different encodings
(UTF-8 and CP1252).

Open either file with VS.NET and it's got to guess which encoding the
file is meant to be in - and in one of the cases, it's bound to be
wrong.

 

[Fergus Cooney]

Hi Guys,

If you save a text file in NotePad as UTF-8 it sticks the
characters 0xEF 0xBB at the front. For Unicode it's 0xFF 0xEE. For
ANSI it doesn't have anything.

I tried the same exercise in VS, selecting encodings with
File\Advanced Save Options. It didn't stick in the encoding.

Who knows?

Regards,
Fergus

 

[Jon Skeet]

If you save a text file in NotePad as UTF-8 it sticks the
characters 0xEF 0xBB at the front. For Unicode it's 0xFF 0xEE. For
ANSI it doesn't have anything.

Sure - that's what notepad does, but not everything does.

I tried the same exercise in VS, selecting encodings with
File\Advanced Save Options. It didn't stick in the encoding.

Who knows?

I know - it's ambiguous, basically.

I picked UTF-8 and CP1252 almost at random. There are other simple
examples - two different simple 8-bit Windows code pages would provide
exactly the same kind of behaviour (different content and different
encodings potentially producing identical files), and there's not even
the possibility of byte ordering marks there.

 

[MarkMurphy]

Thanks all for the enlightening discussion. I have this working now
and here is understanding of the solution.

It appears that VS saves files by default in Western European
(Windows) Codepage 1252, not UTF-8. I had been assuming UTF-8 and
when I loaded the file into a StreamReader and checked the value of
the CurrentEncoding, it was displayed as UTF-8 in the debugger.
Perhaps the encoding could not be determined and defaulted to Western
European.

In any case, we try to store localized files as UTF-8 and so I did so
by doing a 'save as' and selecting the down arrow next to the Save
button. This allows me to save with encoding of Unicode (UTF-8) with
signature. After doing that, those exotic umlauts and accents began
to appear in my string read in by StreamReader.

VS help warns that UTF-8 is not supported by Visual SourceSafe in text
mode. Binary is. I tried checking in some text UTF-8 files and
checking them back out without trouble. Perhaps problems arise when
doing compares and other functions.

 

[Jon Skeet]

Thanks all for the enlightening discussion. I have this working now
and here is understanding of the solution.

It appears that VS saves files by default in Western European
(Windows) Codepage 1252, not UTF-8. I had been assuming UTF-8 and
when I loaded the file into a StreamReader and checked the value of
the CurrentEncoding, it was displayed as UTF-8 in the debugger.
Perhaps the encoding could not be determined and defaulted to Western
European.

No, StreamReader doesn't attempt to work out the encoding. It uses
UTF-8 if you don't specify which encoding to use. (See MSDN for more
info.)

In any case, we try to store localized files as UTF-8 and so I did so
by doing a 'save as' and selecting the down arrow next to the Save
button. This allows me to save with encoding of Unicode (UTF-8) with
signature. After doing that, those exotic umlauts and accents began
to appear in my string read in by StreamReader.

Good good. Alternatively, you could use CP1252 in the StreamReader...