Questions & Answers

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.



Type a product name