byte[] zu String und zurück

[etreu]

Hallo,

ich habe gerade ein kleines Problem auf der Microedition. Ich habe ein byte-Array, dass ich in einen String umwandeln muss. Und zu entgegengesetzt muss ich aus dem String wieder das byte-Array erhalten. Allerdings komme ich auf keine grünen Zweig.

Meine Ideen:

// 1.

String s = String.valueOf(bytes);


// 2.

String s = myStringBuffer.toString();


// 3. 

String s = new String(bytes);

und zurück:

s.getBytes();

Inhalt sollte sein:

48-1261741514...[CODE]

Inhalt ist aber:

[CODE][B][B@1cb37664[/B]48-1261741514...

Der fette String ist da zuviel. Hat jemand von euch ne Idee oder sogar ne Lösung?

[kingofbrain]

Servus,

leider hast Du nicht den kompletten Quelltext gepostet. Der "fette" Teil sieht danach aus, als hättest Du irgendwo vorher noch die Variable s in Deinen Ergebnisstring gepackt (so in etwa: s = s + String.valueOf(bytes).

Poste mal den relevanten Ausschnitt, vielleicht kann man dann mehr sagen.

Peter

[etreu]

StringBuffer buf = new StringBuffer();

buf.append(bytesOrig);


for (int j = 0; j < bytesOrig.length; ++j) {

	buf.append(bytesOrig[j]);

}


byte[] bytes1 = buf.toString().getBytes(); // eine möglichkeit

char[] chars = buf.toString().toCharArray(); // weitere möglichkeit

byte[] bytes2 = new byte[chars.length];

byte[] bytes3 = new String(bytesOrig).getBytes(); // und noch eine (wirft ioexception: "reading reader invalid first byte 10000010"


for (int i = 0; i < chars.length; ++i) {

	bytes[i] = (byte)chars[i];

}


bytesX kann

[fafi]

ich hatte heute das selbe problem in c#

u. bin dann darauf gestoßen:

.NET-Snippets.de

ev. hilfts was...

[kingofbrain]

Servus,

also ich habe leider nicht verstanden, was mir Dein Codeausschnitt sagen sollte. Deshalb habe ich eine kleine Testklasse geschrieben:

public class Test {

    public static void main(String[] args){

        String source = "Hello World";

        byte[] bytes = source.getBytes();

        String intermediate = new String(bytes);

        byte[] result;


        System.out.println(intermediate);


        result = intermediate.getBytes();


        for(int i = 0; i < result.length; i++) {

            System.out.print(result[i] + " + ");

        }

    }

}

Da ein Byte-Array ein Objekt ist, kannst Du - z.B. in dem System.out.print - nicht direkt das byte-Array reinschieben, sonst bekommst Du nur die Instanzadresse des Arrays. Gehst Du aber durch das Array durch, dann kannst Du Dir die einzelnen Bytes rausholen.

Peter

[etreu]

Ich hatte nur gehofft, dass ich es mir ersparen, das Array immer wieder neu zu durchlaufen.

Außerdem hatte ich zeitweise ein paar Problem damit, new String(byte[]) zu benutzen.

Letzten Endes bin auch zu dieser Lösung gekommen. Leider, da ich mit der Microedition arbeite sind Laufzeit und Speicherplatz eben sehr begrenzt.

Danke.

[kingofbrain]

Servus,

ich kann es mir wahrscheinlich grad nicht vorstellen. Aber warum brauchst Du die Schleifenlösung, new String(byte[]) und String#getBytes() funktioniert doch? Oder hast Du damit schon Speicherprobleme?

Erklär doch noch mal kurz das eigentliche Problem, vielleicht gibt es eine andere Lösung.

Peter

[maddin]

new String(byte[]) bzw. String.getBytes() stellen den elegantesten Weg für dein Problem dar. Und wenn du damit Speicherproblem in der ME hast, wirst du auch mit allen anderen Lösungen Probleme bekommen.

Wenn du mit new String(byte[]) Probleme hast, liegt das eher am byte-Array oder an der KVM.

[frquadrat]

Bei Client/Server-Anwendungen kann es leicht passieren, dass beide unterschiedliches Default Encoding nutzen.

Auszug aus der API (java.lang.String):

String(byte[] bytes)

Constructs a new String by decoding the specified array of bytes

using the platform's default charset

.

D.h. Der String "Sülze" kann (als byte[] in hexadezimal) so z.B. als

53c3bc6c7a65 in utf-8

53fc6c7a65 in iso-8859-1

repräsentiert werden.

Konvertiert die Gegenseite also diese Bytefolge wieder zurück in einen String, und hat ein anderes Encoding eingestellt, knallt es u.U.

Auf der sicheren Seite ist man daher, wenn man auf beiden Seiten dasselbe Encoding (Sinnvoll ist utf-8) nutzt:

byte[] data;

try {

	data = text.getBytes("utf-8");

} catch (UnsupportedEncodingException e) {

	// this exception can't occur since utf-8 is always defined 

}

bzw.

String text;

try {

	text = new String(data, "utf-8");

} catch (UnsupportedEncodingException e) {

	// this exception can't occur since utf-8 is always defined 

}

[Akopalüze Now]

Hi frquadrat,

Ich habe ein ähnliches Problem: Ich muss eine Date auslesen und in einem String speichern. Dann soll der String weiter gegeben und bearbeitet werden. Am Ende soll aus dem String wieder ein Byte Array erstellt werden und wieder in eine Datei geschrieben werden.

Weil ich der ganzen Sache nicht so traue bevor ich dann den String weiterreiche, habe ich mir ein kleines Testprog geschrieben, daß im Prinzip nichts anderes macht als:

-Datei in einem Byte[] speichern

-den Byte[] dann mit toString in einen String umwandelt

-dann den String wieder in ein Byte[] wandelt

-beide byte[] vergleicht

-den aus dem String generierten byte[] dann weider in eine andere Datei schreibt

Ergebnisse dieses progs:

-Die Länge der beiden Byte[] ist schon mal anders wenn ich "utf-8" benutze

-Außerdem sind sowohl bei der Benutzung von "utf-8" als auch ohne, die Beldung der Arrays anders

-Wenn ich UTF-8 weglasse, dann ist die Länge und der größte Teil der Belegungen der Arrays identisch.

Problem:

- Auch wenn ich utf-8 weg lasse, dann ist die entsande Kopie der Datei nicht identisch

Warum String:

-Ich bin auf Grund der Rahmenbedingunen meines Projekts auf den String angewiesen, um die Datei in StringForm weiter verarbeiten zu können

Jetzt der java code:

String content = "";

	    	  String filename = "C:\\pdf1.pdf";


	    	  //Datei in byte data[] einlesen

	    	  File file = new File(filename);

			  FileInputStream fileInputStream = new FileInputStream(file);

			  byte[] data = new byte[(int) file.length()];

			  fileInputStream.read(data);

			  fileInputStream.close();


			  //byte data[] als String in String content speichern 

			  content = new String(data,"utf-8");


			  //String content wieder in ein byte[] konvertieren

			  byte[] a = content.getBytes("utf-8");


			  //beide byte[] vergleichen

			  System.out.println(data.length);

			  System.out.println(a.length);


			  for (int i = 0; i < data.length; i++){

		    	  if(data[i]!= a[i]) {

		    		  System.out.println( i +"--" + data[i] + "---" + a[i]);

		    	  }

		      }


		      //und noch zum Praxistest in eine Datei schreiben

			  FileOutputStream f = new FileOutputStream(new File("C:\\lala.pdf"));

		      f.write(a);

		      f.close();

Ziel:

Ich will es schaffen eine z.B. pdf-datei auszulesen, diese dann in einen String zu wandeln und dann den weg zurück wieder zu schaffen um am ende erstmal eine identische Kopie der ausgangsdatei zu haben. Wenn ich UTF-8 weglasse sind die beiden Dateien zwar gleich groß, aber eben nicht identisch, so daß die kopierte PDF nicht richtig angezeigt wird, wenn man diese öffnet

Wichtig:

Es geht mir nicht darum irgendwie eine Kopie zu erstellen, die ich dann öffnen kann, sondern der Transfer von byte[] ind String und dann wieder in byte[] muss klappen.

Frage:

Was mache ich falsch?

[kingofbrain]

Servus,

also es kann sein, dass ich nicht blicke, was Du machen willst, aber ich glaube, Du willst eine PDF-Datei von A nach B kopieren. Wenn dem so ist, dann kannst Du das nicht mit einem String machen, da der String von Character-Daten ausgeht, ein PDF aber ein Binärformat ist. Deshalb wird die Umwandlung von Deinem Byte-Array keinen sinnvollen String liefern und die Rückumwandlung geht dann in die Hose.

Betrachte das ganze als Bytes, das sind sie ja auch, und dann klappt das.

Peter

[frquadrat]

Hallochen,

Das Kapitel

13.3.3 Kopieren mit FileOutputStream und FileInputStream in der [url="http://www.galileocomputing.de/openbook/javainsel7]Insel solltest Du Dir zu Gemüte führen.

Ich würde Dir auch empfehlen, Code-Abschnitte jeweils ihrer Aufgabe nach in eigene Methoden zu packen. Das erhöht selbst bei Methoden, die nur vier, fünf Zeilen lang sind, die Übersichtlichtkeit.