Re: lost mysql root password
- From: anoop aryal <aaryal@xxxxxxxxxxxxxxxx>
- Date: Fri, 3 Mar 2006 16:55:49 -0600
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@xxxxxxxxxxxxxxxx
--
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@xxxxxxxxxxxxxxxx
--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
- References:
- lost mysql root password
- From: Matt Price
- Re: lost mysql root password
- From: anoop aryal
- Re: lost mysql root password
- From: Gene Heskett
- lost mysql root password
- Prev by Date: pppd doesn't connect
- Next by Date: mail disaster
- Previous by thread: Re: lost mysql root password
- Next by thread: Re: lost mysql root password
- Index(es):
Relevant Pages
|
