On Friday 03 March 2006 04:38 pm, Gene Heskett wrote: > On Friday 03 March 2006 17:08, anoop aryal wrote: > >On Friday 03 March 2006 03:12 pm, Matt Price wrote: > >> > do: > >> > > >> > select hex(User) from user where User LIKE 'root%'; > >> > > >> > > >> > that should give you the hex values of the characters that are > >> > there. > >> > > >> > > have all four. I guess there must be some white space in the > >> > > username somewhere. Is there an easy way to identify the > >> > > precise value of a mysql field (e.g. by dumping to a CSV file)? > >> > > I'd like to try to figure > >> > >> +----------------------------------+ > >> > >> | hex(User) | > >> > >> +----------------------------------+ > >> > >> | 726F6F74 | > >> | 726F6F74202020202020202020202020 | > >> | 726F6F74 | > >> | 726F6F74202020202020202020202020 | > >> > >> +----------------------------------+ > >> 4 rows in set (0.00 sec) > > Is that even encoded at all? That looks a bit like it would say > "root ", twice, in ascii to me. Look it up in an ascii table > for old 7 bit ascii stuff to be sure. > > >> thanks anoop! I guess those 02's are spaces then... Looks like > >> most of the user lines from my old db are corrupted in this way as > >> well. wierd. > > Not 02, but $20's, eg an ascii space char. > > >i would check the encoding being used vs. the encoding that was used > > when it was initially created. it sounds like you were using a > > wide_char encoding (eg. UTF-8) before and somehow has now reverted > > back to latin-1 or some other single char encodings. i'm not an > > expert on encodings etc.. know just enough to be dangerous. but if > > this is database wide, (look at char/varchar/text fields and they > > should all display this behavior), this is encoding related. on a > > wide char encoding (say utf-8), the database reserves multiple bytes > > per char not knowing what char it will need to save there. when you > > tell mysql that it's not wide char, it will just show you what it has > > - including the previously reserved bytes. it's odd that it's using > > x20 to pad data tho.
again, the database wide funkyness with char fields suggests encodings not lining up. after counting the chars in the output, it seems like it's reserving 4 bytes per char (strlen("root")*4) (i know utf-8 causes mysql to use three bytes per char), and because the later bytes (3 spaces per char) were uninitialized under old mysql config under, presumably, a different encoding - because in an encoding like UTF-8, ASCII chars are all 1 byte and therefore "root" is the first 4 bytes. the current mysql just spits out x20 for the uninitialized reserved chars?? if(strlen(newFieldValue) == strlen(oldFieldValue) * 4) { the tables were created using a variable wide chars encoding that supports up to 4 bytes per chars. but now are under the 'default' (latin-1?) encoding. } else { i dont' have enough encoding-fu to figure this out. } :) > > > >or something like that. > > > >> Thanks much for your help! > >> > >> matt > > > >-- > > > > > >anoop > >[EMAIL PROTECTED] > > -- > Cheers, Gene > People having trouble with vz bouncing email to me should add the word > 'online' between the 'verizon', and the dot which bypasses vz's > stupid bounce rules. I do use spamassassin too. :-) > Yahoo.com and AOL/TW attorneys please note, additions to the above > message by Gene Heskett are: > Copyright 2006 by Maurice Eugene Heskett, all rights reserved. -- anoop [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]