17.08.2009

Channel php.de ausgewählt, Log vom 17.08.2009

Seite:  < 1 2 3 4 5 >  Letzte Seite

Chatlog

NilsB: In der Administration sind sie auch kaputt?
initCH: ich hol den Wert per POST und speichere dass ganze dann in die DB
initCH: ja NilsB, sie sind schon direkt in der db "kabutt"
initCH: ändere ich dort wieder auf z.b. ä klappts überall
SlashLife: Lass mich raten: Bei der Ausgabe verwendest du utf_encode?
NilsB: Die ausgebende Seite hat dieselbe Kodierung wie die eingebende?
SlashLife: +8
initCH: nein SlashLife
initCH: ein einfaches echo $var
initCH: höchstens htmlspecialchars könnte ich verwenden
SlashLife: Sicher, dass specialchars und nicht entities?
initCH: evtl au entities..
initCH: hier trägt man die anwtort ein http://of.paavo.ch/?page=mitmachen_fragen
SlashLife: Gna. Ich bekomme kein Ausrufezeichen mehr. >_<
initCH: und hier zb wird sie ausgegebn
initCH: http://of.paavo.ch/?page=antworten&antwort=79
initCH: bei der ersten antwort hab ich das ä in der DB ersetzt, die anderen sind nicht verändert
@et-: SlashLife: typischerweise ist einfach das connection encoding kaputt
NilsB: Na das sieht doch fast nach einem Anhaltspunkt aus. htmlentities() raus, kucken obs klappt.
SlashLife: et-: Typischerweise ist es dann aber auf beiden Seiten kaputt, sodass es nicht mehr zu merken ist.
@et-: SlashLife: noe
initCH: ja ich nutze htmlentities seh ich grade, aber erst bei der ausgabe
initCH: kabutt gehts aber schon beim eintragen in die db
@et-: SlashLife: das kam schon ca 100 mal, dass das probleme gemacht hat ;)
SlashLife: et-: Wenn ich da meine UTF-8-Daten ueber eine ISO-8859-Verbindung reinschreibe und ueber eine 8859-Verbindung wieder auslese, habe ich wieder dieselbe Oktettfolge.
initCH: also müsste ich den fehler beim eintragen fixen, nicht?
NilsB: initCH: Du weißt doch gar nicht, ob es in der Datenbank kaputt ist.
NilsB: Vielleicht benutzt dein anderer Anzeiger einfach die falsche Kodierung. Die Daten sind dann völlig in Ordnung, werden dir nur komisch angezeigt.
NilsB: &Atilde;&curren; klingt nämlich sehr nach einem 1A-UTF-8-Umlaut.
initCH: hmm
initCH: könnte auch sein NilsB
initCH: http://of.paavo.ch/?page=antworten <- hier hab ich bei den ersten zwei fragen htmlentities entfernt
initCH: bei der ersten ist das geänderte ä in der db, bei der zweiten kommts richtig mit dem komischen Ã?
initCH: somit hattest du wohl recht NilsB
NilsB: Die erste hast du eben kaputt gemacht.
NilsB: Ist nicht wahr! Ich?
initCH: ja den hab ich butt gemacht
initCH: komisch..
NilsB: nein, gar nicht, eigentlich
SlashLife: ABER HTMLENTITIES IST VIEL SICHERER ALS HTMLSPECIALCHARSausrufezeichenausrufezeichenausriufezeichen
SlashLife: Ich brauche eine neue Tastatur :<
initCH: das war dann wohl die nächste frage
initCH: wie soll ich das jetzt absichern?
bartho: kleine frage, wenn ich mir eine php class programmiere die einen mysql_query ausführen soll, muss ich dann in der classe die DB verbindung herstellen oder kann ich dies auserhalb machen und dann eingach mysql_query(...)
SlashLife: initCH: Das war ein sinngemaesses Zitat eines ##php-Ops im Freenode, bevor ich dafuer gekickt wurde, dass ich es nach Lesen von en.wikipedia.org/wiki/Character_Set nicht einsehen wollte, dass htmlspecialchars viele Sicherheitsluecken offen laesst.
initCH: hmm ok
initCH: und wa mach ich jetzt?
SlashLife: Deine Umlaute in der Datenbank wieder zurueckaendern ...
NilsB: initCH: Du blickst hinter SlashLifes (transparenten) Sarkasmusvorhang und benutzt htmlspecialchars().
SlashLife: ... oder mir erklaeren, WARUM htmlspecialchars unsicherer als htmlentities ist.
initCH: ook ook
initCH: schon passiert =)
rh: SlashLife wenn du ne Antwort hast mir auch sagen. ;)
SlashLife: Du bist off-topic.
SlashLife: Wir schreiben hier PHP, nicht Ook.
rh: :P
@et-: SlashLife: wenn du nur das machst, ja
@et-: du kannst aber mal die logs durchgreppen, wie oft ein "SET NAMES" geholfen hat
SlashLife: Das ist dann aber meist nach dem Laden eines Dumps.
@et-: oder wenn jemand noch ueber phpmyadmin aendert ...
@et-: oder wenn da sql-queries mit substrings vorkommen ...
SlashLife: ... was hier alles nicht der Fall ist.
@et-: oder wenn generell noch andere skripte dran rumfummeln ...
@et-: SlashLife: das mit dem sql-admin-panel tut er ;)
@et-: SlashLife: und ich sagte "typischerweise"
SlashLife: Das hat ihm das ganze ja jetzt erst kaputtgemacht.
@et-: nicht "in diesem fall"
koredn: Dafuer ist dann aber eigentlich nur wichtig, dass das table-encoding stimmt. Wenn connection-encoding != table-encoding konmvertiert MySQL on-the-fly.
SlashLife: Du sagst mir also, dass ich einen speziellen Workaround nicht nennen darf, weil er typischerweise in Faellen, bei denen die Fehlerquelle eine andere ist, nicht funktioniert?
koredn: (Was natuerlich bei charset-inkompabilitaeten auch zu problemen fuehren kann)

Seite:  < 1 2 3 4 5 >  Letzte Seite

Webseiten Tipps

Hier gehts zum jquery Tutorial.
Meine schwarze Webseite: iPhone4Spiel