Re: lost mysql root password
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
> >aaryal@foresightint.com
>
> --
> 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
aaryal@foresightint.com
Reply to: