Ahhh... so the string you have was read from a file, not compiled into
your program. That makes all of the difference in the world. If the
string is read from a file, it really does have backslashes in it. If
it was compiled into your program, it doesn't.
Evidently, Excel processes the string during input and converts the
escape sequences (\", \t, \n, and the like) into their corresponding
characters (", tab, and newline, respectively).
I don't know of any built-in .NET method that will this processing for
you (take a string containing escape sequences and translate them to
their character equivalents). To do a 100% job would be a huge
challenge, but you can do the most common sequences (and perhaps all of
the ones you need) like this:
string cleanString;
cleanString = stringFromXmlFile.Replace("\\\"", "\"").Replace("\\t",
"\t").Replace("\\n", "\n");
You can add as many "replace" calls as you need to do the job.
The first Replace call is different because it involves the
double-quote, which is also the string delimeter in C#, so it needs
some special help. This replace call says, "Replace every occurrence of
a backslash (\\, because a \ by itself is an escape, so two \\
represent a single \ to the compiler) followed by a double-quote (\"
because you can't just say " or that would end the string) to a
double-quote."
The subsequent Replace calls are simpler. They say, "Replace every
occurrence of a backslash (\\ again) followed by (for example) an en by
(for example) the character \n." The compiler translates \n into the
newline character, so the Replace ends up replacing every two-character
sequence \n by the new line character.
You can do the same for tab (\t), return (\r), and a bunch of other
characters. See here for the common ones:
http://msdn.microsoft.com/library/d...en-us/csspec/html/vclrfcsharpspec_2_4_4_4.asp
(watch for line wrapping on the URL).
Mind you, this won't trap all possible values: you can also use the \
escape character in C# followed by a hexadecimal or Unicode escape
sequence, which could indicate any character in the massive Unicode
character space. This Replace trick won't work in that case. I'll leave
it to someone smarter than I am to come up with a solution for that
one.
However, if you don't have any backslashes followed by numeric
sequences in your XML code, then you're probably fine with the trick I
outlined above.