Kurzanleitungen/Howtos

Verschiedenes zu PHP

24.11.2018

PHP-Logo
Colin Viebrock
CC-BY-SA

Dies wird ein Sammelartikel zu PHP-Problemen, die in der Lösung relativ einfach sind, mich aber beim Finden der Lösung einige Zeit gekostet haben.

Zeichensatzprobleme

Beim Aktualisieren der Linux-Distribution und der PHP-Version kann es zu Problemen mit dem Zeichensatz kommen, da jetzt standardmäßig UTF-8 oft verwendet wird.
Sind die Seiteninhalte oder der PHP-Quelltext in einer anderen Kodierung gespeichert (z.B. ISO-8859-1), kommt es zu Darstellungsfehler (z.B. bei Umlauten). Damit die Seiten wieder korrekt angezeigt werden, gibt es z.B. folgende Möglichkeiten:

  • Systemweite Änderung der Kodierung für den PHP-Interpreter unter Apache: Fügen Sie hierzu die Zeile
    php_value default_charset "ISO-8859-1"
    in Ihrer Apache-PHP-Konfigurationsdatei (z.B. /etc/php/7.0/apache2/php.ini unter Debian 9) hinzu und starten Sie Apache neu.
  • Setzen der Kodierung in allen Skripten, die im Browser aufgerufen werden, durch Einfügen der folgenden Zeile am Skriptanfang:
    ini_set('default_charset', 'iso-8859-1');
  • Umkodierung aller Skripte. Beispielsweise mit recode:
    find /var/www/meineSeite -type f | xargs -n1 recode ISO-8859-1..utf-8
    sed -i 's/ISO-8859-1/UTF-8/' /var/www/meineSeite/index.php
    

Schlüsselangaben bei assoziativen Arrays korrigieren

Kate unter TDE
Texteditor Kate unter TDE

Was nicht korrekten Code angeht, ist der PHP-Interpreter ziemlich gutmütig und gibt in vielen Fällen nur eine Warnung aus.
Bei assoziativen Arrays müssen die Schlüssel eigentlich Zeichenketten – also umschlossen von Anführungszeichen oder Hochkommata – sein. Somit wäre folgender Code eigentlich als fehlerhaft zurückzuweisen:

$a[schluessel] = 'wert';
Korrekt wäre hingegen:
$a['schluessel'] = 'wert';
Wenn man viel alten Quelltext hat, wird das manuelle Ändern der betreffenden Stellen schnell zur Sysiphusarbeit. Glücklicherweise bieten aber viele Editoren "intelligente" Suchen- und Ersetzen-Funktionen mit regulären Ausdrücken. Für den Texteditor Kate des Trinity Desktop Environments werden die folgenden beiden Ausdrücke verwendet.
Zum Suchen:
\[([a-zA-Z_0-9]*)\]
Zum Ersetzen:
['\1']

Schreiben nach /tmp unerwünscht

PHP-Skripte, die Dateien nach /tmp schreiben, funktionieren (auf neuen Distributionen) nicht mehr. Greift man mit dem Browser auf ein entsprechendes Skript zu, so zeigt der Browser nur eine andauernde Ladeanimation, aber niemals einen Seiteninhalt.
Dies Verhalten liegt daran, daß Apache (und somit auch der PHP-Interpreter) über systemd so konfiguriert wird, daß er nicht in /tmp schreiben darf. Dies mag aus Sicherheitsgründen wünschenswert sein, kann im Einzelfall aber zu Irritationen (und einer längeren Suche nach der Fehlerursache) führen. Letztendlich gibt es zwei Möglichkeiten zur Lösung des Problems:

  1. Die Dateien in ein anderes Verzeichnis schreiben.
  2. Die Sicherheitsfunktion deaktivieren:
    sed -i 's/PrivateTmp=true/PrivateTmp=false/g' /lib/systemd/system/apache*
    systemctl daemon-reload
    /etc/init.d/apache2 restart

Fließkommazahlen in SQL-Statements

Wenn man innerhalb von PHP-Skripten mit Fließkommazahlen (float) rechnet und die so errechnete Zahl in einem SQL-Statement verwendet, wird sie automatisch in eine Zeichenkette umgewandelt. Beim Umwandeln wird anscheinend die länderspezifische Schreibweise (Komma oder Punkt zum Trennen von Vor- und Nachkommastelle) verwendet. In SQL-Statements ist aber anscheinend die Punkt-Trennung zwingend notwendig. Möglicherweise läßt sich das Verhalten auch irgendwo konfigurieren. Einfacher ist es ‐ durch einfache Zeichenersetzung ‐, die Zahl mittels str_replace in das richtige Textformat umzuwandeln:

$floatZahl = (float)(((float)17)/((float)48));
$SQLZahl = str_replace(',', '.', $floatZahl);

Achtung! Achtung! Die folgenden Anweisungen richten sich ausschließlich an fachkundige Personen. Bei jedem Schritt kann es zum kompletten Datenverlust kommen. Alle Angaben ohne Gewähr!