Keskustelu: Nettisivujen teko: Str_replace

Heippa

Minulla on kerrassaan omituinen ongelma:
Jos käyttäjä lähettää viestin:

Moikka!
Mitä kuuluu?

Niin sen kuuluisi mennä viestit.txt tiedostoon näin:
lähettäjä|aika|Moikka!<br>Mitä kuuluu?|id, mutta jos viestissä on enter lyönti se meneekin:
lähettäjä|aika|Moikka!
<br>Mitä kuuluu?|id
Viestin editoiminen admin paneelissani on mahdotonta, koska jos sillä tallentaa tuon, niin se luo eri viestit joka rivistä.
Ainoa rivinvaihto korvaus on seuraavan lainen: $viesti = str_replace("\n", "<br>", $viesti);

Mikäköhän on ongelmana? :O

<?php
$viesti = "eka\ntoka\nkolmas";
$viesti = str_replace("\n", "<br>", $viesti);
echo $viesti;
?>

Tulostaa:

eka<br>toka<br>kolmas

Kuten pitääkin. Näytä enemmän koodia kuin tuo yksi rivi.

Aika pitkä, ja joissain on turhaa, mutta toivottavasti saatte selvää.

EDIT: Selasin tuon moneen kertaan läpi, mutta en löytänyt kohtaa joka tekisi tämän virheen.
Siksi kukaan varmaan ei ole vielä vastannut tähän, koska ei itsekkään löytänyt :o

Ootko kokeillut tuon str_replacen tilalla käyttää nl2br() -funktiota? Jos siellä on vaikka muun tyyppisiä rivinvaihtoja kuin pelkkiä \n.

Olethan varmistanut, ettet jostain kummasta syystä saa CR LF:ää pelkän LF:n sijasta? Elikkä kokeile:

$viesti = str_replace(array("\n", "\r"), array('<br>'), $viesti);

Näin ei kylläkään pitäisi missään tapauksessa käydä, mutta varmistetaan nyt kuitenkin... tätä ei tietty kannata jättää lopulliseen koodin, ainoastaan testata (ja samalla vähän esitellä str_replacen toisenlaista käyttötapaa).

Eikös lomakedatassa ole nimenomaan CR LF eli "\r\n" rivinvaihtona?

Yksi tapa kiertää tuo ongelma (ja monta muutakin kuten |-merkki viestissä) on tallentaa data enkoodattuna vaikkapa funktiolla rawurlencode tai base64_encode. Tietenkin se täytyy myös purkaa vastaavalla decode-funktiolla.

Merri kirjoitti:

$viesti = str_replace(array("\n", "\r"), array('<br>'), $viesti);

Juu tämä oli se syy. :)

Metabolix: minulla on vahva muistikuva siitä, että sieltä pitäisi tulla aina pelkkä LF. Toisaalta palvelinsoftalla (ja/tai sen asetuksilla) voi olla vaikutusta asiaan. Ehkä pitäisi testailla ja katsoa mitä saa, nyt vaan ei voi (ja väsymys painaa kun pääsee töistä).

Eikös tuo rivinvaihdon merkintätapa riipu clientin käyttöjärjestelmästä? Näin ainakin joskus olen itse väittäny, eikä tuota väitettä ainakaan silloin kukaan kumonnut :)
https://www.ohjelmointiputka.net/keskustelu/8876-rivinvaihdot-tiedoston-muokkauksessa#v74924

ajv kirjoitti:

Eikös tuo rivinvaihdon merkintätapa riipu clientin käyttöjärjestelmästä? Näin ainakin joskus olen itse väittäny, eikä tuota väitettä ainakaan silloin kukaan kumonnut :)

No nyt kumoan, ei ainakaan suoraan tule "käyttiksen" riviaihdot.

Windowsin Firefoxilla tulee CR+LF ja samoin FreeBSD:n Lynxillä tulee CR+LF

Jos joku haluaa testata jollain muulla, niin tuossa on sivu, jossa on tekstilaatikko. Siihen kun laittaa rivinvaihdon ja painaa "Testaa" painiketta, niin se näyttää mitä "ascii"-merkkejä laatikossa oli. Eli omissa testeissä rivinvaihdosta tuli 13, 10,

(Testiohjelman lähdekoodi on myös nähtävillä)

En ehdi testailla, joten onko DOCTYPEllä ja/tai UTF-8:n määrittelemisellä vaikutusta?

HTTP/1.1 speksin mukaan kaikkia vaihtoehtoja (CR+LF, tai pelkkä CR tai pelkkä LF) pitää tukea siirrettävässä sisällössä, mutta HTTP-sanomissa itsessään täytyy käyttää CR+LF:ää:

lainaus:

2.3.1. Canonicalization and Text Defaults

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. In addition, if the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. 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).

Eli jos käytetään merkistöä jossa ei ole CR:ää tai LF:ää normaaleilla paikoilla 13 ja 10, niin sitten käytetään ko. merkistön CR ja LF -merkkejä. Eli UTF8:n kohdalta tilanne on sama kuin Latin - ja ascii-merkistöissä.

Eikös toi nl2br() aja saman asian ku toi eka str_replace?