Linux & Apache2 & UTF-8 Encoding

Ja, PHP ondersteunt dat niet. Je PHP-code zelf moet _NIET_ als UTF-8 worden opgeslagen. Het staat misschien ook ergens bij de requirements, heb het ergens eerder voorbij zien komen. Het punt is dat je bij de output van je PHP script wel een encoding op kan geven, maar je kunt dat niet doen voor het PHP script. Ergo, er is nergens een manier om te zeggen "mijn PHP script is in encoding 'EBCDIC codepage 1140'".
De PHP parser kijkt helemaal niet naar al die bytes alsof het letters zijn, maar behandelt ze als anonieme bytecode sequence. Nouja, anoniem, het verwacht van de PHP files dat ze in Latin1 zijn (welke Latin1 zou ik moeten opzoeken). Dus als je een PHP file opslaat als UTF-8, en je editor plakt daar vooraan nog een Byte Order Mark aan vast, dan zal PHP daar iets mee proberen te doen, of alvast sturen naar de browser. Als je nog andere unicodekarakters hebt die toevallig een byte sequence vormen die PHP herkent dan gebeuren er spannende dingen.
Meestal gaat het goed omdat normale UTF-8 grotendeels backward compatible is met ASCII, maar met exotischer karakters weet je het nooit.

Mijn broer kwam aanzetten met een Raspberry PI 2. Grappig dingetje. Een piep klein PC'tje. 50 euro maar. Er draait nu Debarian GNU/Linux op.
Is er ook een LAMP Server voor zo'n Raspberry ? Zou wel handig zijn.

[size=xsmall]Toevoeging op 24/05/2015 20:32:51:[/size]

Ik heb er nu een MineCraft Servertje op draaien. LOL

LAMP is niet één server maar een combinatie van Apache (webserver), MySQL en PHP op Linux. Op internet zijn er veel tutorials aan gewijd om een dergelijke webserver op te zetten.

Zie ook:
http://www.wikihow.com/Make-a-Raspberry-Pi-Web-Server

Php kan wel degelijk met scripts werken die in utf8 zijn opgeslagen.
Bijvoorbeeld erg handig als je hardcoded string met letters als ö of ß in je tekst hebt staan.

Gebruik je mogelijk een verkeerde variant van utf8? Met of zonder BOM?

@Paco de Wulp -->Is er ook een LAMP Server voor zo'n Raspberry ?
Raspberry is Linux en daar draai je geen LAMP dinges op. Op de Raspberry linux (er zijn diverse linux images) draai je gewoon apache2, MySQL, ftp server, sftp server, sshh en andere handige linux tooling.
Zie: https://www.raspberrypi.org/documentation/remote-access/web-server/apache.md

@Aad B LAMP staat voor: Linux Apacache MySQL Python/Perl/PHP....... (https://en.wikipedia.org/wiki/LAMP_%28software_bundle%29)

An tje op 24/05/2015 19:59:09

Je PHP-code zelf moet _NIET_ als UTF-8 worden opgeslagen.

Volgens mij is dat (idd) BS. Je kunt PHP-bestanden prima UTF-8 encoded opslaan (minus BOM).

En als je denkt dat dat niet hoort, hoe verklaar je dan dat de meeste IDE's dit standaard (minus BOM) doen?

Volgens mij is het zelfs zo dat alle karakters die speciale betekenis hebben in PHP (> < ? $ etc.) vallen onder het standaard ASCII repertoire, en dus op byteniveau dezelfde encoding hebben (zowel in UTF-8 alsmede ISO-8859-1). Oftewel: voor "standaard PHP code" zou dit voor de werking geen drol uit moeten maken in welke character encoding je code opslaat.

Het probleem komt dus waarschijnlijk ergens anders vandaan.

Het is natuurlijk interessant om te weten:
- welke editor + instellingen je gebruikt
- welke code voor problemen zorgt
- misschien versies van de verschillende onderdelen, en welke modules je gebruikt?

Zonder deze informatie blijft het gissen.

An tje op 24/05/2015 19:59:09

Ja, PHP ondersteunt dat niet. Je PHP-code zelf moet _NIET_ als UTF-8 worden opgeslagen.
...
Meestal gaat het goed omdat normale UTF-8 grotendeels backward compatible is met ASCII, maar met exotischer karakters weet je het nooit.

Thomas van den Heuvel op 25/05/2015 19:23:31

Volgens mij is het zelfs zo dat alle karakters die speciale betekenis hebben in PHP (> < ? $ etc.) vallen onder het standaard ASCII repertoire, en dus op byteniveau dezelfde encoding hebben (zowel in UTF-8 alsmede ISO-8859-1). Oftewel: voor "standaard PHP code" zou dit voor de werking geen drol uit moeten maken in welke character encoding je code opslaat.

Het probleem komt dus waarschijnlijk ergens anders vandaan.

Het is natuurlijk interessant om te weten:
- welke editor + instellingen je gebruikt
- welke code voor problemen zorgt
- misschien versies van de verschillende onderdelen, en welke modules je gebruikt?

Zonder deze informatie blijft het gissen.

Hoewel het probleem zichzelf oplost als ik de document op een andere encoding op sla, deel ik de de mening van Thomas wel. Daarom deze vraag ook.
In mijn eerste post melde ik al dat:
<?php
echo 'hello';
?>
Gewoon in de bronvermelding komt zonder uitgevoerd te worden.
Zelfde bestand met ISO encoding werkt prima.

Server info:
PHP Version 5.5.12-2ubuntu4.4

Modules:

core mod_so mod_watchdog http_core mod_log_config mod_logio mod_version mod_unixd mod_access_compat mod_alias mod_auth_basic mod_authn_core mod_authn_file mod_authz_core mod_authz_host mod_authz_user mod_autoindex mod_deflate mod_dir mod_env mod_filter mod_mime prefork mod_negotiation mod_php5 mod_setenvif mod_status

Editors:
gedit & bluefish standaard instellingen.

Er zijn wat varianten 'utf8'.
Heb je de juiste? Welke dan?

Even kort, want ik heb vandaag niet de tijd om veel te zoeken of te testen maar:

Waar staat eigenlijk dat PHP wél met UTF-8 goed kan omgaan?

Ik heb daar nog steeds geen bindende uitspraak over gelezen in een of andere manual. Wel meningen. Maar dat zegt me niets, want hoe wordt er gewaarborgt dat code in UTF-8 altijd goed wordt afgehandeld? Mijn vorige educated guess blijft overeind:
- als PHP al niet met een BOM overweg gaat, waarom zou het dan wel met UTF-8 overweg kunnen
- waar staat met welke UTF-8 en welke versie(s) van Unicode PHP overweg kan? Is het alleen de BMP, of ook de SMP, of ook de andere planes?
- als PHP goed met unicode overweg kan, HOE detecteert het de encoding?
- met welke encodings kan PHP niet overweg?
Bv., als je een exotische .php file hebt met een of andere EBCDIC encodering die vooral NIET ASCII compatible is, gaat het dan ook goed? (EBCDIC codepages zijn onderling niet eens compatible)
- als PHP met Unicode kan omgaan, waarom zijn de mb_* functies dan nodig, en:
- waarom staan daar de nodige beperking in vermeld bij "PHP Character Encoding Requirements" / http://php.net/manual/en/mbstring.php4.req.php voor bijvoorbeeld alleen de Standard ASCII set en niet de Extended ASCII set?

Hoewel mijn geheugen menselijk is en dus feilbaar wil nog niet zeggen dat mijn argumenten, zoals Thomas denkt, BS zijn. Sarcastisch: natuurlijk kan iedereen een PHP file met UTF-8 opslaan en natuurlijk gaat dat altijd goed, want PHP kan daar gewoon mee overweg. PHP snapt automatisch dat het UTF-8 is, en welke. Daarom hebben we deze thread op het forum, toch? ...

Ik verwacht niet dat dit soort dingen automagisch goed gaan, omdat misschien PHP's module van Apache het getranscodeerd aangeleverd krijgt. Dan zou ik verschilen verwachten met de CLI versie.
Volgens mij is PHP gewoon agnostisch tov. encoding en kijkt het alleen maar naar bepaalde byte sequences binnen de PHP tags. Totdat iemand het even grondig uitzoekt (ipv een mening geeft) of even test, door met een andere of niet ASCII-compatible encoding op te slaan en te kijken of alles nog steeds goed gaat blijft het koffiedik kijken.

Gezien de populariteit van functies als utf8_encode() verwacht ik dat PHP scriptbestanden als met de encoding ISO/IEC 8859-1 (Latin1) moeten worden opgeslagen.