aVogt
Returning Creator

FS5: Medium als FILE mit Inhalt erzeugen - einige letzte Zeichen fehlen

Hallo,

(wahrscheinlich) seit der Umstellung auf FS5 habe ich ein Problem mit dem Erzeugen von Medien. Das Medium soll eine HTML-Datei werden.

Bisher hat das mit folgenden Zeilen ohne Probleme geklappt:

...

ByteArrayInputStream bais = new ByteArrayInputStream(fileContent.getBytes());

Integer siInteger = new Integer(fileContent.length());

long length = siInteger.longValue();

Media newMedia = myMediaFolder.createMedia(mediumRef, fileName, Media.FILE, false, true);

File newFile = newMedia.getFile(language);

newFile.setFile(length, bais, fileExtension);

newFile.setEncoding(encoding);

newMedia.save();

...

Nun habe ich durch Zufall gemerkt, dass ein paar letzte Zeichen fehlen. Je größer der Content für das Medium ist, umso mehr Zeichen fehlen.

Ich habe nun noch den "fileContent" in das encoding umgewandelt, von dem das Medium sein soll. Ohne Erfolg.

Kurzzeitig habe ich mir so geholfen, dass ich auf "length" etwas draufgeschlagen habe. Zumindest hilft dass, aber ist nicht schön.

Hat jemand eine Idee, an was das liegen könnte?

Grüße

Andreas

0 Kudos
6 Replies
aVogt
Returning Creator

noch zur Info: der fileContent wird während eines Auftrages in einer Aktion erstellt.

0 Kudos
Peter_Jodeleit
Crownpeak employee

Was ist denn "fileContent"?

Peter
0 Kudos

fileContent ist ein String (in meinem Fall der SourceCode einer zusammengebauten HTML-Datei).

0 Kudos
mbergmann
Crownpeak employee

Kann es sein, dass hier durch das Encoding fileContent.length() (Anzahl der Zeichen im String) und fileContent.getBytes().length (Anzahl der Bytes) nicht übereinstimmt?

0 Kudos

Die stimmen nicht überein.

Das Speichern des Mediums mit einem "Textinhalt" habe ich in ein Modul ausgelagert. Also übergebe ich der Methode u.a. den zu speichernden Text (fileContent) und das Ecoding.

Wenn ich mir von dem übergebenem String fileContent.length() und  fileContent.getBytes().length ausgebe erhalte ich 2435/2445.

Folgende beiden Tests:

Bei:

String convString = new String(fileContent.getBytes(), "UTF-8");

context.logInfo("encoding UTF-8: " + convString.length() + "/" + convString.getBytes().length);

erhalte ich auch 2435/2445.

Somit würde ich davon ausgehe, dass der String als UTF-8 angelegt und somit auch übergeben wurde (beim Anlegen wird nichts angegeben).

Bei:

convString = new String(fileContent.getBytes(), "ISO-8859-1");

context.logInfo("encoding ISO-8859-1: " + convString.length() + "/" + convString.getBytes().length);

erhalte ich 2445/2465

Durch die obenen Versuche, wird das Medium richtig gespeichert, wenn

fileContent.length() vorher nach ISO-8859-1 umgewandelt wurde und

fileContent.getBytes() nicht (sondern so wie es übergeben wurde).

Irgendwie kommt mir das eigenartig vor. Wahrscheinlich hab ich einen Denkfehler?

0 Kudos
mbergmann
Crownpeak employee

Zur Klarstellung: s.getBytes() liefert nicht die "puren Daten" eines Strings (der streng genommen kein Encoding hat) sondern wandelt die enthaltenen Zeichen  in ein Bytearray um, wie es laut aktuellem Default-Charset des jeweiligen Systems aussehen müsste (soweit ich weiß Charset.defaultCharset()).

String s2=new String(s1.getBytes(),"UTF-8");

würde zu einem "kaputten" String führen, wenn das Default-Charset eben nicht UTF-8 ist: Java erhält hier ein Byte-Array und parst gemäß dem übergebenen Encoding daraus einen String.

Der Denkfehler ist hier, dass bei

newFile.setFile(length, bais, fileExtension);

die Anzahl der Zeichen im String übergeben wird und nicht wie es sein sollte die Größe des Byte-Arrays. Diese beiden Werte sind nicht zwingend gleich.