[PHP] data binnen een <pre> laten zien met enters.

[Verwijderd]

Hoe moet ik dat doen?

ik heb al \r\n \n etc gebruikt maar wanneer ik dat doe krijg ik geen enters ...

stel ik heb een text

bladediebla
test
ik wil meer

in php staat dit in 1 string --> bladediebla test ik wil meer

hoe kan ik dat in een <pre> tag onderelkaar laten zien.

ik krijg dus bv dit uit een vardump maar zie geen <br's> etc!

PHP:

<?<pre>array(2) {  [0]=>  array(13) {    [0]=>    string(9) "%photoid%"    [1]=>    string(4) "%id%"    [2]=>    string(9) "%photoid%"    [3]=>    string(7) "%photo%"    [4]=>    string(4) "%id%"    [5]=>    string(9) "%photoid%"    [6]=>    string(4) "%id%"    [7]=>    string(9) "%photoid%"    [8]=>    string(7) "%width%"    [9]=>    string(8) "%height%"    [10]=>    string(6) "%size%"    [11]=>    string(8) "%photoX%"    [12]=>    string(8) "%photoY%"  }  [1]=>  array(13) {    [0]=>    string(7) "photoid"    [1]=>    string(2) "id"    [2]=>    string(7) "photoid"    [3]=>    string(5) "photo"    [4]=>    string(2) "id"    [5]=>    string(7) "photoid"    [6]=>    string(2) "id"    [7]=>    string(7) "photoid"    [8]=>    string(5) "width"    [9]=>    string(6) "height"    [10]=>    string(4) "size"    [11]=>    string(6) "photoX"    [12]=>    string(6) "photoY"  }}</pre>?>

dus zonder \r\n, \n, <br> etc!

dat wil ik dus ook maken maar dan zonder een vardump

[Dennis]

code:

<br />

[Verwijderd]

Op zondag 28 april 2002 13:20 schreef ddc het volgende:

code:

<br />

idd erg , dat is dus niet wat ik bedoel, heb de vraag nog ff wat duidelijker gemaakt

[Freak_NL]

In HTML (dus ook <pre>) worden 0x0A en 0x0D (\n\r) genegeerd, de beste manier om tussen <pre> tags linebreaks te krijgen is gewoon nl2br () over je string heen halen.

[nulkelvin]

Op zondag 28 april 2002 13:50 schreef Freak_NL het volgende:
In HTML (dus ook <pre>) worden 0x0A en 0x0D (\n\r) genegeerd, de beste manier om tussen <pre> tags linebreaks te krijgen is gewoon nl2br () over je string heen halen.

Dat klopt niet, tussen <pre> tags worden juist die \n\r en extra spaties niet genegeerd, dat is juist waarvoor die <pre> tags gemaakt zijn.

voor meer info kijk ff hier: http://www.w3.org/TR/html401/struct/text.html#h-9.3.4

edit:
linkje toegevoegd

[Freak_NL]

Na 3 mokken koffie moet ik helaas concluderen dat ik fout zit. gomennasai ^^;; (m'n excuses)

Na dezelfde 3 mokken koffie zie ik overigens ook het probleem niet.

Je wilt je eigen vardump () maken, maar je \n\r worden niet gezien in <pre>? Probeer het zo eens:

PHP:

<?$ln = chr(13).chr(10);// 13 en 10 -> 0x0D en 0x0A -> \n\r -> linebreak// plak voor elke "enter" een $ln// bijvoorbeeld achter deze $string:$string .= $ln;?>

[nulkelvin]

Op zondag 28 april 2002 13:17 schreef xtentic het volgende:
Hoe moet ik dat doen?

ik heb al \r\n \n etc gebruikt maar wanneer ik dat doe krijg ik geen enters ...

stel ik heb een text

bladediebla
test
ik wil meer

in php staat dit in 1 string --> bladediebla test ik wil meer

hoe kan ik dat in een <pre> tag onderelkaar laten zien.
[...]

Ik denk toch echt dat je hier naar toe moet:

code:

<pre>
bladediebla \n\r test  \n\r  ik  \n\r wil  \n\r meer
</pre>

of zit ik nou weer fout?

[brammetje]

zonder \r\n kan je geen regel afbreken... Gebruik dus gewoon

echo "\r\n"; voor een nieuwe regel en
echo "\t"; voor een tab...

let wel op dat je dubbele quotes gebruikt, en geen enkele!

[Verwijderd]

Op zondag 28 april 2002 14:43 schreef Freak_NL het volgende:
Na 3 mokken koffie moet ik helaas concluderen dat ik fout zit. gomennasai ^^;; (m'n excuses)

Na dezelfde 3 mokken koffie zie ik overigens ook het probleem niet.

Je wilt je eigen vardump () maken, maar je \n\r worden niet gezien in <pre>? Probeer het zo eens:

PHP:

<?echo "door quote verneukt script";?>

dat is um, dat werkte wel

maar vind het nogmaals vaag dat \r\n en andere dingen gewoon niet (goed) werken.

[ACM]

Op zondag 28 april 2002 15:37 schreef xtentic het volgende:
maar vind het nogmaals vaag dat \r\n en andere dingen gewoon niet (goed) werken.

Die zullen wel goed werken, maar je moet ze wel goed toepassen. Het is heus niet ineens zo dat het nu bij jou niet werkt, terwijl het voor ieder ander wel werkt...

[Verwijderd]

Op zondag 28 april 2002 17:54 schreef ACM het volgende:

[..]

Die zullen wel goed werken, maar je moet ze wel goed toepassen. Het is heus niet ineens zo dat het nu bij jou niet werkt, terwijl het voor ieder ander wel werkt...

da zeg ik niet dat het bij iedereen wel of niet werkt. maar vind het gwoon vaag dat ut niet werkt mja 't probleem is opgelost

[Soultaker]

Waarom trouwens dat gedoe met die carriage returns? Een enkel newline-character ('\n') heeft ook al het beoogde resultaat.

[Freak_NL]

Standaard eigenlijk.. In Win32 omgevingen volstaat een 0x0A cq \n, maar verschillende platforms/OS'en (Win32, Un*x, Mac, alle 3 verschillend) gebruiken verschillende standaarden t.o.v. linebreaks.

0x0D 0x0A is blijkbaar het meest vriendelijke/crossplatform

[Verwijderd]

Op zondag 28 april 2002 18:06 schreef Soultaker het volgende:
Waarom trouwens dat gedoe met die carriage returns? Een enkel newline-character ('\n') heeft ook al het beoogde resultaat.

zou je dat in een werkend-source kunnen bevestigen?

[ACM]

Op zondag 28 april 2002 18:24 schreef xtentic het volgende:
zou je dat in een werkend-source kunnen bevestigen?

Dat bevestig ik voor hem, neem het maar van mij aan dan

\n en \r\n worden veelvuldig door elkaar gebruikt op het web en volgens mij is de standaard zelfs \n (internet begon tenslotte op unix platforms, zoals heel tcp/ip)

[Verwijderd]

Op zondag 28 april 2002 18:27 schreef ACM het volgende:

[..]

Dat bevestig ik voor hem, neem het maar van mij aan dan

\n en \r\n worden veelvuldig door elkaar gebruikt op het web en volgens mij is de standaard zelfs \n (internet begon tenslotte op unix platforms, zoals heel tcp/ip)

Dan is het goed

[Verwijderd]

Op zondag 28 april 2002 18:24 schreef xtentic het volgende:

[..]

zou je dat in een werkend-source kunnen bevestigen?

PHP:

<?echo "<pre>";for($i=0;$i<100;$i++)echo "$i\n";echo "</pre>";?>

[tomato]

ACM: \n en \r\n worden veelvuldig door elkaar gebruikt op het web en volgens mij is de standaard zelfs \n (internet begon tenslotte op unix platforms, zoals heel tcp/ip)

In de HTTP standaar wordt volgens mij gesproken over \r\n en wellicht in andere standaarden ook.

Maar je hebt gelijk, de meeste tools gaan goed om met alle varianten (\n, \r en \r\n).

[ACM]

Op zondag 28 april 2002 19:10 schreef tomato het volgende:
In de HTTP standaar wordt volgens mij gesproken over \r\n en wellicht in andere standaarden ook.

* ACM vindt de n hetbeste
carriage return gebruiken we al niet meer sinds de typemachines de deur uit zijn...

En aangezien je een nieuwe regel wilt beginnen -> newline char -> \n

[tomato]

ACM: * ACM vindt de n hetbeste
carriage return gebruiken we al niet meer sinds de typemachines de deur uit zijn...

En aangezien je een nieuwe regel wilt beginnen -> newline char -> \n

Ik heb het nog even nagezocht en ik herinnerde het mij goed:

Zoals in RFC 2616 (HTTP/1.1) te zien is wordt in HTTP CRLF gebruikt. Zoals je hier kunt nalezen wordt met CRLF de \r\n sequence bedoeld

[ACM]

Op zondag 28 april 2002 19:37 schreef tomato het volgende:
Zoals in RFC 2616 (HTTP/1.1) te zien is wordt in HTTP CRLF gebruikt.

Jammer

[Soultaker]

Op zondag 28 april 2002 18:24 schreef xtentic het volgende:
zou je dat in een werkend-source kunnen bevestigen?

Enigszins ter overvloede: ik heb diverse web/CGI applicaties geschreven in C, PHP, Perl en Clean en ik kan me niet herinneren OOIT carriage returns te hebben gebruikt in m'n uitvoer. Ook nooit klachten gehad dat 't niet zou werken trouwens.

Op zondag 28 april 2002 19:37 schreef tomato het volgende:
Zoals in RFC 2616 (HTTP/1.1) te zien is wordt in HTTP CRLF gebruikt. Zoals je hier kunt nalezen wordt met CRLF de \r\n sequence bedoeld

Als we dan toch RFC 2616 gaan quoten:

When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP.

Maar voor de volledigheid:

This flexibility regarding line breaks applies only to text media in the entity-body; a bare CR or LF MUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries)

Kortom, een enkel newline character (equivalent met LF in de RFC) in de HTTP request body is op geen enkele manier minder geschikt, legaal of aangeraden dan een CR LF pair.

[tomato]

Soultaker: Kortom, een enkel newline character (equivalent met LF in de RFC) in de HTTP request body is op geen enkele manier minder geschikt, legaal of aangeraden dan een CR LF pair.

Je hebt gelijk....maar (and now for the tricky part ) bedenk dat je in veel omgevingen niet in kunt staan voor de volledige message body.

Zoals je al quote ziet de HTTP standaard het liefst een consistent gebruik van de CRLF sequence, de CR, of de LF. Denk eraan dat bijvoorbeeld Apache wel eens een paar headers kan toevoegen, of bijvoorbeeld PHP.
Je kunt dan zelf wel leuk altijd '\n' gebruiken, maar als andere onderdelen van je omgeving header fields met '\r\n' toevoegen ben je nog nergens

[Soultaker]

Op maandag 29 april 2002 02:11 schreef tomato het volgende:
bedenk dat je in veel omgevingen niet in kunt staan voor de volledige message body.

Zoals je al quote ziet de HTTP standaard het liefst een consistent gebruik van de CRLF sequence, de CR, of de LF. Denk eraan dat bijvoorbeeld Apache wel eens een paar headers kan toevoegen, of bijvoorbeeld PHP.

Daarmee ondersteun je je eerste stelling niet. Headers hebben vrij weinig met de message body te maken. Die dingen mogen toch alleen maar door 'n CRLF pair begrensd worden.

Je kunt dan zelf wel leuk altijd '\n' gebruiken, maar als andere onderdelen van je omgeving header fields met '\r\n' toevoegen ben je nog nergens

Dat zegt niets. Zelfs als er situaties voorkomen (die ik dus toevallig niet tegenkomen ben) waarin de message body gewijzigd wordt, levert het gebruik van CRLF net zoveel problemen op wanneer enkele CR of LF karakters ingevoegd worden. Het is dus een kwestie van toeval of beide partijen die de inhoud bepalen toevallig dezelfde begrenzingssymbol gekozen hebben.

[tomato]

Ah excuses, ik las een en ander niet goed

Komt het er dus op neer dat je volgens de HTTP specificatie de verschillende message entiteiten moet scheiden met een CRLF sequence. Wat je binnen die entiteiten doet moet je zelf weten (en daar had jij het over met je quote).

Eens?


Ik drukte mij verder niet goed uit (wanneer ik message-body gebruikte). In ieder geval hoor je altijd \r\n te gebruiken wanneer je bijvoorbeeld vanuit je perl-script een header toevoegt:

code:

#!/usr/bin/perl

print "Content-type: text/html\r\n";

__END__

Message-body

Daar doelde ik op met consequent gebruik (dus als Apache een header-field toevoegt zal dat ook met \r\n gebeuren), maar dat was niet relevant (ik las verkeerd).

Waar je wel mag kiezen (maar consequent moet zijn) is binnen een entiteit (bijvoorbeeld de message-body), maar zoals jij al aangaf komt het eigenlijk niet voor dat andere applicaties daar ook nog aan gaan zitten sleutelen.

[Soultaker]

Op maandag 29 april 2002 02:59 schreef tomato het volgende:
Eens?

Mja, tot zover wel.

In ieder geval hoor je altijd \r\n te gebruiken wanneer je bijvoorbeeld vanuit je perl-script een header toevoegt:

code:

#!/usr/bin/perl
print "Content-type: text/html\r\n";

Nou, daar ben ik het nu weer niet mee eens. Dergelijke scripts (zoals ook andere externe applicaties) worden gewoonlijk via CGI uitgevoerd. Om dan maar weer even uit de CGI specificatie te quoten:

The output of scripts begins with a small header. This header consists of text lines, in the same format as an HTTP header, terminated by a blank line (a line with only a linefeed or CR/LF).

Zolang Perl scripts of andere programma's via CGI uitgevoerd worden, is het dus volledig legaal om headers ook met een enkel newline character te scheiden. Dat heb ik dan ook altijd zonder problemen gedaan.

Wanneer applicaties niet via CGI uitgevoerd worden, zal meestal een apart mechanisme beschikbaar zijn voor het uitvoeren van headers. In PHP is dat de header() functie, in mod_perl de header_out() request method. In de praktijk komt het dus zo goed als nooit voor dat je als applicatieprogrammeur (los van de webserver dus) CRLF pairs hoeft te versturen. Dat is ook wel zo netjes, aangezien die CRLF pairs een implementatiedetail van de transportatielaag vormen en voor 'hoger' gelegen applicaties geen betekenis hebben.