Hallo Community,
der Vorteil der @-Schreibweise von String-Literalen besteht darin, dass
Escapesequenzen wie
\n für Newline nicht verarbeitet werden. Dadurch kann man z.B.
@"c:\neu\datei.txt" statt
"c:\\neu\\datei.txt" schreiben.
Wenn man in der @-Schreibweise einen String schreiben will, der selbst Anführungszeichen enthält, dann muss man die Anführungszeichen verdoppeln.
@"Er sagte: ""Hallo""" entspricht
"Er sagte: \"Hallo\""
Man kann in der @-Schreibweise sogar Zeilenumbrüche direkt in den String packen:
@"Zeile1
Zeile2"
entspricht
"Zeile1\nZeile2" oder
"Zeile1\r\nZeile2"
je nachdem, was der Editor als Zeilentrenner in die Quelldatei schreibt.
Die ganze Geschichte steht in der MSDN:
string (C#-Referenz)
herbivore
PS:
Escapesequenzen wie
\n werden
nur vom Compiler und
nur innerhalb von (String-)
Literalen behandelt und umgesetzt - bzw. in der @-Schreibweise eben ignoriert. Wenn
zur Laufzeit Zeichen wie
\ und
n erstmal in einem String oder einer Datei stehen, erfolgt logischerweise keine automatische Umsetzung mehr, sondern dann werden die Zeichen als (zwei) normale, unabhängige Zeichen behandelt. Man kann die Umsetzung selber vornehmen, z.B. mit
 C#-Code: |
myString = myString.Replace (@"\n", "\n");
|
PPS: Im Debugger werden
bei der Anzeige von String-Werten enthaltene Backslashes automatisch gedoppelt. Die Zeichenfolge aus den zwei Zeichen
\ und
n wird als
"\\n" angezeigt. Der im String enthaltene Backslash wird
nur für die Anzeige gedoppelt; im String selbst ist er weiterhin nur einmal vorhanden. Ein einfacher, einzelner Zeilenvorschub wird dagegen als
"\n" angezeigt; im String selbst ist weiterhin nur ein einziges Zeichen, nämlich der Zeilenvorschub vorhanden.
PPPS: Siehe auch
[FAQ] Besonderheiten der String-Klasse (immutabler Referenztyp mit Wertsemantik)
