Länge einer Hexadezimalzahl in Bits

A

andreas2505

Bekanntes Mitglied
Hallo,

ich benötige eine Funktion/Methode, um die Länge eines Strings in bits zu berechnen, also z.B.

String s1 = "50" --> int l1 (Länge) = 6
String s2 = "CEE88040" --> int l2 = 27

Gibt es da schon was vorgefertigtes oder eine einfach Methode?
 
Zuletzt bearbeitet von einem Moderator:
die Strings sollen wohl Hex-Werte sein? ne Zahl draus machen, Integer.toBinaryString()

edit: ok, '8' passt nicht so gut und Integer.toBinaryString(50) liefert zufällig 6 Stellen,
aber das wäre dann ja 50 direkt, nicht 50 Hex..

edit: irgendwie denke ich immer dass bei es bei Hex keine 8 und 9 gibt, stimmt natürlich nicht, das ist Octal
 
Zuletzt bearbeitet von einem Moderator:
also ja es geht hier um hexadezimale strings.

Ich weiß ja auch nicht wie die darauf kommen. Ich weiß nur, dass es so ist und brauche dringend eine Methode, die das berechnen kann.
 
> Ich weiß ja auch nicht wie die darauf kommen.

50 Hex hat nachweislich eine Länge von 7,
unbekannte ungeklärte Dinge hier zu diskutieren macht keinen Sinn,

ansonsten habe ich es ja schon beantwortet,
falls du den Schritt String -> Zahl nicht kennst, da gibt es parse-Methoden,
vielleicht besser aus der Long-Klasse statt Integer

-------

noch eine anschauliche Umrechung: jeder Hex-Wert braucht 4 Bits,
ein Byte von 8 Bit läßt sich immer als 2 Hex darstellen (00 bis FF), das kennst du vielleicht,

"CEE88040" hat 7 volle Stellen, die alleine benötigen 7*4 = 28 Bits, das erste C auch noch 4, macht 32
 
diggaa1984 hat gesagt.:
wie kommste denn auf die bsp-werte für die length!?
ein string in bitlänge wäre eigentlich simpel: "foo".getBytes().length * 8
Zum Vergrößern anklicken....

<-- Das wäre eigentlich die Antwort auf deine ursprügnliche Frage gewesen.

Was du meintest war jedoch: "Anzahl der Stellen einer Hexadezimalzahl, gespeichert in einem String, in Bit, ausrechnen."

Achte bitte darauf deine Fragen deutlicher zu stellen, da es sonst schwierig ist zu erraten was du wohl meintest. Mir viel es echt schwer.
 
ok, ja das stimmt.

Was ich meine sind wohl die Anzahl der Stellen einer Hexadezimalzahl, gespeichert in einem String, in Bit

Wie kann man die denn berechnen?
 
im prinzip wissen wir doch was er sucht, nur uns fällt keine lösung ein 🙂 ... im zweifelsfall sollte der TO mal seine ihm präsentierte Aufgabenstellung 1:1 widergeben.
 
das problem ist, dass ich ja wirklich nicht zu hundert Prozent sagen kann, was ich suche.
Ich weiß nur, dass ich ein String habe in hexadzimaler Form und dazu irgendeine Länge, welche ich ja für die obigen Beispiele mal angegeben habe (ich kann auch noch mehr angeben).
Und ich suche halt irgendeinen Weg, wie man auf diese Werte kommt.
 
Dann tu das mal.

Ich bin nicht mit Diggas Post einverstanden, ich bin mir nicht sicher was der TE wirklich machen muss und was er sucht. So wie ich das verstehe möchte er im Grunde wissen, wieviel Bit man zur Darstellung der Zahl in Binärdarstellung minimal benötigt. Für 0x50 = 0101 0000 in binär wären das 7 Bit. Für 0xCEE88040 =11001110111010001000000001000000 kommt man aber auf 32 Stellen und nicht auf 27. Entweder stimmt die Aufgabe nicht, oder der TE hat sich verlesen / vertippt. So macht das keinen Sinn zu raten.
Ergo wäre es sinnvoll mehr Beispiele zu haben. Im übrigen würde die Aufgabe dann auch nicht mit getBytes.length funktionieren. Da könnte er getBytes machen und müsste dann mittels ner Maske durch verunden die Vorderste eins im MSB suchen und daraus dann die Länge bestimmen.
 
ok, hier mal etwas ausführlicher, so wie es da steht wo ich es her habe:

message der Länge 29

input message (last byte alligned on MSB):
53 58 7B C8

input message in bits
01010011010110000111101111001

hier von mir aus auch noch ein paar beispiele (nur mir wort und länge)

Länge Wort
4 80
16 41FB
36 0127A1D340
58 42DA39AC5951FEC0

vielleicht kann jetzt jemand verstehen, was ich brauche und mir vielleicht auch sagen, wie ich darauf komme...
 
Also meiner Meinung nach stimmt da was nicht, bzw. musst du uns erst erklären was "(last byte alligned on MSB)" hier bedeutet. Last byte von was, MSB=most significant byte???.
Was mir allerdings aufgefallen ist:
Hex: 53 58 7B C8
01010011010110000111101111001000 in Binär
01010011010110000111101111001 in deiner Angabe

Da is doch was faul.
 
tja ich weiß selber nicht so genau was das bedueten soll...

vielleicht ist das ja die Lösung, das die Nullen weggelassen werden...

habs grad nochmal an den 4 Beispielen nachgeprüft. Das haut hin, wenn man die Nullen am Ende weglässt. Was auch immer das für einen Sinn ergibt...

Weiß denn jemand, wie man nun die Anzahl von Nullen dort ermittelt, bzw. die Länge ohne die Nullen...
 
Zuletzt bearbeitet:
Das wäre ja klasse. Wir erzählen das dem Herrn Papandreou und der macht dann aus 273.400.000.000 € grad 2.734 € … 😎

Ebenius

PS: Most Significant Byte ist lustisch.
 
Hm, ich glaube gemeint ist, das das letzte Byte, wenn man von rechts nach links ließt, das MSB ist. Aber irgendwie macht das für mich nicht so Sinn die Nullen hintendran wegzulassen... Aber nun gut wir wollen ja hier nicht über Sinn und Unsinn von schwachsinnigen Aufgaben reden.

Kurzer Tipp (schnell hingehackt...) was du als Grundlage verwenden kannst um dein Problem zu lösen:

Java: 
public static void main(String[] args) {
		byte a = (byte)0x10;
		byte mask = (byte)0x01;
		int counter = 0;
		boolean found = false;
		
		while(counter < 8 && !found){
			if((a & mask) != (byte)0x00)
			{
				System.out.println("Anzahl der Nullen: " + counter);
				found = true;
			}
			mask <<= 1;
			counter ++;
		}
	}
 
Das Problem ist nur, dass das Most significant byte das erste byte und nicht das letzte ist. Im fall von
01010011010110000111101111001000
wäre 0101
oder zumindest 1010
das most significant byte, weil es ja den grösten unterschied in der Zahl, die am Ende rauskommt ausmacht. Ich habe noch nie von algorithmen gehört, die das Most significant byte verändern. Ich weis, dass bei Steganographie das Least Significant byte verändert wird, also das byte das am wenigsten unterschied macht.
Mein Rat an den Topic Starter: poste die Angabe für deine Hausübung 1:1, sonst wird dir hier niemand helfen können.
 
wie ich das sehe hast du doch nen String welcher ein Hex-Wert repräsentiert, und sollst ermitteln wie lang
die zahl in Binärdarstellung ist.

Warum machst du dann nicht einfach string.length()*4;
So berücksichtigst du auch die 0 am ende, was in den Beispielen nicht der Fall ist.

Das geht so schön einfach, weil Hex (16) eine Potenz von 2 (Binär) ist.

Du kannst auch den Hex wert dann auch ganz einfach umwandeln:

Bsp: A 7 0
1010 0111 0000

Vlt. hilft es 🙂

mfg Timo
 
Warum machst du dann nicht einfach string.length()*4;
Zum Vergrößern anklicken....

das kann nicht funktionieren, weil z.B. bei Länge 58 --> 42DA39AC5951FEC0
erst die 4 Nullen von 0000 wegfallen und dann noch zwei Nullen von dem C (1100), deshalb 64-6=58

Mein Rat an den Topic Starter: poste die Angabe für deine Hausübung 1:1, sonst wird dir hier niemand helfen können.
Zum Vergrößern anklicken....

ist nur schwer möglich. Meine Aufgabe ist es die KECCAK Hashfunktion zu implementieren. Es ist auch alles soweit fertig. Bloß muss ich diesen Wert von der Länge eine hexadezimalen Strings berechnen können.

Wie es funktioniert soll, wissen wir ja mittlerweile. Wie nehmen die Anzahl an Stellen (also die Länge string.length()*4 und ziehen dann von hinten alle Nullen ab, bis die nächste 1 kommt. Dann haben wir die Länge. Bloß wie kann man das implementieren?
 
bERt0r hat gesagt.:
Das Problem ist nur, dass das Most significant byte das erste byte und nicht das letzte ist. Im fall von
01010011010110000111101111001000
wäre 0101
oder zumindest 1010
das most significant byte, weil es ja den grösten unterschied in der Zahl, die am Ende rauskommt ausmacht. Ich habe noch nie von algorithmen gehört, die das Most significant byte verändern. Ich weis, dass bei Steganographie das Least Significant byte verändert wird, also das byte das am wenigsten unterschied macht.
Mein Rat an den Topic Starter: poste die Angabe für deine Hausübung 1:1, sonst wird dir hier niemand helfen können.
Zum Vergrößern anklicken....

Schonmal was von Big und Little Endian gehört? Beim Little Endian steht das MSB an der niedrigsten Adresse im Speicher, beim Big Endian an der höchsten Adresse.
 
da's definitiv was faul...
1. dezimal 50 ist hexadezimal 32 -> 6 Bits (0-5)
2. CEE88040 umgedreht ist (0) 4088EEC -> 27 Bits (0-26)
3. Big Endian: 40808ECE -> 31 Bits (0-31)

Daraus folgt, dass es sich nicht mal mit Little- bzw. Big Endian lösen lässt.
Die Beispielergebnisse sehen wirklich sehr nach "hingezaubert" aus. Denke nicht, dass da ein vernünftiger Algo hintersteckt.
 
1. dezimal 50 ist hexadezimal 32 -> 6 Bits (0-5)
Zum Vergrößern anklicken....

das waren alles bereits hexadezimale Werte die ich vorgegeben hab, also 50 hexadezimal!

Ich hab ja gesagt, wie der Algorithmus abläuft.
Den Wert in Bits aufschreiben, also z.B.

50 --> 01010000

und dann von hinten alle Nullen wegmachen, bis die erste 1 kommt!, also

Länge (50) --> 0101, also 4

die Frage ist nur, wie man das als bits darstellen kann und dann alle Nullen abzieht
 
Vllt. in dieser Art?
Java: 
import java.math.BigInteger;

public class HEX_TO_BIN_STRING
{
	public static void main(String[] args)
	{
		// Test mit CEE88040;
		long test = 0xCEE88040L; // long, sonst wird's negativ
		BigInteger bi = BigInteger.valueOf(test);
		System.out.println(bi.toString(16).toUpperCase());
		String bin = bi.toString(2);
		while(bin.length() % 2 != 0) {
			bin = "0" + bin;
		}
		System.out.println(bin);
		int index = bin.length() - 1;
		while(bin.charAt(index) == '0') {
			index--;
		}
		bin = bin.substring(0, index + 1);
		System.out.println(bin + " (" + bin.length() + ")");
		System.out.println();

		// Test mit 50;
		test = 0x50L; // long, sonst wird's negativ
		bi = BigInteger.valueOf(test);
		System.out.println(bi.toString(16).toUpperCase());
		bin = bi.toString(2);
		while(bin.length() % 2 != 0) {
			bin = "0" + bin;
		}
		System.out.println(bin);
		index = bin.length() - 1;
		while(bin.charAt(index) == '0') {
			index--;
		}
		bin = bin.substring(0, index + 1);
		System.out.println(bin + " (" + bin.length() + ")");
	}
}
 
das funktioniert aber leider auch nicht, zumindest nicht bei allen.

Bsp. 0127A1D340 kommt statt 36 28 raus

ich habe gelesen es gibt eine klasse bitset in java, mit welcher man das vielleicht machen könnte, aber wie kriegt man den string überhaupt in die bitset rein (in bits)
 
andreas2505 hat gesagt.:
das funktioniert aber leider auch nicht, zumindest nicht bei allen.

Bsp. 0127A1D340 kommt statt 36 28 raus
Zum Vergrößern anklicken....
Dann erklär' dem lieben Forum doch mal, wie du auf deine Ergebnisse kommst. Sind die etwa vorgegeben? Weil egal, was man nun noch wie dreht, deine Ergebnisse lassen sich iwie nicht berechnen. Auch mit BitSet nicht.
Also ich komme zumindest noch auf 30, wenn ich in meinem Code "% 4" statt "% 2" (Zeilen 12 und 29) schreibe.
 
ja die Ergebnisse sind vorgegeben!

Hab ich doch schon gesagt. Hier nochmal ein paar Werte:

Code: 
Len = 1
Msg = 00

Len = 2
Msg = C0

Len = 3
Msg = C0

Len = 4
Msg = 80

Len = 5
Msg = 48

Len = 6
Msg = 50

Len = 7
Msg = 98

Len = 8
Msg = CC

Len = 9
Msg = 9800

Len = 10
Msg = 9D40

Len = 11
Msg = AA80

Len = 12
Msg = 9830

Len = 13
Msg = 5030

Len = 14
Msg = 4D24

Len = 15
Msg = CBDE

Len = 16
Msg = 41FB

Len = 17
Msg = 4FF400

Len = 18
Msg = FD0440

Len = 19
Msg = 424D00

Len = 20
Msg = 3FDEE0

Len = 21
Msg = 335768

Len = 22
Msg = 051E7C

Len = 23
Msg = 717F8C

Len = 24
Msg = 1F877C

Len = 25
Msg = EB35CF80

so das reicht hoffentlich, damit mir keiner mehr unterstellt, ich denk mir die Werte aus.

Wie die (per Handrechnung für mich) darauf kommen, hab ich ja erklärt. Hier das habe ich noch in einem der Ihrer Paper gefunden, was evtl. helfen könnte.

The bits of the
input message M are numbered from i = 0 to i = |M| - 1. When the bits are gathered in
bytes, it implies the equivalent numbering i = ibit + 8ibyte with 0 <= ibit < 8.
In our internal convention, ibit = 0 indicates the least signi cant bit (LSB) of a byte while
ibit = 7 indicates the most signi cant one (MSB). The NIST convention [2] is di erent: The
bits of a byte are numbered from 0 for the MSB to 7 for the LSB. To be compatible with the
API convention outside and with our convention inside, the following formal bit-reordering
is performed on the input bit string M before it is processed:
For all bytes that contain 8 bits, position ibit+8ibyte is mapped to position 7-ibit+8ibyte.
For the last byte if it contains p < 8 bits, position ibit + 8ibyte is mapped to position
(p - 1) - ibit + 8ibyte.
This mapping is bijective and does not a ect the security.
In practice, the above operation cancels with the change of convention, so there is nothing
to do, except:
For the last byte if it contains p < 8 bits, the bits are shifted by 8-p positions towards
the LSB (i.e., to the "right").
5.2
Zum Vergrößern anklicken....
 
genauso steht es da drin. Keine Ahnung warum...

Ich glaube auch anhand dieser Werte nicht mehr, dass es stimmt, dass man immer nur die Nullen wegnehmen muss, weil das stimmt bei Länge 6 oder 9 ja z.B. auch nicht.
 
also selbst mit der beschreibung da .. ich kann probieren was ich will für manche klappt mein verständnis des algos für manche wieder nicht, änder ich bissel was ab, weil ich glaube es falsch verstanden zu haben, klappts wieder für andere, aber für vorherige nicht mehr .. irgendwie is da echt der wurm drin ^^

mal als bsp:

98 = länge 7 ... 1001 1000 .. so fangen wir an .. da kann ich kreativ sein wie ich will und drehen und machen und shiften, damit es annähernd dem algorithmus ähnelt .. ohne willkür komm ich da nicht auf ne anreihung, die 7 bits füllt. und wenn ich davon ausgehe das mit length vielleicht sogar die position des letzten relevanten bits genannt sei .. dann frag ich mich wie die bei 00 = 0000 0000 auf 1 kommen wollen?!

wie gesagt, man kann es für manche passend hinbekommen aber nicht für alle, so wie ich das hier versucht hab.
 
Zuletzt bearbeitet:
andreas2505 hat gesagt.:
genauso steht es da drin. Keine Ahnung warum...

Ich glaube auch anhand dieser Werte nicht mehr, dass es stimmt, dass man immer nur die Nullen wegnehmen muss, weil das stimmt bei Länge 6 oder 9 ja z.B. auch nicht.
Zum Vergrößern anklicken....

Ist das ein veröffentlichtes Paper? Falls ja, geb mal ne Quelle an. So langsam möchte ich mir das Paper mal ansehen. Das kann doch nicht sein das da so ein Murks bei rumkommt.

Zumindest bei C0 = 2 & C0 = 3 ist den sicherlich ein Fehler unterlaufen.
 
ja bei C0 = 2 oder 3 denk ich is eher n fehler beim aufgabensteller .. das kann so definitiv nicht hinhauen, aber an dem paar sollte man sich nich aufhängen .. gibt ja genug andere wertepaare die es zu knacken gilt
 
Ist das ein veröffentlichtes Paper? Falls ja, geb mal ne Quelle an. So langsam möchte ich mir das Paper mal ansehen. Das kann doch nicht sein das da so ein Murks bei rumkommt.
Zum Vergrößern anklicken....

Ich denke auch, dass genau bei dem einen Beispiel von 2 und 3 ein Fehler vorliegt...
Das ist eine offizielle Datei: The Keccak sponge function family und dort runterladen : Known-answer and Monte Carlo test results version 3.0
und nach dem runterladen auf ShortMsgKAT_egal gehen und da stehen die Werte!

auf der seite sind auch die ganzen anderen paper...
den ausschnitt aus dem einen, wo etwas dazu stand hab ich ja schon gepostet...
 
Siehe auch hier

Ich weiß nicht was an der Formel nicht so ist, wie du das gerne hättest?

Java: 
        int my_string_length = M.length()*4;
        int pos=M.length()-1;
        for(; pos > 0; pos--)
        {
            if(M.charAt(pos)!='0')
                break;
            my_string_length-=4;
        }
        String hexValue = ""+M.charAt(pos);
        int value = Integer.parseInt(hexValue, 16);
        String binValue = Integer.toString(value, 2);
        my_string_length-=(binValue.length()-binValue.lastIndexOf('1')-1);

Ergibt folgende Werte:
Code: 
C0=2
EB35CF80=25
50=4
5030=12

Edit: Ich glaube deine Beispielliste ist falsch:
0x50 = 10010000 => Länge 4
Woher da 6 gesetzte Bit kommen sollen ist mir absolut schleierhaft.
 
Zuletzt bearbeitet:
Ich denke mir ja die Werte nicht aus!!!

Ich weiß ja dass es eigentlich das macht, aber in der Übersicht (die ihr euch ja auch alle mal angucken könnt) sind noch mehr solche Wertepaare wo es nicht hinhaut!!!

Bsp. 17 --> 4FF400
ist ja eigentlich 010011111111010000000000
damit müsste Länge 14 rauskommen


oder 19 --> 424D00
010000100100110100000000
müsste ja eigentlich 16 rauskommen.

Die haben sich ja nicht bei jedem Beispiel verschrieben!!!

Also muss da irgendein anderer "Trick" dahinter stecken, aber ich weiß ihn leider auch nicht.
 
Unglaublich eh!
Anstatt hier die Zeit von so vielen Leuten (+ die, die bisher hier nur gelesenhaben wie ich) zu vergeuden die hier 2 Seiten lang versucht haben aus deinen unvollständigen, falschen und zusammengeratenen Informationen eine sinnvolle Fragestellung und Lösung zu erkennen, hättest du vielleicht erstmal selber ein bisschen recherchieren können was das überhaupt für Daten sind die du hier angibst. Die Datei ShortMsgKAT.txt ist eine Test-Definitionsdatei. Die Daten die dort drin stehen unter "Len" und "Msg" sind die Parameter mit dem der Algorithmus gefüttert wird und nicht irgendwelche Ergebnisse.
Mit "Hexadezimal in Binär umwandeln", oder "Nullen am Ende abschneiden" oder "Bits zählen bis zur letzten 1" hat das ganze auch überhaupt nichts zu tun, der Algorithmus ist schon ein bisschen komplexer...
 
ach ja mister superschlau, dann erklär mir doch mal was die werte für einen sinn ergeben sollen, wenn sie sich denn nicht berechnen lassen.

Natürlich sind das eingabewerte für die Methode, aber die müssen ja auch irgendwie ableitbar und berechenbar sein.

Aber du ja so intelligent bist, kannst du mir und dem forum ja bestimmt auch sagen, was die werte für einen sinn ergeben und wie man sie ermittelt oder einsetzt!!!
 
andreas2505 hat gesagt.:
ach ja mister superschlau, dann erklär mir doch mal was die werte für einen sinn ergeben sollen, wenn sie sich denn nicht berechnen lassen.

Natürlich sind das eingabewerte für die Methode, aber die müssen ja auch irgendwie ableitbar und berechenbar sein.

Aber du ja so intelligent bist, kannst du mir und dem forum ja bestimmt auch sagen, was die werte für einen sinn ergeben und wie man sie ermittelt oder einsetzt!!!
Zum Vergrößern anklicken....

Also jetzt werd mal nicht so unfreundlich. Ich meinem Anonymen Vorposter Recht geben. Du hast eine wirre Aufgabenstellung gepostet und mit der Hilfe sehr vieler wurde so langsam ein Schug draus. Du vorderst hier sehr viel, dafür dass du sehr wenig selbst lieferst.

Deswegen habe ich auch seit dem Anfang nicht mehr gepostet. Das fing schon an mit dem Wirren Thema Titel: Länge eines Strings berechnen. Jetzt sieht man ja, dass das rein gar nichts mit deiner Aufgabe zu tun hatte ...
 
wenn er sich mal alles richtig angeguckt hätte, dann hätte er auch gesehen, dass in den teilweisen Implementierungen auf der Seite bei den Eingabewerten immer steht, dass der String und SEINE Länge übergeben wird (in bits) und damit hat es was miteinander zu tun.

Ich weiß dass ich teilweise sehr verwirrend beschrieben hab was ich gerne hätte, aber das lag daran, dass ich es selber ja nicht genau weiß.
Ich habe auch nur die Werte und weiß, dass ich sie brauche. Und das ich selber nicht viel poste liegt daran, dass ich den ganzen Tag für meine Masterarbeit schreibe und leider dann auch keine Idee habe wie man das lösen kann.

Ich hoffe trotzdem, dass sich vielleicht noch der ein oder andere findet, der mir versucht zu helfen und vielleicht finden wir ja auch irgendeinen Weg wie man darauf nun kommt....
 
Ich weiß nicht wie du auf die Idee kommst dass es einen Zusammenhang zwischen der Länge und der Nachricht geben muss (außer dass Len <= bitAnzahl(Msg) sein muss). Nochmal: Das sind Test Eingabedaten um die Korrektheit eines Algorithmus zu überprüfen, da gibt es nichts zu berechnen oder ermitteln oder einen tieferen Sinn dahinter. Die Testdaten wurden offenbar von der NIST ausgewählt und vorgegeben.
 
Unregistrierter hat gesagt.:
Ich weiß nicht wie du auf die Idee kommst dass es einen Zusammenhang zwischen der Länge und der Nachricht geben muss (außer dass Len <= bitAnzahl(Msg) sein muss). Nochmal: Das sind Test Eingabedaten um die Korrektheit eines Algorithmus zu überprüfen, da gibt es nichts zu berechnen oder ermitteln oder einen tieferen Sinn dahinter. Die Testdaten wurden offenbar von der NIST ausgewählt und vorgegeben.
Zum Vergrößern anklicken....

Die Idee kommt von hier bzw. hier.

Auszug aus dem Python-Code:
Code: 
        """Pad M with reverse-padding to reach a length multiple of n

        M: message pair (length in bits, string of hex characters ('9AFC...')
        n: length in bits (must be a multiple of 8)
        Example: pad([60, 'BA594E0FB9EBBD30'],8) returns 'BA594E0FB9EBBD13'
        """

Gesucht wird der erste Teil des Nachrichtenpaares, ergo die "Länge in Bit".
So wie ich das sehe ist das die Länge des Eingabewortes ohne das Padding durch Bytealignment.
D.h.:
Code: 
(Position der letzten 1 in Binär) <= m <= (Länge des Strings*4)

Beispiele:
Code: 
10110000 -> 10110000 -> B0 (m=8)
1011000  -> 10110000 -> B0 (m=7)
1011     -> 10110000 -> B0 (m=4)
11       -> 11000000 -> C0 (m=2)
110      -> 11000000 -> C0 (m=3)

Das Thema wird irgendwie doppelt diskutiert. Vielleicht sollte man mal einen der beiden Threads dich machen.

Übersetzen Python --> Java
 

Aktuelle Jobs

Neue Themen

Ähnliche Themen

Wie überprüfen ob es sich Hexadezimalzahl handelt?
Antworten: 2
dezimalzahl in hexadezimalzahl umwandeln
Antworten: 14
Dezimal- in Hexadezimalzahl umwandeln
Antworten: 4
Dezimalzahl -> Hexadezimalzahl [Lösungsweg gesucht]
Antworten: 2
Konverter Dualzahl in Hexadezimalzahl
Antworten: 3

Zurück
Oben