In HTML-Seiten kann man kleine Programme einbetten, die in Javascript (von Netscape eingeführt) bzw. dem dazu halbwegs kompatiblen JScript (Microsoft) geschrieben sind. Eine weitere Alternative ist das allerdings nur von Microsoft-Browsern unterstützte VBScript, das an Visual Basic angelehnt ist.
Man kann solche Programme so in HTML einbetten, daß der Browser (der Client) das eingebettete Programm interpretiert und beispielsweise dynamisch neue Fenster öffnet oder Eingaben überprüft. Alternativ kann auch der Web-Server selbst Programmstücke in HTML-Seiten interpretieren. Bei Microsoft nennt man solche Seiten ASP (Active Server Pages). Ferner wird auf Web-Servern oft die Script-Sprache Perl eingesetzt, beispielsweise zur Verarbeitung von Formular-Eingaben oder, wie bei ASP oder PHP, zur Generierung dynamischer Seiteninhalte. Server-Side Includes (SSI) sind eine weitere einfache Möglichkeit zur dynamischen Seitengestaltung.
Die Themen dieses Abschnitts: | Javascript VBScript HTA-Dateien Perl und CGI |
Server-Side Includes PHP Cookies Sicherheitslücken |
Javascript ist die derzeit am häufigsten eingesetzte client-seitige Programmiersprache. Das folgende Beispiel ist in dieser Sprache geschrieben und erzeugt beim Anklicken von diesem Link einfach ein kleines Fenster mit dem Text "Hallo Welt!".
<html><head><title>Test</title> </head><body> |
Der übliche Beginn einer HTML-Datei. |
<script language="JavaScript"><!-- function fenster() { alert("Hallo Welt!"); } // --><script> |
Eine kleine Javascipt- Funktion, die eine Message- Box mit OK-Knopf öffnet. |
<noscript><p> Sie haben Javascipt ausgeschaltet! </p></noscript> |
Dieser Text wird angezeigt, wenn der Benutzer Java- script deaktiviert hat. |
<p><a href="javascript:fenster()"> Bitte hier klicken!</a><p> |
Ein Text als Link, der die Fenster-Funktion aufruft. |
</body></html> | Das übliche HTML-Ende. |
Das kleine Javascript-Programm ist für ältere Browser, die noch keine Script-Sprachen verstehen, in Kommentar-Anweisungen zwischen <!-- und --> eingebaut, so daß sie keinen Unsinn anzeigen. Da sie auch die Anweisung <noscript> nicht verstehen, wird von Ihnen der zwischen <noscript> und </noscript> stehende Text angezeigt. Dasselbe passiert, wenn man in einem modernen Browser Javascript abschaltet.
Die zwei Schrägstriche (//) am Beginn der ersten Zeile nach dem Javascript-Code sorgen dafür, daß diese Zeile vom Script-Interpreter als Javascript-Kommentar aufgefaßt wird, so daß er nicht auf die Idee kommt, das darauffolgende HTML-Tag "-->", das den HTML-Kommentar beendet, zu interpretieren, was zu einer Fehlermeldung führen würde.
Der Code wird in der HTML-Datei genau an der Stelle ausgeführt, an der er steht, und natürlich auch zu dem Zeitpunkt, zu dem der entsprechende Teil der HTML-Datei geladen wird. Deshalb muß ein Javascript-Programm, das auf weiter hinten stehende HTML-Elemente der Seite bezug nimmt, etwa auf Anker (lokale Link-Ziele innerhalb der Datei) oder Formular-Felder, entweder am Ende der Datei stehen oder als Funktion mit <body onload="funktion( )"> im body-Tag der HTML-Seite erst dann aufgerufen werden, wenn die Seite vollständig geladen ist.
Es kann beliebig viele Javascript-Abschnitte in einer HTML-Datei geben. Man kann auch mitten in der Seite einen per Javascript generierten Text einfügen, z.B. so:
<p><script language="Javascript"><!-- document.write("Letzte Änderung: ",document.lastModified); // --></script></p> |
Eine nützliche Anwendung von Javascript ist auch das automatische Nachladen von Frames, wenn ein Benutzer z.B. von einer Suchmaschine kommend nur eine einzelne Datei des Framesets aufruft und ihm dadurch die im Frameset vorhandenen Navigations-Möglichkeiten zunächst fehlen. In jeder Teildatei braucht dazu nur folgendes enthalten zu sein, wobei frame.htm in diesem Beispiel die Frameset-Definition enthält:
<script language="JavaScript"><!-- if (parent.frames.length<1) location.replace("frame.htm"); // --></script> |
Der Javascript-Code braucht nicht unbedingt in der HTML-Datei selbst enthalten zu sein.
Es ist auch möglich, ihn in einer getrennten Datei zu speichern,
typischerweise mit der Endung .js, und in den HTML-Code folgende Zeile einzubauen
(file1.js ist hier natürlich nur ein Beispielname):
<script language="JavaScript" src="file1.js" type="text/javascript"></script>
Javascript-Programme sind case-sensitiv, d.h. die Befehle müssen exakt
mit Klein- und Großbuchstaben geschrieben werden (z.B. indexOf, charAt und so weiter).
Javascript ist eine objektorientierte Sprache; Objekte wie Fenster oder
Frames haben "Eigenschaften", die bestimmte Eigenschaften des Objekts beschreiben oder
verändern können, und es gibt "Methoden", die irgend etwas mit den Objekten tun. So kann
man etwa mit der Anweisung
window.location.href="www.telekom.de/";
den Browser veranlassen, die Eigenschaft href (die Adresse) des Objekts
location auf die Telekom-Homepage zu setzen und somit zu ihr zu springen.
location ist seinerseits ein Objekt, das in der Hierarchie unterhalb des window-Objekts
liegt, also zum jeweils offenen Browser-Fenster gehört.
Javascript benutzt Variant-Variablen, das bedeutet, eine Variable hat keinen bestimmten Typ, sondern kann entweder eine Zahl oder eine Zeichenfolge aufnehmen. Variablen brauchen vor der Verwendung nicht deklariert werden, wenngleich das mit der Anweisung var durchaus möglich ist und der Übersichtlichkeit dient. Anweisungen müssen, wenn in derselben Zeile weitere folgen, mit einem Semicolon enden; man kann sich das aber auch zur generellen Gewohnheit machen.
Wie auch zu HTML gibt es im Web und in Buchform eine ganze Reihe von Abhandlungen zu Javascript bzw. JScript, nicht zuletzt natürlich von Netscape und Microsoft, so daß an dieser Stelle auf eine ausführliche Sprach-Referenz verzichtet wird.
Java hat trotz des ähnlichen Namens wenig mit Javascript gemein. Diese Sprache, die in Applets (Code, der im Browser ausgeführt wird) und Servlets benutzt wird (Code, der auf dem Server ausgeführt wird), wird nicht wie Javascript zur Laufzeit als Quelltext interpretiert, sondern während der Entwicklung in in einen effizienten Zwischencode (Byte-Code) vorcompiliert, der wesentlich schneller ausgeführt werden kann. Dafür benötigt man allerdings eine eigene Entwicklungsumgebung, weshalb Java trotz seiner Bedeutung an dieser Stelle nur am Rande erwähnt wird.
Durch Verbinden von Javascript und Java - Netscape nennt das Liveconnect - kann man Dinge tun, die von manchen gutgläubigen Menschen für unmöglich gehalten werden, so etwa das Ermitteln der E-Mail-Adresse. Ein Beispiel, das so allerdings nur mit Netscape-Browsern funktioniert:
<html><body><script language="JavaScript"><!-- function readPref(prefName) { privName = "UniversalPreferencesRead"; netscape.security.PrivilegeManager.enablePrivilege(privName); alert("Mail-Adresse: " + navigator.preference(prefName)); } //--></script><p> <a href="javascript:readPref('mail.identity.useremail')">Test</a> </p></body></html> |
Wenn man diesen Code als HTML-Datei speichert, sie in den Netscape-Browser lädt und auf den enthaltenen Link "Test" klickt, wird nach einer (abschaltbaren) Sicherheitsabfrage die E-Mail-Adresse des Benutzers in einem Message-Fenster angezeigt.
Das Programm funktioniert nur als lokale Datei. Versucht man, es mit einer http-Adresse von einem Web-Server auszuführen, bricht der Browser die Ausführung sofort ab. Es gibt allerdings bei einigen Browser-Versionen Methoden, die diese Sperre aushebeln.
VBScript ist eine von Visual Basic abgeleitete Programmiersprache, die bisher nur vom Microsoft Internet Explorer interpretiert wird. Aus diesem Grunde ist es nicht besonders zweckmäßig, Seiten ins Web zu stellen, die auf VBScript basieren und somit einen damit kompatiblen Browser voraussetzen - man würde damit einen erheblichen Teil der Besucher aussperren.
Das Einbetten von VBScript-Programmen in HTML funktioniert genauso wie bei Javascript. Mit dem Button "Test" können Sie das Script ausprobieren, sofern Sie den Microsoft Internet Explorer benutzen:
Ein Unterprogramm ohne Rückgabewert wird in VBScript mit sub eingeleitet und
mit end sub beendet. Statt alert heißt die Anweisung zum Anzeigen eines
Meldungsfensters hier msgbox. Die Zeile unter end sub beginnt mit einem
Apostroph, da dies in Visual Basic das Zeichen für einen Kommentar darstellt und der Rest
der Zeile so vom Interpreter ignoriert wird. Der Button "Test" wurde hier mit folgender
HTML-Anweisung realisiert:
<input type="button" value="Test" onclick="vbfenster()">
Beim Microsoft Internet Explorer ab Version 5 kann man HTML-Dateien mit eingebettenen Javascript- oder VBScript-Programmen von der lokalen Festplatte wie eine normale ausführbare Applikation starten, wenn sie die Endung .HTA (HTML Application) besitzen. Dadurch kann man auf einfache Weise kleine interaktive Anwendungen erstellen, für die jene Sicherheitsbeschränkungen, wie sie für HTML-Dateien im Internet absichtlich existieren, nicht gelten. Solche Applikationen sehen auch nicht wie ein Browser aus, sondern wie eine normale Windows-Anwendung.
<html><head><title>Test-Applikation</title> <HTA:APPLICATION ID="TEST" APPLICATIONNAME="HTA-Beispiel" BORDER="thick" BORDERSTYLE="normal" CAPTION="YES" ICON="shamrock.ico" MAXIMIZEBUTTON="YES" MINIMIZEBUTTON="YES" SHOWINTASKBAR="YES" SINGLEINSTANCE="NO" SYSMENU="YES" VERSION="1.00" WINDOWSTATE="normal"> </head><body onload="setTimeout('check()',5000)"> <script language="JavaScript"><!-- function check() { txt = parent.ifr.document.body.innerHTML; // Seiteninhalt keyw = "Shamrock"; // zu suchendes Wort if (txt.indexOf(keyw)<0) a=" nicht"; else a=""; alert("Die Seite enthält"+a+" das Wort "+keyw); } // --></script> <IFRAME SRC="http://www.domain.de/seite.htm" name="ifr" width=242 height=305 align=left hspace=20 vspace=0></iframe> <p>Testseite</p> </body></html> |
Wenn man diese Zeilen als HTA-Datei speichert und aus Windows startet, lädt sie zunächst als "iframe" (das ist eine Sonderform von Frames, die beim Internet Explorer möglich ist) in ein Fenster innerhalb der Seite und prüft nach fünf Sekunden, ob ein bestimmtes Stichwort im Text dieser Webseite vorkommt. Eine "normale" HTML-Datei dürfte das nicht tun, weil für sie aufgrund von Sicherheits-Beschränkungen der Zugriff auf Inhalte anderer Domains gesperrt ist; für ein HTA-Script gelten diese Einschränkungen dagegen nicht. Das HTA-Beispiel enthält im Header auch einige zusätzliche Angaben, die das Aussehen und Verhalten der Applikation bestimmen.
Die Programmiersprache Perl (Practical Extraction and Report Language) wird im Gegensatz zu Javascript, JScript und VBScript ausschließlich auf dem Web-Server ausgeführt. Die Ausgabe eines Perl-Programms erfolgt entsprechend dem CGI-Standard (Common Gateway Interface) über die Standard-Ausgabe (STDOUT) des jeweiligen Betriebssystems. Sie wird vom Web-Server zum Browser z.B. als HTML-Seite durchgereicht.
Umgekehrt kann ein Perl-Programm Eingaben von einem Formular auf einer Web-Seite mit <form action="get"> über die Environment-Variable QUERY_STRING oder mit <form action="post"> über die Standard-Eingabe (STDIN) übernehmen. Damit das Programm bei STDIN weiß, wo die Daten zu Ende sind, wird die Datenlänge zusätzlich in der Environment-Variablen CONTENT_LENGTH übergeben. Der vom Perl-Programm dadurch erhaltene Übergabe-String enthält jeweils durch "&" getrennt die Namen und Werte der im Formular enthaltenen Elemente, hier "Textfeld" und "Button"; Leerzeichen in übergebenen Strings werden durch "+" ersetzt, Umlaute durch %XX als Hex-Code.
Wenn der Client-Browser ein Perl-Programm auf dem Web-Server aufruft, muß das Perl-Programm eine vollständige HTML-Seite inklusive eines Mindest-HTTP-Headers als Antwort zurückliefern. Der HTTP-Header gibt den Informationstyp an (meist text/html), danach folgen zwei Zeilenumbrüche als Header-Endekennzeichen (\n\n), und schließlich der HTML-Text der Ergebnisseite.
Jedes Perl-Programm beginnt mit einer Zeile wie dieser:
#!/usr/bin/perl
Sie nennt dem Web-Server das Verzeichnis (hier /usr/bin/perl), wo er einen
geeigneten Interpreter für die Perl-Datei finden kann. Im sonstigen Script-Text dient die
Raute # zur Kennzeichnung von Kommentaren.
Ohne auf Details einzugehen, sei hier als Beispiel ein Perl-Programm vorgestellt, das dem Besucher der Seite sagt, welcher Typ von Web-Server hier läuft, über welchen Internet-Provider die Verbindung aufgebaut wurde, welchen Browser-Typ der Client benutzt und ein paar interessante Dinge mehr. Die letzte Anweisung "exit(0)" sagt dem Web-Server, daß das Programm erfolgreich beendet wurde.
#!/usr/bin/perl print "Content-type: text/html\n\n"; print "<html><head><title>Informationen</title></head>"; print "<body bgcolor=\"#FFEEC4\">\n"; print "<h2>Server- und Browser-Informationen</h2>"; print "<h3>Web-Server:</h3><table border=0 cellpadding=1>"; print "<tr><td>Software:</td><td>$ENV{'SERVER_SOFTWARE'}</td></tr>"; print "<tr><td>Domain-Name:</td><td>$ENV{'SERVER_NAME'}</td></tr>"; print "<tr><td>Server-Port:</td><td>$ENV{'SERVER_PORT'}</td></tr>"; print "</table><h3>Ihr Web-Zugang:</h3><table border=0 cellpadding=1>"; print "<tr><td>IP-Adresse:</td><td>$ENV{'REMOTE_ADDR'}</td></tr>"; print "<tr><td>Provider:</td><td>$ENV{'REMOTE_HOST'}</td></tr>"; print "<tr><td>Browser:</td><td>$ENV{'HTTP_USER_AGENT'}</td></tr>"; print "</table><p><a href=\"/\">Zur Startseite</a>"; if ($ENV{'HTTP_REFERER'} ne '') { print" - <a href=\"$ENV{'HTTP_REFERER'}\">Zurück</a>"; } print "</p></body></html>"; exit (0); |
Perl-Programme werden auf dem Web-Server meist in einem Unterverzeichnis
/cgi-bin gespeichert. (Alle Dateiangaben und Seiten-Referenzen im Script müssen
entweder relativ zu diesem Verzeichnis oder absolut mit vorangestelltem Schrägstrich
erfolgen!) Nach dem Übertragen des Programms, nennen wir es environ.pl, muß man bei einem
unter Unix oder Linux laufenden Web-Server meist noch dafür sorgen, daß die Datei das
Attribut "ausführbar" enthält. Dies erreicht man durch folgende
Unix-Anweisung:
chmod +x environ.pl
Falls Ihr FTP-Programm numerische Werte für die Dateiattribute zuläßt, geht es
gewöhnlich so:
chmod 755 environ.pl
In FTP-Programmen mit ankreuzbaren Datei-Attributen muß die Einstellung so lauten:
chmod | Owner | Group | Other |
Read | x | x | x |
Write | x | ||
Execute | x | x | x |
Eine mögliche Falle ist noch, daß die Perl-Datei auf Unix-Rechnern nur Line Feeds als Zeilentrennung enthalten darf. Wenn Sie das Perl-Programm auf einem Windows-Rechner erstellt haben, der CR+LF zwischen den Zeilen benutzt, achten Sie darauf, beim FTP-Programm den ASCII-Modus zu benutzen, der die CR-Steuerzeichen entfernt.
Perl-Programme müssen nicht notwendigerweise Textausgaben zurückliefern. Das folgende Beispiel-Script, nennen wir es showgif.pl, liefert beim Aufruf aus einer HTML-Seite mit <img src="cgi-bin/showgif.pl"> die Bilddatei bild.gif zurück:
#!/usr/bin/perl print "Content-Type: image/gif\n\n"; # HTTP-Header+Leerzeile open IN, "/pic/bild.gif" || die; # Pfad relativ zu /cgi-bin! while( <IN> ) { print; } # Gibt den Inhalt der Bilddatei aus close IN; exit (0); |
Während die obigen Beispielprogramme noch halbwegs verständlich sind, sei nicht verschwiegen, daß man zahlreichen Perl-Konstrukten kaum ansieht, was sie eigentlich tun, und das Programmieren in Perl ist sicher eine der anspruchsvolleren Aufgaben für einen Web-Designer.
Eine ganz einfache Methode, auf dem Web-Server Informationen dynamisch in eine HTML-Seite einzufügen, sind Server-Side Includes. Solche HTML-Dateien müssen bestimmte Datei-Endungen haben (typisch .shtml oder .sht), damit der Server weiß, daß er bestimmte Schlüsselworte darin als Anweisungen interpretieren darf. Diese sind im Text als HTML-Kommentare eingebunden, so daß sie nur vom Server beachtet und vom Browser ignoriert werden. Ein paar Beispiele:
SSI-Zeile in der HTML-Datei | Wirkung |
<!--#config errmsg="Syntaxfehler"--> | SSI-Fehlermeldung festlegen |
<!--#config timefmt="%d.%m.%Y %H:%M"--> | Zeitausgabeformat festlegen |
<!--#config sizefmt="bytes"--> | Dateilängen in Bytes azeigen |
<!--#config sizefmt="abbrev"--> | Dateilängen in KByte anzeigen |
<!--#fsize file="test.zip"--> | Anzeige der Länge einer Datei |
<!--#echo var="DATE_LOCAL"--> | Ausgabe der lokalen Zeit |
<!--#echo var="DATE_GMT"--> | Ausgabe der Weltzeit (GMT) |
<!--#echo var="LAST_MODIFIED"--> | Änderungsdatum der akt. Datei |
<!--#flastmod file="index.htm"--> | Änderungsdatum einer and.Datei |
<!--#include virtual="teil2.htm"--> | Fügt den Inhalt einer Datei ein |
<!--#exec cmd="bin/search.exe *.htm"--> | Startet eine ausführbare Datei |
<!--#exec cgi="/cgi-bin/environ.pl"--> | Führt ein CGI-Programm aus |
<!--#printenv --> |
Environment-Variablen anzeigen |
<!--#set var="x" value="abc" --> |
Setzt einen Variablen-Wert |
Zusätzlich gibt es auch noch die Möglichkeit von Bedingungen nach dem Schema if, elif (else-if) und else:
<!--#if x="wert1" -->Bedingung 1 ist erfüllt <!--#elif x="wert2" -->Bedingung 2 ist erfüllt <!--#else -->Keine der obigen Bedingungen trifft zu <!--#endif --> |
Die Ausgabe des vom SSI-Element erzeugten Textes erfolgt genau an der Stelle der HTML-Datei, an der das Element steht. Allerdings sind Server-Side Includes aus Sicherheitsgründen nicht auf allen Web-Servern freigeschaltet. Darüber hinaus unterscheiden sich die zur Verfügung stehenden SSI-Anweisungen je nach Server-Software erheblich. Die obige Liste gilt deshalb ausschließlich für Apache-Server ab Version 1.2. Andere Server benutzen zum Teil eine andere Syntax.
Ähnlich wie Perl wird die Script-Sprache PHP auf dem Web-Server ausgeführt, und ähnlich wie bei SSI wird der PHP-Code in HTML eingebettet. Der Server erkennt PHP-Seiten an ihrer Dateiendung (je nach Version z.B. .php3 oder .php4). Im HTML-Code beginnen PHP-Anweisungen mit <? oder <?php und enden mit ?>. Der Server sendet die PHP-Abschnitte nicht an den Browser des Benutzers, sondern interpretiert sie. Beispiel für einen Abschnitt einer Web-Seite, die die Browser-Version des Benutzers anzeigt:
Ihr Browser: <?php echo $HTTP_USER_AGENT; ?>
Die folgende Sequenz gibt einen passenden Text aus, wenn der Benutzer einen Internet Explorer von Microsoft verwendet:
<?php
if (strstr($HTTP_USER_AGENT,"MSIE"))
{ echo "Sie benutzen den Internet Explorer.<br>"; }
?>
Da PHP einen wesentlich größeren Befehlsumfang als SSI besitzt, ist seine Leistungsfähigkeit mit Perl vergleichbar, besitzt aber den Vorteil, daß es wie SSI direkt in HTML-Seiten integriert werden kann. Eine besondere Stärke ist auch die Möglichkeit von Datenbank-Zugriffen (SQL).
Was haben Cookies mit Script-Sprachen zu tun? Nun, man benutzt gewöhnlich Scripts, um Cookies zu schreiben oder zu lesen, deshalb werden sie im Abschnitt über Script-Sprachen erwähnt.
Was ist ein Cookie? Eine Textzeile einer Datei im Browser-Verzeichnis Ihres Computers, die HTTP- oder script-gesteuert erzeugt und gelesen werden kann und einer bestimmten Web-Adresse zugeordnet ist. Darin kann sich ein Web-Server irgendwelche Dinge merken, bis man ihn irgendwann erneut besucht. Zum Beispiel kann der Server Ihre auf einer Mitteilungs-Seite einmal eingegebene Mail-Adresse in einem Cookie auf Ihrem PC speichern, damit das entsprechende Feld beim nächsten Besuch derselben Seite automatisch passend ausgefüllt wird.
Manche Web-Server benutzen Cookies auch, um die Zahl unterschiedlicher Besucher festzustellen. Dazu wird beim ersten Besuch der Seite einfach ein Cookie gespeichert, sein Name ist meist WEBTRENDS_ID. Ein neuer Besucher ist dann einfach einer, bei dem dieses Cookie noch fehlt. Dadurch kann man die "echte" Besucherzahl besser von der Zahl der Seitenabrufe unterscheiden. (Da viele Anwender Cookies im Browser allerdings deaktiviert haben, ist der Mechanismus etwas fragwürdig.)
Cookies sind im Prinzip ungefährlich, in der Größe auf 4 KByte begrenzt und können keinen ausführbaren Code, sondern nur einfache Wert-Zuweisungen enthalten, zum Beispiel "Vorname=Albert" oder "Mail=abc@xyz.de". Es ist einem Web-Server normalerweise nicht möglich, Cookies auszulesen, die von einem Server mit einem anderen Domain-Namen erzeugt wurden. Bedenken sollte man allerdings, daß viele Server Werbe-Grafiken von einer anderen Domain laden, die dann ebenfalls Cookies speichern kann, wenn die Grafik mit einem CGI-Script realisiert wird.
Wenn ein Web-Server den Browser veranlassen will, ein Cookie zu speichern, liefert er
im HTTP-Header zusätzlich eine Zeile "Set Cookie":
Set-Cookie: Name=Wert; path=/; expires=Mon, 09-Dec-2002 13:46:00 GMT
"Name" steht dabei für den Namen des Cookies, "Wert" für einen numerischen oder alphanumerischen Wert, "path" gibt an, welche Seiten (hier alle derselben Domain) später auf das Cookie zugreifen dürfen, und "expires" sagt dem Browser, wann er das Cookie wieder löschen darf. Wenn expires=... fehlt, wird das Cookie nur bis zum Beenden des Browsers gespeichert.
Wenn der Browser später den Inhalt eines Cookies zum Server schickt, sendet er
ebenfalls einen HTTP-Header, in dem ebenfalls zusätzlich der Cookie-Name und sein Wert
stehen:
Cookie: Name=Wert
In Perl kann man Cookies ganz leicht erzeugen, da ein Perl-CGI-Programm auf dem Server den HTTP-Header selbst generiert; somit kann man auch "Set-Cookie: ..." hineinschreiben. Das Lesen von Cookies erfolgt in Perl über die Environment-Variable $ENV{'HTTP_COOKIE'}, sie liefert das Ergebnis wieder in der Form Name=Wert.
In Javascript oder VBScript kann ein
Cookie ganz einfach mit Hilfe von document.cookie gelesen oder geschrieben
werden. Die Anweisung zum Schreiben kann zum Beispiel so aussehen:
document.cookie="Name=Wert; path=/; expires=Mon, 01-Jan-2001 00:00:00 GMT"
Ob ein Cookie zur eigenen Domain bzw. Seite existiert, kann man einfach mit if
(document.cookie) abfragen. Das Lesen erfolgt wieder durch Auslesen des Werts von
document.cookie, wobei man eine Zeichenfolge der Form Name=Wert erhält. Wenn Cookies
im Browser deaktiviert sind, führen diese Anweisungen nicht zu einer Fehlermeldung,
sondern werden einfach ignoriert. Falls dieselbe Domain mehrere Cookies erzeugt hat,
werden sie in der Form
Name1=Wert1; Name2=Wert2; Name3=Wert3
gemeinsam zurückgeliefert, zum Beispiel:
Vorname=Albert; Nachname=Einstein; Mail=albert@einstein.de
Um ein Cookie scriptgesteuert zu löschen, kann man entweder seinen Wert auf einen Leerstring setzen oder das Verfalldatum auf einen Wert in der Vergangenheit ändern. Um dagegen alle Cookies des Browsers manuell zu löschen, muß man bei Netscape die Datei Cookies.txt löschen und beim Microsoft Internet Explorer alle Dateien im Windows-Unterverzeichnis Cookies entfernen, nachdem man den Browser beendet hat.
Konzeptionell weisen Script-Sprachen und Cookies eine hohe Sicherheit gegen das Ausspionieren persönlicher Daten und sonstige Angriffe auf den eigenen Rechner auf. So sind etwa Zugriffe auf lokale Dateien mit Javascript nur möglich, wenn die HTML-Datei, die das Script enthält, selbst als lokale Datei vorliegt. Es haben sich allerdings immer wieder Fehler in marktüblichen Browsern herausgestellt, die gewieften Hackern ein Umgehen dieser Sicherheits-Barrieren ermöglichen. Ein paar Beispiele:
Der einzig sinnvolle Ausweg ist im Prinzip, Javascript (bzw. Active Scripting bei Microsoft), Java und Cookies nur bei vertrauenswürdigen Domains zuzulassen und ansonsten generell zu deaktivieren. Allerdings verlassen sich inzwischen viele Webseiten bei der Navigation auf Scripts oder benutzen Cookies, um sich Benutzer-Einstellungen oder Zugangscodes zu merken. Also: Wenn Sie mutig genug sind, von einer Webseite irgend eine Demo-Software oder Freeware herunterzuladen, die ja wesentlich mehr Schaden auf Ihrem PC anrichten könnte, wäre es widersinnig, bei derselben Seite Javascript zu deaktivieren.
Mobile Geräte, insbesondere GSM-Handys, benutzen meist ein spezielles Verfahren zum Internet-Zugang, das an ihre begrenzten Speicher- und Prozessor-Möglichkeiten angepaßt ist, das "Wireless Application Protocol" (WAP).
Für die an das kleine Handy-Display angepaßten Internet-Seiten wurde die "Wireless Markup Language" (WML) erfunden. In den Gateway-Rechnern der GSM-Netzbetreiber werden WML-Seiten aus dem Internet vor dem Senden ans Endgerät komprimiert; dabei werden die WML-Tags wie etwa <p> oder <br/> jeweils in einen 1-Byte-Code übersetzt, um Übertragungszeit zu sparen. Damit ein Web-Server überhaupt WML-Dateien korrekt an ein WAP-Gateway liefern kann, muß er für die Dateiendung .wml als MIME-Typ im HTTP-Header "text/vnd.wap.wml" liefern.
WML-Dateien sind nicht wie übliche HTML-Seiten aufgebaut, sondern als Decks und Cards organisiert. Ein "Deck" ist einfach eine WML-Datei und kann ihrerseits mehrere "Cards" enthalten, die jeweils einen Bildschirm umfassen. Jede WML-Datei beginnt typischerweise mit folgenden Header-Zeilen:
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> |
Die erste Zeile ist eine XML-Anweisung (eXtended Markup Language), da XML sozusagen die Übermenge von WML darstellt. Die zweite definiert den sogenannten XML-Namespace für WML; damit wird festgelegt, wo die Definition der WML-Schlüsselworte zu finden ist. <wml> schließlich kennzeichnet den Beginn des WML-Decks und somit der Nutzdaten.
Im Gegensatz zu HTML ist es bei XML und WML nicht egal, ob die Formatierungs-Anweisungen (tags) in Groß- oder Kleinbuchstaben eingegeben werden - sie müssen kleingeschrieben sein. Ebenso ist das symmetrische Benutzen von Anweisungen wie etwa <p> und </p> im Gegensatz zu HTML zwingend erforderlich. Singuläre HTML-Anweisungen wie etwa <br>, zu denen es kein </br> gibt, werden in WML mit nachgestelltem Schrägstrich geschrieben, in diesem Fall also <br/>. (Mehr über WML finden Sie auf den SelfWML-Seiten von Roland Ortner.)
Das folgende Beispiel zeigt den typischen Aufbau eines WML-Decks, bestehend aus drei Cards. Die erste Card stellt ein kleines Menü dar, mit dem man zu den übrigen zwei Cards verzweigen kann. Damit man aus diesen zwei Cards einfach wieder zum Menü zurückgelangt, wurde ein "Template" defniert, das auf jeder Card des Decks erscheint und einen "Zurück"-Button enthält.
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <template><do type="prev" label="Zurück"><prev/></do></template> <card id="C0" newcontext="true" title="Menü"><p> <card id="C1" title="Card 1"><p>Text für Card 1</p></card> <card id="C2" title="Card 2"><p>Text für Card 2</p></card> </wml> |
Ebenso, wie WML der HTML-Syntax ähnelt, steht mit WML-Script auch eine Javascript-ähnliche Sprache zur Verfügung, die allerdings nicht in die Seite (Deck) selbst, sondern als getrennte, vorcompilierte Bytecode-Datei eingebunden wird.
Die WAP-Technologie befindet sich derzeit noch in den Anfängen. Trotz fortgeschrittener Standardisierung des Protokolls und der Seitenbeschreibungs-Sprache gibt es je nach Geräte-Hersteller erhebliche Unterschiede in der Größe der Anzeige und in den Darstellungs-Möglichkeiten. Die folgende Tabelle nennt die Eigenschaften von drei typischen WAP-Geräten inklusive der nutzbaren Bildschirm-Pixelzahl (Breite mal Höhe) und der maximalen Größe einer komprimiert übertragenen WML-Datei, also eines Decks. Die ursprüngliche, unkomprimierte WML-Datei kann naturgemäß etwas größer sein als die Angabe in der Tabelle:
WAP-Gerätetyp | Pixel BxH | Zeichen x Zeilen | Deck max. |
Nokia 7110 Ericsson R320 Ericsson R380 Siemens S35 |
95 x 45 101 x 52 304 x 98 101 x 80 |
19 x 4 14 x 5 32 x 7 14 x 6 |
1397 Byte 3000 Byte 3800 Byte 1580 Byte |
WAP hat sich bisher nicht auf breiter Front durchsetzen können. Ein Hauptgrund für die Entwicklung des WAP-Standards war die geringe Bandbreite bei der GSM-Übertragung. Einerseits kann man aber auf den winzigen Handy-Displays ohnehin keine umfangreichen Informationen darstellen, andererseits spielt dieser Faktor bei GPRS und bei UMTS-Netzen kaum noch eine Rolle. Etwas größere Geräte wie Palm-Computer oder Pocket-PCs besitzen dagegen oft schon einen "richtigen" Browser, der normale HTML-Seiten anzeigen kann und nicht auf WAP-Gateways angewiesen ist.
Als Konsequenz daraus hat das WAP-Forum im Jahr 2001 eine Spezifikation für WAP 2.0 vorgestellt, die auch die Standard-Internet-Protokolle TCP/IP und HTTP unterstützt. Ferner beinhaltet es den GPRS-basierenden Multimedia Messaging Service MMS, der neben reinen Textnachrichten auch Bilder (JPG- und GIF-Format), Töne (z.B. AMR = Adaptive Multi-Rate encoding) und Video-Sequenzen übertragen kann und von den meisten Netzbetreibern Mitte 2002 eingeführt wurde. E-Mail- und Web-Gateways erlauben den MMS-Austausch auch Benutzern, die selbst kein MMS-fähiges Gerät besitzen.
<smil> <body> <par dur="10000ms"> <text src="begleit.txt"></text> <audio src="sample.rm"></audio> <img src="sample.jpg"></img> </par> </body> </smil> |
Als MMS-Darstellungs-Sprache hat sich das HTML-ähnliche SMIL etabliert (Synchronized Multimedia Integration Language). Das Beispiel links zeigt 10 Sekunden lang eine MMS-Nachricht an, die mit SMIL aus einem Text, einer Audio-Sequenz und einem Bild zusammengesetzt wird. |
Wer über eine eigene Domain verfügt und Subdomains einrichten kann, sollte das WAP-Angebot unter der Subdomain "wap." abelegen, also zum Beispiel "wap.irgendwer.de", und dort eine Seite "index.wml" als Startseite festlegen. Ein Problem dabei ist, daß herkömmliche HTML-Browser mit den WAP-Daten nichts anfangen können und diese statt dessen oft zum Download anbieten. Beim Apache-Server kann man mit Hilfe einer Datei .htaccess dafür sorgen, daß HTML-Browser eine andere Seite angezeigt bekommen:
RewriteEngine On RewriteCond %{HTTP_ACCEPT} !text\/vnd\.wap\.wml RewriteRule \.wml$ /error.htm |
Dabei wird ein Browser, der keine WML-Dateien anzeigen kann, beim Abruf dieser automatisch zu einer HTML-Seite "error.htm" umgeleitet, in der man den Besucher dann darüber aufklären kann, daß die jeweilige Subdomain nur für WAP-Geräte gedacht ist.
Inhaltsverzeichnis/Copyright - © Shamrock Software GmbH - Das Kopieren des Inhalts auf andere Websites ist nicht gestattet.