Forum Replies Created
-
AuthorPosts
-
peterlaursen
Participantyou are right .. I'm confused now 🙁
hmmm .. I better shut up for a while and rethink it.
But it is not a wrong decoding in PHP. In is the input to php_decode() that is wrong.
And this happens somewhere between when it is logged and decoded.
peterlaursen
ParticipantI believe there is nothing special with your servers' response. My local php and the php at my webhost does exactly the same with the examples that you posted.
The php_encode() and php_decode() work together – with your examples and with Danish, German, Swedish, Spanish special characters. All the situations where WRITE with SQLyog/ SJA and HTTP-tunnelling fails. I have tested that on my local (php 5.1.1) and my webhost (php 4.4.2). Encoding and decoding again always returns the 'source'.
The 'SQLyog_encode()' and php_decode() does not work together in some special situations! I don't think Ritesh has the power to change (globally) php_decode(). But he can change SQLyog_encode(). And will have to. Or use something else than base64. But I don't believe that is necesary either!
Go ahead and finish your script. It is a wonderful exercise!
peterlaursen
Participantdon't ask me to do that 🙂 Everything that has the slightest resemblance of javascript …
But you are missing some PHP-tags, aren't you ??
I tried to add some around the IF-statement but looks like there is some error in there – PHP does not send anything to Apache when I test it on my local WAMP-stack.
Let Ritesh explain for himself, what he meant. But it does not HELP anyone just to state 'this is a bug with PHP'. Sounds like: 'Not my fault so I don't need to do anything'.
Wrong! He/We must find a solution! That was my point! 😎
And personally I don't believe in a bug with PHP here. Rather a bug somewhere else. Or an issue with base64-'dialects'. Or some kind of initialisation that must be done somewhere.
Hopefully he sleeps sweet now!. He is back at office in 6-7 hours from now!
peterlaursen
Participantyes .. do that! PHP is broken on my LINUX at the very moment, so I can't!
but encoding is being done from a compiled binary written in C (SQLyogEnt.exe and SJA.exe). That means that the encoding the written i C. So this code may as well be 'defect'.
It is too easy ('cheap' I would say) just to blame PHP here. and @Ritesh: that fires back on yourself, actually! You should not use it if it does not work! It is your decision to use it!
But I think a buggy C-code is responsible for this issue as well as for the failure to write national European characters (all non-English Latin1 -characters) with HTTP. PHP is used by millions of people everyday. That issue would have been found long before is it was an issue with PHP.
I STILL think a buggy C-code is responsible – and will continue to do so until proven otherwise! 🙄
peterlaursen
Participantpeterlaursen
Participanthowever PHP encode and decode match: try:
Code:'Pragmatic Unit Testing',
'rn',
'/images/sk_utc_small.jpg',
'29.95',
'2004-06-18 00:00:00')”);
echo $encode;echo “nn”;
$decode = base64_decode($encode);
echo $decode;?>
returns
Code:aW5zZXJ0IGludG8gcHJvZHVjdHMgdmFsdWVzKDExLA0KJ1ByYWdtYXRpYyBVbml0IFRlc3RpbmcnLA0K
w0KPC9wPicsDQonL2ltYWdlcy9za191dGNfc21hbGwuanBnJywNCicyOS45NScsDQonMjAwNC0wNi0xO
AwMDowMDowMCcp insert into products values(11, 'Pragmatic Unit Testing', ' ', '/images/sk_utc_small.jpg', '29.95', '2004-06-18 00:00:00')peterlaursen
ParticipantThis script:
Code:$decode = base64_decode (“aW5zZXJ0IGludG8gcHJvZHVjdHMgdmFsdWVzKDExLA0KJ1ByYWdtYXRpYyBVbml0IFRlc3Rpbmcn
A0K
J1xyXG48L3A JywNCicvaW1hZ2VzL3NrX3V0Y19zbWFsbC5qcGcnLA0KJzI5Ljk1JywNCicyMDA0LTA2LTE4IDAwOjAw
OjAwJyk=”);
echo $decode;
?>returns
Code:insert into products values(11, 'Pragmatic Unit Testing', 'rn
šœÉËB‰ÌŽKŽMIËB‰ÌŒ
L ‹LN Œ Œ ÊHowever this
Code:$decode = base64_decode ('VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==');
echo $decode;
?>does as php docs at http://www.php.net/manual/en/function.base64-decode.php say!
there are variations of base 64 http://en.wikipedia.org/wiki/Base64
peterlaursen
Participantlet me add that that if it is correct what I assume here that SQLyog simply counts the number of lines processed when importing it should display 'lines processed: xxxx' and NOT 'rows imported: xxxx'.
peterlaursen
ParticipantIt looks like — and /* */ are standards, # is a MySQL speciality.
http://dev.mysql.com/doc/refman/5.0/en/comments.html
http://dev.mysql.com/doc/refman/5.0/en/ans…f-comments.html
http://dev.mysql.com/doc/refman/5.0/en/portability.html
I have noticed that the (also C-style?)
// this is a comment
often works too as a comment when it start as the first cahracter of a line.
However it is undocumented, and probably should be avoided.
peterlaursen
ParticipantQuote:I *think* phpMyAdmin would also get confused with commenting such as thisI don't thinks so! The parsing is done by the server and not the client. Don't think that phpmyadmin attempts to parse either.
But it is true that the /* */ comments style is a C-impact on MySQL that is not originally a SQL comment – and probably does not conform with ANSI standards either.
Personally I don't care!
peterlaursen
Participant1st issue confirmed!
That also explains two issues I think.
1) in some text-editors (not Notepad but Textpad for instance) there is an empty line between each row of data.
2) when importing data SQLyog reports twice as may rows as there are.
What is the particular reason for the 2nd request?
peterlaursen
ParticipantFAQ done.
peterlaursen
ParticipantMySQL docs at http://dev.mysql.com/doc/refman/5.0/en/create-procedure.html
“The parameter list enclosed within parentheses must always be present. If there are no parameters, an empty parameter list of () should be used. Each parameter is an IN parameter by default. To specify otherwise for a parameter, use the keyword OUT or INOUT before the parameter name.
Note: Specifying a parameter as IN, OUT, or INOUT is valid only for a PROCEDURE. (FUNCTION parameters are always regarded as IN parameters.) “
peterlaursen
ParticipantQuote:What about a rename feature with use on own risk?I don't like that proposal! How ever I do realize that if your DB is at an ISP where you have only one DB available all the copying could be quite slow! However in this case it might fail anyway due to privilege issues.
peterlaursen
ParticipantThis has been asked before:
-
AuthorPosts