filter_var() resultaat komt niet overeen met verwachting

[MekZi]

Waarom komt het onderstaande niet overeen met mijn verwachting?

PHP:

<?php
$inputwaarde = 'â&#710;';
$sanitized = filter_var($inputwaarde, FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_HIGH);
    
echo 'De sanitized output: '.$sanitized."\n";
?>

Het bovenstaande geeft:
De sanitized output: âˆ

Wanneer je de ASCII HTML nummers omzet in ASCII staat er: âˆ
Terwijl ik het volgende verwacht: ∠(= ∠).

Iemand een idee waarom mijn verwachting niet overeenkomt met het resultaat?

[alex3305]

Waarom niet gewoon een strip_tags of htmlspecialchars gebruiken? Dit doet geloof ik precies wat jij wilt. Zie daarvoor ook dit StackOverflow artikel.

[MekZi]

Het gaat zich nu niet om welke andere functie ik ook kan gebruiken (strip_tags/htmlspecialchars/htmlentities), maar waarom de bovenstaande niet leidt tot de verwachte resultaat. Ik probeer de filter_var() function te begrijpen en wil dalijk ook de validatie en andere sanatize filters gebruiken.

[RobIII]

Shot in the dark: wat is de encoding van je php file?

[MekZi]

Oe... dat weet ik niet. Wist niet eens dat ik daar rekening mee moest houden. De HTML document bevat wel "<meta charset="utf-8" />".

Zal eens snel kijken (googelen). Neem aan dat er of een functie voor is of dat het in phpinfo() wordt weergegeven.

edit:
In phpinfo wanneer ik ctrl-f gebruik komen de volgende twee zaken terug (zoekterm "encode"):
exif.encode_jis no value no value
exif.encode_unicode ISO-8859-15 ISO-8859-15
default_charset no value no value (op mijn locale XAMPP-server)

Denk dus dat die exif.encode_unicode UTF-8 moet zijn inplaats van ISO-8859-15? Ik geloof dat je de waardes of in een .htacces kan aanpassen of per script (of natuurlijk direct in de php.ini, maar dat zal niet lukken met mijn hosting).

edit2:
Heb even gegoogled, maar heb niet kunnen uitvogelen hoe en wat mbt encode van php.

Verder wil ik nog vertellen waarom ik deze functie wil gebruiken. Ik ben namelijk bezig met een "emailwebformulier". De mail wil ik als platte tekst versturen (7bit). Ik wil uiteindelijk de flag "FILTER_FLAG_STRIP_LOW" in combinatie met "FILTER_FLAG_ENCODE_HIGH" gebruiken (dit kan m.b.v. de | teken). Het resultaat wil ik vervolgens omzetten naar base64 en deze vervolgens met de functie chuck_split() gaan opsplitsen (er mag per regel niet meer dan 70 tekens. Staat o.a. op php.net/mail).

Met het bovenstaande ga ik er wel vanuit dat een email client zonder een HTML-interpreter de &#asci-code; juist kan weergeven (iemand die dit toevallig weet?). Als dit niet het geval is, zal ik er een text/html mail van maken.

[ Voor 87% gewijzigd door MekZi op 04-02-2013 00:22 ]

[RobIII]

Begin even met The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

De encoding van je PHP file bepaal je in je editor/IDE. De meeste editors hebben een mogelijkheid de encoding te specificeren bij opslaan. Die exif.<blaat> meuk heeft er niets mee van doen (ik snap ook even niet hoe je tot die conclusie komt ); beide hebben namelijk betrekking op EXIF. Ik ben geen PHP kenner maar ook de default charset lijkt me niet relevant hier.

MekZi schreef op zondag 03 februari 2013 @ 23:48:
Met het bovenstaande ga ik er wel vanuit dat een email client zonder een HTML-interpreter de &#asci-code; juist kan weergeven (iemand die dit toevallig weet?). Als dit niet het geval is, zal ik er een text/html mail van maken.

Euh; ik weet niet of ik je hier goed begrijp, maar de numeric character references (zoals jij &#931; noemt) werken alleen in HTML; die gaan in "ASCII mail" niet werken. Sowieso zijn in ASCII enkel de 'gewone letters en leestekens' beschikbaar. In Extended ASCII heb je dan nog wat diakrieten tot je beschikking maar het is me vooral vaag wat je nou eigenlijk precies probeert te bereiken. Bij mij is de output van je code:

Ik weet dan (ook ) weer niet genoeg van 'platte mail', maar kun je niet gewoon UTF-8 gebruiken? En waarom ben je überhaupt 't wiel opnieuw aan 't uitvinden en gebruik je niet PHPMailer o.i.d.? (En als je die niet wil gebruiken: spiek eens in hun sourcecode?). En anders moet je eens even hier kijken en de daar gelinkte RFC's.

[ Voor 109% gewijzigd door RobIII op 04-02-2013 01:00 ]

[MekZi]

Ik heb de de 'The Absolute Minimum...Set (No Excuses!)'-artikel gelezen (en wat meer geleerd over encode).

Verder kwam ik op dat van 'exif' door te zoeken op de term "utf-8" op een phpinfo()-pagina. Dacht namelijk, omdat er "utf-8" als waarde in de rij voorkwam dat het misschien te maken kon hebben met het probleem (dat is dus blijkbaar niet het geval).

Verder heeft de high in de filter "FILTER_FLAG_ENCODE_HIGH" te maken met de extended ASCII. De flag zou namelijk ervoor moeten zorgen dat de extended ASCII letters/tekens omgezet worden in de 'numeric character references'. Echter wanneer je dus een letter/teken pakt, die in de 127+ reeks valt, en die laat sanitizen, komt het antwoord niet overeen met wat je zou verwachten. (De voorbeeld hierboven is waarschijnlijk door kopieer/plak en de encoding niet juist weergegeven):

PHP:

<?php
    $inputwaarde = 'â&#710;'; // **
    echo mb_detect_encoding('â&#710;')."\n";
    $sanitized = filter_var($inputwaarde, FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_HIGH);
    
    echo 'De sanitized output: '.$sanitized."\n"; // --> âË&#8224; (terwijl ik verwacht
?>

Je krijgt dan het volgende te zien:
UTF-8
De sanitized output: & #195; & #162; & #203; & #134;
(Heb spaties moeten toevoegen)
Wanneer je de 'numeric character references' opzoekt en vertaald krijg je: âË&#8224; (laatste &#8224;-teken wilt hij niet weergeven op tweakers.net, maar wanneer je hem in google tikt krijg je de teken te zien - soort van kruis).

Nou weet ik misschien dat ik beter de third-party mail lib's kan gebruiken, maar ben eigenlijk gewoon aan het "spelen" en leren met php. Nu ik tegen dit probleem aanloop wil ik heel graag weten waardoor dit komt (ben een beetje een controle en want-to-know-all freak ).

edit:
***hmm, nog een teken die door tweakers.net-forum niet wordt weergegeven? Komt dit misschien omdat ik een niet-extended ascii teken invul? (Heb de alt key ingehouden en random op twee toetsen gedrukt. Zal eens even twee tekens direct uit de extended ascii table kopieren en invullen).

edit2:
Nope, wanneer ik een teken van http://www.ascii-code.com/ kopieer (uit de extended reeks) geeft hij mij nog steeds gibberish terug.

[ Voor 13% gewijzigd door MekZi op 04-02-2013 21:18 ]

[RobIII]

De numeric char ref is 710; lijkt me niet echt uit de extended ASCII range (0-255) te komen Ik zit op m'n iPhone te GoTten dus heb zo snel niet slles bij de hand maar als er tekens niet weergegeven worden: al eens bedacht dat die tekens ook in het gebruikte font (arial hier??) aanwezig moeten zijn om weergegeven te worden? (Hoewel er in die gevallen wel mogelijk teruggevallen moet worden naar een "placeholder" afaik). Either way: als je nou eens test met échte data i.p.v. "random tekens" die je toch nooit gaat gebruiken, voordat je overgaat tot het uitpuzzelen van vage edgecases?

[ Voor 72% gewijzigd door RobIII op 04-02-2013 21:18 ]

[MekZi]

RobIII schreef op maandag 04 februari 2013 @ 21:11:
De numeric char ref is 710; lijkt me niet echt uit de extended ASCII range (0-255) te komen

Heb nu zojuist het teken dat behoort tot & #138; gekopieerd en toegepast en ook die geeft mij als waarde het volgende: & #197; & #160;

Mijn document is als UTF-8 opgeslagen. Ook heb ik een meta charset (html). Wat ik alleen niet zeker weet is of mijn test server UTF-8 pagina's serveert? Ik heb een standaard XAMPP installatie op een Mac. Weet niet of het hierdoor kan komen?

[Gomez12]

Ondersteunt dat hele filter_var wel multi-byte encodings?

Zou het geen mb_filter_var moeten zijn?

Php is namelijk een klein beetje ruk met utf-8 (sommige functies ondersteunen het niet, andere hebben een mb_variant en weer andere doen het gewoon )

Qua php heb ik uit ervaring geleerd : ver ver ver weg blijven van utf-8, dat zit er maar halfbakken in

[8088]

MekZi schreef op maandag 04 februari 2013 @ 21:16:
Wat ik alleen niet zeker weet is of mijn test server UTF-8 pagina's serveert?

Dat zou je uit de headers moeten kunnen afleiden.

[MekZi]

Gomez12 schreef op maandag 04 februari 2013 @ 21:52:
Ondersteunt dat hele filter_var wel multi-byte encodings?

Zou het geen mb_filter_var moeten zijn?

Php is namelijk een klein beetje ruk met utf-8 (sommige functies ondersteunen het niet, andere hebben een mb_variant en weer andere doen het gewoon )

Qua php heb ik uit ervaring geleerd : ver ver ver weg blijven van utf-8, dat zit er maar halfbakken in

Er is geen 'mb_filter_var()' functie (misschien onder een andere naam?). Maar waarom zou filter_var() dan een een FILTER_FLAG_ENCODE_HIGH/FILTER_FLAG_STRIP_HIGH flag hebben? Met de HIGH bedoelen ze dus 127+ en dat is 8bits/1byte inplaats van 7bits (2byte hmm, tijdens het tikken schiet mij dit te binnen ).

Zou best eens kunnen dat de function_var geen multibyte ondersteuning heeft. Dus dan moet ik waarschijnlijk ISO 8859-1/latin-1 gebruiken?

[Gomez12]

MekZi schreef op maandag 04 februari 2013 @ 21:59:
[...]
Zou best eens kunnen dat de function_var geen multibyte ondersteuning heeft. Dus dan moet ik waarschijnlijk ISO 8859-1/latin-1 gebruiken?

8859-1 / latin-1 is redelijk oud. Ondersteunt bijv geen euro teken.

Wat ik tegenwoordig vaak gebruikt zie worden is 8859-15.

[MekZi]

Met behulp van Firefox/firebug zie ik bij headers het volgende staan: Content-Type text/html; charset=utf-8.
Dus ik denk dat de server dus utf-8 pagina's serveert. Dus dan kan het dus alleen nog maar liggen aan de functie zelf. Echter wanneer gebruik je dan die high flag's want ze zijn bedoeld voor extended ascii tekens.

[P.O. Box]

misschien ligt het toch aan de opslag van je PHP file, vanwege het BOM-kenmerk:
http://stackoverflow.com/...ource-code-files-in-utf-8

citaat:

There are a few pitfalls to take care of:

1.PHP is not aware of the BOM character certain editors or IDEs like to put at the very beginning of UTF-8 files. This character indicates the file is UTF-8, but it is not necessary, and it is invisible. This can cause "headers already sent out" warnings from functions that deal with HTTP headers because PHP will output the BOM to the browser if it sees one, and that will prevent you from sending any header. Make sure your text editor has a UTF-8 (No BOM) encoding; if you're not sure, simply do the test. If <?php header('Content-Type: text/html') ?> at the beginning of an otherwise empty file doesn't trigger a warning, you're fine.
2.Default string functions are not multibyte encodings-aware. This means that strlen really returns the number of bytes in the string, not the actual number of characters. This isn't too much of a problem until you start splicing strings of non-ASCII characters with functions like substr: when you do, indices you pass to it refer to byte indices rather than character indices, and this can cause your script to break non-ASCII characters in two. For instance, echo substr("é", 0, 1) will return an invalid UTF-8 character because in UTF-8, é actually takes two bytes and substr will return only the first one. (The solution is to use the mb_ string functions, which are aware of multibyte encodings.)
3.You must ensure that your data sources (like external text files or databases) return UTF-8 strings too, because PHP makes no automagic conversion. To that end, you may use implementation-specific means (for instance, MySQL has a special query that lets you specify in which encoding you expect the result: SET CHARACTER SET UTF8 or something along these lines), or if you couldn't find a better way, mb_convert_encoding or iconv will convert one string into another encoding.

[Gomez12]

ASCII = 1/127
Extended ASCII = 128/255

Zie ook : http://www.asciitable.com/

[MekZi]

Gomez12 schreef op maandag 04 februari 2013 @ 22:21:
ASCII = 1/127
Extended ASCII = 128/255

Zie ook : http://www.asciitable.com/

En om precies te zijn:
1-31 control characters
32-127 printable characters

Maar dat wist ik dus al voordat ik de topic had geplaatst.

Vind het maar raar waarom dit niet werkt zoals ik het dus verwacht dat het zou moeten werken.

[P.O. Box]

na enig denken herinner ik me dat ik een soortgelijk probleem ook eens heb gehad... bij mij bleek het te komen omdat PHP source code niet MULTIBYTE kan worden opgeslagen... ik kan zo snel even geen bron meer vinden waar ik dat toentertijd vandaan haalde...

ter vergelijking mijn probleem:
ik wilde een functie maken die bijv é omzette naar e... het betrof een klein aantal karakters dus in eerste instantie dacht ik, ik zet in de broncode keihard een conversie-array.... maar ik kreeg het niet voor elkaar... uiteindelijk heb ik het opgelost door de karakters met bijbehorende vervanging in een tabel in MySQL te zetten en van daaruit op te halen... waardes die in het geheugen worden geladen, kunnen in PHP namelijk WEL multibyte zijn...

misschien dat je als test eens je inputwaarde in een mysql tabel kunt zetten (wel de juiste encoding gebruiken voor je table-velden dan he ), hem van daaruit op kunt halen, en dan de mb-functies van PHP kunt gebruiken?


dit is mijn functie die het toen (en nu nog steeds) oploste:

PHP:

    function replaceutf($str) {
        global $db;

        $query_result = $db->query("SELECT * FROM character_replacements");
        while ($query_row = $query_result->fetch_object()) {
            $str = mb_ereg_replace($query_row->from, $query_row->to, $str);
        }
        return $str;
    }

[ValHallASW]

Zoals je in Joel Spolsky's guide hebt kunnen lezen moet je helder onderscheid maken tussen opslag (bytes) en betekenis (characters). In het volgende houd ik de volgende (python-based)-notatie aan:

• \xaa = byte met waarde hex aa = base10 170;
• \uaaaa = unicode character aaaa = 'TAI VIET LETTER LOW VO' = ꪪ.

OK. Nu even door je code lopen:

1. php strings zijn geen lijst met characters maar een lijst met bytes
2. Jij typt in je teksteditor $inputwaarde = 'âˆ'; (\u00e2\u02c6 LATIN SMALL LETTER A WITH CIRCUMFLEX, MODIFIER LETTER CIRCUMFLEX ACCENT)
3. Omdat je je php-file als utf-8 hebt opgeslagen wordt dat opgeslagen als \xc3\xa2\xcb\x86.
4. filter_var($inputwaarde, FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_HIGH); loopt door de bytes heen, en vervangt elke byte met een waarde groter dan 128 door een ascii-encoded string "&waarde;" waarbij waarde de waarde van de byte was.
5. $inputwaarde is nu dus: \xc3\xa2\xcb\x26\x31\x37\x33\x3b

Vervolgens is de vraag wat die bytereeksen voorstellen als je ze als latin-1 of utf-8 interpreteert:

bytes	utf-8	latin-1
\xc3\xa2\xcb\x86	âˆ	âˆ
\xc3\xa2\xcb\x26\x31\x37\x33\x3b	â�&173;	âË&173;

Wat er dus gebeurt is het volgende:

• Je editor maakt (mbv utf-8 encoding) van je characters "âˆ" de bytes \xc3\xa2\xcb\x86
• filter_var maakt van de bytes \xc3\xa2\xcb\x86 de bytes \xc3\xa2\xcb\x26\x31\x37\x33\x3b
• je browser maakt (mbv latin-1 decoding)van de bytes \xc3\xa2\xcb\x26\x31\x37\x33\x3b de characters âË&173;

[curvemod]

MekZi schreef op zondag 03 februari 2013 @ 23:48:
Verder wil ik nog vertellen waarom ik deze functie wil gebruiken. Ik ben namelijk bezig met een "emailwebformulier". De mail wil ik als platte tekst versturen (7bit). Ik wil uiteindelijk de flag "FILTER_FLAG_STRIP_LOW" in combinatie met "FILTER_FLAG_ENCODE_HIGH" gebruiken (dit kan m.b.v. de | teken). Het resultaat wil ik vervolgens omzetten naar base64 en deze vervolgens met de functie chuck_split() gaan opsplitsen (er mag per regel niet meer dan 70 tekens. Staat o.a. op php.net/mail).

Met het bovenstaande ga ik er wel vanuit dat een email client zonder een HTML-interpreter de &#asci-code; juist kan weergeven (iemand die dit toevallig weet?). Als dit niet het geval is, zal ik er een text/html mail van maken.

Even los van de vraag, ik heb echt geen idee waarom je dit doet. Waarom zou je een filter_var over een email willen halen? Volgens mij gebruik je dit normaliter om input te filteren van bijvoorbeeld een POST of een GET. Is het niet een kwestie van de juiste encoding op je email (je weet in welke taal de website gebruikt wordt), chunk_split erover knallen en mailen?

Ik heb toevallig ook wel ervaring met deze problematiek, dat is gewoon K.. om op te lossen in PHP. De reden dat wij het toen hadden was dat we een mailparser hadden die email binnen kreeg in de meest bizarre encodingen, en dat dat juist geparsed moest worden. Hadden we uiteindelijk wel een oplossing voor, maar dat is een lang verhaal.

[Verwijderd]

jhuiting schreef op dinsdag 05 februari 2013 @ 08:33:

Even los van de vraag, ik heb echt geen idee waarom je dit doet. Waarom zou je een filter_var over een email willen halen? Volgens mij gebruik je dit normaliter om input te filteren van bijvoorbeeld een POST of een GET.

Volgens mij moet je dan gewoon eens de documentatie gaan lezen. Met filter_var kun je prima emailadressen valideren.

[curvemod]

Verwijderd schreef op dinsdag 05 februari 2013 @ 08:44:
[...]

Volgens mij moet je dan gewoon eens de documentatie gaan lezen. Met filter_var kun je prima emailadressen valideren.

Ik leid anders uit het verhaal over chunk_split af dat het om een body gaat, volgens mij is dat hele encoding verhaal anders helemaal niet te plaatsen toch. Ik zeg ook, prima voor GET en POST variables a.k.a formuliervelden maar om hele email bodies er doorheen te halen is volgens mij niet handig.

_{PS. Ik heb de filter_var documentatie al vaak genoeg gelezen, maak je geen zorgen}

[Verwijderd]

My bad, ik interpreteerde je zin verkeerd. Ik las "emailadres" maar je bedoelde daarwerkelijk de complete email. De TS is inderdaad een beetje aan het rommelen met encodings, en in dat opzicht is het inderdaad het best om gewoon de complete tekst te encoden met 7-bit compatible functie, zoals base64 of quoted-printable (aargh, liever niet). Excuses, zal voortaan beter lezen

[curvemod]

Verwijderd schreef op dinsdag 05 februari 2013 @ 09:46:
My bad, ik interpreteerde je zin verkeerd. Ik las "emailadres" maar je bedoelde daarwerkelijk de complete email. De TS is inderdaad een beetje aan het rommelen met encodings, en in dat opzicht is het inderdaad het best om gewoon de complete tekst te encoden met 7-bit compatible functie, zoals base64 of quoted-printable (aargh, liever niet). Excuses, zal voortaan beter lezen

Ja precies, dat was ook mijn gedachte. Ik zou er lekker een base64 overheen gooien, maar het blijft een feit dat PHP gewoon slecht met dit soort zaken om kan gaan. Ik zeg op naar PHP6

[MekZi]

ValHallASW schreef op dinsdag 05 februari 2013 @ 00:22:
Zoals je in Joel Spolsky's guide hebt kunnen lezen moet je helder onderscheid maken tussen opslag (bytes) en betekenis (characters). In het volgende houd ik de volgende (python-based)-notatie aan:

...

• je browser maakt (mbv latin-1 decoding)van de bytes \xc3\xa2\xcb\x26\x31\x37\x33\x3b de characters âË&173;

Ah, nu zie ik wat filter_var verkeerd doet. Heb dit tooltje gevonden en dat laat inderdaad zien dat de teken omgezet wordt naar UTF-8 byte's en deze dan vervolgens als latin wordt gezien:
â: http://www.ltg.ed.ac.uk/~...gi?input=%C3%A2&mode=char
ˆ: http://www.ltg.ed.ac.uk/~...gi?input=%CB%86&mode=char

Wat alleen nog niet hoe ik dit kan oplossen. Misschien dat dit niet op te lossen valt?

Heb dit probleem ook eens op stackoverflow geplaatst (wilde het altijd al eens uitproberen! ):
http://stackoverflow.com/...r-filter-flag-encode-high

jhuiting schreef op dinsdag 05 februari 2013 @ 08:33:
[...]

Even los van de vraag, ik heb echt geen idee waarom je dit doet. Waarom zou je een filter_var over een email willen halen? Volgens mij gebruik je dit normaliter om input te filteren van bijvoorbeeld een POST of een GET. Is het niet een kwestie van de juiste encoding op je email (je weet in welke taal de website gebruikt wordt), chunk_split erover knallen en mailen?

Ik heb toevallig ook wel ervaring met deze problematiek, dat is gewoon K.. om op te lossen in PHP. De reden dat wij het toen hadden was dat we een mailparser hadden die email binnen kreeg in de meest bizarre encodingen, en dat dat juist geparsed moest worden. Hadden we uiteindelijk wel een oplossing voor, maar dat is een lang verhaal.

Ik wil uiteindelijk een contactformulier maken. De input zal dus via een POST worden verkregen en zal dus eerst gesanitised moeten worden. Wil naast filter_var ook de volgende functie gebruiken om email injection te voorkomen:

PHP:

<?php
function antiMailInjection($waarde)
{
    $verboden = array('\r', '\n', '%0a', '%0d', 'content-type:', 'bcc:', 'cc:');
    $waarde = str_ireplace($verboden, '', $waarde);
    return $waarde;
}
?>

[ Voor 57% gewijzigd door MekZi op 06-02-2013 22:41 ]

[RobIII]

With all due respect, seriously, dit is een disaster waiting to happen. Je "antiMailInjection" is al niet waterdicht* en je "grasp on the subject" is, afgaand op die snippet en andere zaken in dit topic, gewoon te laag. Dat is overigens niets om je voor te schamen; er is zo veel te weten omtrent dit onderwerp. En dan laat je 't beter over aan mensen die zich er op hebben toegelegd en projecten de wereld in hebben geholpen als PHPMailer e.d. (er zijn zat alternatieven).

Dit zeg ik niet om je af te zeiken; ik probeer je alleen duidelijk te maken dat "een mailtje" gewoon best complex in elkaar kan zitten en als je alle RFC's en andere zaken erbij neemt zul je zien dat 't best wat werk kost om die goed te implementeren. Neem de sourcecode van, zeg, een PHPMailer erbij en concludeer dat daar een heleboel gebeurt waar jij geen rekening mee hebt gehouden en waar je zéér waarschijnlijk mee op je bek gaat. Tenzij je van plan bent een, again, zeg, PHPMailer te verbeteren en je dus komende weken/maanden exclusief wil richten op 't bouwen van een mailer component neem je best gewoon andermans bloed, zweet en tranen en gebruik je dat. Standing on the shoulders of giants

* En waarom zou ik niet in mijn mail iets als "ik stuurde de volgende mensen een bcc: Jan, Piet, Klaas" mogen zetten Dat is, op zichzelf, al een clbuttic mistake.

[ Voor 70% gewijzigd door RobIII op 06-02-2013 22:52 ]

[MekZi]

RobIII schreef op woensdag 06 februari 2013 @ 22:42:
With all due respect, seriously, dit is een disaster waiting to happen. Je "antiMailInjection" is al niet waterdicht* en je "grasp on the subject" is, afgaand op die snippet en andere zaken in dit topic, gewoon te laag. Dat is overigens niets om je voor te schamen; er is zo veel te weten omtrent dit onderwerp. En dan laat je 't beter over aan mensen die zich er op hebben toegelegd en projecten de wereld in hebben geholpen als PHPMailer e.d. (er zijn zat alternatieven).

Dit zeg ik niet om je af te zeiken; ik probeer je alleen duidelijk te maken dat "een mailtje" gewoon best complex in elkaar kan zitten en als je alle RFC's en andere zaken erbij neemt zul je zien dat 't best wat werk kost om die goed te implementeren. Neem de sourcecode van, zeg, een PHPMailer erbij en concludeer dat daar een heleboel gebeurt waar jij geen rekening mee hebt gehouden en waar je zéér waarschijnlijk mee op je bek gaat. Tenzij je van plan bent een, again, zeg, PHPMailer te verbeteren en je dus komende weken/maanden exclusief wil richten op 't bouwen van een mailer component neem je best gewoon andermans bloed, zweet en tranen en gebruik je dat. Standing on the shoulders of giants

* En waarom zou ik niet in mijn mail iets als "ik stuurde de volgende mensen een bcc: Jan, Piet, Klaas" mogen zetten Dat is, op zichzelf, al een clbuttic mistake.

Je hebt zeer zeker gelijk en zal naar de phpmailer lib kijken en gebruiken (en dit tevens vergelijken met de andere lib. Ik weet dat er twee zijn die het meest gebruikt worden.). Dit begon met "Laat ik even een emailwebformuliertje maken" om eens wat anders te doen dan wordpress.

Wat ik alleen wel nog graag wil zien op te lossen is dus de filter_var() encode probleem, om het te gebruiken bij andere "projecten". En als ik aan het eind van de week nog geen antwoord heb gevonden dan zal ik filter_var maar negeren en andere functie's gebruiken .