Codierung und Spamschutz für mailadresse
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
adresse
aja
ausgabe
beitrag
bild
chinesisch
client
datei
daten
datenempfang
dokument
encoding
fragen
funktion
mu
set
speicher
variant
webseite
zeichensatz
-
HI Leute ich hab da ein Paar fragen:
1)
Hab mir grad bei meiner Webseite gedanken über die Codierung gemacht.
Also ob ANSI(nem mal an dass das dann ASCII bedeutet) oder UTF-8 oder Unicode.
Wollte wissen was den da am Besten ist. Meine Webauftritt ließt viele Daten auch aus einer MySQL-DB aus.
Und es kommt auch vor das aus diesen Daten PDFs, XML, Mails erstellt werden. (also im moment noch her selten bis gar nicht ;)
Die DB ist im moment auf utf8_general_ci. Aber wo ist den Jetzt der unterschied zu utf8_unicode_ci oder uft8_bin ?
Aja damit die Verbindung zur DB auch klappt natürlich : SQL> SET NAMES utf8; bei jeder verbindung. (oder gibts da was besseres/anderes ?)
Die html/php datein sind die meisten (fasst alle) UTF-8 ohne BOM codiert.
Da gäbe es ja noch ANSI, UTF-8 mit BOM, Unicode/Unicode Big Endian. Nur wo ist bei all denen eigentlich der unterschied,
also mal abgesehen vom Zeichenumfang, das ist ja wohl klar ....
dachte ich frag auch gleich obs da probleme mit der FTP übertragung (ASCII/BIN) geben kann,
da ich da letztens öffters hinerteinander stecken geblieben bin...
Naja und damit auch der Browser Kappiert was gesprochen wird:
<?php
header('Content-type: text/html; charset=utf-8');
echo '<?xml version="1.0" encoding="utf-8"?>';
echo '<meta http-equiv="content-type" content="text/html; charset=utf-8" />';
?>
ist irgendwas an meinem Vorgehen absolüter blödsin ? oder würdet ihr das auch so machen ?
bzw wie macht ihr das? Kann es zu pars probs kommen oder so ?
2)
Spammschutz: Bis jetzt haben sich die E-Mailadressen auf der Webseite noch nie geändert, jetzt müsste ich aber trotzdem
einige ändern. Früher wurden die Mail-links (mailto:hugo@eample.com) in JavaScript irgendwie so verschlüsselt, dass diese nur
bei eingeschaltenem JS anklicken liesen. andernfalls wurde die adresse als plaintext bis zum @ ausgegeben. dieses wurde durch ein bild
mit dem alt und titel tag ="@" ersetzt und dann die Domein. dadurch konnte der Surfer die Adresse kopieren.
So jetzt zu miener Frage, macht das überhaubt sinn? Können die Mail-Harvester nicht auch JavaScript ?
Sonst hätte ich nämlich vor eine Php-funktion zu schreiben die mir die den Mail-link so umschreibt das er eben geschützt ist, und ich das nicht extra bei jeder mail ady von hand machen muss. (da wäre dann meine Frage welche ver & entschlüsselung können beide PHP und JavaScript ?)
oder wie löst ihr das ? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Hi,
zur Frage bezüglich Kodierung usw. kann ich dir leider keine Antwort geben, da ich in diesem Gebiet nicht sehr erfahren bin ... ;). Frag' mal Alopex, der weiss da am besten Bescheid denke ich.
Mit dem Spamschutz kann ich dir weiterhelfen.
Spambots "können" normalerweise kein Javascript, deshalb empfehle ich dir folgende php-Funktion, die ich umgebaut auch verwende:
http://web.archive.org/web/20060502152342/aidanlister.com/repos/v/function.mail_obfuscate.php
Alternativ dazu könntest du auch eine Funktion schreiben, die entweder ein Bild mit der E-Mail-Adresse ausgibt, @ bzw. . durch at bzw. dot ersetzt, Javascript-verschlüsselt usw ... solch eine abwechslung ist auch ziehmlich sicher.
mfg,
hr
Beitrag geändert: 18.7.2007 19:50:48 von heavyraptor -
Wow endlich mal jemand der was mit utf-8 anfangen kann.
Also um es mal vorweg zu nehmen... Webseite? ...ich würde KEINE OHNE utf-8 mehr machen.
Hat ganz einfach folgende Vorzüge:
1. utf-8 unterstützt so gut wie alle Zeichen (auch Chinesisch usw.)
2. man muß nicht mehr schauen ob der Nutzer gültige Zeichen eingegeben hat-Man kann ja alle Zeichen in der DB speichern
(auf SQL Injection sollte man aber noch testen)
3. der Server wird weniger belastet, weil dieser keine Konvertierung utf-
B zu iso beim Client vornehmen muß
Soo wen ich deinen Text mal so überfliege hast du auch alles angesprochen was man machen muß wenn man utf-8 nutzen will.
Also nochmal in Kurzform:
1. DB auf utf-8 umstellen
2. Seiten encoding <meta...> auf utf-8 stellen
3. Datenempfang der DB-Daten über "set names utf-8" angeben
Demzufolge kann ich dich zu dem Schritt nur beglückwünschen
Zu deinem zweiten Punkt, kann ich nur sagen dass die Bots meist kein Javascript können und dadurch auch nicht die E-Mail Adresse auslesen können.
Grüßle -
1>> Spambots "können" normalerweise kein Javascript, ...
2>>kann ich nur sagen dass die Bots meist kein Javascript können
Wieso, bzw woher wisst ih das ? Ich dank da eher so, wenn ein Browser das anzeigen kann, dann erkennt das auch der Harvester, ...
Sonst könne man da ja so ziemlich alle 2-wege verschlüsselungen in JavaScript verwenden. und als No JS variante ein Bild ....
hab jetzt auch noch diese Variante ausgegraben ...
der link in einer Datei: <a href="mail_me.php">Mail</a>
die andere datei(mail_me.php):
<?php
header("Location: mailto://user@example.com");
?>
aber Klapt nicht bei allen Browser + Mailclinet kombinationen. -> ab in die Tonne...
Und für die im impresum muss man sich ja sowieso was ohne JavaScript und Bild ausdenken, da das ja immer erkennbar sein muss.
edit: Aja Harvester haben nicht zufällig einen erkennbaren UserAgentString, sonst könnte man ja anhand dem schon ausfilten ... naja wäre aber blöd von ihnen, also vergest es ;)
Zur Kodierung:
>>1. utf-8 unterstützt so gut wie alle Zeichen (auch Chinesisch usw.)
wieso gibts dann in der Datenbank(
Zeichensatz / Kollation der MySQL-Verbindung) so viele verschiedene UTF-8s:
utf8_general_ci, utf8_bin, utf8_unicode_ci, utf8_persian_ci, utf8_swedish_ci, ...
>>2. man muß nicht mehr schauen ob der Nutzer gültige Zeichen eingegeben hat-Man kann ja alle Zeichen in der DB speichern
Hmmm ja aber darf man auch alle zeichen an den Browser sichcken, das ist ja die frage.
äöüß sind zwar Valide wenn sie in einem utf-8 dokument sind, aber einige andere nicht "'´`§$ ...
wenn man die wieder vorher konvertiert belstet es den server doch ?
>>1. DB auf utf-8 umstellen
>>2. Seiten encoding <meta...> auf utf-8 stellen
>>3. Datenempfang der DB-Daten über "set names utf-8" angeben
du hast die Komunikation von Server und Client:
Ich hab dazu in htaccess:
### AddType ######################### AddType text/css;charset=utf-8 .css AddType text/html;charset=utf-8 .html
und sende den Document Header mit php auch vor
<?php header('Content-type: text/html; charset=utf-8'); ?>
Damit der Browser auch weiß als was da die Zeichen Kodiert sind die da jetzt ankommen.
Aja seinen Editor sollte man auch umstellen das er gleich als Standart utf-( kodiert, sonst wundert man sich später noch ein paar mal)
Auch der FTP-Client sollte zumindest auf Auto, vl sogar besser Binär sein. Die Windows Zeilenumbrückse sollten den server ja nicht stören.
aja zum: SQL> SET NAMES utf8; ist das das sinnvollste ? oder gibts da was besseres, kenn mich nicht so aus, und das war das erste was ich versucht habe und es klappte eben :)
Beitrag geändert: 19.7.2007 13:36:26 von karl-tofel -
Wieso, bzw woher wisst ih das ? Ich dank da eher so, wenn ein Browser das anzeigen kann, dann erkennt das auch der Harvester, ...
Sonst könne man da ja so ziemlich alle 2-wege verschlüsselungen in JavaScript verwenden. und als No JS variante ein Bild ....
Nunja sagen wir so - ein Bot ist auch nur ein Programm. Wenn man also ein Bot schreibt der das in Zukunft unterstützt, dann ja. Derzeit sind mir allerdings keine Bots bekannt die JS auswerten.
Die Bots werten einfach nur Formularfelder und Links aus. Die Formularfelder werden evtl. mit Werten per URL übergeben und geschaut was zurück kommt - der Bot brauch dazu kein Javascript. Bei Links brauch er das auch nicht und bei irgendwelchen Javascript sachen die da evtl. dann auf der Webseite dargestellt werden, will der ehh nix zu tun haben. Bis jetzt gibts einfach keine Notwendigkeit dass ein Bot Javascript können müsste, um seine Zwecke zu erfüllen.
hab jetzt auch noch diese Variante ausgegraben ...
der link in einer Datei: <a href="mail_me.php">Mail</a>
die andere datei(mail_me.php):
<?php
header("Location: mailto://user@example.com");
?>
aber Klapt nicht bei allen Browser + Mailclinet kombinationen. -> ab in die Tonne...
Versteh ich nicht... der Browser soll also den eMail Client öffnen ohne eine Webseite anzuteigen? ...weil durch header wird diese Seite aufgerufen ohne die vorhergehende Seite anzuzeigen. Ist also meiner Ansicht nach totaler Blödsinn, aber hat ja auch nicht funktioniert.
Zur Kodierung:
>>1. utf-8 unterstützt so gut wie alle Zeichen (auch Chinesisch usw.)
wieso gibts dann in der Datenbank(
Zeichensatz / Kollation der MySQL-Verbindung) so viele verschiedene UTF-8s:
utf8_general_ci, utf8_bin, utf8_unicode_ci, utf8_persian_ci, utf8_swedish_ci, ...
Naja einfach aus Pervormancegründen. Je mehr Zeichen so ein Zeichensatz enthält desto länger brauch der Rechner natürlich auch diesen zu laden und zu verarbeiten.
Man hat also einfach weitere Teilzeichensätze mit ein wenig eingeschränkten Zeichen. Dadurch muß der PC nicht so viel verarbeiten.
Man muß halt immer so ein Spagat machen - will man alles unterstützen und dafür an schnelligkeit einbüßen oder eher nicht alles unterstützen und dafür schneller sein.
>>2. man muß nicht mehr schauen ob der Nutzer gültige Zeichen eingegeben hat-Man kann ja alle Zeichen in der DB speichern
Hmmm ja aber darf man auch alle zeichen an den Browser sichcken, das ist ja die frage.
äöüß sind zwar Valide wenn sie in einem utf-8 dokument sind, aber einige andere nicht "'´`§$ ...
wenn man die wieder vorher konvertiert belstet es den server doch ?
Sorry weiß gerade nicht was du willst. Die Datenbank und der Client unterstützen auch Zeichen wie "'´`§$ ... ...das einzigste was du auf jeden Fall machen mußt ist die Zeichen evtl. escapen, weil diese mit unter eine Funktion in der Verarbeitung haben.
Also immer die Eingaben vom Client mit mysql_escape_string() escapen, bevor du diese per sql-String zur DB sendest.
<? $sWert1 = mysql_escape_string($_POST['str_eingabe']); $iWert1 = intval($_POST['int_eingabe']); $sql = "INSERT INTO test (str_wert,int_wert) VALUES ('".$sWert1."',".$iWert1.");"; $res = mysql_query($sql); // usw. ... ?>
>>1. DB auf utf-8 umstellen
>>2. Seiten encoding <meta...> auf utf-8 stellen
>>3. Datenempfang der DB-Daten über "set names utf-8" angeben
du hast die Komunikation von Server und Client:
Ich hab dazu in htaccess:
### AddType ######################### AddType text/css;charset=utf-8 .css AddType text/html;charset=utf-8 .html
und sende den Document Header mit php auch vor
<?php header('Content-type: text/html; charset=utf-8'); ?>
Damit der Browser auch weiß als was da die Zeichen Kodiert sind die da jetzt ankommen.
hmm weiß nicht ob das geht, ich schreib es einfach mit bei der Dokument-Header-Ausgabe in der PHP Datei dazu mit dem <meta>-Tag. Du schreibst ja schließlich auch das "SET NAMES" in der PHP Datei Weiß nicht was günstiger ist.
aja zum: SQL> SET NAMES utf8; ist das das sinnvollste ? oder gibts da was besseres, kenn mich nicht so aus, und das war das erste was ich versucht habe und es klappte eben :)
Also in anderen Datenbanken (z.B. Postgres) wird es genauso gemacht. Ok der Befehl heißt dort bissl anders ("pgsql_set_client_encoding('utf-8');") aber das ist ja egal.
Eine andere Möglichkeit ist mir auch nicht bekannt.
Hoffe konnte bissl helfen.
Grüßle
Beitrag geändert: 19.7.2007 16:36:11 von scout -
das mim JS werd ich wohl so hinnehmen müssen, werd sowas basteln.
Das mim header() ist ja so das der nur HTTP-Anfangsinformationen sendet. Hab den Trick ausm Archiv von selfHTML, dort haben sich die aber darüber gestritten obs geht. Ob Widerspruch in der PHP Dokumentation ist und haben dann mit RFCs und anderen Spezifikationen herumgeworfen (HTTP, absulute/relative URI) ... ich kenn mich da aber auch nicht aus ...
Naja einfach aus Pervormancegründen. Je mehr Zeichen so ein Zeichensatz enthält desto länger brauch
der Rechner natürlich auch diesen zu laden und zu verarbeiten.
hmmmm naja dann finde ich die bei mir angebotenen Seltsam, den Chinesiche oder so sind dabei nicht extra angeboten, und die könnt ich mir vorstellen das es gut wäre sie extra zu machen.
Sorry weiß gerade nicht was du willst. Die Datenbank und der Client unterstützen auch Zeichen wie "'´`§$ ... ...das einzigste was du auf jeden Fall machen mußt ist die Zeichen evtl. escapen, weil diese mit unter eine Funktion in der Verarbeitung haben.
Also immer die Eingaben vom Client mit mysql_escape_string() escapen, bevor du diese per sql-String zur DB sendest.
Hmm ich miene jetzt wircklich nur die Ausgabe an den Browser, zB will er alle unds Im Quellcode unbedingt ecaped als & ... das meine ich ...
hmm weiß nicht ob das geht, ich schreib es einfach mit bei der Dokument-Header-Ausgabe in der PHP Datei dazu mit dem <meta>-Tag. Du schreibst ja schließlich auch das "SET NAMES" in der PHP Datei $Var Weiß nicht was günstiger ist.
Da weiß ich jetzt niht was du meinst ...
Also in anderen Datenbanken (z.B. Postgres) wird es genauso gemacht. Ok der Befehl heißt dort bissl anders ("pgsql_set_client_encoding('utf-8');" $Var aber das ist ja egal.
Das es in anderen Sprachen anders heißt dacht ch mit schon aber ich meinte eigentlich eh MySQL ...
meinte wegen:
SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;
naja danke soweit
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
