LinkVerify -
Details -
(English)
An dieser Stelle wird die Funktion von LinkVerify im Detail beschrieben. Es gibt auch eine kurze Bedienungsanleitung.
Die Parameter braucht man normalerweise nur, wenn LinkVerify in einem Skript aufgerufen werden soll, oder man nur eine Textkonsole zur Verfügung hat.
java | wiebicke.htmltools.LinkVerify [-x] [-c] [url] | |
url | Die zu prüfende root url. | |
-x | Externe Verweise nicht prüfen. | |
-c | Schaltet in den Konsolenmodus. Im Konsolenmodus öffnet sich kein Fenster. Der Prüfprozeß startet sofort, und die Ergebnisse werden auf die Standardausgabe geschrieben. Im Konsolenmodus muß eine URL angegeben werden, ansonsten wird diese Option ignoriert. | |
Folgende Html-Attribute werden bei der Analyse von Html-Dateien berücksichtigt:
| Tag | Attribut | Bedeutung |
|---|---|---|
A | HREF | Ein normaler Hyperlink. |
BASE | Die dokumentenweite Basis für relative URL's. Wenn dieses Tag angegeben wird, beziehen sich alle relativen URL's im Dokument auf diese URL, und nicht mehr auf die URL des Dokuments selbst. Achtung: Einfacherhalber gilt hier die neue Basis-URL erst ab dem Erscheinen im Dokument. Als work-around sollte das <BASE>-Tag vor allen anderen Tags stehen, die eine URL beinhalten. (siehe auch selfhtml) | |
LINK | Ein Standardverweis in einer Dokumentenstruktur - oder ein Style Sheet. | |
AREA | Eine anklickbare Karte mit Hyperlinks. | |
APPLET | ARCHIVE | Die JAR files mit den Klassen des Applets. Mehrere Dateien werden durch Kommas getrennt. |
SRC | Eine Supportadresse/ein Quelltext zu einem Applet - je nach dem, in welche Doku man guckt. | |
FRAME | Die Startdateien in einem Frameset. | |
IFRAME | Der Inhalt eines Floating Frames. | |
EMBED | Die Quelle eines ala Netscape eingebetteten Objekts. | |
SOUND | Eine .wav oder .au-Datei ... | |
BGSOUND | .. auch als Hintergrundmusik. | |
INPUT | Das Bild eines <INPUT>-Buttons. | |
SCRIPT | Das externe Quellfile für ein Script. | |
IMG | Ein Bitmops .. | |
LOWSRC | .. und dessen weniger großes Arme-Leute-File, | |
USEMAP | .. mit einer Client-seitigen Map, | |
DYNSRC | .. oder einem AVI-Filmchen | |
VRML | .. oder einer VRML-3D-Welt. | |
BODY | BACKGROUND | Die Hintergrundtapete eines ganzen Dokuments ... |
TABLE | .. oder einer Tabelle .. | |
TH | .. oder eines Tabellenkopf- .. | |
TD | .. bzw. Datenelements. | |
LAYER | SRC + | Der Inhalt eines Layers .. |
ILAYER | .. bzw Inline-Layers. (beides nur Netscape) | |
INS | CITE | Bezugs-URL für eingefügten .. |
DEL | .. bzw. gelöschten Text, .. | |
Q | .. oder ein Zitat .. | |
ACRONYM | .. oder eine Abkürzung. | |
FORM | ACTION | Die Submit-Adresse eines Formulars .. |
ISINDEX | .. bzw eines durchsuchbaren Index. |
LinkVerify ist ebenfalls in der Lage, URLs zu überprüfen, die über Formatvorlagen (Stylesheets) eingebunden werden.
Eine Formatvorlage kann mit dem <LINK>-Tag eingebunden werden, oder mit dem Tag <STYLE> direkt in der Html-Kopf definiert werden. Beide Möglichkeiten werden unterstützt. Das Definieren von Formatieranweisungen innerhalb des STYLE-Attributs wird (noch) nicht unterstützt.
In einer Formatvorlage wird alles, was innerhalb von "url(" und ")" steht, wird als URL betrachtet. Das sind normalerweise die Hintergrundbilder oder externe (mit @import eingebundene) Formatvorlagen.
Im Fenster Frames wird ein Abgleich zwischen definierten und referenzierten benannten Frames durchgeführt. Eine Framedefinition ist nur mit dem Tag <FRAME NAME="name"> möglich. Referenziert werden Frames mit dem Attribut TARGET in den Tags <A>, <BASE>, <AREA> und <FORM>.
Dieser Test ist keine strukturelle Analyse. Es wird lediglich geprüft, ob jeder verwendete Frame-Name auch irgendwo innerhalb der analysierten Dateien definiert wird. Es können also Probleme übersehen, aber auch erfunden werden. Dieses Feature kann vor allem Tippfehler erkennen.
Wenn ein nicht definierter Frame referenziert wird, generiert der Browser ein neues Fenster ala _blank. Dieses Fenster erhält als Titel den nicht definierten Framenamen. Ein solchen Verhalten kann durchaus auch so gewollt sein.
Wer die innere Verweisstruktur einer Site prüfen will, wird das i.A. erstmal lokal versuchen. Leider gibt es da einen kleinen aber feinen Unterschied. Wenn bei HTTP ein Verzeichnis referenziert wird, sucht der Server in diesem Verzeichnis nach ausgezeichneten Dateinamen, i.A. index.html. Nur wenn diese Datei nicht existiert, bekommt man (Rechte vorrausgesetzt) das Verzeichnis aufgelistet. Wenn man das Protokoll file: benutzt, bekommt man auf jeden Fall das Verzeichnis. Deshalb kann ein lokaler Prüflauf mehr Dateien prüfen, als einer über den HTTP-Server.
Bei meinen Versuchen habe ich hin und wieder tote Links gefunden mit dem Fehlertext "Method not allowed" oder "Method HEAD disabled on this server". Der zugehörige HTTP-Response-Code ist 405, manchmal aber auch 403.
Der Grund dafür ist, daß manche Server keine HEAD-Requests zulassen. Mit einem solchen HEAD-Request kann ein HTTP-Client ermitteln, ob eine bestimmte URL auf dem Server existiert oder nicht, ohne diese URL selbst zu laden. HEAD-Requests werden vorzugsweise von Webspidern benutzt, also z.B. Suchmaschinen und eben auch von LinkVerify. Offensichtlich wollen diese Server keinen Besuch von Webspidern.
Einen vernünftigen Grund dafür kann ich mir nicht vorstellen. Trotzdem wird es keine Workarounds geben, etwa indem man nach jedem abgewiesenen HEAD request einen GET request durchführt. Wenn Du sowas brauchst, implementiere es Dir selber.
Interne Anker ermöglichen es, eine Position innerhalb einer HTML-Datei mit einer URL zu referenzieren. Ein solcher Anker wird definiert mit dem Tag <A NAME="ref">. Referenziert wird der Anker mit <A HREF="datei#ref">.
LinkVerify überprüft bei Verweisen auf interne Anker einer Html-Datei, ob dieser Anker in der Datei auch definiert wurde. Das funktioniert aber nur bei nicht externen Links, d.h. wenn sich die Zieldatei im gleichen Verzeichnis oder einem der Unterverzeichnisse der root url befindet.
Die Quellen sind in den Downloadpaketen enthalten.
Erstellt von Ralf Wiebicke, letzte Änderung am 20. Dezember 1998