Neues OnPage Analysierungstool

madeby · **madeby** » 03.03.2014, 13:58 **Neues OnPage Analysierungstool**

Mich würde auch interessieren, woher die Infos kommen, also von welcher Unterseite. Also z.B. bei uns steht, "Werbung vorhanden"
Wir haben aber keine Werbung auf unserer Seite.
Jetzt muss dein Tool ja nicht falsch liegen, auch wenn Beta.

Nur würde mich das jetzt interessieren, da wir vor 7 Monaten einen Hack hatten und bei uns auf der Seite Werbung plaziert wurde. Auch Unterseiten.. vielleicht befindet sich ja noch irgendwo ein Restcode.

Kristian · **Kristian** » 03.03.2014, 18:13 **Neues OnPage Analysierungstool**

Hallo,

Webtrixx hat geschrieben:@SloMo: Umlaute,entities und tags sollten jetzt auch keine probleme mehr machen

Da ich vermute, dass das Tool in PHP gecodet wurde würde ich bei solchen Aussagen vorsichtig sein.
PHP kann die 256 Zeichen des aktuell gewählten Zeichensatzes - I18N - nach UTF-8 konvertieren.
Wenn es mehr sein soll, muss man eine Sprache wählen, die wirklich UTF-8 kann.
UTF-8, 1.114.112 Möglichkeiten

Viel Erfolg und auf gute Konkurrenz.

Gruß
Kristian

Webtrixx · **Webtrixx** » 04.03.2014, 02:28 **Neues OnPage Analysierungstool**

Kleines Update:

- Keywordanalyse verbessert.
- LongTail-Keywords nocht nicht ausgereift jedoch stark verbessert

@madeby: ich werd mir das mal anschauen... aber gehe bitte mal davon aus, dass es unser Werbefilter ist, der etwas falsch interpretiert.

SloMo · **SloMo** » 04.03.2014, 08:38 **Neues OnPage Analysierungstool**

Kristian hat geschrieben:Da ich vermute, dass das Tool in PHP gecodet wurde würde ich bei solchen Aussagen vorsichtig sein.

Man muss natürlich die richtigen Funktionen nutzen und auf sowas wie utf8_encode() bzw. utf8_decode() verzichten. PHP kann das schon ganz gut, nur die meisten Entwickler nicht ;)

https://de3.php.net/manual/de/ref.mbstring.php

Bei Online-Dokumenten ist eigentlich das Hauptproblem, dass sehr häufig das falsche Encoding behauptet wird. Da steht dann UTF-8 im Header, der Content ist aber bis 255 in ISO-Codierung mit Einmischung von Entities usw... also richtige Moppelkotze die man dann so gut wie möglich entwirren muss. Ich finde das ist eine der größten Herausforderungen beim Scrapen.

Meine Herangehensweise ist immer, erstmal alle Dokumente in den UTF8-Raum zu verschieben. Danach kann man falls nötig auf die teuren MB-Funktionen zurückgreifen oder den Code komfortabel per preg_match(_all) zerpflücken. Mehr braucht es eigentlich nicht.

Hoffe es hilft.

Kristian · **Kristian** » 04.03.2014, 10:05 **Neues OnPage Analysierungstool**

SloMo hat geschrieben:
Kristian hat geschrieben:Da ich vermute, dass das Tool in PHP gecodet wurde würde ich bei solchen Aussagen vorsichtig sein.
Man muss natürlich die richtigen Funktionen nutzen und auf sowas wie utf8_encode() bzw. utf8_decode() verzichten. PHP kann das schon ganz gut, nur die meisten Entwickler nicht

https://de3.php.net/manual/de/ref.mbstring.php

Bei Online-Dokumenten ist eigentlich das Hauptproblem, dass sehr häufig das falsche Encoding behauptet wird. Da steht dann UTF-8 im Header, der Content ist aber bis 255 in ISO-Codierung mit Einmischung von Entities usw... also richtige Moppelkotze die man dann so gut wie möglich entwirren muss. Ich finde das ist eine der größten Herausforderungen beim Scrapen.

Meine Herangehensweise ist immer, erstmal alle Dokumente in den UTF8-Raum zu verschieben. Danach kann man falls nötig auf die teuren MB-Funktionen zurückgreifen oder den Code komfortabel per preg_match(_all) zerpflücken. Mehr braucht es eigentlich nicht.

Hoffe es hilft.

Ich stimme mit jein zu.
Die von dir referenzierte Seite sagt nicht aus, das PHP jetzt UTF-8 kann.
Ok, um zu helfen:
Es ist immer sinnig, alle Angaben, die ISO-8895-1 oder ISO-8859-15 vermuten lassen, als Windows-1252 zu parsen, damit erschlägt man schon mal die Hälfte der "Seltsamkeiten".
Ansonsten, ich bleibe dabei, wenn du UTF-8 willst musst du eine Sprache nehmen, die es kann. PHP wird es vor 6.0 nicht können.

Webtrixx · **Webtrixx** » 04.03.2014, 11:42 **Neues OnPage Analysierungstool**

@SloMo und @Kristian: Ich stimme euch beiden zu. Der Umstand von UTF ist mit PHP wirklick nicht leicht zu händeln. Das Problem was ich hatte (und hoffe, dass ich es nicht mehr habe) war, dass eine Seite einen UTF Header aufwies aber mit allen möglichen Varianten bestückt war (ISO-8895, Entities,Specialchars, UTF8). Da hat der Crawler seinen Dienst quittiert.

Durch die Verwendung von den mbstring (mb_detect_encoding,mb_convert_encoding etc. etc.) hatte ich alles auf den selben Nenner gebracht, auf UTF8 getrimmt und die Htmlenitities dekodiert womit mit ich dann alles einheitlich hatte. Jedoch wie Kristian schon erwähnte, sind 2-3 Charakter dabei gewesen, die sich nicht behandeln liessen (aber dies kann man vernachlässigen). Sollte dies doch zu einem Problem werden, werde ich den Quellcode durch ein externens Script parsen lassen.

P.S. bin am überlegen ob ich das Tool nicht umbaue als eine "permante" OnPage Analyse ala Google Analytics, so dass eingetragene Seiten inkl. aller Unterseiten stetig analysiert werden.

SloMo · **SloMo** » 04.03.2014, 11:43 **Neues OnPage Analysierungstool**

Kristian hat geschrieben:Ansonsten, ich bleibe dabei, wenn du UTF-8 willst musst du eine Sprache nehmen, die es kann. PHP wird es vor 6.0 nicht können.

Nö sorry Kristian, das ist Unfug. Natürlich muss man als Programmierer seine Datentypen im Blick haben. Wer auf UTF-8-Strings mit alten PHP-Funktionen wie strlen() etc. einprügelt, ist halt selbst schuld. Man kann es auch richtig machen und die Multibyte-Extenstion nutzen. Die ist auch bei jedem ordentlichen Hosting an Bord.

SloMo · **SloMo** » 04.03.2014, 11:50 **Neues OnPage Analysierungstool**

Webtrixx hat geschrieben:Jedoch wie Kristian schon erwähnte, sind 2-3 Charakter dabei gewesen, die sich nicht behandeln liessen

Fehlerresistenz ist alles, was da hilft. Witzig sind auch nicht-abgeschlossene Entities. Wenn Du plötzlich uuml und auml aus Top-Keywords hast, muss es nicht an Deinem Algo liegen. Dann hat vielleicht nur wieder ein Webbastler das Semikolon vergessen.

Webtrixx · **Webtrixx** » 04.03.2014, 12:05 **Neues OnPage Analysierungstool**

@SloMo: Stimmt... ist mir schon öfter aufgefallen, dass man mal das ";" gern vergisst. Doch nichts desto trotz muss ich schauen, das ich diese Fehler irgendwie abfange.

SloMo · **SloMo** » 04.03.2014, 12:11 **Neues OnPage Analysierungstool**

Du kannst schwer alle Dummheiten ausbügeln, aber Du kannst auf Probleme im Encoding hinweisen. Ist ja auch ein gravierender Onpage-Fehler.

Webtrixx · **Webtrixx** » 04.03.2014, 13:01 **Neues OnPage Analysierungstool**

die idee mit dem hinweisen hatte ich gestern schon ... werde ich wohl auch umsetzen. im moment bin ich an der DocType Verarbeitung (ob HTML 5 oder 4 und wenn HTML 5 dann die Tags auslesen etc etc)

Kristian · **Kristian** » 04.03.2014, 13:51 **Neues OnPage Analysierungstool**

SloMo hat geschrieben:Du kannst schwer alle Dummheiten ausbügeln, aber Du kannst auf Probleme im Encoding hinweisen. Ist ja auch ein gravierender Onpage-Fehler.

Zumindest hier sind wir mal einer Meinung.
Wenn man einen Crawler auf das Netz los lässt kann man nie vorhersehen, welchen "Müll" man bekommt.
Die Software dafür ist noch nicht geschrieben, ich versuche es seit Jahren.
Try and Error sind zeitweise der Normalfall.
Mich freut immer, wenn ich die jeweiligen Problemchen (Horror-Seiten) googele und die Tante auch den Error hat. Das baut dann wieder auf.

Kristian · **Kristian** » 04.03.2014, 13:58 **Neues OnPage Analysierungstool**

SloMo hat geschrieben:
Kristian hat geschrieben:Ansonsten, ich bleibe dabei, wenn du UTF-8 willst musst du eine Sprache nehmen, die es kann. PHP wird es vor 6.0 nicht können.
Nö sorry Kristian, das ist Unfug. Natürlich muss man als Programmierer seine Datentypen im Blick haben. Wer auf UTF-8-Strings mit alten PHP-Funktionen wie strlen() etc. einprügelt, ist halt selbst schuld. Man kann es auch richtig machen und die Multibyte-Extenstion nutzen. Die ist auch bei jedem ordentlichen Hosting an Bord.

Hier sind wir nicht einer Meinung.
Zeige mir die Quelle, in der steht, PHP könne intern oder "egal wie", den kompletten Unicode-Zeichensatz verarbeiten.
Es sollten für eine Demo japanische, chinesische, bulgarische und deutsche Texte in einer Seite stehen, diese sollte man - on the fly- sortieren können.

SloMo · **SloMo** » 04.03.2014, 16:50 **Neues OnPage Analysierungstool**

PHP kann intern alles verarbeiten. Strings sind in PHP grundsätzlich nur Bytefolgen. Du kannst in einer PHP-Variablen alles ablegen.

Die Multibyte-Extension kann folgende Encodings verarbeiten:

https://www.php.net/manual/en/mbstring. ... odings.php

Darunter UTF-7/8/16/32 und eine Menge lokaler 8-Bit-Codepages. Mit UTF-8 kannst Du japanische, chinesische, bulgarische und deutsche Texte abbilden. Unicode ist generell völlig sprachagnostisch.

Ich vermute, Ihr hattet ein anderes Problem, z.B. keine Multibyte-Strings genutzt, Dokumente in exotischen (nicht unterstützten) Codepages erhalten und kaputtkonvertiert, oder einfach nur auf einen Font hereingefallen, der nicht alle Zeichen enthalten hat (dann siehst Du nur Kästchen oder Fragezeichen, jemand mit dem richtigen Font sieht es aber korrekt).

Kristian · **Kristian** » 04.03.2014, 17:37 **Neues OnPage Analysierungstool**

SloMo hat geschrieben:PHP kann intern alles verarbeiten. Strings sind in PHP grundsätzlich nur Bytefolgen. Du kannst in einer PHP-Variablen alles ablegen.

Die Multibyte-Extension kann folgende Encodings verarbeiten:

https://www.php.net/manual/en/mbstring. ... odings.php

Darunter UTF-7/8/16/32 und eine Menge lokaler 8-Bit-Codepages. Mit UTF-8 kannst Du japanische, chinesische, bulgarische und deutsche Texte abbilden. Unicode ist generell völlig sprachagnostisch.

Ok. das sieht aus als sollte ich meine Hausaufgaben machen.
Sprich, ich bin in PHP nicht mehr uptodate.

SloMo hat geschrieben: Ich vermute, Ihr hattet ein anderes Problem, z.B. keine Multibyte-Strings genutzt, Dokumente in exotischen (nicht unterstützten) Codepages erhalten und kaputtkonvertiert, oder einfach nur auf einen Font hereingefallen, der nicht alle Zeichen enthalten hat (dann siehst Du nur Kästchen oder Fragezeichen, jemand mit dem richtigen Font sieht es aber korrekt).

Nein, so was macht hier niemand in PHP.
Perl hat seit der Version 5.8 (etwa 5 Jahre her) eine brauchbare interne Umsetzung für Unicode.
Auch wenn die Sprache im Markt gerade im Abwärtstrend ist, für die Lösung der Aufgabe (onPage-Optimierung) ist alles schon da.
Mit dem Font hast du aber Recht, da bin ich die Tage dumm aufgelaufen, mein Lieblings-Rechner hat Debian und da sind "non-free" Dinge nicht verfügbar, das gilt teilweise auch für Schriften
Bei exotischen Dokumenten hast du auch Recht, ich habe schon Dinge gesehen, da gibt der Server sein eingestelltes Encoding aus, in der Seite finden sich dann 2 "http-equiv" mit jeweils anderen Encodings, da kommt die Tante aber auch nicht mit, daher ist es nicht so tragisch bzw. kein Ding, das einen sorgen müsste.