Chr()

  • Thread starter Thread starter M K
  • Start date Start date
M

M K

I am wondering where I could find a table of the byteCodes
for Chr. I get all confused with ASCII, ANSI and UTF, so I
was wondering if there was a resource that cleared this
all up. Specifically, I wanted to know the max int I could
use with Chr. Or in other words, how many characters can
Chr access. I work in VB.Net
 
Hi Mark,

The number of characters depends on the code page set for the current thread
(which I believe defaults to the one specified in the Control Panel's
Regional Settings). You can find out this value by querying the

System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage

property.

Most of the code pages are single-byte and therefore the range of accepted
values will be 0-255. For the double-byte ones (e.g. Eastern Asian
languages), the range will be -32768 through 65535, but the negative
sub-range is mainly for VB6 compatibility and you can think of it as
0-65535 - the negative values will be mirrored to those above 32768.
 
ASCII is 0-255. When you get into unicode, however, you have 64k worth of
possibilities. You can find ASCII and Unicode charts on the web.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************
 
Cowboy (Gregory A. Beamer) said:
ASCII is 0-255.
Click to expand...

No it's not. It's 0-127, or even 32-127 depending on how strict you
are. There are various 8-bit encodings which share values 0/32-127 with
ASCII, but that's a different matter.
When you get into unicode, however, you have 64k worth of
possibilities. You can find ASCII and Unicode charts on the web.
Click to expand...

Indeed, and any "ASCII" chart which claims to include values over 127
should be taken with a pinch of salt.
 
One other good resource, M K, is the book "Visual Basic .NET Text
Manipulation Handbook: String Handling and Regular Expressions" by Paul
Wilton, et al.
 
I stand corrected. I was thinking byte and forgot about the non-printing
characters 0 (null char) through 31. I also neglected the 128 - 255, which
was set aside for "your own use". The fact so many different "standards"
came out made Unicode necessary.

This is a little routine to use for ASCII (and beyond):

using System;

namespace CSharpConsole
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
for(int i = 0;i<256;i++)
{
char currentChar = (char)i;
Console.WriteLine("{0} = {1}", i, currentChar.ToString());
}
Console.Read();
}
}
}

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************
 
The initial goal was to elminate duplicate characters in Chinese, Japanese
(and Korean). The initial size was 16 bits, or 2 bytes, which yields 64k
characters. Today, there are a variety of "Unicode" encodings, which lead to
a variety of numbers of characters. As such, stating 64k is an
oversimplification. I will yield. :-)

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************
 
LOL. Sorry to be pedantic. <g>

Cowboy (Gregory A. Beamer) said:
The initial goal was to elminate duplicate characters in Chinese, Japanese
(and Korean). The initial size was 16 bits, or 2 bytes, which yields 64k
characters. Today, there are a variety of "Unicode" encodings, which lead to
a variety of numbers of characters. As such, stating 64k is an
oversimplification. I will yield. :-)

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************
Click to expand...
 
I guess to clarify (I hope you can see how I have been
confused) I wish to create code that generates every
possible string combination using letters and numbers,
including upper case chars up to 8 chars long.
So 0-9, a-z, A-Z.
From 1 char to 8 chars long.
Any ideas?
 
Um, do you know how many strings that will be? If you only include a-z, A-Z
and 0-9, that's 62 different characters. For example, if you want to just
do the eight-character permutations, like

00000001
00000002
00000003
....
ZZZZZZY
ZZZZZZZ

I believe that translates to 8 ^ 62, or 9.80797146 × 10^55, different
permutations. (And that doesn't include the one-character permutations, two
character permutations, ... seven-character permutations.)

Your computer will have to crank a very long time to complete that task --
we'll probably be long dead by then. <g> You might want to consider a
different approach.
 
Correction -- it will be 62 ^ 8 (about 200 trillion) permutations. That's
still far more than can be easily computed.

Also, I trust that this isn't for something nefarious, like a password
cracking tool.


----- Original Message -----
From: "Robert Jacobson" <[email protected]>
Newsgroups: microsoft.public.dotnet.framework
Sent: Tuesday, October 21, 2003 2:04 PM
Subject: Re: Chr()
 
M K said:
I guess to clarify (I hope you can see how I have been
confused) I wish to create code that generates every
possible string combination using letters and numbers,
including upper case chars up to 8 chars long.
So 0-9, a-z, A-Z.
From 1 char to 8 chars long.
Any ideas?
Click to expand...

Every possible combination up to 8 characters is going to take a very
long time to generate - there are 218340105584896 combinations (62^8).
Do you really have enough time to generate them all? If not, what
implications does that have for what you're trying to do?

(If you're trying password cracking, I sincerely hope it's for entirely
benign purposes.)
 
M K said:
I am sincere in stating that I am not involved in password
cracking, spam, or hacking. I was simply interested in
testing a theory.

What I was considering would actually be more involved
than simply generating all those strings.

MD5 and SHA1 both use a 'one way' algorithm. You can't
just run the encrypted string through the algorithm again
to get the original string. However, an original string
would always generate the same encrypted string.

I wanted to see if this was true, because if you did go
through all those permutations, and developed a dictionary
you could theoretically look at the encrypted string,
compare it to the table, and find the original string.
Click to expand...

Yes, if you had a big enough lookup table, this would be possible. It
could be made much harder, however, using salting. This is the process
of adding a few random characters to the start of the given password
before running it through the one-way transform. You put the same
characters at the start of the result as well, so that the process is
repeatable. For instance:

password=dont_tell_anyone (entered by user)
salt=xyz (randomly generated)
before transform=xyzdont_tell_anyone
after transform=123kjhd123dsf456
store in database as=xyz123kjhd123dsf456

When you check the password, you just ask the user to enter their
password, add the salt which appears in the database to the front of
it, and then transform the result.

To crack the result, you'd effectively need a table for all
combinations 62^(password length+salt length) instead of just
62^(password length) - and seeing as the salt could be as long as the
system wants it to be, that basically makes it entirely impractical to
dictionary attack it, even if the password itself isn't very long.
 
Back
Top