If $parameter
Als aangevinkt wordt dat mensen een nieuwe koelmachine aanvinken moet waarde 3 worden ingevuld. Indien geen nieuwe waarde wordt aangevinkt, is een andere reeds bekende $parameter geldig(middels een lijst met waarden).
$copkoelmachinenieuw = $_POST['vernieuwenkoelmachine']; // ja of nee, waarbij value bij nieuw is 3 en bij nee $copkoelmachineoud
$copkoelmachineoud = $_POST['COP'];
Hoe krijg ik dit werkend? Heb al aantal dingen geprobeerd, maar blijkbaar mis ik nog wat kennis.
Alvast bedankt!
// dan is de waarde zoals invuld bijv. value="3" bijhorend bij de radiobox
} else {
// Nee, dan wordt gekozen $_post:['COP']
Bouwjaar huidige koelmachine:
<select name="COP">
<option value="2">1990 - 2000</option>
<option value="2.5">2000 - 2010</option>
}
?>
Je kunt namelijk niet zomaar html in php gooien, deze moet dan in een echo geplaatst worden of buiten de php.
Let ook op hoofdletters en typfouten
$_post:['COP'] zou moeten zijn $_POST['COP']
Een formulier plaats je altijd in een <form> en dient wel een button of submit te hebben.
Select dien je ook weer te sluiten.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
if($_SERVER['REQUEST_METHOD'] == 'post') {
// hierin doe je alle afhandelingen wanneer het formulier is gepost
if(isset($_POST['vinkboxje'])) {
$waarde = 3;
} else {
$waarde = $_POST['COP'];
}
echo $waarde;
}
?>
<form method="POST">
<select name="COP">
<option value="2">1990 - 2000</option>
<option value="2.5">2000 - 2010</option>
</select>
<input type="checkbox" name="vinkboxje" />
<button>Post</button>
</form>
if($_SERVER['REQUEST_METHOD'] == 'post') {
// hierin doe je alle afhandelingen wanneer het formulier is gepost
if(isset($_POST['vinkboxje'])) {
$waarde = 3;
} else {
$waarde = $_POST['COP'];
}
echo $waarde;
}
?>
<form method="POST">
<select name="COP">
<option value="2">1990 - 2000</option>
<option value="2.5">2000 - 2010</option>
</select>
<input type="checkbox" name="vinkboxje" />
<button>Post</button>
</form>
Gewijzigd op 08/09/2015 12:11:11 door Michael -
Code (php)
1
if($_SERVER['REQUEST_METHOD'] == 'post') {
gebruik ik ook wel eens, maar ik dacht dat 'POST' dan met hoofdletters moest, tenminste zo staat het wel in het voorbeeld http://php.net/manual/en/reserved.variables.server.php .
Er staat ook een (misschien out-of-date) waarschuwing tegen arbitrary methods, en volgens mij was het zo dat je dit soort waarden zowieso als tainted moet beschouwen omdat ze client-side worden ingesteld.
Kan je dan niet beter iets doen als:
Code (php)
1
if (isset($_SERVER['REQUEST_METHOD']) && $_SERVER['REQUEST_METHOD'] === 'POST') {
Code (php)
1
if (isset($_SERVER['REQUEST_METHOD']) && strtoupper($_SERVER['REQUEST_METHOD']) === 'POST')
$_SERVER wordt gevuld door de webserver, dus kun je bij sommige webservers afwijkende resultaten krijgen. $_SERVER['REQUEST_METHOD'] kan bijvoorbeeld ontbreken als het PHP-script via een commandline (zoals een cronjob) wordt aangeroepen. Vandaar dat je dit voor maximale compatibiliteit beter met isset() kunt ondervangen.
Als ik het goed begrijp van http://stackoverflow.com/questions/4400678/http-header-should-use-what-character-encoding moet de HTTP header in US-ASCII gecodeerd zijn. Omdat US-ASCII altijd een subset is van UTF-8, ben ik geneigd te zeggen dat je met mb_strtoupper() altijd goed zit. Van strtoupper() weet ik het niet zeker, het zou kunnen dat als er een andere locale wordt ingesteld, bv. met setlocale(), het niet goed werkt. Daar komt bij dat setlocale() ook nog eens niet thread safe is, en dan heb je een extra (klein) veiligheidsrisico, het kan daar gaan rammelen, als een ander script een andere locale instelt.
Van http://php.net/manual/en/function.setlocale.php :
Quote:
Warning
The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS, HHVM or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale().
The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS, HHVM or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale().
Oke, het is wel een tikje paranoïde, het gaat vast en zeker vrijwel altijd goed anders hadden we hier wel meer over gehoord. Toch?
Er is geen door PHP ondersteunde karakterset waarin de hoofdletters POST niet in de eerste 7 bits staan. Verschillen ontstaan pas vanaf de 8e bit.
Ik denk dat je het voor de veiligheid hier dus zou moeten omkeren: niet erop vertrouwen dat je overal correcte en volledige UTF-8 kunt afdwingen. (Hacks met 16-bits karaktersets maken daarvan namelijk dankbaar misbruik.) Staat er ongeacht karakterset en ongeacht locale niet 'POST', dan weet je al genoeg.
HTML en PHP had ik uiteraard los staan. Had het daarna gedaan zoals aangegeven door AAR, alleen was bij mij een fout ingeslopen, waardoor het niet direct werkte...
Toch maar meer verdiepen in PHP, mogelijkheden zijn oneindig ;-)
Ondanks dat logica in deze te kort schiet wil ik voor het oog liever alles multibyte-compatible houden, en zal ik mb_strtoupper() blijven gebruiken. Op de één of andere manier vind ik eleganter staan omdat het dan consistenter / gelijkvormiger is met de rest van mijn code.
Off-topic: nog even wat historie van ASCII bekeken, en toen kwam het weer naar boven dat een van key-features van de uiteindelijke ASCII-standaard juist is dat de printable charachters op vaste code-points zitten waarmee ASCII in hoge mate compatible is met codepages van zichzelf, dit in tegenstelling tot oudere encoding schema's als EBCDIC. EBCDIC codepages zijn niet bijzonder compatible met andere EBCDIC codepages, inclusief special characters, die weer op andere codepoints zitten. Bij EBCDIC maakt het enorm uit met welk encoding schema je source bestanden zijn opgeslagen. PHP maalt er totaal niet om, omdat de parser (net als andere talen) dankbaar gebruik kan maken van de vaste codepoints van (US-)ASCII. Onlangs had ik nog nageplozen dat PHP dus ook met UTF-8 uit te weg kan, omdat UTF-8 encoding juist zo is gemaakt dat het alleen encodeert met de 8e bit er bij, en daarmee is UTF-8 volledig ASCII-compatible. Dus andere encoding schema's die niet volledig compatible zijn met ASCII zullen problemen geven voor de PHP parser. Volgens mij geven onder andere UTF-16 en UTF-32 problemen.
Er zijn (multinationale) bedrijven die als bedrijfsregel hebben dat data in databases opgeslagen moet zijn als UTF-16. JavaScript werkt facto de standaard met UTF-16. Je hebt het gewoon lang niet altijd voor het kiezen welke encoding de data heeft waar je mee moet werken. Dus wanneer je op die data wilt afstemmen dan moet je PHP code dus met UTF-16 data of anderzins ge-encodeerde data uit de voeten kunnen. Het wil natuurlijk niet zeggen dat de PHP code zelf als UTF-16 moet worden opgeslagen.
Wat ik wel steeds merk als terugkerend punt, is dat programmeurs (waaronder ikzelf) met enige regelmaat pas in een laat stadium met het begrip encoding te maken krijgen. Het gaat steeds automagisch goed, Latin1 is default op -UX, Windows, en OSX, en compatible met ASCII. UTF-8 is compatible met ASCII, en er zijn veel misverstanden over Unicode, wat niet eens een encoding is. Dus om goed te begrijpen waarom het goed gaat, is begrip van encoding essentieel. Vooral als je een keertje moet afwijken van de standaard.
Maar als je de meeste literatuur, wordt er weinig tot geen aandacht in besteed. Sterker nog, er zijn heel de nodige sites die een poging doen om het uit te leggen, maar de plank net niet helemaal goed slaan. Dus ik wist heel lang niet waarom PHP 'agnostisch' was ten opzichte van encoding. Maar nu blijkt dus dat PHP helemaal niet agnostisch is, maar volledig afhankelijk van ASCII. Niet dat het erg is, er was alleen niemand die het even kort en bondig kon uitleggen.
Hooguit dat een ë niet goed werd weergegeven, maar dan deed ik wel iets als str_replace("&54i9n", "ë", $string);... dat werkte ook.
Later (zeg: 6 maanden geleden) dacht ik van: alles UTF8 (of LATIN1, wat dan ook).
Maar in de meeste websites geef ik dus (nog steeds niet) expliciet aan welke encoding nodig is. Gewoon, omdat het nu ook prima werkt.
Quote:
.. maar dan deed ik wel iets als ..
Misschien begrijp ik het verkeerd? Als je met data werkt, dan moet je toch besef hebben van welke encoding de bits in je bytes representeren als je die bytes gaat bewerken. Hoe vaak kom je 'problemen met diakritische tekens' tegen, gewoon omdat men niet doorheeft wat encoding en transcoding is? Terwijl het in essentie simpel te begrijpen is, en je moet er even op letten, en dan ben je veel ellende voor. Bijvoorbeeld als je data in je database door onkunde keer op keer gemangeld wordt, waarna je geen idee meer hebt van hoe je je data kunt terugkrijgen? In een praktijksituatie heb ik meegemaakt dat iemand door een incompatible codepage te kiezen, met één onwetende druk op de knop 30 jaar werk heefd vernietigd. Men kwam er pas na 6 maanden achter dat de code niet ging werken, waardoor het werk van 60 man (maal een half jaar) overnieuw moest. Nu gun ik niemand zo'n praktijkervaring, maar ik vind de lakse houding over de belangrijkheid van encoding wel wat te wensen over laten:
Quote:
in de meeste websites geef ik dus (nog steeds niet) expliciet aan welke encoding nodig is. Gewoon, omdat het nu ook prima werkt
Kan je vertalen naar: ik doe maar wat en ik geef er niets om totdat het fout is gegaan en er maar hard genoeg over geklaagd gaat worden.
Ik hoop niet dat een programmeur met dergelijke attitude nooit cruciale applicaties hoeft te maken, totdat-ie heeft begrepen dat de werkelijke waarde van data letterlijk van levensbelang kan zijn.
Ik ben maar hobbist die thuis wat raak kloot en toevallig nog wat resultaat neer zet.
Encoding is iets wat je pas doet als je het nodig hebt en/of fout gaat.
Data opslaan doe je met mysql_-functies (toen nog wel) en welke encoding daarin zat... ach. Het werkte.
Pas als er problemen gaan ontstaan, ga je verder kijken.
Eddy
Nouja, ergens is er wat voor te zeggen; iedereen heeft een beperkte hoeveelheid tijd tot z'n beschikking, al dan niet professioneel, waarin je iets wilt neerzetten. Encoding is alleen wel heel erg belangrijk, zonder dat je het in eerste instantie doorhebt, het is dan ook niet zo heel vreemd dat PHP6 volledig Unicode moest zijn. Helaas bleek dat zo lastig dat de ontwikkelaars PHP6 maar hebben overgeslagen. Dus zijn we toch weer op onzelf aangewezen.
Waarom je het wel wilt/moet weten:
Wanneer je iets programmeert of zelfs maar typt in een tekstverwerker heb je al onbewust met encoding te maken. Dat gaat goed zolang de encoding hetzelfde blijft. Je krijgt met encoding te maken bijvoorbeeld:
- als je even vlug een site klust en later de vraag naar boven komt om een webwinkel te bouwen en het euro-teken nodig is
- je wilt je site aanvullen met AJAX, en dan blijkt de benodigde encoding (Unicode) niet te passen op de default encoding van je OS cq. PHP (Latin1).
- je wilt maar zelfs iets inlezen van een CSV, tekstbestand met BOM, of zelfs XML schrijven via SimpleXML, XMLWriter of DOMDocument, die laatsten willen allemaal Unicode als input.
- je wilt iets lezen of wegschrijven naar je MySQL-database met een andere encoding
In al deze gevallen krijg je te maken met het overzetten van de ene encoding naar de andere, oftewel transcoding. Als je je daar niet bewust van bent, gaan de dingen zeker verkeerd (data wordt verkeerd geinterpreteerd of erger - karakters die niet naar de doelencoding worden gemapped raken domweg kwijt), en dat is jammer omdat het vooraf relatief simpel voorkomen had kunnen worden. Dan hoef je niet achteraf nog eens in alle voorkomende gevallen met str_replace() de diakritische tekens te vervangen voor HTML-entities, dat kost extra en dus onnodige resources, niet alleen van de CPU maar ook van je eigen ontwikkeltijd. Jij en je klant zijn uiteindelijk beter af als je van te voren aandacht hebt voor encoding.
Quote:
Later (zeg: 6 maanden geleden) dacht ik van: alles UTF8 (of LATIN1, wat dan ook).
Het beste kan je Unicode gebruiken gebruiken voor je website of -applicatie, UTF-8 is de default van HTML5.
Korte checklist:
- je kunt je PHP files opslaan in UTF-8 omdat UTF-8 ASCII-compatible is zonder BOM of Byte Order Mark. Een BOM is niet van toepassing op UTF-8 en het zorgt dat er te snel HTTP headers worden verstuurd, dus dat willen we niet.
- je geeft encoding aan via HTTP-headers
Code (php)
1
header('Content-Type: text/html; charset="UTF-8"');
- je checkt de input die de browser naar PHP stuurt of de strings wel UTF-8 compliant zijn (*)
Bijvoorbeeld met een soort van is_utf8() -functie van een library als Portable UTF-8
- je gebruikt utf8mb4 als encoding voor tabellen en kolommen
Code (php)
1
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- je stelt de verbinding met de database via mysqli of PDO in als UTF-8 (om automatische transcoding via de driver te voorkomen)
Code (php)
1
2
3
2
3
$db = new mysqli(...);
$db->set_charset('utf8mb4');
$db->query('SET NAMES "utf8mb4" COLLATE "utf8mb4_unicode_ci";');
$db->set_charset('utf8mb4');
$db->query('SET NAMES "utf8mb4" COLLATE "utf8mb4_unicode_ci";');
- je moet een lettertype gebruiken dat de Unicode karakters ondersteunt die je wilt zien
Bij het programmeren in PHP moet je vervolgens op twee dingen blijven letten:
1.) De oudere, SBCS-functies (Single Byte Character Support) zoals strlen() en alle andere werken op byte-niveau, ze zijn niet geschikt voor UTF-8. Je moet dan de MBCS-functies (Multi Byte Character Support) gebruiken zoals mb_strlen(). PHP biedt niet voor alle SBCS-functies een MBCS-variant. Via het internet zijn libraries te vinden die PHP aanvullen.
2.) De nodige MBCS-functies van PHP werken alleen met de eerste Unicode plane en niet met de overige planes, de MBCS-functies zijn dus niet volledig Unicode compliant. Dat bemoeilijkt bijvoorbeeld gebruik van emoji en vele andere Unicode karakters. Gelukkig hebben we de meeste van die karakters niet nodig, en zijn er omwegen met notatie in andere vormen die weer ASCII-compliant zijn, en extra ruimte nodig hebben.
Hopelijk biedt PHP7 volledige ondersteuning voor Unicode, maar ik vermoed van niet anders hadden ze dat wel groots aangekondigd.
(*) Dit punt is waar het mij om te doen is bij het controleren van de $_SERVER['REQUEST_METHOD'] die door de browser wordt ingesteld. Gelukkig blijkt de tekst 'POST' altijd hetzelfde te zijn in zowel ASCII als Latin1 als Unicode.
En wellicht als tutorial? Je weet er genoeg van (of doet dat zo lijken): dan blijft het namelijk ook voor het nageslacth gebundeld bestaan ;)
Quote:
Wat ik wel steeds merk als terugkerend punt, is dat programmeurs (waaronder ikzelf) met enige regelmaat pas in een laat stadium met het begrip encoding te maken krijgen
Als je met data (uit databases of andere (externe) bronnen) werkt loop je hier toch vrij snel tegenaan.
Het "probleem" van PHP is dat het een lage instapdrempel heeft. Hobbyisten beginnen met "programmeren" voordat ze de basisbeginselen van HTML/CSS/JavaScript onder de knie hebben (laat staan dat ze een elementair begrip hebben van hoe HTTP werkt).
De truuk is ook om het simpel te houden. Een heleboel techno blabla en mensen haken af.
Een redelijk toegankelijk artikel is nog steeds: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).
En inderdaad, maak een tutorial oid, dit is best nuttige informatie allemaal, maar hier is niet de plaats om al dit soort kennis (hoe nuttig ook) te etaleren. Because off topic.
En ik weet er inderdaad het nodige van omdat ik een paar jaar geleden ook op het punt kwam dat mijn zelfgeschreven programma bugs had met data en diakritische tekens.
Dit probeerde ik eerst ook op Eddy's manier op te lossen, maar wat ik aan de ene kant oploste ging aan de andere kant weer fout; en dat allemaal omdat ik niet volledig bewust was van encoding. Met als gevolg dat ik het na liet om op alle punten transcoding te doen.
Het heeft me dagen gekost om de bugs en de corrupt geraakte data in de database te herstellen. Na het instellen van Unicode als UTF-8 op de database, database driver, PHP, HTML (en CSS...) waren alle problemen als sneeuw voor de zon verdwenen.
Het herstellen van vertrouwen van gebruikers in het programma duurde ietsje langer, want voor de gebruikers is de data veel belangrijker dan het programma. Gelukkig is ook dat weer goedgekomen.