[gentoo-user-de] [OT] Daten fuer PHP und MySQL maskieren

[gentoo-user-de] [OT] Daten fuer PHP und MySQL maskieren

[Jan C. Potthoff]

Moin ...

Ist zwar eine Spur OT und Newbie, aber ich weiss, dass
ich auf dieser Liste fundierte Anworten und
verschiedene Meinungen erhalten kann. Googlen konnte
mir leider nicht das Fuer und Wider zu meinem Problem
liefern ... oder ich war zu doof, Google richtig zu
benutzen :-)

Meine Frage ist: Wie maskiere ich Daten im
Zusammenspiel mit PHP und MySQL sinnvoll?

Ich hatte vor, das mit so einer Funktion zu
realisieren:

<code>
maskiere($str_input)
{
    return htmlentities(strip_tags(trim($str_input)));
}
</code>

Entfernt mir ueberfluessige Leerzeichen, PHP- und
HTML-Tags und macht aus Umlauten &xuml;.

Wenn ich nun damit aber die Eingaben maskieren wuerde,
die in die DB sollen, werden die Strings ja nicht mehr
ganz berechenbar lang:

Z.B. habe ich ein Feld "Name char(50)" und moechte
dann jemanden speichern, der einen 50 Stellen langen
Namen mit 10 Umlauten hat. Das taet ja nicht mehr
passen, weil ein Umlaut zu fuenf Zeichen konvertiert
wuerde. Daten wuerden abgeschnitten, obwohl der Name
fuer den User ja nur 50 Stellen lang ist.

Sollte man also nur strip_tags(trim($wert)) in der DB
speichern?
Dann muss ich natuerlich auf die gleiche Codierung von
DB und uebergebenen Daten aus dem HTML-Formular
achten, damit in der DB anstatt den Umlauten nicht
irgendwelche komische Sonderzeichen stehen.

Fuer die Ausgabe koennte man dann
htmlentities(strip_tags(trim($str_input)))
verwenden.

Wenn ich nun aber das ganze bei einem 08/15-Anbieter
hosten lassen, kann ich dann ueberhaupt die Codierung
der DB beeinflussen, wenn ich "nur" Zugriff ueber
phpMyAdmin habe?

Was sind Eure Ansaetze fuer dieses Problem?

Vielen Dank im Vorraus fuer jegliche Anregung.

Jan


Send instant messages to your online friends http://au.messenger.yahoo.com 
-- 
gentoo-user-de@gentoo.org mailing list

Re: [gentoo-user-de] [OT] Daten fuer PHP und MySQL maskieren

[Sebastian Damm]

[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]

Hallo,

Am 11. August 2005 schrieb Jan C. Potthoff:
>     return htmlentities(strip_tags(trim($str_input)));

Ich hab bis jetzt immer 
	htmlentities(nl2br(trim($str_input)))
genutzt. strip_tags war mir recht neu, scheint aber sinnvoll zu sein,
werde ich bei der nächsten Version meiner Seite berücksichtigen.

> Wenn ich nun damit aber die Eingaben maskieren wuerde,
> die in die DB sollen, werden die Strings ja nicht mehr
> ganz berechenbar lang:

In die Datenbank gehören immer die Rohdaten. Was dann beim Auslesen
daraus gemacht wird, ist Sache des Skriptes. trim und striptags können
natürlich vorher drüberlaufen gelassen werden.

> Dann muss ich natuerlich auf die gleiche Codierung von
> DB und uebergebenen Daten aus dem HTML-Formular
> achten, damit in der DB anstatt den Umlauten nicht
> irgendwelche komische Sonderzeichen stehen.

Ist das nicht automatisch gegeben? Wenn die Daten aus einem Formular
auf einem UTF-8-System ankommen, müsste doch auch die Datenbank UTF-8
als Kodierung haben. Damit regelt sich das denk ich mal von allein. Was
anderes ist es natürlich, wenn Webserver und MySQL auf verschiedenen
Servern laufen, die verschiedene Kodierungen benutzen. 

So stell ich mir das zumindest vor, ich hab allerdings noch keine
Versuche bezüglich dieser Frage gemacht, allerdings auch noch nie
Probleme gehabt. 

> Wenn ich nun aber das ganze bei einem 08/15-Anbieter
> hosten lassen, kann ich dann ueberhaupt die Codierung
> der DB beeinflussen, wenn ich "nur" Zugriff ueber
> phpMyAdmin habe?

Man kann in phpMyAdmin (zumindest in neueren Versionen) die Kodierung
einstellen, auch beim Import kann man die Kodierung angeben. Ob da
jedoch irgendwas fest in der Datenbank geändert wird, weiß ich nicht.

Ciao
Sebastian
-- 
Sebastian Damm
Blog: http://blog.sdamm.de
GPG-Encrypted mail welcome! ID: 0x64D96827 @ pgpkeys.pca.dfn.de
Fingerprint: CB7F F23F D950 644D 838B  215A 550F 75EC 64D9 6827

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user-de] [OT] Daten fuer PHP und MySQL maskieren

[Jan C. Potthoff]

--- Sebastian Damm <lists@sdamm.de> wrote:
> In die Datenbank gehören immer die Rohdaten. Was
> dann beim Auslesen daraus gemacht wird, ist Sache
> des Skriptes. trim und striptags können natürlich
> vorher drüberlaufen gelassen werden.

Das leuchtet ein. Man koennte die Daten ja auch mal
z.B. als PDF ausgeben wollen.
 
> Ist das nicht automatisch gegeben? Wenn die Daten
> aus einem Formular auf einem UTF-8-System ankommen,
> müsste doch auch die Datenbank UTF-8 als Kodierung
> haben. Damit regelt sich das denk ich mal von
allein.

Hmm .. ich habe im Meta-Tag der Skripte
charset=ISO-8859-1, also latin1, angegeben und MySQL
sagt das:

<code>
mysql> status;
[...]
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1
[...]
</code>

Demnach sollten beide das gleiche Charset benutzen. Es
kommen aber leider die Sonderzeichen anstatt der
Umlaute in der DB an.

Aber nach Deinem Hinweis auf utf-8 habe ich bei Google
diese Anleitung gefunden. Ist zwar in Teilen fuer
PostgreSQL, aber diese Parts werden sich wohl
irgendwie auch auf DB-unabhaengig umsetzen lassen:

http://www2.uibk.ac.at/zid/systeme/webserver/webapp/postgres_zeichensatzkodierung.sdbk#id2788436

Tschoe und Danke
Jan


Send instant messages to your online friends http://au.messenger.yahoo.com 
-- 
gentoo-user-de@gentoo.org mailing list

Re: [gentoo-user-de] [OT] Daten fuer PHP und MySQL maskieren

[Sebastian Damm]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

Hallo,

Am 11. August 2005 schrieb Jan C. Potthoff:
> Hmm .. ich habe im Meta-Tag der Skripte
> charset=ISO-8859-1, also latin1, angegeben

Das hat ja aber eigentlich nur was mit der Ausgabe für den Browser zu
tun, wenn ich da jetzt nix falsch verstehe. Und während der Bearbeitung
gibst du ja nix aus und dem System ist das glaub ich auch egal, ob und
was da im Meta-Tag steht. Ich denk, da zählt eher die Systemeinstellung.

> und MySQL sagt das:
> Server characterset:    latin1
> Db     characterset:    latin1
> Client characterset:    latin1
> Conn.  characterset:    latin1
> [...]
> </code>

Interessant, sowas sagts bei mir auch. Aber der locale-Befehl im System
sagt was ganz Andreas:

dams@eddie ~ $ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=de_DE.utf8

Bei meinem Webhoster das gleiche, in der Shell bekomm ich nur alles
korrekt angezeigt, wenn ich mein Putty auf UTF-8 einstelle, also nehm
ich das mal als locale an, kann ich aber nicht nachprüfen, der Befehl
ist gesperrt. Der MySQL-Status zeigt mir aber auch dort Latin1 als
Zeichensatz an, irgendwie trau ich der Ausgabe nicht. In der my.cnf
kann man auch nix in Bezug auf Zeichensatz einstellen.

Du kannst natürlich mal probieren, ob das mit den Sonderzeichen besser
wird, wenn Du die nach einem utf8_encode() in die Datenbank einträgst.
Nur so eine Idee.

Ciao
Sebastian
-- 
Sebastian Damm
Blog: http://blog.sdamm.de
GPG-Encrypted mail welcome! ID: 0x64D96827 @ pgpkeys.pca.dfn.de
Fingerprint: CB7F F23F D950 644D 838B  215A 550F 75EC 64D9 6827

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]