Es gab in meinem Leben bisher nichts, womit ich so viel Zeit verschwendet habe wie mit Encoding Problemen.

Für mein aktuelles Projekt entwickle ich zur Zeit einen crawler, der Websites zieht und analysiert. Natürlich bin ich da direkt auf sämtliche Encoding-Problemchen gestoßen, die man sich nur vorstellen kann und hatte unglaublich viel Spaß damit …

Ich verwende das Zend Framework und daher entsprechend die Klasse Zend_Http_Client um die HTTP-Requests abzusetzen.
Danach suche ich den Inhalt der Seite raus, sodass lediglich ein String ohne HTML-Tags und damit reinem Text übrig bleibt.
Gebe ich mir diesen nun einfach auf die Shell aus, stimmt das Encoding manchmal und manchmal nicht. Das sieht man dann immer schön an den kaputten Umlauten.

Also habe ich eine Funktion gebraucht, die das Encoding eines Strings konvertiert … Tja, wenn es denn so einfach wäre …
Die letzten Tage habe ich rund 20 Stunden damit verbracht eine Funktion zu schreiben, welche dafür sorgt, dass der String, der am Ende rauskommt, sauber dargestellt wird – unabhängig davon, was rein kommt. Das Problem hier war in erster Linie, dass selbst Strings, die sich als UTF-8 ausgegeben haben und von denen sogar mb_check_encoding() behauptet hat, es sei alles in bester Ordnung, haben kaputte Umlaute mit sich getragen. Also darauf konnte man sich schonmal gar nicht verlassen.

Ich möchte hier das Ergebnis meiner Arbeit mit euch teilen. Nicht erschrecken, es ist keine saubere Lösung (die sauberen Implementierungen haben allesamt nicht funktioniert). Der Code deckt auch nicht alle denkbaren Fälle ab, aber ich konnte bisher jeden beliebigen kaputten String mit deutschem Text und explodierten Umlauten in einen lesbaren String mit intakten Umlauten konvertieren. Da das mehrere 100 Texte aus verschiedensten Quellen aus dem Netz waren, behaupte ich mal, dass der Code recht brauchbar ist. Im Zweifelsfall dient er als gute Basis für eine umfassendere Implementierung.

Der Methode magicFixStringEncoding() kann man also einen beliebigen  String übergeben unabhängig davon ob er völlig in Ordnung ist oder total verstümmelt. Die Rückgabe der Methode sollte immer einen sauberen String mit funktionierenden Umlauten entsprechen.

Für Verbesserungsvorschläge bin ich jeder Zeit offen. Annsonsten viel Spaß denen, die den Code gebrauchen können

 

 

class ITWS_Tool {
	public static function magicFixStringEncoding($strInput) {
		if (preg_match('/[üäöÄÖÜß]/i', $strInput) === 1) {
			$strInput = self::convertEncoding($strInput, 'UTF-8');

			if (strlen(utf8_decode($strInput)) !== strlen(utf8_decode(utf8_decode($strInput)))) {
				$strInput = utf8_decode($strInput);
			}
		} else {
			$strInput = self::convertEncoding($strInput, 'UTF-8', 'ISO-8859-15');
		}

        return $strInput;
    }

    public static function convertEncoding($strInput, $toEncoding, $fromEncoding = '') {
        if ($fromEncoding == '') {
            $fromEncoding = mb_detect_encoding($strInput, array('UTF-8', 'ASCII', 'ISO-8859-1', 'JIS', 'EUC-JP', 'SJIS'), true);
		}

        if ($fromEncoding == $toEncoding) {
            return $strInput;
		}

        return mb_convert_encoding($strInput, $toEncoding, $fromEncoding);
    }
}

Im nächsten PHP Release gibt es ein neues Feature für horizontalen Code Reuse: sog. Traits (engl. Merkmal, Charakterzug). Was das ist und wie es funktioniert, erfahrt ihr im folgenden Artikel.

Vererbung: Vertikaler Code Reuse

class A {
	public function foo() { ....}
}

class B extends A { }

Bei der objektorientierten Vererbung werden alle nicht-privaten Methoden und Attribute einer Klasse auf die Kind-Klasse vererbt. Das ist toll, denn so braucht man viele Methoden nur einmal zu implementieren, kann sie aber in vielen verschiedenen Klassen wiederverwenden. Das ist vertikaler Code Reuse. Tolle Sache, kein Thema.

Dennoch gab es ein paar Dinge, die sich mit einfacher Vererbung nicht umsetzen ließen. z.B. eine Basis-Klasse für das Singleton-Pattern. Gerade in PHP ist das Hauptproblem hier, dass keine Mehrfach-Vererbung möglich ist – also eine Klasse nicht von mehr als einer anderen Klasse abgeleitet werden kann. Das zwingt uns leider oft dazu, dass wir uns der unangehmen Entscheidung stellen müssen, ob wir nun konzeptionell sauberen Code oder aber möglichst gute Wiederverwendung von Code haben wollen. Um dennoch irgenwie horizontalen Code Reuse zu realisieren mussten Methoden kopiert werden (also praktisch kein Reuse) oder Methoden bis in die Wurzel der Klassen-Hierarchie geschoben werden, was alles andere als schön ist.

(weiterlesen …)

Gestern war ich auf der Suche nach einem neuen geeigneten Framework für ein Projekt (bisher Codeigniter verwendet, aber das hat nie so ganz meinen Bedürfnissen entsprochen). Nach dem ich nochmal auf die Websites von codeigniter 2.0, cakePHP, akelos etc. gesurft bin und jeweils einen Blick reingeworfen habe, habe ich beschlossen mich mal von meinem Vorurteilen zu befreien und mir das Zend Framework anzusehen.

Vor diesem Framework habe ich mich lange Zeit zurückschrecken lassen, da ich der Ansicht war, dass das nur ein Haufen sinnlos zusammengestückelter PHP Files ist und das praktische Arbeiten mit dem ZF nicht besser aussieht.

Aber man muss auch mal über seinen Horizont hinausblicken, weswegen ich mir mal die Dokumentation des Frameworks angesehen habe. Erst auf deutsch. Dann auf englisch, weil die Übersetzung so schlecht ist, dass ich viele Sätze fünfmal lesen musste, bis ich sie verstanden habe
Den Quickstart Guide fand ich bis zu einem gewissen Punkt sehr gut, dann wurd es aber sehr schwammig und viele wichtige Punkte haben gefehlt, weswegen ich den Guide an dieser Stelle verlassen habe und beschlossen habe die Dokumentation zu lesen. Auf englisch natürlich. Die Doku ist soweit also nicht ideal aber auch nicht ausgesprochen schlecht.

Das Framework an sich ist deutlisch komfortabler als ich dachte, das autoloading erspart viel Arbeit und die saubere objektorientierte Implementierung der Komponenten ist wirklich gut.

Bisher sieht es also ganz danach aus, als würde ich das anstehende Projekt mit dem Zend Framework umsetzen. Das hat verschiedene Konsequenzen. Zu erstmal bin ich froh, diesen Schritt getan zu haben und mich endlich mit dem Framework zu befassen. Zum Anderen wird mir das wohl auch einiges an Stoff liefern, über den ich hier im Blog schreiben kann und zum anderen kann ich endlich mal wieder ein Projekt starten und habe was zum coden. Wurde auch mal wieder Zeit.

Angeregt durch den Artikel Die "Vor- und Nachteile von PHP" auf entwickler.de, möchte ich eine bestimmte Aussage hier nochmal aufgreifen und am Ende meine leicht provokante Meinung dazu abgeben.

Dennis Becker gab folgendes Kommentar zu dem besagten Artikel auf entwickler.de ab:

 

 

 

PHP hat einen großen Nachteil: der Zwang, abwärtskompatibel zu bleiben. In Ruby & Python sehen ich gleich gute Alternativen, besser würde ich aber nicht sagen. PHPs Problem liegt einfach in der Vergangenheit und für die urspürngliche Kernaufgabe, für die es entwickelt wurde: Form Handling und Database Communication. Ruby & Python wurden von Anfang an mit einem viel größeren Scope entwickelt!

(weiterlesen …)

Oft liest man, dass man bestimmte Verzeichnisse in den sog. include path aufnehmen soll oder im include path irgendwelche scripts ablegen soll und das meist ohne weitere Erklärung. Der Include Path und das Administrieren des Selbigen gehört also mehr oder weniger zu den Grundkenntnissen. Dennoch ist es für viele ein Mysterium.
Da ich gestern ein wenig damit gearbeitet habe, dachte ich, ich blogge mal ein wenig drüber. Warum? Weil ichs kann. Und weil ich eine kleine Hilfestellung zum Thema path im Allgemeinen und dem PHP include path im Speziellen zur Verfügung stellen möchte.

(weiterlesen …)