tags:

views:

385

answers:

4

In C#: How do I store an ASCII character to a "char" literal?

The ASCII character I want to use for my special character is the File Separator symbol:

Decimal: 028
Octal: 034
Hex: 01C
Binary: 00011100

// This works in C/C++, but not C#:
static const char FS = 0x1C; // File Separator
+7  A: 

The static modifier is not necessary and you have to explicitly cast your int to a char.

const char FS = (char)0x1C;
ChaosPandion
Thanks. I guess it was so simple, I didn't even think about the cast.
jp2code
+2  A: 

const char FS = '\x1C';

Seva Alekseyev
The `\x` escape sequence is pure evil - at least for strings. For instance, the difference between "\x9Bad Compiler" and "\x9Good compiler" is pretty hard to spot. Not so bad for a single char though, I guess. I'd still use `\u001c` myself though.
Jon Skeet
ChaosPandion got it first. I had tried using '\1C', but that didn't work. Thanks!
jp2code
@Jon Skeet: But you can just as easily use `\x` with four digits as you can `\u` with four digits. For instance `"\x0009Bad Compiler"` would compile the same as `"\u0009Bad Compiler"`. And `\x` is more convenient for `char` literals, since you don't *have* to use all four digits. For strings it can be tricky if you're not careful, as you point out. But if there's no ambiguity (say there's no alphanumeric after the sequence), then I still prefer `\x`. By the way, I strongly object to the use of the word **evil** to mean "a tricky or dangerous construct".
P Daddy
So I'm evil. I jaywalk, I double-dip, I use \x. Mwa-ha-ha!!!Seriously though, once you run headfirst into this once or twice, you won't ever make the same mistake again. Considering the fun of debugging such an issue, the brain will have a dedicated lobe just for that.
Seva Alekseyev
+3  A: 

I would imagine '\u001C' would work.

Marc Gravell
A: 

Be careful with encodings if you're going to be writing this to a stream; .NET's characters and strings are UTF-16 encoded, so that will actually be written as 001C (or 1C00, depending on endianness; I don't remember which). You can avoid this problem by specifying the appropriate encoding when opening the stream.

Edit: Actually, this isn't the case! Having just tested it, the default behaviour for StreamWriter et al is to use the system's current ANSI code page (usually ISO-8859-1), so it does in fact get written in the expected 8-bit format. This will, of course, give unexpected results for non-ANSI characters.

Will Vousden
@Inquisitor: Would Jon Skeet's and Marc Gravell's suggestion of using '\u001C' prevent UTF-16 streams slips?
jp2code
@jp2code: I was actually wrong, so never mind :) However, no, the way in which the character is assigned won't affect how it's written to streams.
Will Vousden