ich finde es nicht nett mir asci2 gestern als vierstellige 0 und 1 folge zu praesentieren, ein bisle habt ihr drei mich gestern schon verarscht
Macht Sinn – dann bleibst du bei deinem bewährten Muster und musst keine krumme 7-Bit-Sonderlogik einbauen. Kurz durchgerechnet, ob das sauber aufgeht:
Ein Byte (8 Bit) lässt sich exakt in zwei Nibbles (je 4 Bit) teilen – High-Nibble und Low-Nibble. Jedes Nibble deckt 0000 bis 1111 ab, also genau den Bereich, den du schon über deine Uhrzeit-Ablesung (0–15, "Null Uhr X") beherrschst. Praktisch liest du dann pro Zeichen zwei Uhrzeiten hintereinander ab, z.B. für ein Byte 01000001 (das ist "A" in Extended ASCII/Latin-1, identisch mit Standard-ASCII an der Stelle):
High-Nibble: 0100 → "Null Uhr 4" → 4
Low-Nibble: 0001 → "Null Uhr 1" → 1
Zusammen: 4 und 1 → hex 41 → dezimal 65 → "A"
Das Verfahren skaliert sauber auf alle 256 Zeichen, weil hex ja ohnehin genau danach aufgebaut ist (zwei Hex-Ziffern = ein Byte = zwei Nibbles). Du liest im Grunde direkt den Hex-Wert über deine Uhr ab, ohne dass du das Wort "Hex" dafür brauchst.
Einziger Punkt, den du im Kopf behalten musst: die zweite Hälfte der Tabelle (128–255) ist nicht mehr genormtes ASCII, sondern hängt von der gewählten Kodierung ab (Latin-1, Windows-1252, etc. – die unterscheiden sich in diesem Bereich). Falls du dir also 256 Zeichen "die" Extended-Version einprägst, lohnt sich ein Blick, welche Zeichentabelle du dabei genau lernst, sonst passt das obere Byte-Nibble später nicht zu jeder Software/Datei, die du damit lesen willst.
ich weis nichtmal was das wort "hex" bedeutet und bei dezimal nur das des halt immer in 0 und 1 endet oder?
Kurze Klarstellung, bevor sich da was Falsches festsetzt: Dezimal endet nicht "immer in 0 und 1" – das verwechselst du wahrscheinlich mit Binär. Die drei Systeme kurz nebeneinander:
Dezimal (das normale Zählsystem, das du täglich nutzt): 10 Ziffern, 0 bis 9. Beispiel: 65.
Binär: nur 2 Ziffern, 0 und 1. Das ist das, was du bei deinen Uhrzeiten abliest – jede Stelle ist entweder 0 oder 1, nichts dazwischen. Beispiel: 1000001 (= 65 dezimal).
Hexadezimal ("Hex"): 16 Ziffern/Zeichen – 0 bis 9, und dann geht's weiter mit A, B, C, D, E, F für die Werte 10 bis 15. Beispiel: 41 (= 65 dezimal). Der Grund, warum Hex bei Bytes so praktisch ist: eine Hex-Ziffer deckt genau 0–15 ab, also genau ein Nibble (4 Bit) – exakt der Bereich, den du schon über deine Uhr abliest. Deshalb passt "Uhr ablesen" so gut zu Hex: jede Uhrzeit-Ablesung (0–15) ist automatisch eine Hex-Ziffer, du nennst sie nur nicht so.
Schau nochmal auf deine Tabelle, dritte Spalte (z.B. "41" bei A): das ist genau dieser Hex-Wert, zwei Ziffern, eine pro Nibble. Die zweite Spalte davor (dezimal, z.B. "65") ist die normale Zählweise. Du brauchst das Wort "Hex" nicht zu benutzen, wenn du nicht willst – aber wenn du deine zwei Uhrzeiten pro Byte abliest, produzierst du technisch gesehen genau diese Hex-Zahl, egal wie du sie nennst.
des sagt mir gerade der doktor google, das die zweite haelfte NICHT einheitlich genormt ich, nun ich bin deutscher geistig behinderter, aber zu deutsch, ^^ als das ich damit dann was anfangen kann also back to se ruuuts ^^ und wieder auf die 128 zeichen, die extra 0 oder 1, denke ich mir einfahc dazu, das bedeutet, ich schreibe die dorthin, wo sie sowieso hin soll und ich vermute mal das die dann hinten dran gehoert???
Guter Instinkt, dass du zurück zu den 128 willst, wenn die zweite Hälfte eh nicht einheitlich ist – spart dir späteren Ärger. Aber bei der Platzierung der Extra-Stelle muss ich dir widersprechen, sonst kippt dir später jede Ableseübung.
Die zusätzliche 0 kommt vorne dran, nicht hinten. Grund: Bei Binärzahlen hat jede Position einen festen Wert – ganz rechts ist die 1er-Stelle, dann 2er, 4er, 8er, 16er, 32er, 64er, und die achte Stelle (ganz links) wäre die 128er-Stelle. Deine 7-Bit-Zahlen nutzen diese 128er-Stelle nie (weil dein höchster Wert 127 ist), deshalb ist sie bei dir immer 0. Wenn du die 0 stattdessen hinten anhängst, veränderst du den Wert der Zahl komplett – du würdest quasi eine 1er-Stelle einschieben, wo keine hingehört, und alles verschiebt sich.
Konkretes Beispiel mit "A" aus deiner Tabelle:
Original 7-Bit: 1000001 (= 65, "A")
Richtig (0 vorne): 01000001 → immer noch 65, "A" ✓
Falsch (0 hinten): 10000010 → das wäre 130, ein ganz anderes Zeichen
Für dein Uhr-System heißt das: die vordere, zusätzliche Stelle gehört ins erste Nibble mit rein (die erste "Uhrzeit" liest du dann aus einer 0 plus den ersten 3 der ursprünglichen 7 Bit ab), die zweite Uhrzeit bleibt wie gehabt die hinteren 4 Bit unverändert. Willst du das nochmal am Beispiel "A" durchgehen, wie das an deiner Uhr-Ablesung genau aussieht?
sehr gut ich hatte naemlich gehofft, das es immer die 0 ist und das ich sie vorne dran machen kann, statt hinten als preufsumme oder so verzeihe meine kindliche art das zu lernen, aber dann ist es auch wieder einfahcer, ich zerteile dann also ine fuer mich immer 8 stellige 0 und 1 folge in zwei haelften in der mitte, mache ich die auseinander, dann, kommt in die mitte der beiden mitten ein doppelpunkt, der zerlegt das wiederum in eine eindeutige uhrzeit. ich brauche auch nicht soooo viele zeichen 128 scheinen ganz schoen viele moeglichkeiten zu sein, die ich nicht sehe in meiner verwendung, aber ich will ja kommunizieren, vermutlich in den programmen mit dem nutzer, ergo, solte ich das mal so belassen, findest du jetzt noch denkfehler allgemein erstmal? Das muss ja sauber gelernt werden dann klappt es auch der anfang war ja nicht schlecht gestern auf heute habe ich das gelernt
Thought for 6s
Dein Verfahren ist technisch sauber: 8 Stellen, in der Mitte halbieren, Doppelpunkt einfügen, jede Hälfte als eigene Uhrzeit lesen – das ist exakt die Nibble-Aufteilung, die wir vorhin durchgerechnet haben, nur mit deinem eigenen Trennzeichen-Trick. Kein Denkfehler in der Grundmethode.
Eine Sache solltest du aber wissen, damit du beim Lernen nicht verwirrt bist: Wenn du bei den 128 Zeichen bleibst (also die vordere Extra-Stelle immer 0 ist), dann kann deine erste Uhrzeit (das linke Nibble) nie den vollen Bereich 0–15 erreichen. Weil die führende Stelle fest auf 0 steht, bewegt sich die erste Uhrzeit nur zwischen 0000 und 0111, also 0 bis 7 – nie 8 bis 15. Die zweite Uhrzeit (rechtes Nibble) dagegen deckt den vollen Bereich 0–15 ab. Schau z.B. bei "z" in deiner Tabelle (1111010): geteilt wäre das 0111:1010 → erste Uhrzeit 7, zweite Uhrzeit 10. Die erste Zahl wird also bei dir immer kleiner/gleich 7 sein – das ist kein Fehler, nur eine Eigenheit, die du dir merken solltest, damit du nicht denkst, du hättest dich verlesen, wenn die erste "Uhr" nie über 7 hinausgeht.
Sonst: Ansatz stimmt, Grundlage ist stabil. Von 0 auf ein funktionierendes eigenes Kodierschema an einem Tag ist ein ordentliches Tempo.