Entwickler-Ecke :: Thema anzeigen - Byte[] zu String konvertieren: Richtige Codierung gesucht

C0der - Mo 10.05.10 00:04
Titel: Byte[] zu String konvertieren: Richtige Codierung gesucht

Hallo Leute,

Damit ihr mein Problem besser verstehen könnt, müsst ihr zuerst wissen was es tut.
Ich lese quasi Sektor für Sektor raw von der Festplatte aus und speichere es in einem Byte Array.
Das Problem ist nun, wenn ich es in einen String umcodieren will (um eine Pattern Recognition durchzuführen) mit

C#-Quelltext

1:	buf2=Encoding.Convert(Encoding.UTF8, Encoding.Unicode, buf);

oder jeglichen anderen Quellcodierung (ist der erste Parameter) bekomme ich nicht das Ergebnis, dass ich machen würde wenn ich statt dem obigen Folgendes durchführe:

C#-Quelltext

1:
2:
3:
4:
5:

for (int x = 0; x < 512; x++)
{
      c = (char)buf[x];
      this.richTextBox1.Text += c;   
}

Ich weiß, dass von der Festplatte ziemlicher "Müll" kommt, der teilweise nicht codiert werden kann, aber ich kann mit der ersten Methode nicht einmal den MBR auslesen, der 100%ig einen lesbaren String beinhaltet (z.B. "No operating system installed"). Wisst ihr woran das liegen könnte?

Danke im Vorraus!

Mit freundlichen Grüßen
C0der

C0der - Mo 10.05.10 00:29

Kha hat folgendes geschrieben :

:welcome:

Wie wird denn dann der Buffer weiterverarbeitet/angezeigt? Das Äquivalent zu deiner Schleife sollte jedenfalls Encoding.ASCII.GetString sein.

Angezeigt wird es dann in einer RichTextBox, was aber hier nicht das Problem ist, denn bei der Methode, wo ich jedes einzelne Byte in einen char caste, wird es auch mit der RichTextBox angezeigt.
Mit Encoding ASCII bekomm ich erneut nicht das gleiche Ergebnis. Ich bin gerade echt ratlos was das angeht :)

JüTho - Mo 10.05.10 09:06

Hallo und ebenfalls :welcome:

Und wie ist es mit Encoding.Default? Das ist die Version des Betriebssystems. Bei Dateien sind noch GetEncoding() mit 1250, 1251, 1252 vorzuschlagen; aber das kannst du nur für die Bereiche machen, die eindeutig zu einer bestimmten Datei gehören.

Jürgen

C0der - Mo 10.05.10 13:33

JüTho hat folgendes geschrieben :

Encoding.Default funktioniert ebenfalls nicht.

Ich werde jetzt einfach die BitEncoder Klasse verwenden, und mir den String als HEX anzeigen lassen. Wenn ich Muster Suche wandle ich den String nachdem gesucht werden soll einfach um und suche ihn dann.

Es würde mich jedoch trotzdem interessieren warum es nicht funktioniert :/

C0der - Mo 10.05.10 17:07

Kha hat folgendes geschrieben :

C0der hat folgendes geschrieben :

Es würde mich jedoch trotzdem interessieren warum es nicht funktioniert :/

Mich auch, könntest du uns so ein Array mal zukommen lassen :) ? Am besten wohl per File.WriteAllBytes in eine Datei dumpen.

So, anbei das Dump file :)
Wenn man sichs mit nem Editor (notepad) oder einem Hex Editor ansieht ist wie gesagt alles kein Problem.

C0der - Mo 10.05.10 21:19

Greenberet hat folgendes geschrieben :

Der Text scheint UTF8 kodiert zu sein.
Allerdings hat der String viele NPC ( Non Printable Characters ). Es könnte sein, dass die Richtextbox diese nicht anzeigen und dadurch "durcheinander" kommt

Das Problem ist, dass ich diese mit der Char-Cast Methode (im Ursprungspost erwähnt) in der Rich Box anzeigen kann. :)

Kha - Mo 10.05.10 21:40

Non Printable Charactes anzeigen? Interessant ;) .
Das hier tut jedenfalls wie erwartet bei mir nicht:

C#-Quelltext

1:
2:
3:
4:
5:

var buf = File.ReadAllBytes("dump.txt");
for (int x = 0; x < 512; x++)
{
  this.richTextBox1.Text += (char)buf[x];
}

C0der - Mo 10.05.10 21:55

Kha hat folgendes geschrieben :

Non Printable Charactes anzeigen? Interessant ;) .
Das hier tut jedenfalls wie erwartet bei mir nicht:

C#-Quelltext

1:
2:
3:
4:
5:

var buf = File.ReadAllBytes("dump.txt");
for (int x = 0; x < 512; x++)
{
  this.richTextBox1.Text += (char)buf[x];
}

Achso ^^ Ähm, wie soll ich sagen, der MBR konnte mit der char Methode eben angezeigt werden, mit den anderen jedoch nicht. Daher sollte es die RichTextBox nicht "durcheinanderbringen".

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!