Offen BUG: Exportfunktion bricht fälschlicherweise Zeilen um

[saschadd]

Hallo,

ich bin mir ziemlich sicher, einen Fehler in der Exportfunktion gefunden zu haben.
Und zwar werden beim Export die Spalteninhalte teilweise in der CSV-Datei umgebrochen, wodurch die Konsistenz des Datensatzes in einer Zeile nicht mehr gegeben ist und die CSV auch nicht korrekt in Excel, OpenOffice, CSVEd etc. geöffnet werden kann.
Ein wirkliches System habe ich noch nicht erkennen können, es wird meist an Leerzeichen umgebrochen und es sieht so aus, als ob eine maximale Spaltenbreite angenommen wird.
Aufgefallen ist mir das ganze bei den Beschreibungen der Artikel, die meist länger sind als alle anderen Spalten.

Ich vermute, dass der gleiche Fehler in der Importfunktion existiert, siehe https://forum.jtl-software.de/jtl-w...66324-html-wird-nicht-richtig-improtiert.html

Für Rückfragen oder eine Beispieldatei bitte PM.

Wäre schön, wenn das schnell gefixt werden könnte, da ich die Export- Importfunktionen zeitnah benötige.

Gruß Sascha

 

[MichaelH]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Vermutlich ist das Leerzeichen kein Leerzeichen sondern ein nicht sichtbares "Steuerzeichen" (das als Leerzeichen dargestellt wird) und das verursacht den Umbruch, das kann die Ameise nicht "korrigieren".
Mit Notepad++ kannst du die CSV-Datei dahingehend genau ansehen an den Stellen die du kennst bzw. schon gefunden hast und deine Texte entsprechend korrigieren.

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Hallo Michael,
danke für deinen Tip.
Ich hab jetzt die CSV in Notepad++ geöffnet und sehe aber kein Steuerzeichen.
Muss ich die CSV in einem bestimmten Modus öffnen?

Gruß Sascha

 

[MichaelH]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Je nach Codierung - umschalten auf "Hex-Editor", Leerzeichen/Blank/Space = Code "40" alles > 40 sind Zeichen, alles < 40 sind Steuerzeichen.

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Okay, ich hab zwar die Umschaltung auf den Hexeditor nicht hinbekommen (eventuell kannst du mir sagen wo ich das machen muss)
aber ich hab mal "Alle Zeichen anzeigen" ausgewählt und da zeigt es mir immer am Ende der Zeile an CR LF

 

[MichaelH]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Ja, dann inspizier mal die Datenzeile(n) genau ... CR LF ist korrekt aber im Text sollte das nicht vorkommen.

Weiters kannst du eine Datenzeile mal kopieren und in Excel pasten und schauen was Excel selber damit macht.

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Kann ich dieses CR LF irgendwie per Suchen und ersetzen erwischen?
Dann könnte ich die Exportdatei bereinigen und importieren um diesen Fehler zu beseitigen.

Besser wäre natürlich noch ein "Lösche alle CR LF, die sich zwischen zwei Feldtrennern befinden".

Allerdings ist mir nicht klar, woher diese Zeichen in den Beschreibungstexten kommen.
Selbst wenn wir Beschreibungen von den Herstellern übernehmen, schicken wir die nochmal "durch" Notepad (Copy+Paste aus der Quelle in Notepad und danach Copy+Paste aus Notepad in die Wawi) um irgendwelche Formatfragmente zu entfernen.
Das scheint aber nicht zu reichen?!

 

[MichaelH]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Tja, sauber arbeiten ... die betroffenen Spalten mit Copy/Paste rausholen, dort mit STRG+H korrigieren und dann ggf. "zusammensetzen" mit einer Formel in eine neue Zelle und dann diese Zelle/Spalte als Text in die Originaldatei zurückholen ... kann so klappen, auch massenhaft.

Vermutlich hat der Ersteller der Texte unsauber gearbeitet.

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Okay, letzte Frage bevor ich mich mal daran versuche:

Wie kann ich dieses CR LF sichtbar machen bzw. nach was muss ich suchen?

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Ich hab mir jetzt ne SQL Query gebaut, die die Texte direkt in der Datenbank korrigiert.
Nur funktioniert die entweder nicht richtig oder die Ameise zieht aus einer ganz anderen Tabelle die Daten.
Die Spalten cKurzBeschreibung und cBeschreibung gibts ja auch zig mal. Weiß jemand welche man alle ändern muss oder wie ich alle ändern kann?

SELECT REPLACE(cKurzBeschreibung, CHAR(13) + CHAR(10), '')
FROM dbo.tartikel

SELECT REPLACE(cast(cBeschreibung as varchar(max)), CHAR(13) + CHAR(10) ,' ')
FROM dbo.tartikel

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Okay, meine Query scheint irgendwie die Zeichen nicht zu erwischen.
Ich müsste aber möglichst direkt in der Datenbank das ganze ändern, da die CSV übel lang ist und das ganze ewig dauern würde.

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

&nbsp; scheint in CRLF beim Export gewandelt zu werden.

 

[reneromann]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Zeilenumbrüche innerhalb eines Textfeldes werden sauber von Excel verarbeitet, wenn das Textfeld sauber markiert wird, z.B. mittels " ". Dann weiß Excel auch, dass alles zwischen eben jenen Anführungszeichen -egal was kommt- zur "Zelle" gehört. Andernfalls geht Excel nämlich davon aus, dass bei einem Zeilenumbruch [CR + LF] eine neue Datenzeile beginnt.

Und nur nebenbei:
Steuerzeichen haben die Werte von 0 (hex. 0x00) bis 31 (0x1F) in der ASCII-Tabelle. Ab dem Wert 32 (0x20) kommt dann der "normale" Teil, wobei das Zeichen mit dem Wert 32 gleich das Leerzeichen ist. Ab 48 (0x30) kommen die Ziffern, ab 65 (0x41) die Großbuchstaben und ab 97 (0x61) die Kleinbuchstaben.

 

[MichaelH]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Und nur nebenbei:
Steuerzeichen haben die Werte von 0 (hex. 0x00) bis 31 (0x1F) in der ASCII-Tabelle. Ab dem Wert 32 (0x20) kommt dann der "normale" Teil, wobei das Zeichen mit dem Wert 32 gleich das Leerzeichen ist. Ab 48 (0x30) kommen die Ziffern, ab 65 (0x41) die Großbuchstaben und ab 97 (0x61) die Kleinbuchstaben.

Ja korrekt, als ich mich damit noch beschäftigte waren die 80er Jahre und es war EBCDIC Codepage 500 ... und nicht ASCII ...
Wenn "saschadd" eine TXT/CSV gespendet hätte, wäre es einfacher gewesen ...

 

[saschadd]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

So nachdem es ein bißchen wild hier geworden ist, während ich ausprobiert habe das Problem in den Griff zu bekommen, will ich mal zusammenfassen.

Also erstmal danke für den Tip mit Notepad++, das hatte ich bisher noch nicht so umfangreich genutzt und hab jetzt ein gutes Tool hinzugewonnen.

Ich konnte mit Notepad++ das Problem soweit erstmal beheben, allerdings konnte ich nicht über die Ameise-Exportfunktion gehen, da ich da alles voller CRLF hatte.
Per Direktverbindung mit OpenOffice Base mit der Datenbank und Drag and Drop der Tabelle tartikel in OpenOffice Calc konnte ich die Daten so extrahieren, dass ich zwar überall LF in den Texten hatte, aber ich konnte dann erstmal alle LF entfernen und dann aus CR wieder CRLF erstellen.

Soweit so gut.
Jetzt hab ich das ganze über den AmeiseImport eingespielt und mir mal einen Artikel angeschaut.
Wenn ich auf die Beschreibungsseite gehe, sehe ich in den Beschreibungsfeldern die Texte korrekt ohne irgendwelche Zeilenumbrüche etc..
Wenn ich jetzt den HTML-Editor in JTL-Wawi öffne sehe ich die Texte korrekt formatiert.
Schließe ich den HTML-Editor sehe ich in den Textfeldern die Texte mit Zeilenumbrüchen etc.
Wenn ich diesen Text dann in Notepad++ kopiere hab ich schon wieder alles voller CRLF.
Dementsprechend bleibe ich bei der Vermutung, dass ein Fehler bzw. Bug vorliegt, aber wohl im integrierten HTML-Editor.

Zeilenumbrüche innerhalb eines Textfeldes werden sauber von Excel verarbeitet, wenn das Textfeld sauber markiert wird, z.B. mittels " ". Dann weiß Excel auch, dass alles zwischen eben jenen Anführungszeichen -egal was kommt- zur "Zelle" gehört. Andernfalls geht Excel nämlich davon aus, dass bei einem Zeilenumbruch [CR + LF] eine neue Datenzeile beginnt.

Trifft für mich so nicht zu, da ich kein Excel habe. Hätte ich vielleicht anmerken sollen.

Und nur nebenbei:
Steuerzeichen haben die Werte von 0 (hex. 0x00) bis 31 (0x1F) in der ASCII-Tabelle. Ab dem Wert 32 (0x20) kommt dann der "normale" Teil, wobei das Zeichen mit dem Wert 32 gleich das Leerzeichen ist. Ab 48 (0x30) kommen die Ziffern, ab 65 (0x41) die Großbuchstaben und ab 97 (0x61) die Kleinbuchstaben.

Was genau du mir damit sagen möchtest, habe ich nicht verstanden, sorry.

Ja korrekt, als ich mich damit noch beschäftigte waren die 80er Jahre und es war EBCDIC Codepage 500 ... und nicht ASCII ...
Wenn "saschadd" eine TXT/CSV gespendet hätte, wäre es einfacher gewesen ...

Hier weiß ich auch nichts mit der Information anzufangen, sorry.

 

[reneromann]

AW: BUG: Exportfunktion bricht fälschlicherweise Zeilen um

Zeilenumbrüche innerhalb eines Textfeldes werden sauber von Excel verarbeitet, wenn das Textfeld sauber markiert wird, z.B. mittels " ". Dann weiß Excel auch, dass alles zwischen eben jenen Anführungszeichen -egal was kommt- zur "Zelle" gehört. Andernfalls geht Excel nämlich davon aus, dass bei einem Zeilenumbruch [CR + LF] eine neue Datenzeile beginnt.

Trifft für mich so nicht zu, da ich kein Excel habe. Hätte ich vielleicht anmerken sollen.[...]

Das gilt für OpenOffice genau wie für Excel...
Sollte innerhalb eines Zellenwertes die Zeile umgebrochen werden, gehen ALLE Tabellenkalkulationsprogramme [und auch die Ameise] davon aus, dass eine neue Datenzeile anfängt. Erst durch "Maskierung" dieser Zeilenumbrüche durch die Anführungszeichen [verstehen Excel, OpenOffice und auch die Ameise] werden die Zeilenumbrüche innerhalb des Wertes "ignoriert" und die Zeile geht "normal" weiter.

Zum internen HTML-Editor:
Das der interne HTML-Editor nicht gerade das Gelbe vom Ei ist, hat selbst JTL schon bestätigt. Jedoch ist -gerade für Laien ohne HTML-Kenntnis- dieses Tool besser als gar keinen Editor zu haben. Für "vernünftige" Beschreibungen sollte man jedoch auf externe Editoren/selbstgeschriebenen HTML-Code zurückgreifen und diesen über die Quellcodeansicht einbinden.