In Bearbeitung [WAWI-13941] Export Artikelbeschreibung geht nicht / Umlaute werden als HTML-Code gespeichert

[HelmaSpona]

Ich versuche bei einem Kunden aus der Wawi die Artikeldaten zu exportieren. Ich hab es jetzt schon mit allen möglichen Trennzeichen probiert. Es geht nicht. Sobald eine Beschreibung mit HTML-code drin ist, macht er nach der HTML-Zeile einen Zeilenumbruch und der führt in der CSV-Datei dazu, dass die Zeile zuende ist. Das sehe ich, wenn ich die Datei in Word öffne. Da ist dann eine Absatzmarke an der Stelle. Das komische ist, ich kann bei mir aus der WAwi auch die Beschreibung exportieren.
Der Kunde hat die Beschreibung mit dem HTML-Editor bearbeitet. Ich gebe den Code immer direkt von Hand ein. Macht das den Unterschied?

In dem Zusammenhang das zweite Problem. Beim Bearbeiten mit dem HTML-Editor werden Umlaute mit den entpsrechenden HTML-Codes eingefügt. Das führt dazu, dass bei Amazon die Artikel nicht online gehen, weil sie ungültige Zeichen enthalten. Gibt es dafür eine Lösung? Ich hätte jetzt einfach Suchen-Ersetzen in Excel genommen, aber das scheitert daran, dass ich das nicht vernünftig exportieren kann

 

[Rico Giesler]

Wir haben zum Thema Umlaute ein Ticket: https://issues.jtl-software.de/issues?query=WAWI-13941

 

[Xantiva]

@HelmaSpona Was ist daran jetzt nicht in Ordnung? Wenn in der Artikelbeschreibung ein Zeilenumbruch drin ist (was normal ist), muss er den doch auch ausgeben, oder? Dafür gibt es die Textbegrenzungszeichen. Wenn ein Zeilenumbruch innerhalb von diesen Textbegrenzungszeichen ist, wird er beim Import entsprechend zum Feldinhalt gezählt und nicht als neue CSV Zeile. In Word oder echten Texteditoren siehst Du nur den Text, die machen da keine Unterscheidung.

@Rico Giesler Das Ticket ist aber jetzt nicht erst gemeint, oder? Der Editor "zerstört" die Umlaute nicht, sondern er macht halt HTML-Entities daraus. Was durchaus zu seiner Aufgabe gezählt werden kann

 

[Rico Giesler]

Guten Morgen @Xantiva
Ich hab das Ticket nicht geschrieben sondern nur hier verlinkt.
Die Wortwahl klingt ein wenig dramatisch, geb ich zu.

 

[Xantiva]

Aber warum ist das überhaupt ein offenes Ticket mi der Priorität "Hoch"? Ich würde erwarten, dass es zurückgewiesen wird, weil dort die Funktionsweise des HTML-Editors als Fehler beschrieben wird.

 

[Enrico W.]

Erst einmal wird ein Ticket aufgenommen. Dann kann noch immer diskutiert/entschieden werden, ob es sich um einen Fehler handelt oder ob das tatsächlich so sein muss oder ob es im Sinne der Kunden einen anderen Weg gibt. Danach kann ein solches Ticket noch immer abgelehnt werden. Es gibt nur wenige Fälle, die wir nicht erst einmal intern besprechen. Diese wenigen Fälle sind dann aber auch sehr offensichtlich.

 

[HelmaSpona]

@HelmaSpona Was ist daran jetzt nicht in Ordnung? Wenn in der Artikelbeschreibung ein Zeilenumbruch drin ist (was normal ist), muss er den doch auch ausgeben, oder? Dafür gibt es die Textbegrenzungszeichen. Wenn ein Zeilenumbruch innerhalb von diesen Textbegrenzungszeichen ist, wird er beim Import entsprechend zum Feldinhalt gezählt und nicht als neue CSV Zeile. In Word oder echten Texteditoren siehst Du nur den Text, die machen da keine Unterscheidung.

Nicht in Ordnung ist, dass sich die so exportierten Daten nicht importieren lassen, weil weder Excel noch Access noch OpenOffice den Zeilenumbruch innerhalt des Textes trotz Texbegrenzungszeichen richtig einlesen. Sie machen daraus eine neue Zeile in der CSV-Datei.

 

[HelmaSpona]

Was die Umlaute angeht, ich würde das schon als "Bug" ansehen, denn es führt dazu, dass die Artikel nicht bei Amazon hochgeladen werden, weil die HTML-Enitities keine HTML-Tags sind, nicht ausgefiltert werden können und Amazon dann über ungültige Zeichen in der Beschreibung meckert.

 

[Xantiva]

Wieso werden die nicht richtig eingelesen?

Wenn ich das als .csv abspeichere ...

A;B;C
12;"Die ist ein Test";123
13;"Die ist ein 2.
Test";122

... dann sieht das so aus, wenn ich das mit Excel öffne (per Doppelklick):



Der Zeilenumbruch wird sauber eingelesen.

Und zu Amazon - wie lädst Du die Artikel nach Amazon hoch? Werden die nicht über eazyAuction übermittelt?

Aus meiner Sicht liegt hier auch Mißverständnis vor. Der HTML Editor (egal wie gut der jetzt gerade ist) soll sicher dafür Sorge tragen, dass die Beschreibungen mit allen möglichen Sonderzeichen fehlerfrei in der Datenbank gespeichert werden und je nach Ausgabemedium (z. B. Webshop) und benötigter Zeichenkodierung (UTF-8, Windows-1252, ...) von der Wawi richtig ausgegeben werden können. Dafür werden alle "Nicht-Standard-Zeichen" in sogenannte HTML-Entities umgewandelt. Die Ameise gibt die Daten dann 1:1 aus. Wenn Du die Beschreibung ohne HTML-Entities benötigst, dann mussen die dekodiert werden. Für den Texteditor Notepad++ gibt es ein Plugin, was das angeblich kann: https://kollegaru.wordpress.com/tag/notepad/

 

[HelmaSpona]

Wenn meine CSV-Datei so aussieht, stellt Excel sie auch korrekt dar. Wenn aber Artikelbeschreibungen enthalten sind, die im HTML-Code Absatzmarken enthalten, bricht der die da in der Textdatei um. und dann geht die Beschreibung die eigentlich in Spalte C stehen sollte, in der nächsten Zeile in Spalte A weiter.

Zu Amazon: Ja klar werden die mit eazyAuction hochgeladen. Aber das funktioniert eben nicht. Es kommt von Amazon die Fehlermeldung, die Beschreibung enthält ungültige Zeichen. Natürlich ist das Kontrollkästchen "HTML-Tags entfernen" aktiviert. Die einzigen aus meiner Sicht problematischen Zeichen können die HTML-Enitities sein. Ich habe die jetzt mal mit Dreamviewer entfernt und den Code so wieder eingefügt. Mal sehen, ob die jetzt hochgeladen werden. Nur hat mein Kunde leider kein Dreamwiewer. Es sollte doch auch so gehen, eigentlich .. . denke ich ....

 

[Xantiva]

Sonst poste doch mal bitte ein Beispiel, denn das hier funktioniert auch ...

A;B;C
12;"Die ist ein Test";123
13;"<p>Die ist ein 2.</p>
<p>Test</p>";122

Und wenn eazyAuction das HTML-Tags entfernen nicht funktioniert, dann mach ein Support Ticket auf, dass die Daten dort nicht richtig ankommen. Der HTML-Editor macht nur seine Arbeit, dann wäre das ein Bug im Export nach Amazon.

 

[HelmaSpona]

So sieht die exportierte Datei bei mir aus. nach dem </h2> bricht er die Zeile um. Was dazu führt, dass in Excel dann das <ul> in einer neuen Zeile in Spalte 1 beginnt.
http://www.helma-spona.de/temp/CSV-Datei.jpg

 

[HelmaSpona]

Und das macht dann Excel daraus:
http://www.helma-spona.de/temp/CSV-Excel.jpg

 

[Xantiva]

• Wie hast Du die Datei geöffnet? Per Doppelklick auf die Datei (müsste funktionieren) oder per Datei Öffnen in Excel (da macht Excel dann Unsinn)?
• Hast Du mal sucht die in .csv umzubenennen?

 

[HelmaSpona]

Ich hab die original CSV ja in txt umbenannt, denn beim Öffnen einer csv vermurkst mir Excel immer die EANS. Die Textdatei öffne ich dann mit "Datei öffnen" und kann im Import-Assistenten Trennzeichen alles einstellen. Mache ich immer so und hat bisher bei mir auch funktioniert. Nur bei den CSV-Dateien des Kunden nicht, der eben den HTML-Editor nutzt. Wenn ich die Original CSV-Datei per Doppelklick öffne, ist das Ergebnis das gleiche.
Nachtrag: Nicht ganz das gleiche, Manche Artikel zeigt er dann korrekt an, dann kommen die Fehler an anderer Stelle im HTML-Code in Artikeln, die beim öffnen der TXT-Datei korrekt angezeigt werden.

 

[Xantiva]

Sind bei den fehlerhaften Artikeln evtl. Anführungszeichen in der Beschreibung, die nicht als HTML-Entities codiert sind ( &quot; )?
Das wäre dann ein Ticket für die JTL Ameise, denn wenn Textbegrenzungszeichen im Feld selber vorkommen, sind diese gesondert zu behandeln (zu verdoppeln).
Das ist fehlerhaft:

123;"Die ist ein "Test".";"abc"

Richtig wäre:

123;"Die ist ein ""Test"".";"abc"

 

[HelmaSpona]

Nein, so wie ich gesehen habe, sind die nicht das Problem. Ich hab es auch schon mit dem | als Trennzeichen probiert, weil da im HTML ja regulär nicht vorkommt. Auch damit erhalte ich das gleiche Ergebnis. Und er bricht immer da um, wo man m HTML-Editor ein ENTER eingefügt hat.