[LØST]Kontaktskjema, feil i script? ÆØÅ problem

[Habitats]

Hei

 

Jeg har laget et kontaktskjema script som som jeg skal bruke på en nettside jeg har laget. Selve skjemaet fungerer utmerket men om man skriver ÆØÅ blir det problemer, om du vet hva dette angår så går jeg ut ifra at du vet hvilke problemer jeg snakker om. I stedet for ÆØÅ så kommer det masse rare tegn. Jeg går ut ifra at det har noe charset/utf-8 å gjøre.

 

Jeg har følgende kode i header:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

 

Så jeg forstår ikke helt hvorfor det ikke fungerer. Ellers på siden så fungerer ÆØÅ utmerket.

 

Her er scripet:

<?php 

if ($_POST['submit'] == TRUE) {
$receiverMail = "[email protected]";
$name = stripslashes(strip_tags($_POST['name']));
$email = stripslashes(strip_tags($_POST['email']));
$subject = stripslashes(strip_tags($_POST['subject']));
$msg = stripslashes(strip_tags($_POST['msg']));
$ip = $_SERVER['REMOTE_ADDR'];
$msgformat = "From: $name ($ip)\nEmail: $email\n\n$msg";

if(empty($name) || empty($email) || empty($subject) || empty($msg)) {
echo "<h2>E-posten ble ikke send.</h2><p>Vær snill og fyll inn alle feltene</p>";
}
elseif(!ereg("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$", $email)) {
echo "<h2>E-posten ble ikke sendt</h2><p>E-posten er ikke gyldig.</p>";
}
elseif(mail($receiverMail, $subject, $msgformat, "From: $name <$email>")) {
echo "<h2>Eposten har blitt sendt!</h2><p>Vi takker for din henvendelse og du vil motta et svar så fort som mulig.</p>"; }
else {
echo "<h2>E-posten ble ikke sendt!</h2><p>Prøv igjen... Vis problemet fortsetter, er det noe feil med serveren.</p>";
}
}
else { ?>

<p>
<form method="post" action=""><br>
<label for="name">Ditt Navn:</label><br>
<input id="name" name="name" type="text" size="30" maxlength="40"><br>
<label for="email">Din Email:</label><br>
<input id="email" name="email" type="text" size="30" maxlength="40"><br>
<label for="subject">Emne:</label><br>
<input id="subject" name="subject" type="text" size="30" maxlength="40"><br>
</p>
<p>Melding:<br>
<label for="message"></label>
<textarea id="message" name="msg" cols="50" rows="6"></textarea>
</p>
<p>
<label for="submit"></label>
<input id="submit" class="button" type="submit" name="submit" value="Send!">
</p>
</form>

<?php } ?>

 

Takker for svar.

 

 

//hab

Endret 13. august 2008 av Habitats

[Flin]

mail() funksjonen er ikke altid like glad i UTF-8. Finnes løsninger på dette. Hvis du titter her så kan du finne flere løsninger. Hvis du googler "mail utf-8 php" eller noe sånt finner du sikkert flere.

[Ernie]

Korreksjon: Det er ikke mail() som er problemet her, det er hele språket. PHP er bygget opp rundt singlebyte ASCI-kompatible tegnsett, og da primært ISO-8859-1. UTF-8 er IKKE et singlebyte tegnsett, men dog ASCI-kompatibelt. At det er ASCI-kompatibelt er eneste grunnen til at det faktisk til en viss grad fungerer i PHP. Uannsett, UTF-8 er et multibyte tegnsett noe som vil si at hvert tegn kan ta alt mellom 1 og 4 byte (teoretisk sett mellom 1 og 6, men det finnes ikke «Unicode codepoints» over 10FFFD som tilsvarer 4 byte i UTF-8). Dette medfører at tegnsettet aldeles ikke er så enkelt å jobbe med som man er vant til, og dessverre er det omtrent ingen PHP-utviklere som fatter dette (jeg vil tippe over 90% ikke har snøring på problematikken). Å bruke UTF-8 i PHP helt uten videre er langt fra garantert sikkert, og er i praksis å anta at andre står for sikkerheten (dvs. nettleseren, databasen etc.).

 

Uannsett, i PHP har vi utvidelsen «mbstring» som tilbyr litt funksjonalitet for multibyte tegnsett (ink. UTF-8). Funksjoner som er verdt å merke seg er mb_check_encoding (et absolutt must på input), mb_internal_encoding (også et must) og en rekke str-funksjoner med multibyte-støtte (f.eks mb_strlen). I listen finner man også mb_send_mail(...). Uten at jeg hardnakket skal påstå det for sikkert vil den funksjonene være eksakt lik mail med unntak av at den setter header for encoding (som trådstarter har «glemt») og kjører dataene igjennom base64 (som trådstarter også har «glemt») hvilket både gjør dataene trygge for absurd utdatert programvare for mail (IMC anser all programvare for mail som ikke støtter Unicode og er laget/oppdatert i/etter 1999 for utdatert) og ikke minst vil sikre at ting blir vist korrekt (med mindre mail-klienten er håpløst utdatert).

 

Har man ikke mbstring så glemt å bruk UTF-8. Så lenge du ikke har et behov for annet enn norsk er det ulogisk å lage slikt trøbbel for seg selv ved å lagre ting som UTF-8. Både Norsk og PHP fungerer uproblematisk med ISO-8859-1.

Endret 13. august 2008 av Ernie

[Habitats]

Takker for fint innlegg Ernie.

 

Når sant skal sies driver jeg kun med web på hobbybasis og var faktisk ikke klar over dette med ISO-8859-1 vs UTF-8. Vet ikke helt hvorfor jeg bruker(brukte) UTF-8, fikk vel høre/lese et sted at det skulle passe best, uten noen videre forklaring.

 

Men skal fikse opp i dette nå å gå over til ISO-8859-1

[Ernie]

Vel, UTF-8/Unicode er utvilsomt fordelaktig/bedre. Det gir «uendelig» antall tegn og mulighet til å ha et tegnsett som støtter praktisk talt alt. Problemet er bare at verktøyet man bruker (PHP) ikke støtter det enda, og da er det ingen god ide å bruk det når man alikevel ikke benytter seg av fordelene UTF-8 og Unicode har.

[Habitats]

Ja ok, skjønner. Vet du om PHP vil få støtte for dette senere da, eller vil det aldri la seg gjøre grunnet det du nevnte i forrige post?

 

Slik som jeg ser det ser det ut som at UTF-8 er fremtiden, eller er jeg helt på jordet nå?

[shaker]

PHP 6 vil ha "native" støtte for unicode.

[Flin]

Greit nok at du har peiling Ernie, men jeg synes liksom at det blir litt overkill å legge ut hele begrunnelsen. Det er vel ikke nødvendig for å løse problemet? Greit at det er kjekt å vite, men man må se ann sitt publikum litt også.

[Ernie]

Greit nok at du har peiling Ernie, men jeg synes liksom at det blir litt overkill å legge ut hele begrunnelsen. Det er vel ikke nødvendig for å løse problemet? Greit at det er kjekt å vite, men man må se ann sitt publikum litt også.

Nei, det er ikke «overkill» med mindre du synes ubegrunnede utsagn ala «UTF-8 er best, bruk det» er okey og akseptabelt. Det er nødvendig for å skjønne hvorfor ting ikke fungerer og hvorfor det kan være en god ide å holde seg unna UTF-8 inntil videre. Endel bruker UTF-8 uten å egentlig vite at man må tenke og bruke forskjellige ting enn i forhold til singlebyte tegnsett man vanligvis bruker. UTF-8 krever en helt annen bevisthet enn f.eks ISO-8859-1, og det er forsåvidt det jeg forsøker å fremheve. Problemet i dette tilfellet er strengt tatt ikke bare at mail «feiler», men at man også er åpen for sikkerhetsproblemer i forhold til UTF-8 grunnet manglende validering. Input «encoded» som UTF-8 må kjøres igjennom mb_check_encoding på forhånd.

 

Forøvrig, det er aldeles ikke hele begrunnelsen. Den vil inkluderer ting som oppbygning av UTF-8 binært for å vise hvordan og hvorfor «non-shortes form» er farlig og kan lede til at uønskede ASCI-tegn havner inn i applikasjonen på tross av at man sjekker etter ASCI-tegnene.

 

 

Btw: mens jeg er inne på sikkerhet. Habitats, du bør sjekke at subject og from-adressen/navnet ikke inneholder «newline»/CRLF (\r\n). Dette kan brukes til å sette inn ekstra headere og potensielt gjøre at du sender ut SPAM (v.hj.a CC eller BCC).

[Peter]

Greit nok at du har peiling Ernie, men jeg synes liksom at det blir litt overkill å legge ut hele begrunnelsen. Det er vel ikke nødvendig for å løse problemet? Greit at det er kjekt å vite, men man må se ann sitt publikum litt også.

Skjønner definitivt ikke problemet.

Når du får beskjed om å gjøre noe annerledes vil du jo gjerne vite hvorfor?

 

Særlig i et språk som er så knotete når det kommer til encoding som PHP er.

[Habitats]

Nå var det vel strengt tatt jeg som hadde problemet, og jeg syntes det er flott at folk gir grunnlag for forklaringen sin. Man kan så klart bare bedt meg bytte charset, men jeg hadde aldri fått vite hvorfor.

 

Men ja, jeg ble noen erfaringer klokere av dette, takker for svar. Alt fungerer som det skal nå hvert fall

[shaker]

Input «encoded» som UTF-8 må kjøres igjennom mb_check_encoding på forhånd.

 

Jeg har ikke jobbet med PHP og UTF-8 før men kan man ikke bruke iconv for å filtrere bort deler som ikke er utf8?

 

$utf8 = iconv("utf-8", "utf-8//IGNORE", $input);

Endret 15. august 2008 av shaker

[Ernie]

Input «encoded» som UTF-8 må kjøres igjennom mb_check_encoding på forhånd.

 

Kan man ikke bruke iconv for å filtrere bort deler som ikke er utf8?

 

$utf8 = iconv("utf-8", "utf-8//IGNORE", $input);

Joda, det går jo det, men i teorien er det ikke en sjekk av tegnsett/«encoding», men en transformasjon mellom to tegnsett/«encoding»-er. Akkurat det gjør at du ikke direkte kan oppdage om strengen inneholdt ugyldige bytesekvenser i og med at du får en muligens modifisert streng ut fra funksjonen.

[shaker]

Ja det er sant