Hex Ausdruck kürzen

S

SuperPCFan

Mitglied
Vielleicht habe ich ein Brett vor dem Kopf aber ich komme einfach nicht drauf.
Ich möchte mit einer Methode prüfen/ausführen, dass ein 4Byte signed Hex-Ausdruck auf die kürzest mögliche Byteanzahl reduziert wird.
Dies ist möglich, da der resultierende Wert später anhand seiner Byteanzahl interpretiert und nicht aufgefüllt wird.

Integer 1 -> 0x00000001 -> 0x01
Integer 256 -> 0x00000100 -> 0x0100
Integer ‭16777216‬ -> 0x10000000 -> 0x10000000
Integer -1 -> 0xffffffff -> 0xff
Integer -256 -> 0xffffff00 -> 0xff00
Integer ‭-285214972‬ -> 0xeefff704‬ -> 0xeefff704

Ich habe natürlich schon gegoogelt. Die Standardvorschläge wie
  • Integer.parseInt(x, 16)
  • Integer.parseUnsignedInt(x, 16)
  • Integer.toHexString()
  • Bitoperationen (&, |, >>, usw.)
erzeugen alle bei mindestens einem der Beispiele einen Ausgabefehler und/oder eine Exception.
Und wie ich die Methoden kombinieren könnte um zum Ziel zu kommen, hat sich mir bisher nicht erschlossen.

Gibt es dafür irgendeine Standardmethode, die ich bisher übersehen habe? Vielleicht in der ByteBuffer Klasse?
 
Beste Antwort
S
Ich habe zu viel in Schleifen gedacht (ist wohl eine "Programmiererkrankheit" ;)). Aufgrund der "Sonderfälle" macht eine Schleife hier wenig Sinn. Ich habe es nun so gelöst:

Java:
// zum testen
ArrayList<Byte> dataArray = new ArrayList<>();
dataArray.add((byte)0x00); // <- Steuerbyte
Byte[] testData = new Byte[]{(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00}; // <- Testdaten
Collections.addAll(dataArray, testData);
// testausdrücke ende

switch (dataArray.size()){
        case 5:
            if(isDataBlockReduceable((short)(((dataArray.get(4) & 0xff) << 8) | (dataArray.get(3) & 0xff)), dataArray.get(2))){
                dataArray.remove(4);
                dataArray.remove(3);
            } else{
                break;
            }...
1

123neu

Bekanntes Mitglied
Bei mir funktionieren die Methoden ohne Probleme. Das besondere Verhalten bei negativen Werten wird hier beschrieben: https://stackoverflow.com/questions/4355619/converting-string-to-integer-hex-value-strange-behaviour Nichts, was nicht schon einmal gefragt wurde... also

Java:
    public static String intToHexString(int x) {
        return Integer.toHexString(x);
    }

    public static int hexStringToInt(String x) {
        return (int) Long.parseLong(x, 16);
    }

    public static void main(String[] args) {
        System.out.println(intToHexString(1));
        System.out.println(hexStringToInt(intToHexString(1)));
        System.out.println(intToHexString(256));
        System.out.println(hexStringToInt(intToHexString(256)));
        System.out.println(intToHexString(16777216));
        System.out.println(hexStringToInt(intToHexString(16777216)));
        System.out.println(intToHexString(-1));
        System.out.println(hexStringToInt(intToHexString(-1)));
        System.out.println(intToHexString(-256));
        System.out.println(hexStringToInt(intToHexString(-256)));
        System.out.println(intToHexString(-285214972));
        System.out.println(hexStringToInt(intToHexString(-285214972)));
    }
 
Oneixee5

Oneixee5

Bekanntes Mitglied
Eine Exception erhälst du z.B.: bei 0xffffffff, du kannst da einen Trick verwenden:
Java:
        final String x = "ffffffff";
        final long l = Long.parseLong(x, 16);
        System.out.println((int)l);
 
1

123neu

Bekanntes Mitglied
1

123neu

Bekanntes Mitglied
1617988965214.png
 
S

SuperPCFan

Mitglied
Genau, da hat sich ein unsichtbares Zeichen reingemogelt, sonst hätte er schon bei "ffffffff" meckern müssen.
Die Magie ist, Long.parseLong() statt Integer.parseInt() zu benutzen und das Ergebnis dann wieder auf int zu casten.

Damit klappt schonmal der erste Schritt des einlesens.

Bei der Ausgabe der negativen Werte klappt das kürzen aber nicht wie ich es benötige.

SuperPCFan hat gesagt.:


Dies ist möglich, da der resultierende Wert später anhand seiner Byteanzahl interpretiert und nicht aufgefüllt wird.
Der Satz ergibt keinen Sinn. Wie wärs mit Deutsch?

Natürlich ergibt das Sinn.
Stell mal den Windows-Taschenrechner auf "Doppelwort" und gib "ffffff00" ein.
Dann stell' den Taschenrechner auf "word", ohne den eingegebenen manuell zu überschreiben.
Der angezeigte Dezimalwert ist derselbe, weil die verfügbare Byteanzahl bei der Interpretation berücksichtig wird.
 
1

123neu

Bekanntes Mitglied
Robert Zenz

Robert Zenz

Bekanntes Mitglied
Ich denke nicht dass es da eine bereits existierende Methode gibt, weil zumindest

Integer -1 -> 0xffffffff -> 0xff
Integer -256 -> 0xffffff00 -> 0xff00

ist nicht standard. Sicher dass du das so kuerzen willst? Weil laut deinen Beispielen muesste naemlich "0x000000ff" muesste ebenfalls auf "0xff" gekuerzt werden.

Um die fuehrenden Nullen los zu werden, kannst du einfach die fuehrenden Nullen entfernen, zum Beispiel mit einer Regex und "String.replaceAll" mit dem Ausdruck "^0+".
 
S

SuperPCFan

Mitglied
Das ist leider so eine dumme Logik.
0x000000ff muss auf 0x00ff gekürzt werden.

Aber wie es scheint muss ich dann tatsächlicher selber die bits auf low Level verbiegen um das zu erreichen.
 
W

White_Fox

Top Contributor
Ehrlich gesagt, verstehe ich das noch nicht so ganz:

Ich möchte mit einer Methode prüfen/ausführen, dass ein 4Byte signed Hex-Ausdruck auf die kürzest mögliche Byteanzahl reduziert wird.
Dies ist möglich, da der resultierende Wert später anhand seiner Byteanzahl interpretiert und nicht aufgefüllt wird.

Wenn du von den vier Bytes eines Integers eines entfernst, nimmst du wesentliche Information weg. Wenn du von der Zahl 120.000 die nachfolgenden Nullen streichst, bleibt 12 übrig - und das ist etwas völlig anderes.
Wenn du eine zusätzliche Information hinzufügst, nämlich z.B. daß die Zahl ursprünglich aus sechs Ziffern bestand und das nur nachfolgende Nullen entfernt werden, kannst du die ursprüngliche Information wieder rekonstruieren.

Nur: Ist das sinnvoll? Wenn du z.B. Speicher sparen mußt, dann könnte man auf solch eine Idee kommen. Allerdings bringt das nur unter einer Vorraussetzung etwas: Du darfst nicht mehr Speicher zum Halten der Zusatzinformation "Anzahl der Stellen" verbrauchen als du einsparen kannst.

Daher mal eine Frage: Was willst du eigentlich erreichen? Wir wissen zwar wie du dir die Lösung in etwa vorstellst, aber was genau ist das Problem?
 
S

SuperPCFan

Mitglied
Das ist die Aufgabenstellung, nicht die Lösung.
Die USB-HID-Spezifikation für Report Descriptoren schreibt aus Speicherplatz- , Transferpaketgröße- und Parsing-dauer- Gründen vor:

Ein Datenpaket darf aus maximal 4 byte bestehen, muss aber gemäß der beschriebenen Logik auf das Minimum reduziert werden.
Die "Byteanzahl", welche du als "zusätzliche Information" beschreibst, ist in einem weiteren Byte enthalten.
Das Byte enthält neben dem Bytecount noch weitere Informationen. Es ist also nicht "zusätzlich" da.
 
W

White_Fox

Top Contributor
Hm...wenn es um sowas geht, dann würde ich ein Integer einfach ein Integer mit seinen vier Bytes sein lassen. Wenn du ein Integer übertragen willst, und das hat nunmal vier Bytes, dann sind auch vier Bytes zu übertragen.

Dann würde ich eher prüfen, ob dir nicht ein Short oder gar ein Byte reichen würde. Sollte dies der Fall sein, kannst du damit weitaus mehr erreichen.

Wenn du das doch zerlegen willst: Schau dir mal die Klasse ByteBuffer an. Die kannst du mit Platz für vier Bytes oder gleich einem Bytearray initialisieren und in einzelne Bytes zerlegen. Du kannst dann über das Bytearray iterieren und prüfen, welche Bytes 0 sind, aber eleganter fände ich eine Betragsbildung und anschließender Vergleich (>2^(n*8)-1; n=1, 2, 3).
Und dann läßt du dir die entsprechenden Bytes von der ByteBufferklasse einfach ausgeben.

Nachtrag:
Die Rückwandlung (vier Bytes nach Integer/Short/...) geht mit ByteBuffer natürlich auch.

Nachtrag 2:
Es gibt auch IntegerBuffer...vielleicht ist das auch hilfreich.
 
Zuletzt bearbeitet:
H

httpdigest

Top Contributor
Ich glaube, am besten ist, wenn du einfach die tatsächliche Spezifikation hier anführst, denn du hast keine Beschreibung eines Algorithmus' gegeben, sondern einfach ein paar Beispiele, aus denen keine klare Regel hervorgeht.
Du hast zwar gesagt "USB-HID-Spezifikation für Report Descriptoren", aber hier finde ich keine solche Regel.

Du sagst:
Integer 1 -> 0x00000001 -> 0x01
Integer 256 -> 0x00000100 -> 0x0100
Integer ‭16777216‬ -> 0x10000000 -> 0x10000000
Integer -1 -> 0xffffffff -> 0xff
Integer -256 -> 0xffffff00 -> 0xff00
Integer ‭-285214972‬ -> 0xeefff704‬ -> 0xeefff704

Dabei gibt es laut dir die Ausnahme, dass 0x000000ff auf 0x00ff gekürzt werden soll.
Was ist denn jetzt aber mit z.B. 0x000000fe? Soll das auch auf 0x00fe gekürzt werden?
Und ab wann wird angenommen, dass wieder mit Nullen aufgefüllt werden soll?
Also, 0x00000001 wird ja _nicht_ zu 0x0001 gekürzt, obwohl es das aber laut deiner Beispiellogik müsste.
Deswegen meine Frage: Ab welchem Wert des niedrigstwertigen Bytes wird bei der Dekomprimierung wieder angenommen, dass mit Nullen als höherwertige Bytes aufgefüllt werden kann, statt mit Einsen (ff)?

tl;dr: Gib bitte eine Referenz auf den eigentlichen Algorithmus bzw. eine Spezifikation.
 
Zuletzt bearbeitet:
S

SuperPCFan

Mitglied
https://www.usb.org/hid

Ob höhere Bytes entfernt werden dürfen, hängt vom signed-Zustand des nächste niedrigen Byte ab:

Was ist denn jetzt aber mit z.B. 0xfe? Soll das auch auf 0x00fe gekürzt werden?
"0xfe" wird nicht gekürzt. Das ist ja schon auf der niedrigsten Größe. 0 Byte würde ja keine Daten enhalten.

"0x00fe" dürfte nicht gekürzt werden, weil das MSB von Byte0 das byte als negativ ausweist und Byte1 gleich 0 ist.
"0x00000001" wird zuerst zu "0x0001", weil das MSB von Byte1 das byte als positiv ausweist und Byte3 & Byte2 gleich 0 ist.
"0x0001" wird zu "0x01", weil das MSB von Byte0 das byte als positiv ausweist und Byte1 gleich 0 ist.

"0xffffffff" wird zuerst zu "0xffff", weil das MSB von Byte1 das byte als negativ ausweist und Byte3 & Byte2 gleich -1 ist.
"0xffff" wird zu "0xff", weil das MSB von Byte0 das byte als negativ ausweist und Byte1 gleich -1 ist.
"0xffffff00" wird zuerst zu "0xff00", weil das MSB von Byte1 das byte als negativ ausweist und Byte3 & Byte2 gleich -1 ist.
"0xff00" wird nicht gekürzt, weil das MSB von Byte0 das byte als positiv ausweist.

Die Logik habe ich vor Augen. Ich hatte nur gehofft das nicht mit Bitverbiegen bauen zu müssen.
 
W

White_Fox

Top Contributor
Also läßt du einfach das zweite, das dritte, oder das zweite und das dritte Byte weg? Das erste bleibt immer stehen um das Vorzeichen zu erhalten, und das letzte sowieso, damit es überhaupt etwas zu übertragen gibt?


Die Logik habe ich vor Augen. Ich hatte nur gehofft das nicht mit Bitverbiegen bauen zu müssen.
Mußt du ja nicht...dafür gibts die ByteBufferklasse. Schau sie dir an.
 
S

SuperPCFan

Mitglied
@White_Fox: Jup, danke für den Hinweis. ich schaue mir ByteBuffer und IntegerBuffer nochmal genauer an.

@httpdigest:
Das was du als "die Spezifikation" erwartest, gibt es bei USB nicht. Das steht nicht an der einen "Superstelle".
Die USB Foundation ist Meister darin, Verhalten über viele Stellen und Kapitel zu verketten.
Das Grundkonstrukt steht in Kapitel 2 "Generals". Das Format steht in Kapitel 5 "Report Descriptor" und in welchem Kapitel die Optimierung selbst steht, habe ich schonwieder vergessen. :rolleyes:
 
H

httpdigest

Top Contributor
Okay, eine Frage habe ich noch:
Du sagtest oben "0xff00" wird nicht gekürzt, bleibt also 2 Bytes. Das sehe ich nicht so, weil 0xff00 ist ja erstmal dasselbe wie 0x0000ff00 und das müsste eigentlich zu 0x00ff00 gekürzt werden. Oder sehe ich das falsch?
Weil, wir nehmen ja immer 4-Byte (also int) Werte als Eingabe des Algorithmus an. Wenn wir also immer 4-byte signed Integer verwenden und 0xff00 demnach dasselbe ist wie 0x0000ff00, dann müsste das zu 0x00ff00 werden.

Damit wäre ein Algorithmus für die Anzahl der zu sendenden Bytes der hier:
Java:
public static int compressedLength(int v) {
  int r;
  for (r = 0; v != 0; r++, v >>= 8)
    if ((v & 0x80) != 0)
      v = ~v;
  return r;
}

Test:
Java:
System.out.println(compressedLength(0x00000001)); // =1
System.out.println(compressedLength(0x00000100)); // =2
System.out.println(compressedLength(0x10000000)); // =4
System.out.println(compressedLength(0xffffffff)); // =1
System.out.println(compressedLength(0xffffff00)); // =2
System.out.println(compressedLength(0xeefff704)); // =4
System.out.println(compressedLength(0x00fe));     // =2
System.out.println(compressedLength(0xff00));     // =3

Ein Spezialfall ist hier tatsächlich der Wert v = 0, der durch 0 Bytes repräsentiert werden kann.

Dann kann man dann mit Hilfe der Anzahl der zu sendenden Bytes einfach per Schleife und Bitshift + &0xFF die zu sendenden Bytes durch welches API Interface auch immer wegschrieben, z.B.:
Java:
interface ByteSink {
  void write(byte b);
}
public static void writeBytes(int v, int len, ByteSink sink) {
  for (int i = 0; i < len; i++, v >>>= 8)
    sink.write((byte)(v & 0xFF));
}

Die konkrete Implementierung hiervon hängt aber stark davon ab, wie dein "ByteSink" tatsächlich aussieht. Du willst ja sicherlich keine "0xFF" oder "0x01" Strings schreiben.
 
Zuletzt bearbeitet:
S

SuperPCFan

Mitglied
Immer ausgehend von 4 Bytes, genau richtig:
"0x0000ff00" wird nicht gekürzt, weil Byte1 negativ ist und Byte3 & Byte2 == 0 ist.
-> Oder anders ausgedrückt: Die Information "4Bytes" muss wegen der Möglichkeit "0xff00 -> -256" erhalten bleiben.
"0xffffff00" wird zu "0xff00" gekürzt, weil Byte1 negativ ist und Byte3 & Byte2 == -1 ist. Aber dann nicht weiter.

"0x0000ff00" könnte (theoretisch) zu "0x00ff00" gekürzt werden. Da kommt aber noch der Komplexitätsgrad dazu, das byte3 und byte2 zusammen betrachtet werden müssen. Es gibt nur 1, 2 oder 4 Byte Pakete.
 
H

httpdigest

Top Contributor
Okay, wenn dieser Spezialfall nicht wäre, wäre es tatsächlich sehr einfach. Dann könnte man jedes Byte für sich betrachten und gucken, ob der Restwert mit dem aktuellen Byte arithmetisch herausgeshiftet dem erwarteten Wert (fffff... oder 0000....) gemäss des MSB des aktuellen Bytes entspricht.

Und ein Dekodierer, der ja die Anzahl der komprimierten Bytes und die komprimierten Bytes als Information erhält, könnte dann einfach auf das MSB des ersten Bytes gucken und entsprechend die nötigen Bytes des 4-Byte ints entweder mit 00 oder mit FF oben auffüllen.

Ich glaube, die Frage ist jetzt eher: Wie würde ein Dekodierer hier funktionieren?
"2 Bytes und 0xFF00" würden für einen Dekodierer ja zu 0xFFFFFF00 werden.
Und "2 Bytes und 0x00FF" würden zu "0x000000FF" werden.
Und "3 Bytes und 0x00FF00" könnte er eigentlich auch zu "0x0000FF00" expandieren.
 
Zuletzt bearbeitet:
mihe7

mihe7

Top Contributor
Irgendwie verstehe ich das Problem nicht ganz:
Dies ist möglich, da der resultierende Wert später anhand seiner Byteanzahl interpretiert und nicht aufgefüllt wird.
Es gibt nur 1, 2 oder 4 Byte Pakete.
Das heißt für mich einfach, dass es Werte gibt, die mit 1 Byte, 2 Byte und 4 Byte (byte, short, int) im Zweierkomplement dargestellt werden. Die Frage ist doch damit nur, wie viele Bytes werden für einen gegebenen Wert benötigt, oder sehe ich hier was falsch?
 
S

SuperPCFan

Mitglied
Ich habe zu viel in Schleifen gedacht (ist wohl eine "Programmiererkrankheit" ;)). Aufgrund der "Sonderfälle" macht eine Schleife hier wenig Sinn. Ich habe es nun so gelöst:

Java:
// zum testen
ArrayList<Byte> dataArray = new ArrayList<>();
dataArray.add((byte)0x00); // <- Steuerbyte
Byte[] testData = new Byte[]{(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00}; // <- Testdaten
Collections.addAll(dataArray, testData);
// testausdrücke ende

switch (dataArray.size()){
        case 5:
            if(isDataBlockReduceable((short)(((dataArray.get(4) & 0xff) << 8) | (dataArray.get(3) & 0xff)), dataArray.get(2))){
                dataArray.remove(4);
                dataArray.remove(3);
            } else{
                break;
            }
        case 3:
            if(isDataBlockReduceable(dataArray.get(2), dataArray.get(1))){
                dataArray.remove(2);
            }
            break;
        default:break;
}

private boolean isDataBlockReduceable(int iDataBlockToReduce, int iNextlowerDataBlock){
    boolean bReduceable = false;
    if (iNextlowerDataBlock >= 0){
        if (iDataBlockToReduce == 0) {
            bReduceable = true;
        }
    } else {
        if (iDataBlockToReduce == -1) {
            bReduceable = true;
        }
    }
    return bReduceable;
}

Danke für die Diskussion.
 
Beste Antwort
1

123neu

Bekanntes Mitglied
Ist denn vorher bekannt ob du 1 byte, 2 byte oder 4 byte brauchst, und wenn ja ist auch bekannt ob mit oder ohne Vorzeichen? Weil dann brauchst du doch einfach nur 3 Methoden...
 
mihe7

mihe7

Top Contributor
Ich wiederhole mich, die Frage ist doch einfach, wie man den Datentyp (bzw. die Zahl der Bytes/Bits herausfindet), den man mindestens braucht, um eine vorzeichenbehaftete Ganzzahl mit einer Breite von max. 32-Bt darzustellen.

Kurz: liegt mein Wert zwischen Byte.MIN_VALUE und Byte.MAX_VALUE, dann brauche ich ein Byte. Zwischen Short.MIN_VALUE und Short.MAX_VALUE brauche ich 2 Bytes und sonst halt 4.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
N Regulären Ausdruck in normalen Java-Code umwandeln Allgemeine Java-Themen 12
N Regulärer Ausdruck funktioniert nicht Allgemeine Java-Themen 6
J JavaFX var Ausdruck Allgemeine Java-Themen 1
L Hä? Lambda-Ausdruck geht, Methoden-Referenz nicht Allgemeine Java-Themen 8
L Erste Schritte Ausdruck schöner schreiben? Allgemeine Java-Themen 8
J Frage zu regulärem Ausdruck Allgemeine Java-Themen 2
H Reg Exp Ausdruck erweitern Allgemeine Java-Themen 2
W Regulärer Ausdruck für 0 oder mehr Blanks Allgemeine Java-Themen 8
M Regulärer Ausdruck Allgemeine Java-Themen 3
A Bestimmte Sonderzeichen im Regulären Ausdruck Allgemeine Java-Themen 2
R Regulärer Ausdruck Allgemeine Java-Themen 5
G Regulärer Ausdruck für 2 Wörter Allgemeine Java-Themen 3
P JFormattedTextField für durch Semikolon getrennte Integer-Werte gesucht / Regulärer Ausdruck Allgemeine Java-Themen 3
B Problem mit Regulärem Ausdruck Allgemeine Java-Themen 4
J RegEx Ausdruck Allgemeine Java-Themen 2
G RegEx- Ausdruck Allgemeine Java-Themen 4
L String Replace mit Regulärem Ausdruck Allgemeine Java-Themen 2
H Problem mit der Klasse Pattern - Regulärer Ausdruck Allgemeine Java-Themen 2
O Text mit Wildcard gegen regulären Ausdruck prüfen Allgemeine Java-Themen 3
S Regulärer Ausdruck tut überhaupt nichts Allgemeine Java-Themen 2
M Regulärer Ausdruck Allgemeine Java-Themen 6
T Ausdruck mit pdfBox macht Probleme Allgemeine Java-Themen 2
M Ausgabe in Datei zum Ausdruck Allgemeine Java-Themen 2
Iron Monkey Regulärer Ausdruck Allgemeine Java-Themen 2
T Regulärer Ausdruck Allgemeine Java-Themen 6
S Regulärer Ausdruck für HTML-Tag Allgemeine Java-Themen 18
P [Regulärer Ausdruck] Auf Gruppe mit Quantifier separat zugreifen? Allgemeine Java-Themen 2
F Problem mit regulären Ausdruck in Zusammenhang mit HTML Allgemeine Java-Themen 8
J Regulärer Ausdruck - Der Punkt und der Zeilenumbruch Allgemeine Java-Themen 6
X String zerlegen mittels regulärem Ausdruck Allgemeine Java-Themen 31
M Wertepaar in relulärem Ausdruck Allgemeine Java-Themen 15
Iron Monkey Regulärer Ausdruck Allgemeine Java-Themen 6
A Regulären Ausdruck für Funktionsnamen Allgemeine Java-Themen 4
A Regulärer Ausdruck für die Uhrzeit Allgemeine Java-Themen 3
G Regulärer Ausdruck Allgemeine Java-Themen 4
M Regulären Ausdruck negieren Allgemeine Java-Themen 6
G Frage zu Regulärem Ausdruck Allgemeine Java-Themen 2
S regex-Pattern Ausdruck negieren Allgemeine Java-Themen 2
L Passwort mit Regulärem Ausdruck prüfen Allgemeine Java-Themen 6
M Regulärer Ausdruck Allgemeine Java-Themen 3
I Composite Pattern für Ausgabe von Ausdruck Allgemeine Java-Themen 3
P Regulärer Ausdruck um sich wiederholende Zeichen zu finden. Allgemeine Java-Themen 9
M Regulärer Ausdruck mit [ und ] Allgemeine Java-Themen 9
P Problem - Regulärer Ausdruck funktioniert nicht Allgemeine Java-Themen 5
J Regulärer Ausdruck Allgemeine Java-Themen 3
N Regulärer Ausdruck Allgemeine Java-Themen 2
X problem mit regulären ausdruck Allgemeine Java-Themen 3
F Problem mit regulärem Ausdruck Allgemeine Java-Themen 6
M Regulärer Ausdruck Allgemeine Java-Themen 2
M backreference im regulären ausdruck Allgemeine Java-Themen 9
A Probleme Umwandlung Ausdruck String in double Allgemeine Java-Themen 4
B regulärer ausdruck Allgemeine Java-Themen 9
P Dateinamen mit regulärem Ausdruck testen Allgemeine Java-Themen 9
T Einfacher regulärer Ausdruck Allgemeine Java-Themen 2
A Regulärer Ausdruck EMail-Prüfung Allgemeine Java-Themen 3
N Regulärer Ausdruck Allgemeine Java-Themen 2
X Brüche kürzen mittels Methoden und ggT Allgemeine Java-Themen 15
J Methoden Commands kürzen Allgemeine Java-Themen 6
K URL kürzen Allgemeine Java-Themen 19
X Textdatei auf gewünschte Anzahl der Zeilen kürzen Allgemeine Java-Themen 2
S Stringvariableninhalt kürzen Allgemeine Java-Themen 4

Ähnliche Java Themen


Oben