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.

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);
    }
}

Ähnliche Artikel

• PHP 5.4 Feautre: Traits – Horizontaler Code Reuse
• Den Horizont erweitern: Das Zend Framework
• [PHP] Der include path

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.

Traits: Horizontaler Code Reuse

Abhilfe schaffen hier in PHP 5.4 die sogenannten Traits, welche bereits in Perl 6 oder Scala zur Verfügung stehen. Sie erlauben es dem Entwickler Behaviors (also Verhalten) in Code zu gießen. Diese Traits funktionieren im Prinzip wie Klassen können jedoch – ähnlich wie Interfaces und abstrakte Klassen – nicht instanziiert werden.

Sie sind dazu gedacht, Funktionalitäten zu gruppieren. Einer der Vorteile ist, dass eine Klasse mehrere Traits verwenden kann. Traits beheben somit einige Probleme von single inheritance Sprachen wie PHP oder Java.

Um das eben angesprochene Singleton-Pattern-Problem zu lösen genügt nun ab PHP 5.4 folgene Klassen-Definition:

trait Singleton {
    public static function getInstance() { ... }
}

class A {
    use Singleton;
    // ...
}

class B extends ArrayObject {
    use Singleton;
    // ...
}

// Beide Klassen verwenden nun das Singleton Trait und implementieren somit das Singleton-Pattern:
A::getInstance();
B::getInstance();

Es wird noch besser: Wie bereits erwähnt, kann eine Klasse kann beliebig viele Traits verwenden. Da stellt sich der aufgeweckte Coder natürlich die Frage:

Was passiert bei Konflikten?

Sprich: Was passiert, wenn zwei Traits verwenden werden, die beide eine Methode mit der selben Signatur definieren?

trait A {
    public function foo() {
        echo 'a';
    }

    public function bar() {
        echo 'A';
    }
}

trait B {
    public function foo() {
        echo 'b';
    }

    public function bar() {
        echo 'B';
    }
}

class C {
    use A, B;
}

Dazu ist folgeneds zu sagen: Traits werden bereits in einigen Sprachen verwendet und es hat sich gezeigt, dass Konflikte zwar auftreten aber das eher die Ausnahme darstellt. Dennoch muss es natürlich ein definiertes Verhalten geben, das vorschreibt, was passieren soll, wenn Konflikte auftreten.

Diese Konfliktlösung sieht hier wie folgt aus:

Erstmal wirft PHP eine Warning um dem Entwickler darauf aufmerksam zu machen, dass ein Konflikt aufgetreten ist. Und gibt dazu auch die Info, wo der Konflikt genau auftritt. In dem Fall würde es die beiden Methoden foo() und bar() melden.

Und das ist auch gut so, denn keine der beiden Methoden werden in Klasse C zur Verfügung stehen! Richtig, die Konfliktlösung sieht vor, dass alles, was einen Konflikt erzeugt, rausfliegt.

PHP zwingt uns damit, die Traits ordentlich zu verwenden und PHP zu sagen, was wir aus welchem Trait haben wollen:

class C {
    use A, B {
        B::foo instead A;
        A::bar instead B;
    }
}
?>

Dieser Code bewirkt folgendes Verhalten: Klasse C erhält aus Trait B die Methode foo() und aus Trait A die Methode bar().
Entsprechend würde ein Aufruf der beiden Methoden auf Klasse C “b” und “A” ausgeben.

Das ist zwar cool, aber dennoch nicht die sauberste Lösung. Es gibt Alternativen: So kann der Entwickler auch Aliase vergeben:

class C {
    use A, B {
        B::foo instead A;
        A::bar instead B;
        B::bar as bar2;
    }
}

Ok, ich gebe zu, dass sich die Beispiele jetzt nicht gerade durch Kreativität auszeichen, aber solange man erkennen kann um was es geht, reicht das

Klasse C würde nach diesem Beispiel nun zusätzlich eine Methode bar2() besitzen, welche der bar()-Methode von Trait B entspricht.

Fazit

Kombiniert man die OOP und ihre Features (Vererbung, Interfaces, Namespaces, Kapselung) nun mit den Traits kann man problemlos PHP-Anwendungen implementieren, die streng dem DRY-Prinzip folgen und gleichzeitg eine konzeptionell saubere Klassen-Hierarchie besitzen.

Es gibt hierzu noch ein wenig mehr zu sagen, aber das ist erstmal das Wichtigste. Alles Weitere kann ich gerne noch in einen zweiten Artikel erklären

over and out

Ähnliche Artikel

• Schei? Encoding …
• Den Horizont erweitern: Das Zend Framework
• [PHP] Der include path

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.

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.

Ähnliche Artikel

• YAP: Framework-Wahl
• Zend Framework Resourcen
• Schei? Encoding …

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!

Meiner Meinung nach ist das der springende Punkt: Eine Anforderung an PHP ist die Abwärtskompatibilität und genau das ist auch eine Schwäche, da hier nicht nur Altlasten existieren sondern auch einige Konzepte wie eine etwas stärkere Typisierung etc. nur schwer umzusetzen sind. Dass Ruby und Python oft als bessere Sprachen angepriesen werden, liegt daran, dass diese mit anderen Anforderungen entwickelt wurden.

Meiner Meinung nach, wäre ein Fork von PHP mal ne wirklich coole Sache. In diesem Fork könnte man stärkere Typisierung implementieren, die OOP von PHP etwas ausweiten, die ganze Altlast entfernen und in der API durchgehend für Konsistenz sorgen und – ähnlich wie Ruby und Pyhton – könnte man auf einem ganz anderern Niveau ansetzen als PHP damals in seiner ersten Version. Das klingt nun etwas Wahnsinnig, aber eine solcher Fork hätte durchaus das Potential die aktuellen Favoriten in Sachen Scriptsprachen abzulösen. Vorausgesetzt man lässt die Erfahrungen aus Ruby, Python und PHP 5.3 einfliesen und lässt die historisch-bedingten Aspekte der Sprache entfallen.

Ich würde es ja selbst machen, mir fehlt nur leider die Zeit

So, das reicht an verrückten Behauptungen für einen Tag …

Ähnliche Artikel

• YAP: Framework-Wahl
• Zend Framework Resourcen
• Debian: Von Apache zu Nginx – Teil 3: PHP

Was ist ein (include) path?

Das Wichtigste vorweg: was ist ein path eigentlich? Der path ist eine Variable, welche einem System eine Sammlung von Verzeichnis-Pfaden angibt. In diesen Verzeichnissen sucht das System Bibilotheken oder ausführbare Dateien. Linux beispielsweise verwaltet den  path in der PATH-Variable welche wie folgt aussieht:

[ghost@spacebox ~]$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/var/lib/gems/1.8/bin

Die Verzeichnisse werden durch einen Doppelpunkt ":" getrennt.

Gibt man in der BASH nun einen Befehl ein, durchsucht das System die Verzeichnisse, welche im PATH angegeben sind, ob eine ausführbare Datei existiert, deren Namen dem eingegeben Befehl entspricht und führt dieses script oder diese binary im Anschluss daran aus.

In PHP gibt es auch einen path: den include path. Diese Variable wird in der php.ini gesetzt und gibt die Verzeichnisse an, in denen include-Dateien zu finden sind.

Wie funktioniert der include path?

Verwendet man in seinem script nun require, require_once, include oder include_once, versucht PHP den Dateinamen in den, im include path angegebenen, Verzeichnissen zu finden. Da der erste Eintrag im include path "." ist, welcher dem aktuellen Arbeitsverzeichnis des scripts entspricht, durchsucht PHP dabei zuerst das Verzeichnis, in dem das Script ausgeführt wird.

Wie trage ich ein Verzeichnis in den include path ein?

Wir bereits erwähnt, wird der include path in der php.ini gesetzt. Die entsprechende Variable kann jederzeit um weitere Pfade erwetiert werden.

Beispiel:

include_path = ".:/usr/share/php"

wird zu:

include_path = ".:/usr/share/php:/usr/lib/php"

Des Weiteren gibt es die Möglichkeit, den include path für das aktuelle Script anzupassen. Dazu stehen die Funktionen set_include_path() und get_include_path() zur Verfügung.

Beispiel:

<?php
    
    set_include_path(get_include_path() . ':/usr/lib/php');

Mit der Funktion restore_include_path() kann der originale include path wiederhergestellt werden.

Zusätzliches know how

Auch die Funktionen fopen, file, file_get_contents und readfile verwenden den include path!

Ich hoffe, ich konnte euch das Thema path etwas näher bringen. Fragen dürfen natürlich gerne als Kommentar verfasst werden

Ähnliche Artikel

• [Linux] Apache/MySQL/Eclipse PDT unter Ubuntu einrichten
• Debian: Von Apache zu Nginx – Teil 3: PHP
• Debian: Von Apache zu Nginx – Teil 1: Vorwort