Koodi tulostaa hienosti alertiin muuttujan 23 ensimmäistä merkkiä ja 3 pistettä, vaikka muuttuja olisi annettu textareassa.
Mutta jos muuttujassa on useampi rivi JA ensimmäinen rivi on lyhyempi kun 23 merkkiä, ei tulostu mitään. Eli jos tulostettavaan alueeseen sattuu rivinvaihto, ei tapahdu mitään.
Onko mahdollista saada alertiin tulostettua useampirivinen teksti kokonaisuudessaan?
Tavoite on saada käyttäjälle tekstiä klikkaamalla popup tai vastaava, jossa olisi esitetty muuttujassa oleva teksti ja tämä popup tai vastaava suljetaan/kuitataan esim. painikkeella OK.
Mulla toimii ainakin näin...
<a href=" " onClick="alert('Note: <?php $row['texti']="1234567890\\n12345";echo substr($row['texti'],0,23)."..."; ?> ');">Check</a>
Edit - siis tällaista oletan sinun tarttevan.
Muista kokeilla myös muita erikoismerkkejä tekstissäsi. Esimerkiksi a"b>c"d'e>f'g↠h
rikkoo HTML-koodin, koska et käytä htmlspecialchars-funktiota, ja JavaScript-koodin, koska et enkoodaa tekstiä mitenkään. Lisäksi ääkköset voivat katketa keskeltä, jos käytät substr-funktiota Unicode-merkistön kanssa. Yleensä mb_substr oikeilla merkistöasetuksilla on parempi.
Järkevä vaihtoehto on laittaa teksti erilliseksi data-attribuutiksi. Tällöin riittää, että saat tekstin sallitussa muodossa PHP:stä HTML-attribuutiksi (eli ihan normaalisti htmlspecialchars-funktiolla).
<a href="#" onclick="alert('Note: ' + this.dataset.viesti); return false" data-viesti="<?= htmlspecialchars(mb_substr($teksti, 0, 23)."...") ?>" >Tästä saat ärsyttävän alert-ikkunan!</a>
Jos jostain syystä välttämättä haluat tunkea kaiken samaan, enkoodaa teksti ensin funktiolla json_encode JavaScript-merkkijonoksi ja sitten funktiolla htmlspecialchars HTML-koodiin sopivaksi.
<a href="#" onclick="alert('Note: ' + <?= htmlspecialchars(json_encode(mb_substr($teksti, 0, 23)."...")) ?>); return false" >Tästä saat ärsyttävän alert-ikkunan!</a>
Kiitoksia! Vastaus oli nopea ja tehokas. peran vastauksen kanssa ogelma on että täytyy asettaa tuo \\n.
Metabolixin vastaus toimi täysin. Sen 'ongelma' on ääkköset, jotka tulostuvat väärin, mutta tämä ei liene Ongelma koska käytetään yleensä englanninkieltä.
note on tässä aika pitkä
ja lisää tekstiä tässä
kolmas rivi
4 oli tyhjä, tämä 5
Kyllä ääkköset tulostuvat koodissani aivan oikein, jos ne ovat muuttujassa oikein. Eli jos asetat arvoksi esim. $teksti = "åäö", tämä tulostuu täysin oikein kummallakin ratkaisutavallani.
Kannattaa opetella nettisivujen teosta sellainen perusasia, että data muutetaan tulostettavaan muotoon (kuten HTML-muotoon) vain tulostusvaiheessa. On nyt täysin oma syysi, jos tunget muuttujiin HTML-koodia valmiiksi. HTML-koodin katkaisu substr-funktiolla (kuten myös alkuperäinen yrityksesi tekee) ei varmasti ole toimiva ratkaisu, koska tuossa saatat tuottaa tulokseksi vaikka tekstin "12345678901234567890&au", jossa ä:tä tarkoittava ä katkeaa kesken. (Kun etsit tällaisia vikoja, katso selaimesta sivun lähdekoodia, älä näkyvää sivua.)
Purkkaratkaisuna voit tietenkin vaikka muuntaa HTML-muotoisen tekstin ensin tavalliseksi tekstiksi funktiolla html_entity_decode ja vasta sitten käyttää antamiani ratkaisuja.
Tässä taitaakin olla niin että merkit koodataan jo muuttujaan sisäänkirjoitusvaiheessa tietoturvasyistä. Ettei siis muuttujaan voisi kirjoittaa ihan mitä tahansa.
Lisäys:
<a href="#" onclick="alert('Note: ' + this.dataset.viesti); return false" data-viesti="<?= $row['texti'] ?>" >Check</a>
Tämä toimiikin täydellisesti.
Kiitos ja kumarrus avusta.
mercier kirjoitti:
Tässä taitaakin olla niin että merkit koodataan jo muuttujaan sisäänkirjoitusvaiheessa tietoturvasyistä. Ettei siis muuttujaan voisi kirjoittaa ihan mitä tahansa.
Tuo on epälooginen ja vaarallinen ajatusmalli. Mitä haittaa, että muuttujaan tai tietokantaan tulee käyttäjän syöttämää tekstiä ilman HTML-käsittelyä? Ei mitään! Tieto ei ole vaarallista. Vaaraksi on vain tiedon väärä käyttö.
”Koodaaminen” eli htmlspecialchars on selvintä ja loogisinta tehdä tulostusvaiheessa eli juuri sillä hetkellä, kun teksti pitää laittaa HTML-koodin sekaan. Sivustollasi tulee luultavasti aina olemaan tietoa, jonka käsittelet näin vasta tulostusvaiheessa. Jos jotkin tiedot on käsitelty aiemmin ja toisia ei, todennäköisesti jossain kohti teet virheen ja aiheutat sivustollesi joko XSS-tietoturva-aukon tai tuollaisen ä-bugin, jonka äsken sait aikaan.
OK. Tulipa perehdyttyä tuohonkin.
Aihe on jo aika vanha, joten et voi enää vastata siihen.