strayer's testpage - Xtra Zeugs

Xtra Zeugs

---Info---

XML-Dateien
(BZFlag, TVinfo)

Firefox
(search-plugins)

Eingebettete Medien

ToDo-Liste

Webseiten-Statistik

Was ist neu?
(2004-12-02)

News

Anzahl der Einträge:

Letzter am:

2006-10-07

von:

STRAYER

Gästebuch

Anzahl der Einträge:

Letzter am:

2011-09-24

von:

strayerfan

BZFlag

Anzahl der Server:

180

Anzahl der Spieler:

Abfrage vor:

2 min

TVinfo|DE

Anzahl der Sender:

107

Sendungen:

143267

Daten seit:

2024-12-19

Daten bis:

2025-01-29

Statistik

Besuche*:

???

Aufrufe*:

???

*:o) ohne strayer (o:

Sitemap

Enjoy www.strayer.de!

Die obigen Daten werden aus Gründen der Performance für kurze Zeit gecached.

Eingebettete Medien

...sind Medien, welche in anderen Dokumenten integriert sind, ohne lediglich einen Ressourcelink zu setzen. Das beste Gegenbeispiel zu eingebetteten Medien ('inline media') sind gängige HTML-Seiten, bei denen die Medien nur als Quelllink mit zusätzlichen Attributen angegeben werden. Im Folgenden wird sich bei eingebetten Medien speziell auf Bilder bezogen, wobei die Beschreibung auch für jegliche andere Art zutreffend ist.

<img src="./pics/favicon.png" alt="inline image" width="150" height="160" />
Wie im obigen Beispiel zu sehen ist, ist die Quelle (respektive Ressource) des Bildes dem Attribut 'src' des HTML-Tags 'img' zugeordnet und gibt an, wo das Bild zu finden ist. Daraufhin kann die auswertende Applikation, bei HTML-Seiten meist ein Webbrowser, dieses Bild nachladen und dem Nutzer präsentieren. In einigen Fällen kann es jedoch gewünscht sein, dass ein solches Nachladen nicht möglich oder schlicht unerwünscht ist. Ein Beispiel hierfür wäre eine HTML-E-Mail, der keine Bilder angehängt werden sollen oder dürfen. Entsprechend RFC 2397 und RFC 2557 ('Request for Comments') ist es erlaubt, die Bilddaten ('image stream') auch direkt in Dokumente einzufügen.

inline image

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAJYAAACgBAMAAAAcDIhhAAA
AD1BMVEUAAAARKg0oQCXA1sDG/8bRXuTeAAAAAXRSTlMAQObYZgAAAAlwSFlzAAAOxAAA
DsQBlSsOGwAAAMFJREFUaIHt18ENwzAMQ9Gs4BWyQlbI/jMFdoEKEahUQC9l8XmUxedbj
GxjZvs2LwULy8pS4F5FMVhYrtZKVEaVcgULy8Z67nWzFCwsGyt9/1eOmbKnTuVbgoVlZZ
WV8hIsLC8r3o7jHVVWBzHL7xAWlouVds6Zcc+aqTuxsKytBEZFzbCw/smKcmOGheVvldv
PKhaWl5V+bhtgzWBhOVtRUUl7WFiuVhfsMFhYVlaASk3CBwYLy8pSakpbwML6VesCmOfu
PMgWmoQAAAAASUVORK5CYII="
alt="inline image" width="150" height="160" />
Im Beispiel oben ist zu erkennen, dass die 'src'-Angabe aus bis zu vier Teilen besteht:

data:[<mediatype>][;base64],<data> (siehe RFC 2397)

data: ... gibt an, dass nachfolgend kein Verweis auf die Ressource sondern die Bilddaten direkt kommen.
<mediatype>: ... steht für die Art des Mediums.
base64: ... ist optional und zeigt, dass der nachfolgende Datenstrom base64-kodiert ist. Sollte diese Angabe fehlen, so handelt es sich um eine ASCII-Zeichenkette.
<data>: ... ist der Datenstrom selbst.

Man sieht an diesem Beispiel sehr deutlich, dass schon ein so einfaches Bild eine recht lange Zeichenkette als base64-kodierte 'Datenschlange' zur Folge hat. Hier liegt auch schon der Schwachpunkt dieser Variante des Einbettens von Medientypen, denn nach RFC 1866 dürfen HTML-Dokumente nicht unendlich lange Zeichenketten verwenden, weshalb sich nur 'kleine' Bilder hierfür eignen. Bei anderen Dokumenttypen (wie XML) sind diese Beschränkungen entweder nicht oder in einem anderen Maße vorhanden.

Auf dieser Webseite kommt diese Technik von eingebetteten Medien (in dem Fall: eines Bildes) bei meinem Gästebuch zum Tragen, da unerwünschten Einträgen durch sogenannte Spambots, welche entweder Unsinn oder Werbung eintragen, vorgebeugt werden soll. Es wird ein Bild erzeugt, welches einen bestimmten zufällig generierten Code enthält, welcher vom Nutzer abgelesen und zur Kontrolle eingegeben werden muss, damit die Nachricht tatsächlich gespeichert wird.
Die Vorteile eines eingebetten Bildes gegenüber anderen Varianten ergeben sich aus der Art der Generierungsmöglichkeit des Bildes und des zugehörigen HTML-Codes:

Verhindern des Cachens eingebetter Bilder (nützlich bei CAPTCHA-Bildern)
Verzicht auf Cookies
Verzicht auf Speicherung von gültigem Code für eine Session (und auf Sessions allgemein)
Verzicht auf Listen mit gültigen Codes (wird häufig verwendet ist aber auch eher zweifelhaft)
Verzicht auf Weitergabe des Codes an eine seperate Skriptdatei die das Bild dann seperat erzeugt (PHP-Skripte können i.d.R. nicht HTML-Code erzeugen und zeitgleich Bilder ausgeben)
Generierung des Codes und des Bildes in einer einzigen Datei und damit Verzicht von Datenbanken und zusätzlichen Dateien zur Codespeicherung

Dementsprechend erzeugt ein PHP-Skript sowohl den Code, das Bild als auch ein verstecktes Eingabefeld, welches den mittels Einwegverschlüsselungsverfahrens (wie MD5, SHA1 oder CRC32) verschlüsselten Code als Inhalt hat, der dann nach dem Absenden des Formulars als Vergleichszeichenkette zu dem vom Nutzer eingegeben Code dient. Stimmen beide überein, so wird der gesamte Eintrag gespeichert. Einwegverschlüsselungsverfahren in Kombination mit kurzem Schlüssel (Code) sind für solch weniger heikle Anwendungsgebiete wie Gästebücher hinreichend sicher. :o)

Einen weiteren gewichtigen Haken hat dieses Verfahren allerdings noch, denn Microsofts Internet Explorer (des Teufels lästigste Plage) ist bis inklusive der Version 6.x nicht konform zu oben angegebenen RFCs und unterstützt dieses Verfahren nicht. Wie es mit den Internet Explorer-Versionen 7.0 und höher aussehen wird, ist mir unbekannt und auch irgendwie egal. Sofern sich ein IE-Nutzer diesen Artikel anschaut und feststellt, dass er das Beispielbild sehrwohl sehen kann, so liegt das an einem Workaround von Dean Edwards, den ich hier angewendet habe. Wer dazu mehr erfahren möchte, möge die Informationen dazu auf seiner Webseite nachlesen.

Viel Spaß beim Rumspielen...ich habe damit auch schon einige Zeit vertan, bis ich genug davon hatte... ;o)

...(2005-08-29)...

This is strayer's / ASP's BZFlag site, test-platform and private homepage with TVinfo and other stuff.