byte.toString() -> Datenmüll

[jansen]

so da bin ich wieder
also:
du hast schon recht, dass man SOH als \u0001, \x01 und 1 ausdrücken kann

aber man erkennt dies nicht im string:
BSP:

String einkomprimierterString = new String("\x01 ist ein Steuerzeichen, ebenso wie \x02");
//Ausgabe des Strings würde folgendes ergeben:
[] ist ein Steuerzeichen, ebenso wie []
//[] ist dieses komische Quadrat, welches immer dann auftaucht, wenn ein Zeichen nicht dargestellt werden kann

man kann hinterher nicht mehr feststellen, welcher byte[]-Code hinter den "[]" steckt, da die Auswertung später über den reinen String passiert (ich hoffe das ist einiger Maßen verständlich, wenn nicht dann sofort meckern )

Meine Überlegung:

nach dem im komprimierten byte[] nur positive Zahlen(ist mir schon geglückt) von 0 bis 255 drinne stehen, werden die elemente des byte[] herausgesucht, die als steuerzeich interprtiert werden

d.h:

bsp: byte[] kompriBytes : 65 65 1 66 //diese werte stehen im byte
in einen String gepackt müsste es das hier ergeben:
"AA[]B"

[] wäre aber eigentlich SOH

also, sage ich:
an stelle aller steuerzeichen, die im string auftreten, packe ich eine kombination aus 2 verfügbaren zeichen rein

darausfolgt:

NUL entspricht ^!
SON enspricht ^#
.
.
.
DEL entspricht ^B
^ entspricht dann ^^

so sind zwar statt einem zeichen zwei enthalten, aber den obulus gehe ich ein

also sähe der String aus dem beispiel wie folgt aus:

"AA^#B"

beim empfänger weiß ich dann:

byte[] komprimierteb={byte(A),byte(A),byte(SOH),byte(B)}

was hältst du davon?
Habe ich eventuell etwas übersehen?

 

[Ark]

aber man erkennt dies nicht im string:
BSP:

String einkomprimierterString = new String("\x01 ist ein Steuerzeichen, ebenso wie \x02");
//Ausgabe des Strings würde folgendes ergeben:
[] ist ein Steuerzeichen, ebenso wie []
//[] ist dieses komische Quadrat, welches immer dann auftaucht, wenn ein Zeichen nicht dargestellt werden kann

man kann hinterher nicht mehr feststellen, welcher byte[]-Code hinter den "[]" steckt, da die Auswertung später über den reinen String passiert (ich hoffe das ist einiger Maßen verständlich, wenn nicht dann sofort meckern )

Es klingt seltsam, sehr seltsam.

Erfolgt die Auswertung von Menschen, die die Glyphen entziffern müssen? Ich denke nämlich nicht! Nur weil die Zeichen nicht vernünftig angezeigt werden, heißt das nicht, dass sie nicht korrekt gespeichert wären.

Mal zur Verdeutlichung:

// eine Maschine erzeugt einen String mit allen ASCII-Zeichen:
StringBuilder sb=new StringBuilder(128);
for(int i=0;i<128;i++){
	sb.append((char)i);
}
String alleASCII = sb.toString();

Wenn du dir das ausgeben lässt, sieht es vielleicht nach Müll aus, aber es ist nach wie vor alles korrekt gespeichert:

// alleASCII ist der String von eben
for(int i=0;i<alleASCII.length();i++){
	System.out.println((int)alleASCII.charAt(i));
}

Wie du vielleicht siehst: Innerhalb von Java sind Steuerzeichen in Strings kein Problem. (Mit anderen Unicode-Zeichen geht es genauso.) Warum also willst du Escape-Sequenzen drumherum bauen? Diese Escape-Sequenzen sind doch nur dazu da, um in einem Quelltext wie einem Java-Quelltext diese Zeichen eingeben zu können, ohne dass der Compiler auf Probleme stößt oder meckert. Im laufenden Programm ist es vollkommen egal, wie die Zeichen da reingekommen sind: ein SOH ist ein SOH, und wie es kodiert wird, steht auf einem völlig anderen Blatt (sprich: ist dann nicht mehr relevant).

[] wäre aber eigentlich SOH

Es wäre eines und es ist auch eines! Es sieht zwar doof auf dem Bildschirm aus, aber intern ist SOH gespeichert.

was hältst du davon?
Habe ich eventuell etwas übersehen?

Ja: Der Aufwand ist schlicht nicht nötig, es sei denn, dieser QR-Code hat wirklich Probleme mit Steuerzeichen.

Bist du dir immer noch sicher, dass Steuerzeichen wirklich ein Problem sind? Hast du schon einmal eine Verarbeitung von Anfang bis Ende vorgenommen, ohne dich von seltsam anmutenden Bildschirmausgaben verwirren zu lassen?

Ark

 

[jansen]

kurze antwort: ja , ich habe schon einmal einen string QRcodieren lassen, in dem nichts lesbares steht.
der algorithmus konnte damit nicht umgehen, da er sich die zeichen aus dem string nimmt und nicht etwa die bytes.

du weißt doch auch gar nicht wie der algo funktioniert- deswegen sehe ich auch deine argumentation nicht ein.

am ende hast du eh immer was zu meckern
wenn das jetzt hier klappt dann bin ich zu frieden

egal wie man zum ziel kommt, es gibt ja viele wege
der eleganteste ist mein weg nicht das gebe ich zu
vielleicht zu kompliziert- das gebe ich auch zu

aber mehr zeit um über diese sache nachzudenken habe ich nicht, obwohl ich das gerne würde!

auf jeden fall danke ich dir für deine denkanstöße, ark!
ohne deine hinterfragungen wäre ich wahrscheinlich nicht zu diesem resultat gekommen

zu deiner aussage: soh ist ein soh, und wie es kodiert wird, steht auf einem völlig anderen Blatt
das ist richtig
ich möchte nur nicht das in dem string steuerzeichen stehen - is einfach ne schlichte vorgabe vom arbeitgeber

bis denne antenne

ich werde denk ich mal noch ne abschlussbemerkung schreiben wenn das hier alles gelaufen ist

tschuss