OK, danke für eure Antworten.

Nur hab ich keine htaccess sondern eine global.asa - nix PHP also MSSQL und ASP...

Aber danke für die Hilfe, ich werde dann wohl mich an die lange Variante ranmachen.

nur so ... was meinst du damit?

was hat PHP damit zu tun, dass HTML-dokumente mit einer korrekten zeichensatz-angabe ausgeliefert werden sollten?

Ich hab das ganze so verstanden, dass er die daten falsch in der DB abspeichert ... das muss ja heissen er bearbeitet die daten weder vor, noch nachdem es in der DB war ... wenn mans vernünftig gecodet hätte, würde ers entweder vorher oder nachher durch ne phpfunktion jagen, das er alles so umwandelt das der zeichensatz wurscht is.. (&#blub; bzw & ...)

deswegen meinte ich das...

__edit: boah sry für das schlechte deutsch... ^^

Schon mal darüber nachgedacht die Daten mit Charset/UTF8 in die DB zu legen

Ist aber erst mit MySql 4.1 möglich ........... (bin aber nicht sicher)

hier ein THREAD dazu http://www.xhtmlforum.de/viewtopic.p...ght=mysql+utf8


Außerdem legt man die Daten zwar Validiert aber nicht verändert in die DB, sondern macht dies generell beim Auslesen, sonst mußt Du die wieder "zurück bearbeiten", oder wie stellst Du HTML-Entities in einem textarea/input-Element dar.

PHP http://de.php.net/manual/de/function.htmlentities.php

__________________
</ulle>

na ja, in mysql kann man erst ab 4.1 auch unicode als character set definieren.

unicode-texte in der ascii-kodierung in die DB-speichern geht aber auch schon vorher, in normalen textfeldern mit beispielsweise iso-8859-1 als charset.
muss man dann nur beispielsweise bei suchabfragen natürlich dafür sorgen, dass die suchargumente genauso kodiert sind. (ob's bei FULLTEXT SEARCH evtl. probleme bereiten könnte, hab ich noch nicht ausprobiert.)

Jetzt habe ich denn Satz 3mal gelesen, (stutz)
_____________________________________

Wenn ich ein "ä" in einem "normalen textfeldern mit beispielsweise iso-8859-1 als charset" an den Server sende, kommt da auch ein "ä" an. Nämlich genau 1 Zeichen; bei UTF-8 genau 2 Zeichen



Also nochmal genau:


1. Dokument:
~ Content-Type: text/html; charset=iso-8859-1
~ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
~ <form .... accept-charset="iso-8859-1"......>

Eingabe [ä] ankommend am Server [ä] (1 Zeichen)



2. Dokument:
~ Content-Type: text/html; charset=UTF-8
~ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
~ <form .... accept-charset="UTF-8"......>

Eingabe [ä] ankommend am Server [ä] (2 Zeichen), zumindest wird es als [ä] angezeigt, was auch logisch ist ist ja eine UTF-8 Ausgabe.


Ausgelesen habe ich das so:Also kommen verschiedene Daten am Server an, und diese kann ich einfach so, ohne Änderung in die DB tüten. Okay das verstehe ich noch, aber Deinen obigen Satz nicht wirklich.

Könntest Du mir das nochmal genau erläutern....

__________________
</ulle>

eben, es kommt ä für das ä am server an.
das kannst du als zwei stinknormale ascii-characters in die DB schreiben, eben à gefolgt von ¤. damit hat die auch bei charset iso-8859-1 kein problem.

und wenn du jetzt bei der ausgabe auch wieder ä ins dokument schreibst (also genau so, wie's von der DB kommt), und dein dokument drumherum als unicode in ascii-kodierung gespeichert hast sowieso das character-encoding für die ressource korrekt als utf-8 angibst, stellt das auch jeder korrekte browser wieder als ä dar.

Bis auf diesen Satz "damit hat die auch bei charset iso-8859-1 kein problem." gehe ich mit Dir syncron.......

Nur was meinst Du mit dem Satz, wer ist den "die"

<edit>
Jetzt verstehe ich, Du meinst die DB steht in iso-8859-1

__________________
</ulle>

Und da wir schon dabei sind, was ist wenn ich die ankommenden Daten als Email weiter verarbeiten will

__________________
</ulle>

die datenbank.
die bekommt reine ascii-zeichen geliefert, also warum sollte sie da anlass zur beschwerde haben? und sie liefert dir auch wieder reine ascii-zeichen zurück.

wie schon gesagt, die einzige stelle, wo ich mir wirklich ein problem vorstellen kann, wäre eine FULLTEXT SEARCH - ob mysql da richtig bestimmen kann, was ein "wort" ist und was nicht, da habe ich noch leichte zweifel.

wenn du aber nur per normaler suche beispielsweise nach datensätzen suchst, die ein ä enthalten, gibt's kein problem - du musst halt nur vorher dafür sorgen, dass dieses ä genauo kodiert wird, wie es eigentlich in der DB steht - also WHERE textfeld LIKE '%ä%' beispielsweise, wird dir alle datensätze liefern, die ein ä enthalten.
OK, wenn der vergleich case-insensitive gemacht werden soll, haben wir hier u.U. auch ein problemchen - denn das große Ä ist 'Ä', das finden wir so nicht wieder.


das untersuche ich derzeit auch noch ...


und btw: nimm's mir nicht übel, aber dein teilweise exzessiver grafik-einsatz nervt ein wenig - ein einfaches ? statt tut's doch m.E. im allgemeinen auch, oder? also stell dich doch bitte nicht mit dem schreibstil der scriptkiddies auf eine stufe, danke!!!!!!!1