[gelöst] Sonderzeichen aus Word - Problem nur beim Auslesen

[Quetschi]

Hab hier eine Tabelle in der hauptsächlich über ein Webformular Texte per Copy&Paste aus Word übernommen werden.

Problem:
Die Texte landen laut phpMyAdmin korrekt in der DB, wenn ich allerdings dann per Script eine Ausgabe machen will, werden Sonderzeichen wie z.B. das "Anführungszeichen unten" oder der verlängerte Gedankenstrich (wie sie Word eben oft automatisch setzt) nicht mehr korrekt dargestellt. Umlaute "ÖÄÜöäü" usw. werden dagegen korrekt dargestellt.

Es ist komplett von vorn bis hinten alles in UTF8 gehalten:
- Zeichensatz der Seite mit dem Eingabefeld
- Zeichensatz des verarbeitetenden Scripts
- Zeichensatz der MySql-Verbindung
- Zeichensatz der DB/Tabelle
- Zeichensatz des auslesenden Scripts
- Zeichensatz der ausgebenden html-Seite

Warum zum Henker (sorry) kann phpMyAdmin diese Zeichen korrekt darstellen und mein Ausgabescript nicht?

Ich hab auch schon beim Ausgabescript nach der Verbindung zu mySql alles nochmal explizit auf UTF8 gesetzt:

$query = "SET character_set_connection = 'utf8'";
$query = "SET character_set_client = 'utf8'";
$query = "SET collation_connection = 'utf8_general_ci'";
$query = "SET character_set_results = 'utf8'"; 

Was überseh ich noch?

[AmicaNoctis]

Hallo,

ich hab zwar im Moment auch keine Idee, aber wenn du den Firefox benutzt, lohnt es sich, das Firebug Add-On zu installieren. Damit kannst du dir z. B. auch ansehen, wie die Formulardaten zum Server übertragen werden, welchen Response Content-Type der Server mitschickt und sowas alles. Vielleicht kommst du so dem Übeltäter auf die Schliche.

Für gespeicherte Dateien nehm ich nen HEX-Editor (oder den Lister von Total Commander, geht auch über FTP) um sicher zu gehen, dass die in UTF-8 vorliegen.

Gruß,

Amica

[Quetschi]

Die HTTP-Header hab ich schon angeschaut - wie gesagt, es läuft von vorn bis hinten in UTF8.

Ein Problem bei der Übertragung der Formulardaten würd auch ned erklären, warum phpMyAdmin die Datensätze richtig darstellen kann, nur meine Ausgabe nicht - ich muss ein Problem beim ausgebenden Script oder html haben.

[AmicaNoctis]

Ich will dir ja glauben, dass alles auf UTF-8 läuft, aber die Tatsachen sprechen leider dagegen. Wenn deutsche Umlaute korrekt sind, typografische Sonderzeichen aber nicht, sieht es für mich verdammt nach ISO Latin-1 aus.

[Kropff]

Ich sehe das Problem eher bei Word. Musste mich vor drei Jahren auch mit dem Problem herumschlagen und habe dafür keine Lösung gefunden. Lag imho daran, dass Word diese speziellen Zeichen nicht standardkonform ausgibt. Das hängt, glaube ich sogar, von der Word-Version ab. Wenn die schon ein wenig älter ist, dann wird's das wohl sein.

Peter

[Quetschi]

Ich hab jetzt mal das html weggelassen und lasse nur den Inhalt der Textspalte ausgeben. Vor der Ausgabe schicke ich noch den entsprechenden Header vorab

header("Content-Type: text/plain; charset=utf-8"); 

bzw. wenn ich es in html einbinde

header("Content-Type: text/html; charset=utf-8"); 

Witzig - wenn ich im Browser den Zeichensatz auf ISO-8859-1 stelle, wird der Text korrekt angezeigt.

Ich raff jetzt gar nichts mehr - was bedeutet das nun? Das der Text aus der DB gar nicht in UTF8 kommt?

[AmicaNoctis]

was bedeutet das nun? Das der Text aus der DB gar nicht in UTF8 kommt?

Dass er doppelt UTF-8-codiert ist?
Edit: Ach nee, das ist es nicht.

[pekka]

Ich würde mal drauf tippen, daß die Sonderzeichen aus Word in ISO oder einer ähnlichen Kodierung geliefert werden?

Eventuell sind die Mechanismen anguckenswert, die die großen Rich-Text-Javascript-Editoren fürs Copy&Paste von Word-Inhalten einsetzen. Das sind normalerweise Funktionen nach dem Muster cleanupWordHTML(). Ob die auch Zeichensätze konvertieren weiß ich nicht, es kann aber gut sein.

[Quetschi]

@Kropff (hab dein Post vorhin ned gesehen)
IMHO sind diese Zeichen in UTF8 drin - phpMyAdmin ist ja auch zur korrekten Darstellung imstande - die Frage kann eigentlich nur lauten: Was mach ich bei der Ausgabe falsch??

@AmicaNoctis
Ich konvertier in dem Fall auch nichts hin- und her - darum ja auch durchgehend utf8 um das eben nicht machen zu müssen.

Hat noch jemand eine Eingebung?

Langsam krieg ich Kopfweh davon

[Quetschi]

@pekka
Die Editoren machen in der Regel numerische Entities draus.

[pekka]

@pekka
Die Editoren machen in der Regel numerische Entities draus.

Was gar nicht der dümmste Umweg wäre, oder? Aus den Entities kriegst Du beim Speicherzeitpunkt ja ohne weiteres wieder normale Zeichen gemacht.

[Quetschi]

Das kann irgendwie nicht Sinn der Sache sein - was mir primär einfach nicht aus dem Kopf geht ist ja:

1. phpMyAdmin kann die Zeichen darstellen
2. Ich bzw. mein Ausgabescript kann es nicht

„Umwege“ möcht ich irgendwie nicht gehen müssen, wenn ich sehe, dass es offensichtlich (siehe Satzanfang) auch anders geht.

Edit:
Die numerischen Entities sind ja IMHO dafür da, Zeichen aus eben z.B. UTF8 in einer simplen ANSI-kodierten Datei zu speichern.

[pekka]

In welcher Kodierung zeigt phpMyAdmin die Zeichen denn an?

[AmicaNoctis]

Fragen dazu:

Welchen Response Content-Type hat denn die PMA-Seite?
Hattest du mysql_set_charset() schon benutzt? Du warst nur auf die Queries von Hand eingegangen, daher bin ich mir grad nicht sicher.

[Quetschi]

@pekka

phpMyAdmin hat im Quelltext

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 

Ebenso liefert der Server die Daten auch mit

Content-Type: text/html; charset=utf-8

aus.

Ein Blick unter Ansicht->Zeichenkodierung sagt ebenfalls, dass der Browser in UTF-8 geschaltet hat.