C# equivilent for Asc and Chr

[INeedADip]

'Asc' returns an Integer value representing the character code
corresponding to a character

'Chr' is the inverse and returns the character associated with the
specified character code

What are the equivilents in C#?

 

[Justin Crites]

In C#, the `char' data type is an integer type. You can cast them
between each other using normal C# casts. Here's an example:

char b = (char) 64;
int n = b;

Console.WriteLine("Character {0} is {1}", b, n);

Program output:

Character @ is 64

This depends upon you using ASCII. .NET is meant to work with Unicode
natively, so I suspect some complicated Unicode/ASCII conversion is
happening when you say (char) 64. If you wanted to write functions
that look the same as their VB counterparts, you could do that easily:

char Chr(int n) {
return (char) n;
}

There's not really much point to that, though, and you might end up on
thedailywtf.com if you do

 

[Mattias Sjögren]

'Asc' returns an Integer value representing the character code
corresponding to a character

'Chr' is the inverse and returns the character associated with the
specified character code

A simple cast will do in most cases, like (int)'A' or (char)70.

But that will get you the behaviour of VB's ChrW and AscW respectively
(the Unicode versions of the functions). Asc and Chr do ANSI<->Unicode
conversion, so if that's what you really need then you have to use
System.Text.Encoding.Default.


Mattias

 

[Gabriel Magaña]

Here's my very old quick 'n dirty implementation for these two functions:

public static byte Asc(char src) {
return(System.Text.Encoding.GetEncoding("iso-8859-1").GetBytes(src +
"")[0]);
}

public static char Chr(byte src) {
return(System.Text.Encoding.GetEncoding("iso-8859-1").GetChars(new byte[]
{src})[0]);
}

C#/.NET does not have a direct equivalent because you can have many
different encondings (the old Asc() and Chr() implied ISO8859P1, but doing
things this way is "old" thinking...

 

[Bruno van Dooren]

check out the Convert class and BitConverter class.

kind regards,
Bruno.

 

[Jon Skeet [C# MVP]]

Here's my very old quick 'n dirty implementation for these two functions:

public static byte Asc(char src) {
return(System.Text.Encoding.GetEncoding("iso-8859-1").GetBytes(src +
"")[0]);
}

public static char Chr(byte src) {
return(System.Text.Encoding.GetEncoding("iso-8859-1").GetChars(new byte[]
{src})[0]);
}

C#/.NET does not have a direct equivalent because you can have many
different encondings (the old Asc() and Chr() implied ISO8859P1, but doing
things this way is "old" thinking...

No, they didn't imply ISO-8859-1 - they implied whatever the current
codepage for the thread was, I believe. That's certainly what the
VB.NET documentation states.

(From what I remember, that's not strictly accurate either - I believe
some caching goes on, and the behaviour is very hard to predict. I had
a look at it a while ago, and it's horrible.)

 

[Gabriel Magaña]

No, they didn't imply ISO-8859-1 - they implied whatever the current

codepage for the thread was, I believe. That's certainly what the
VB.NET documentation states.

Hmm I was talking about VB6 and prior to that... (I guess I qualify as "old
fart" in the computer world, having been programming since the DOS days, but
I'm only 32!)

Anyway, this ambiguity is exactly why, in retrospect, I'm glad Asc() and
Chr() don't exist as built-in functions in C#... I've started to write a
lot of multi-lingual user interfaces and I can really see where code page
assumptions would have screwed me up!

 

[Jon Skeet [C# MVP]]

Hmm I was talking about VB6 and prior to that... (I guess I qualify as "old
fart" in the computer world, having been programming since the DOS days, but
I'm only 32!)

Well, seeing as the VB.NET function is meant to mirror VB6 as far as
possible, I doubt they'd put a code-page dependency in there at this
point - especially when it would actually be *easier* to always use
8859-1.

The documentation I've found on MSDN for Asc isn't specific at all,
unfortunately - do you have any which clear it up for definite either
way? I don't really want to install VB6 to check

Anyway, this ambiguity is exactly why, in retrospect, I'm glad Asc() and
Chr() don't exist as built-in functions in C#... I've started to write a
lot of multi-lingual user interfaces and I can really see where code page
assumptions would have screwed me up!

Localisation is a horrible business, made worse by code pages. Heck, it
would be bad enough without things like Unicode surrogates, which just
add to the problems too

 

[Gabriel Magaña]

The documentation I've found on MSDN for Asc isn't specific at all,

unfortunately - do you have any which clear it up for definite either
way? I don't really want to install VB6 to check

Hmm information is sketchy... I was never a VB programmer, Asc() and Chr()
seem to be one of theose few functions that are called the same in a bunch
of languages! I did find this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbenlr98/html/vafctchr.asp

Which implies that the value returned is based on the current system
codepage, since it states that "Numbers from 0 31 are the same as standard,
nonprintable ASCII codes. For example, Chr(10) returns a linefeed character.
The normal range for charcode is 0 255. However, on DBCS systems, the actual
range for charcode is -32768 to 65535."

 

[Frank Rizzo]

At the risk of being burned at the stake...

Step 1. Add Microsoft.VisualBasic runtime to your references.
Step 2. Code, like you did in VB6

string s = Strings.Chr(64).ToString()
char c = Strings.Chr(64)