Nachdem ich nun alle Unklarheiten beim Import der Artikel gelöst habe, taucht ein anderes auf. Mein Kunde hat die CSV Datei aus Yatego exportiert. Und im Artikeltext tauchen nun überall diese “
” auf. Hat wohl was mit Zeilenumbruch (<br />) zu tun. Er hat nun natürlich keine Lust, bei ca. 200 Artikeln diese “Teile” manuell zu entfernen bzw. in <br /> umzuwandeln. Gibt es eine Möglichkeit, das automatisch machen zu lassen. Ich hab was über nl2br gelesen. Aber ich mit meinen bescheidenen PHP Kenntnissen komm da irgendwie nicht weiter. Hat jemand eine Idee für mich?
Für nl2br musst Du überall im Template, wo diese Texte ausgeben werden
anstatt (ungetestet)
[{$sVariable}]
so etwas
[{$sVariable|@nl2br}]
machen.
IMHO zu viel Aufwand, das ganze Template anzupassen. Ich würde das direkt in der DB lösen… zumal diese Zeichen wenn sie in HTML sichtbar sind bereits escaped wurden und nl2br so nicht geht.
Oder noch besser, die CSV-Datei bzw. den Oxid-Importer anpassen und den kompletten Import nochmals machen.
Das wollte ich ja. Ich hab hier die geöffnete CSV Datei und wollte die “long_desc” jeweils rauskopieren, “irgendwo” durchlaufen lassen und dann sauber wieder einfügen. Danach wollte ich dann die saubere CSV in OXID importieren. Geht so etwas irgendwie (also das “filtern”)?
Eine Zeile der CSV-Datei, die diesen Fehler hat würde weiterhelfen… auch das was später in HTML ausgegeben wird.
Mir ist nich klar, ob die Zeichen escaped werden oder nicht und wo dies geschah.
Falls in der CSV-Datei schon
als Text steht, dann einfach diese mit einen Texteditor (kein Excel, Notepad++ ist zu gebrauchen) öffnen und mit diesen ‘suchen und ersetzen’.
Danke! Das hat auch geklappt. War eben Fleißarbeit. Nur wenn ich mir das Umlautproblem jetzt anschaue, hätte ich mir das fast sparen können. Wenn man sowieso in jeden Artikel reingehen muss um die Umlaute zu ändern, hätte man bei der Gelegenheit auch die überflüssigen Zeichen löschen können …
[QUOTE=atomicbunny;20738]Danke! Das hat auch geklappt. War eben Fleißarbeit. Nur wenn ich mir das Umlautproblem jetzt anschaue, hätte ich mir das fast sparen können. Wenn man sowieso in jeden Artikel reingehen muss um die Umlaute zu ändern, hätte man bei der Gelegenheit auch die überflüssigen Zeichen löschen können …[/QUOTE]
Das liegt daran, dass der Zeichensatz der Quelldatenbank ein anderer ist als der der Zieldatenbank…
Die müssen natürlich kompatibel sein, sonst gibt es evtl. Umlautprobleme
Wenn es daran liegt, könnte ich da nicht einfach den Shop auf latin1 laufen lassen? Jetzt (Testinstallation) läuft er auf utf-8. Kann das wirklich nur die falsche Kodierung sein oder gibts da noch andere Möglichkeiten?
Ja, das ist klar. Ich bin mir nur nicht sicher, ob die Zeichenkodierung vom alten Shop (bzw. das was von dort als CSV Datei ausgegeben wurde) latin1 ist. Der Testshop (in dem ich im Moment mit dem Import experimentiere) läuft auf utf-8.
Sollte ich einfach mal alles löschen, DB und Shop neu installieren (latin1) und einen neuen Import der CSV Datei wagen? Oder kann ich mir das sparen, weil vielleicht unabhängig von allen Kodierungen in der CSV Datei schon Schrott drinsteht ( so wie
)?
Anstatt den Shop neu zu installieren würde ich lieber gucken dass die CSV-Datei den richtigen Zeichensatz hat. Im Editor sollten die Umlaute in der CSV-Datei richtig dargestellt werden. Falls nein, anderen Editor verwenden, wenn das auch nicht bringt ist evtl. die CSV-Datei schon kaputt.
Wenn die Umlaute im Editor OK sind, kannst du bei “Speichern unter…” den Zeichensatz festlegen.
Ich dreh ab. Sowohl Numbers,TextMate wie auch Excel auf dem Mac haben die CSV Datei ohne korrekte Umlaute dargestellt. Nur mein Liebling Coda hat sie korrekt angezeigt. Nicht sehr übersichtlich, so ohne Spalten. Aber ich musste ja nur die “
” rausfiltern lassen.
Der Import in OXID hat auch funktioniert. Noch einmal Danke an Alle für die Hilfe!
