Mailinglisten-Archive |
Hi Jens, Zitat von Jens Vetter: > erstmal ganz herzlichen Dank für Deine große Mühe und die Zeit, die du > investiert hast. keine Ursache. :-) Es hat mir selbst sehr viel Spass gemacht, der Sache auf den Grund zu gehen, und ich denke, es gab auch eine Menge dabei zu lernen. > Es funktioniert ... [...] > Also erstes Problem gelöst. Das freut mich sehr. :-))) > Nur das zweite größere Problem, wie ich die Daten nun in eine Exceldatei > bekomme steht immer noch offen. > > Ich habe gerade auch den Header in Verbindung dem PEAR Excel > Spread-Sheet probiert. Keine Chance. Ich habe bisher mit dem PEAR Spreadsheet Excel Writer nicht gearbeitet. Also kann ich Dir nur ein paar "laienhafte" Fragen stellen... :-) Hast Du den Header mit folgender Funktion mitgegeben?: - http://www.dcc.uchile.cl/~xnoguer/peardoc2/package.fileformats.spreadsheet-excel-writer.spreadsheet-excel-writer-worksheet.setheader.html Hast Du auch einmal alternativ versucht, den Zellen die Schriftart mitzugeben? Vielleicht geht das ja hiermit: - http://www.dcc.uchile.cl/~xnoguer/peardoc2/package.fileformats.spreadsheet-excel-writer.spreadsheet-excel-writer-workbook.addformat.html - http://www.dcc.uchile.cl/~xnoguer/peardoc2/package.fileformats.spreadsheet-excel-writer.intro-format.html Besteht das Problem auch, wenn Du die Datei lokal wegschreibst und nicht ueber den Browser ausgibst?: - http://www.dcc.uchile.cl/~xnoguer/peardoc2/package.fileformats.spreadsheet-excel-writer.intro.html > Der Browser bekommt zur Darstellung jetzt seine UTF-8 Vorgabe, die Daten > bleiben aber unkonvertiert. Mir ist nicht ganz klar, worauf Du Dich jetzt beziehst, aber vielleicht trifft folgendes, was Du meintest: Die Browsereinstellung bezieht sich sehr wahrscheinlich nur auf Dateien, die der Browser selbst anzeigt, nicht jedoch auf Dateien, die er lediglich zum Download anbietet. D.h. wenn Du mit dem Writer eine Excel-Datei generierst und zum Download anbietest, dann hat der Browser dabei ueberhaupt keinen Einfluss auf den Zeichensatz, selbst wenn er sich die Excel-Anzeigekomponente ins Browserfenster holen und von dieser die Excel-Datei anzeigen lassen sollte. Da bist Du naemlich dann praktisch schon in Excel. > Welche Möglichkeit gibt es denn jetzt, die Daten konvertiert an den > Excel-Export weiter zu geben ? Die Daten muessen in dem Sinne nicht konvertiert werden, Du musst nur sicherstellen, dass die Zeichensatz-Informationen die ganze Zeit richtig mitgenommen werden. Also wenn der Import ueber CSV geklappt hat, dann waere aus meiner Sicht der folgerichtige Ansatz, auch den Export erst einmal auf der transparentesten und einfachsten Ebene ueber CSV zum Laufen zu bringen. Danach kannst Du immer noch an einer eleganteren Loesung tuefteln. Um alle Browserunwaegbarkeiten auszuschliessen und zu gucken, ob es serverseitig und clientseitig praktisch funktioniert, wuerde ich folgendes machen: 1. Aus der Datenbank die UTF-8-formatierten Daten auslesen und lokal, d.h. auf dem Server, in eine CSV-Datei speichern. Dabei musst Du nur auf die korrekte Syntax der CSV-Datei achten, also Feldtrennung mit Semikolon, Textfelder mit doppelten Anfuehrungsstrichen umschliessen und Zeilenumbruch am Ende des Datensatzes entweder mit \n oder \r\n. Ich glaube, es war letzteres, kann mich aber nicht mehr genau erinnern. Musst Du durch Import in Excel ausprobieren, was von beiden korrekt ist. 2. Diese Datei per FTP auf Deinen Arbeitsplatzrechner holen, Excel oeffnen und die Datei in Excel importieren. Sollte das funktionieren, kannst Du die Loesung Schritt fuer Schritt in die Richtung weiterentwickeln, in die Du moechtest. Viele Gruesse Lutz > Lutz Zetzsche schrieb: > > Hi Jens, > > > > ich habe das Problem jetzt eingegrenzt und vermutlich geloest, wenn ich > > nicht noch irgendetwas falsch verstanden habe. Und sollte ich die > > Loesung gefunden haben, dann war ich die letzten zwei Tage mit meinen > > Vermutungen schon verdammt nah an der Loesung. :-) > > > > > > Ich fasse noch einmal kurz zusammen: > > > > 1. Du hast Daten in einer Excel-Tabelle, die in einem kyrillischen > > Zeichensatz (z.B. koi8-r) formatiert sind. > > > > 2. Die Daten werden in der MySQL-Datenbank im UTF-8-Format abgelegt. > > > > 3. Wenn Du die Daten aus Excel kopierst, in ein phpMyAdmin-Formular > > einfuegst und durch das Abschicken dieses Formulars in die > > MySQL-Datenbank eintraegst, dann liegen die kyrillischen Zeichen als > > Entities, also nicht roh in der Datenbank vor, was nicht gewuenscht > > ist. > > > > 4. Wenn Du die Daten aus Excel ueber das CSV-Format in die > > MySQL-Datenbank exportierst und dabei ins UTF-8-Format konvertierst, > > dann liegen die kyrillischen Zeichen roh, also nicht als Entities in > > der Datenbank vor, was gewuenscht ist. > > > > 5. Wenn Du Dir die unter 4. erwaehnten Daten von phpMyAdmin anzeigen > > laesst, siehst Du zwar keine durch Entities dargestellten Zeichen, weil > > die Zeichen nicht als Entities in der Datenbank abgelegt sind, aber > > auch keine kyrillischen Zeichen, obwohl die Daten roh in der Datenbank > > abgelegt sind. > > > > > > Meine Ausgangsvermutungen von gestern und heute: > > > > 1. Es koennte ein Zeichensatz-Problem vorliegen, welches mit den > > Zeichensatz-Angaben im PHP- oder HTML-Header (<meta > > http-equiv="content-type" content="text/html; charset=...">) bzw. den > > diesbezueglichen Server- und Browser-Einstellungen zu tun haben und > > ueber die Korrektur dieser Angaben geloest werden koennte. > > > > 2. Die Konvertierung der kyrillischen Zeichen in UTF-8-formatierte > > Entities in dezimaler Schreibweise koennte durch den Browser beim > > Abschicken des Formulars erfolgen, mit dem die Daten in die > > MySQL-Datenbank eingetragen werden. > > > > 3. Wenn die Konvertierung der kyrillischen Zeichen in UTF-8-formatierte > > Entities erst beim Abschicken des Formulars durch den Browser erfolgen > > sollte, koennte dies daran liegen, dass der Zeichensatz des > > kyrillischen Textes nicht mit der Zeichensatz-Angabe in der HMTL-Seite, > > in der das Formular ist, und in der verarbeitenden und ausgebenden > > Seite uebereinstimmt, z.B. weil er iso-8859-1 ist. > > > > > > Ergebnis meiner Tests: > > > > Meine Ausgangsvermutungen haben sich bestaetigt. > > > > > > 1. Ich habe ein HTML-Formular mit einem Textfeld gebaut, in welches ich > > einen kyrillischen Text aus Deiner Excel-Datei eingefuegt habe. Dieses > > Formular habe ich an eine ausgebende PHP-Seite geschickt. > > > > a) Wenn ich in der Formular-Seite die Zeichensatzangabe <meta > > http-equiv="content-type" content="text/html; charset=iso-8859-1"> > > gemacht habe, haben der Internet Explorer und Mozilla die kyrillischen > > Zeichen beim Abschicken des Formulars in die entsprechenden > > UTF-8-formatierten Entities umgewandelt. Opera und Konqueror tun dies > > nicht, so dass auf der anderen Seite nur noch Fragezeichen ankommen. > > Die Zeicheninformationen sind also verloren gegangen. > > > > b) Wenn ich in der Formular-Seite die Zeichensatzangabe <meta > > http-equiv="content-type" content="text/html; charset=utf-8"> gemacht > > habe, hat KEINER der Browser die kyrillischen Zeichen beim Abschicken > > des Formulars in die entsprechenden UTF-8-formatierten Entities > > umgewandelt. Vielmehr sind die Zeichen auf der anderen Seite IMMER > > UFT-8-formatiert angekommen. Die Zeicheninformationen sind also nie > > verloren gegangen. > > > > c) Wenn ich in der Ausgabe-Seite die Zeichensatzangabe <meta > > http-equiv="content-type" content="text/html; charset=iso-8859-1"> > > gemacht habe, wurden die wie unter b) uebergebenen kyrillischen Zeichen > > in allen Browsern kryptisch und damit falsch dargestellt. > > > > d) Wenn ich in der Ausgabe-Seite die Zeichensatzangabe <meta > > http-equiv="content-type" content="text/html; charset=utf-8"> gemacht > > habe, wurden die wie unter b) beschrieben uebergebenen kyrillischen > > Zeichen in allen Browsern auch als solche und damit richtig > > dargestellt. > > > > > > 2. Die Angabe <meta http-equiv="content-type" content="text/html; > > charset=..."> soll dem Server und dem Browser helfen, die jeweilige > > HTMl-Ausgabe richtig zu interpretieren. Man kann jedoch in den > > Browsereinstellungen den Zeichensatz der Seite fest vorgeben und damit > > die Meta-Tag-Angabe "ueberschreiben". Dies hat bei mir auch > > funktioniert. > > > > Wenn ich in der Formular-Seite die Zeichensatzangabe <meta > > http-equiv="content-type" content="text/html; charset=iso-8859-1"> > > gemacht und im Browser fix UTF-8 als Zeichensatz vorgegeben habe, hat > > KEINER der Browser die kyrillischen Zeichen beim Abschicken des > > Formulars in die entsprechenden UTF-8-formatierten Entities > > umgewandelt. Vielmehr sind die Zeichen auf der anderen Seite immer roh > > UFT-8-formatiert angekommen. > > > > > > 3. Ich habe nach diesen nicht ganz unerwarteten Ergebnisse dann > > abschliessend phpMyAdmin heruntergeladen, installiert und geprueft. > > > > a) Auf der Startseite von phpMyAdmin kann man einen passenden > > Zeichensatz auswaehlen, den phpMyAdmin dann auch auf den Seiten > > verwendet. > > > > b) UTF-8 befindet sich NICHT unter den auswaehlbaren Zeichensaetzen. > > > > > > Loesung: > > > > 1. Die Seiten, in denen sich die Formulare befinden, in welche Du die > > kyrillischen Daten aus Excel einfuegst, muessen entweder die Angabe > > <meta http-equiv="content-type" content="text/html; charset=utf-8"> im > > Header besitzen oder mit der fixen Zeichensatz-Einstellung "UTF-8" im > > Browser angezeigt werden, damit die Daten beim Abschicken der Formulare > > nicht von einigen Browsern in Entities umgewandelt und von anderen > > Browsern ins Nirvana befoerdert werden. > > > > 2. Die Seiten, mit denen Du die Daten wieder aus der MySQL-Datenbank > > anzeigst, muessen ebenfalls entweder die Angabe <meta > > http-equiv="content-type" content="text/html; charset=utf-8"> im Header > > besitzen oder mit der fixen Zeichensatz-Einstellung "UTF-8" im Browser > > angezeigt werden, damit die Daten in kyrillischen Zeichen und nicht als > > kryptische Zeichen angezeigt werden. > > > > 3. Da phpMyAdmin UTF-8 als Zeichensatz nicht zur Auswahl anbietet, > > kannst Du hier phpMyAdmin nur verwenden, wenn Du UTF-8 im Browser fix > > als Zeichensatz einstellst. Du musst allerdings pruefen, ob phpMyAdmin > > sich dann noch korrekt verhaelt, weil es diesen Zeichensatz selbst > > nicht vorgesehen hat und phpMyAdmin auf einer differenzierten, internen > > Zeichensatzverwaltung aufbaut. > > > > 4. Sollte 3. nicht funktionieren, weil phpMyAdmin sich nicht mehr > > korrekt verhaelt, wenn man mit dem Browser den Zeichensatz UTF-8 hart > > vorgibt, dann bleibt nur noch das Programmieren einer eigenen > > Pflegeoberflaeche fuer Deine Daten, wobei die Beachtung der > > Loesungspunkte 1. und 2. ausreichen sollte. Oder Du suchst einen > > phpMyAdmin-Ersatz, der bereits UTF-8 unterstuetzt. ;-) > > > > > > So. Das war es dann eigentlich schon. So sieht das doch eigentlich > > wieder recht uebersichtlich und einsichtig aus. ;-) > > > > Ich hoffe, meine Nachforschungen und die daraus resultierende Loesung > > beheben auch tatsaechlich Dein Problem. Leider konnte ich es nicht bis > > ins Ende nachstellen und nachvollziehen, weil dies dann doch zu > > aufwendig geworden waere. :-) > > > > > > Viele Gruesse > > > > Lutz > > > > > > > > Am Mittwoch, 21. Januar 2004 10:40 schrieb Lutz Zetzsche: > > > >>Hi Jens, > >> > >>ich habe gerade einmal einen Test gemacht und kyrillische Zeichen aus > >>der Excel-Tabelle, die Du mir und Norbert freundlicherweise per PM > >>zugaenglich gemacht hast, in ein textarea-Feld eines eMail-Formulars > >>kopiert und dann das Formular abgeschickt. > >> > >>Dabei hat sich mein Verdacht von heute Morgen erhaertet: Der Internet > >>Explorer und Mozilla, also die Browser, haben die kyrillischen > >>Zeichen in UTF-8-Entities umgewandelt. Beim Opera kamen hingegen auf > >>der Sendebestaetigungsseite keine Entities, sondern nur Fragezeichen > >>an. > >> > >>D.h. damit waere aus meiner Sicht schon einmal eingegrenzt, wo die > >>Entities her kommen. Es scheint also nicht an phpMyAdmin zu liegen > >>und eigene Formulare zu bauen, wuerde das Problem wohl ebenfalls > >>nicht loesen. > >> > >>Die Frage ist nun, WANN die beiden genannten Browser die kyrillischen > >>Zeichen in UTF-8-Entities umwandeln. Tun sie das bereits beim > >>Einfuegen der Zeichen in das Formularfeld, oder tun sie das erst beim > >>Abschicken? Das koennte ich allerdings erst heute Abend feststellen. > >>Bei ersterem haetten wir u.U. leider schlechte Karten, das Problem zu > >>loesen. > >> > >>Meine Vermutung ist, dass sie es erst beim Abschicken tun. > >>Hintergrund meiner Ueberlegung: Wenn Du einen Text aus Excel kopierst > >>und in der Zwischenablage hast, muss der Zeichensatz nicht unbedingt > >>UTF-8 sein. Zum Text koennte in der Zwischenablage aber noch der > >>urspruengliche Zeichensatz, z.B. iso-8859-5, abgelegt sein. Diese > >>Information koennte auch noch beim Einfuegen ins Textfeld vorhanden > >>sein. Wenn also die Umwandlung erst beim Abschicken erfolgt, koennte > >>dies daran liegen, dass der Zeichensatz des Textes mit dem > >>Zeichensatz der Seite, in der das Formular ist und mit dem > >>Zeichensatz in der verarbeitenden und ausgebenden Seite nicht > >>uebereinstimmt, z.B. weil er iso-8859-1 ist. > >> > >>Damit komme ich dann doch noch einmal auf meine Mail von gestern > >>zurueck, die sich auf falsche Zeichensatz-Angaben bezog, obwohl ich > >>spaeter dachte, die waere aufgrund eines Missverstaendnisses voellig > >>am Thema vorbei. Ansatzpunkte sind hier wie gesagt: Meta-Tag, > >>PHP-Header, Server- und Browser-Einstellungen. > >> > >>Allerdings koennte man auch genau anders herum vermuten: Wenn der > >>Text in ein Formularfeld einer Seite eingefuegt wird, deren > >>kyrillischer Zeichensatz nicht mit dem des einzufuegenden Textes > >>uebereinstimmt, wandelt der Browser die Zeichen bereits beim > >>Einfuegen ins Formularfeld um. > >> > >>Welche Vermutung zutrifft, ist u.U. sogar browserabhaengig! Opera > >>handhabt das Ganze ja auch anders, als die anderen beiden... > >> > >>Ein weiterer interessanter Ansatzpunkt: Du erwaehntest ja, dass Du > >>korrekt UTF-8-Zeichen siehst (und zurueckschreibst?), wenn Du Dir die > >>Daten mit phpMyAdmin direkt aus der Datenbank holst, die Daten also > >>nicht ueber Kopieren und Einfuegen in das Formularfeld gelangen. > >> > >>D.h. aus den obigen Vermutungen und Beobachtungen laesst sich eine > >>Versuchsreihe bauen, mit der Du eingrenzen kannst, wo das Problem > >>tatsaechlich liegt. Hier kann auch Javascript helfen, um z.B. den > >>Inhalt des Formularfelds nach dem Einfuegen auszulesen (ohne zu > >>versenden). Vielleicht kann man das Problem dann sogar am Ende nicht > >>nur lokalisieren, sondern auch loesen. Da mache ich mit heute Abend > >>einmal dran, wenn mir keiner zuvor kommt. :-) > >> > >>So, das war jetzt eine Menge Information, aber ich hoffe, sie ist > >>erstens verstaendlich, ist zweitens nicht an Deiner Intention vorbei > >>und hilft drittens weiter. ;-) > >> > >> > >>Viele Gruesse > >> > >>Lutz > > > > > > > > -- > ** Allgemeine deutschsprachige PHP-Liste: php at phpbar.de ** > Informationen: http://www.phpbar.de > http://lists.phpbar.de/mailman/listinfo/php >
php::bar PHP Wiki - Listenarchive