[samandhi]

hmmmm maybe this?

You can find the following bitmask definitions in `m_ctype.h':

#define _U 01 /* Uppercase */
#define _L 02 /* Lowercase */
#define _N 04 /* Numeral (digit) */
#define _S 010 /* Spacing character */
#define _P 020 /* Punctuation */
#define _C 040 /* Control character */
#define _B 0100 /* Blank */
#define _X 0200 /* heXadecimal digit */

The ctype[] entry for each character should be the union of the applicable bitmask values that describe the character. For example, 'A' is an uppercase character (_U) as well as a hexadecimal digit (_X), so ctype['A'+1] should contain the value:

_U + _X = 01 + 0200 = 0201

Closest I could find.. No binary that I could see... This doc is in the \doc folder in your MySQL directory....

edit:This might be useful to you check it out:

Binary values such as 0xFFDF now are assumed to be strings instead of numbers. This fixes some problems with character sets where it's convenient to input a string as a binary value. With this change, you should use CAST() if you want to compare binary values numerically as integers:
mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER);
-> 0

If you don't use CAST(), a lexical string comparison will be done:
mysql> SELECT 0xFEFF < 0xFF;
-> 1

Using binary items in a numeric context or comparing them using the = operator should work as before. (The --new option can be used from 4.0.13 on to make a 4.0 server behave as 4.1 in this respect.)
For functions that produce a DATE, DATETIME, or TIME value, the result returned to the client now is fixed up to have a temporal type. For example, in MySQL 4.1, you get this result:
mysql> SELECT CAST("2001-1-1" as DATETIME);
-> '2001-01-01 00:00:00'

In MySQL 4.0, the result is different:
mysql> SELECT CAST("2001-1-1" as DATETIME);
-> '2001-01-01'

DEFAULT values no longer can be specified for AUTO_INCREMENT columns. (In 4.0, a DEFAULT value is silently ignored; in 4.1, an error occurs).
LIMIT no longer accept negative arguments. Use 18446744073709551615 instead of -1.
SERIALIZE is no longer a valid option value for the sql_mode variable. You should use SET TRANSACTION ISOLATION LEVEL SERIALIZABLE instead. SERIALIZE is no longer valid for the --sql-mode option for mysqld, either. Use --transaction-isolation=SERIALIZABLE instead.
All tables and string columns now have a character set. See section 9 National Character Sets and Unicode. Character set information is displayed by SHOW CREATE TABLE and mysqldump. (MySQL versions 4.0.6 and above can read the new dump files; older versions cannot.)
The table definition format used in `.frm' files has changed slightly in 4.1. MySQL 4.0 versions from 4.0.11 on can read the new `.frm' format directly, but older versions cannot. If you need to move tables from 4.1 to a version earlier than 4.0.11, you should use mysqldump. See section 4.9.7 mysqldump, Dumping Table Structure and Data.
If you are running multiple servers on the same Windows machine, you should use a different --shared_memory_base_name option on all machines.
The interface to aggregated UDF functions has changed a bit. You must now declare a xxx_clear() function for each aggregate function XXX().