Code Page characters darstellen

javango

Mitglied
Hallo,
ich möchte für eine Art Hex-Editor Zeichen (einzelne Bytes) auch in ASCII darstellen. Nun sind die normalen Formate wie UTF-8 usw. dafür nicht geeignet, da diese zeichen grösser 127 nicht oder nur teilweise darstellen können.
Ich hab mich noch an die alten DOS-Programme erinnert und hab dann auf die Erweiterte ASCII-Tabelle mit Codepage "IBM850" gefunden, welche auf von Java 8 unterstützt wird:
https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html
Mit einer mit dieser Code Page erweiterten ASCII - Tabelle lässt sich dann jeder Bytewert von 0-255 mit einem Zeichen darstellen. Es dürfte auch eine andere sein, welche alle Bytewerte in Zeichen unterscheiden kann.
Damit hab ich ein bisschen rumprobiert mit folgendem Code:
Java:
      boolean bo = Charset.isSupported("IBM850");
      if (bo) {
        Charset cs = Charset.forName("IBM850");
        ByteBuffer bb = ByteBuffer.allocate(256);
        for (int i = 0; i < 256; i++) {
          byte b = (byte)(i+32);
          bb.put(i, b);
        }
        Stringss = cs.decode(bb).toString();
        System.out.printf(ss);
      }
Das programm kopiert in einen ByteBuffer alle 256 Zeichen und wandelt diese dann laut dem Charset mit decode() in einen Charbuf und da gleich in einen string (toString()) um und soll diesen dann ausprinten.
Dabei kommt er bis zum printf(), wirft dann aber eine Exception java.util.UnknownFormatConversionException
Aber der String ss kann ich beim Debuggen vorher noch anschauen. Dieser enthält zwar ab 128 nur noch Vierecke, aber ich kann ihn eben im Debugger sehen. Wieso es dann beim printf() knallt, ist mir ein Rätsel.
Ausserdem hab ich die Zeichen der IBM850er Code Page nicht bekommen, obwohl diese offenbar unterstützt wird.
 
Ersetze printf durch println

EDIT: und warum addierst du 32 zu dem byte??? Ich dachte, du willst tatsächlich das entsprechende Byte 0-255 (und nicht 32-287) in sein Zeichen wandeln.
EDIT2: Ach ja, durch den byte Cast wird daraus ja auch 0-255, nur eben Start bei 32 und dann Überlauf.
EDIT3: Der Grund, warum du für die ersten 31 Zeichen wahrscheinlich nur Fragezeichenkästchen bekommst, ist, dass die Console, auf der du das ausgibst, selbst die Zeichen nicht unterstützt. Die Eclipse Console z.B. unterstützt die nicht.
Versuch es mal auf einer richtigen Console, wie etwa ConEmu/Cmder unter Windows. Unter Linux sollte das sowieso gehen.
 
Zuletzt bearbeitet:
Sorry sollte natürlich Strings heissen und das mit den 32 dazuaddieren war ein Versuch, weil die untersten 32 werte auch nur Kästchen liefern.

OK, println funktioniert erstmal zum printen, nun muss ich nur noch eine code page finden, welche für alle werte ein anderes Zeichen bringen. CP437 z.B. müsste ja eigentlich das tun, da gibt es diese smilies und Zeichen zum Rahmen erstellen - DOS halt:
http://www.fship.com/charsets/codepages.html
Stattdessen bekomme ich viele ???? und kästchen:

Kästchen konnte ich nicht kopieren (die ersten 32)
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜ¢£¥?ƒáíóúñѪº¿?¬½¼¡«»?????????????????????????????????????????????????ß????µ??????????±????÷?°?·??²?
 
Ja, es hängt von der Konsole (bzw. dem darauf verwendeten Font) ab, auf der du das printest, ob sie die Zeichen unterstützt oder nicht. Unter ConEmu sieht das z.B. so aus:
DdTpBRK.png
 
Zuletzt bearbeitet:
Diese Charsets sollten aber eben gerade plattformunabhängig sein (siehe mein oberster link) und mit decode() werden diese in unicode-Zeichen übersetzt. Dann sollte es ja kein Problem mehr sein. Fragt sich nur, ob die Zeichen in Unicode überhaupt vorhanden sind. Sind aber ja mögliche 64k zeichen...
 
Ja natürlich sind sie plattformunabhängig. Und ja, Java wandelt es immer in Unicode um. Wenn aber die Konsole nun mal kein Unicode kann, sieht man nichts.
 
Einverstanden, aber ich muss es schlussendlich nicht in einer Konsole darstellen, sondern in meinem Java-Programm. Und da kommt die Ausgabe so daher:
upload_2018-8-14_22-24-8.png
Sorry für das kleine Bild aber offenbar kann man hier mittels den Funktionen nur Bilder vom Internet einfügen. Jedenfalls sind alle Zeichen da, ausser die ersten 32.
 

Anhänge

  • upload_2018-8-14_22-23-6.png
    upload_2018-8-14_22-23-6.png
    10,2 KB · Aufrufe: 27
Also der Codepage Decoder in Java verhält sich schon sehr merkwürdig. Wenn man ihn danach fragt, die Bytes 0-255 von Cp850/IBM850 zu decodieren, und den erhaltenen String wieder in seine UTF-8 Bytes konvertiert, dann erhält man für die ersten 127 Bytes genau die Folge: 0, 1, 2, 3, 4, 5, ..., 127, was sogar korrekt ist laut dieser Wikipedia-Seite: https://en.wikipedia.org/wiki/Code_page_850
Dort sagen sie, dass die Zeichen 0-127 Zeichen in Cp850 genau denen von ASCII entsprechen, was für die ersten 31 Zeichen nicht-druckbare Steuerzeichen sind, die Java dann mit dem Fragezeichenkästchen darstellt.
Interessanterweise sagt aber die deutsche Wikipediaseite etwas anderes: https://de.wikipedia.org/wiki/Codepage_850
Dort sind die ersten 0-127 Zeichen eben mal überhaupt nicht die von ASCII, plus sie geben sogar den Unicode-Wert der einzelnen Zeichen hübsch an.
Java's Codepage Decoder scheint wohl dem Wortlaut von der englischen Wikipediaseite zu folgen und somit einfach die ersten 0-127 Zeichen als tatsächlich die Bytes 0, 1, 2, 3, ..., 127 abzubilden, was ja in ASCI, ANSI und UTF-8 dieselben Zeichen sind.
Somit bleibt dir eigentlich nur, die Unicode-Escapesequenzen aus der Tabelle der deutschen Wikipedia-Seite abzutippen, um wirklich wiiiirklich reproduzierbare Ergebnisse zu erhalten, also:
Java:
public static void main(String[] args) {
  String s = "\u263A\u263B\u2665\u2666\u2663...";
  JOptionPane.showMessageDialog(null, s);
}
 
Zuletzt bearbeitet:
Also der Codepage Decoder in Java verhält sich schon sehr merkwürdig.

Ausgehend von den Wiki-Artikeln habe ich mal ein wenig recherchiert. Merkwürdig sind vor allem CP437 und Konsorten, denn es handelt sich dabei nicht um fixe Kodierungen, sondern jeweils um mehrere, die abhängig vom Einsatzgebiet verwendet werden (https://web.archive.org/web/2016060...bm.com/software/globalization/cp/cp00437.html).

Man mag sich fragen, was die damals geraucht haben, jedenfalls gibt es somit natürlich keine eindeutige Zuordnung zu Unicode. Allerdings findet man ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT - und dort sind tatsächlich die Steuerzeichen und keine Smileys oder Herzchen angegeben.

Aber Achtung: natürlich gibt es auch noch Unterschiede zwischen CPxxx von MS und CPxxx von IBM (https://github.com/pentaho/pentaho-reporting/tree/master/libraries/libfonts/encodings/VENDORS/IBM) - wo kämen wir auch hin, wenn das alles einheitlich wäre?
 
Somit bleibt dir eigentlich nur, die Unicode-Escapesequenzen aus der Tabelle der deutschen Wikipedia-Seite abzutippen
Ja, werde wohl eine 256 grosse lookup table machen und dort die Zeichen einzeln ablegen. Ist zwar mühsam, aber wohl schneller als sich durch die grosse Flut an "Standards" durchzuarbeiten, wo dann wohl eh keine richtig das erfüllt was ich möchte.

Man mag sich fragen, was die damals geraucht haben
🙂) Angesichts dieser Fülle von code pages kann man sich dies sicher fragen, wobei man natürlich beachten muss, dass früher halt eben der Speicherplatz rar war und man nicht einfach so 4 Bytes für ein einzelnes Zeichen verschwenden konnte/wollte. Dazu kamen sicher rechtliche Belange wie z.B. Copyrights und so hat dann halt jeder sein eigenes Süppchen gekocht.

Ich hab mich schon gefragt ob ich auch noch eine eigene code page machen soll, es gibt ja schon so viele, da kommt es auf eine mehr oder weniger auch nicht an ;-)
Da werd ich dann bei Nummer 0 und 255 welche ja wie ein Blank aussehen wenigstens auch noch ein Bildchen reinmachen, so dass man auch diese unterscheiden kann!
 
Angesichts dieser Fülle von code pages kann man sich dies sicher fragen, wobei man natürlich beachten muss, dass früher halt eben der Speicherplatz rar war und man nicht einfach so 4 Bytes für ein einzelnes Zeichen verschwenden konnte/wollte. Dazu kamen sicher rechtliche Belange wie z.B. Copyrights und so hat dann halt jeder sein eigenes Süppchen gekocht.
Das erklärt sicher die Fülle der code pages (z. B. 437 für US, 850 für Europa usw.), nicht aber, dass man in einer CP einem Code verschiedene Zeichen zuordnet und dann sagt, dass es vom Kontext abhängt, welches Zeichen zu verwenden ist.
 

Zurück
Oben