String variable read from Mysql DB + echo = Newline problem

[weirdstuff]

Hi. I have this simple code:

=============== =============== =============
->Database query here

(.. some code)

$row=mysql_fetc h_array($res);

(...)

$formatting2 = $row['formatting2"];

(..)

//Echo variable from DB
echo "$formattin g2";

$formatting2 = "USERNAME: %1\$s \r\nSERIAL: %2\$s \r\n\r\n";
//Echo same string - this time from an "inline" variable
echo "$formattin g2";
=============== =============== =============

Ok, maybe that was overly complicated. I hope you follow anyway. Whats
happening here is that I am getting a formatted string from a database
which I throw in a variable. What you see here is my test case to
visualize the problem. Now, when I echo this variable or pass it to
printf/sprintf then I get a different result than if I "manually"
create the variable inline in my php script.

So, the first echo $formatting2 there will output:

USERNAME: %1$s \r\nSERIAL: %2$s \r\n\r\n

whilst the second shows the newlines correctly. Also printf/sprintf
barfs if I pass the string I got from the DB.

What the heck is going on here? Database returning some strange string
format?
Thanks :)

Arni Johannesson

[Jerry Stuckle]

weirdstuff wrote:

Hi. I have this simple code:

=============== =============== =============
->Database query here

(.. some code)

$row=mysql_fetc h_array($res);

(...)

$formatting2 = $row['formatting2"];

(..)

//Echo variable from DB
echo "$formattin g2";

$formatting2 = "USERNAME: %1\$s \r\nSERIAL: %2\$s \r\n\r\n";
//Echo same string - this time from an "inline" variable
echo "$formattin g2";
=============== =============== =============

Ok, maybe that was overly complicated. I hope you follow anyway. Whats
happening here is that I am getting a formatted string from a database
which I throw in a variable. What you see here is my test case to
visualize the problem. Now, when I echo this variable or pass it to
printf/sprintf then I get a different result than if I "manually"
create the variable inline in my php script.

So, the first echo $formatting2 there will output:

USERNAME: %1$s \r\nSERIAL: %2$s \r\n\r\n

whilst the second shows the newlines correctly. Also printf/sprintf
barfs if I pass the string I got from the DB.

What the heck is going on here? Database returning some strange string
format?
Thanks :)

Arni Johannesson

Arni,

No, this is operating as expected.

In PHP strings, "\n" is a newline character. However, when read in from
an external source, these are the characters "backslash" and "en". The
equivalent in PHP would be "\\n" - the backslash is escaped and the
letter "n" follows.

But this is how it should be. External data should *never* be language
dependent - what happens if, for instance, you wanted the characters
blackslash and en in some text? For PHP you'd use "\\n", but for COBOL
the data would have to be "\n".

So, what you have to do is change your formatting characters. Replace
"\\n" with "\n" and "\\r" with "\r", for instance.

It should resolve your problem.

Or, alternatively, put the actual characters themselves in the database.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[weirdstuff]

Errr, what? :)

Ok I had figured that a backslash was being added when I read the
string from DB, but all my attempts of correcting that have failed.
What we have here is a case where knowing how the output is formatted
_exactly_ is very important. So it would be nice to be able to
"manually" format stuff like newlines and breaks.

Now, your suggestions:

So, what you have to do is change your formatting characters. Replace
"\\n" with "\n" and "\\r" with "\r", for instance.
The string already has single backslash in the database. If I add
another "just for fun" I just get two in the output. If I then do a
stripslashes() on one or the other then that doesn't help either.
Or, alternatively, put the actual characters themselves in the database.

Thats exactly what I'm trying not to do.
So we can agree that the problem is when I am getting the string from
the database. Then PHP (or MySQL?) does some funkyness to the string
variable which makes PHP think that \n means it should print
"backslash" and "en"

Jolly good show. Now lets fix it! :)

[Jerry Stuckle]

weirdstuff wrote:

Errr, what? :)

Ok I had figured that a backslash was being added when I read the
string from DB, but all my attempts of correcting that have failed.
What we have here is a case where knowing how the output is formatted
_exactly_ is very important. So it would be nice to be able to
"manually" format stuff like newlines and breaks.

Now, your suggestions:

So, what you have to do is change your formatting characters. Replace
"\\n" with "\n" and "\\r" with "\r", for instance.

The string already has single backslash in the database. If I add
another "just for fun" I just get two in the output. If I then do a
stripslashes() on one or the other then that doesn't help either.

Or, alternatively, put the actual characters themselves in the database.

Thats exactly what I'm trying not to do.
So we can agree that the problem is when I am getting the string from
the database. Then PHP (or MySQL?) does some funkyness to the string
variable which makes PHP think that \n means it should print
"backslash" and "en"

Jolly good show. Now lets fix it! :)

Please read it again. Replacing "\\n" with "\n" will not add another
backslash. It will convert the backslash and en to a newline character.

You really only have two choices. Either put the characters themselves
in the database, or put something representing the characters in the
database and substitute after you read them out.

And BTW - you cannot exactly control formatting on the user's browser.
All you can do is recommend formatting. If you want exact, create a PDF.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[weirdstuff]

Alrighty cool. Thanks Jerry. I can be a bit slow sometimes ;)

I'll follow your suggestions. I think the replace option will be the
way to go.

PS: The output is read by remote automated systems which I have no
control over. Thus the stringent formatting rules.

Again, thanks...!