Gray-Code-Konverter

Nichtbinäre Eingaben scheitern mit einem klaren invalid_input-Fehler, statt stillschweigend Müllziffern abzuschneiden.

Was reflektierter Gray-Code ist und welche Eingaben gültig sind

Die Aliasse bits, binary und n werden akzeptiert, wenn Ihr Formular oder SDK das Feld bereits so etikettiert. Die Richtung muss binary_to_gray oder to_gray zum Kodieren und gray_to_binary oder from_gray zum Dekodieren sein; die Aliasse dir und mode wirken gleich. Gleitkommawerte, negative Zahlen, leere Zeichenketten und gemischter Text, der keine Binärziffern ist, scheitern mit invalid_input, weil dieses Produkt eine exakte Ganzzahlumwandlung verspricht, keine Näherung. Identische Eingaben erzeugen stets identisches JSON: Es gibt keinen Netzwerkaufruf, keinen Zufalls-Seed und keine Wanduhr auf dem Pfad.

Antwortfelder lesen und gängige Ergebnisse von Hand prüfen

Schnellchecks schaffen Vertrauen: Binär eins null eins eins kodiert zu Gray eins eins eins null; Gray null eins eins eins dekodiert zurück zu Binär null eins null eins; Binär null mappt auf Gray null; ein dreistelliges Binär eins null null wird Gray eins eins null. Weil jeder Schritt XOR auf diskreten Bits ist, driften Ergebnisse nie so, wie Gleitkomma-Tricks bei großen Eingaben es tun würden. Bei Erfolg spiegelt die Antwort value als die ursprüngliche Bitkette oder die sichere Ganzzahl, die Sie gesendet haben, direction als die kanonische binary_to_gray- oder gray_to_binary-Bezeichnung, bits_in als die normalisierte Eingabekette mit höchstwertigem Bit zuerst und bits_out als die umgewandelte Kette, die Sie typischerweise für Anzeige, Bewerter und Encoder-Dokumentation wollen. integer_in und integer_out interpretieren diese Bitketten als nichtnegative Ganzzahlen, wenn die Größe in eine sichere JSON-Zahl passt, oder als dezimale Ziffernketten, wenn sie größer ist, sodass Pipelines beide Formen prüfen können. bit_width meldet die Länge von bits_in, und method ist stets reflected_gray, damit nachgelagerter Code verzweigen kann, ohne Formen zu erschnüffeln. Fehlendes value, fehlende direction, nichtbinäre Ketten, nicht unterstützte Richtungsbezeichnungen und übermäßige Bitbreiten scheitern alle mit invalid_input und werden nach Ablehnung der Validierung nicht berechnet. Verwenden Sie bits_out allein, wenn ein Mensch oder Bericht eine einzelne Zeile braucht; verwenden Sie das volle Objekt, wenn automatisierte Prüfer Richtung, Breite und Methode neben der Ziffernkette prüfen müssen.

API-Nutzung, Preise, Unterrichtsabläufe und praktische Grenzen

Rufen Sie den kostenlosen Gray-Code-Konverter im Browser für Hausaufgabenprüfungen, Vorlesungsdemos, Drehgeber-Labore und schnelle Verifikation auf, ohne ein Wegwerfskript zu schreiben. Bevorzugen Sie unterrichtstaugliche Breiten für benotete Orakel und halten Sie die Bitlänge innerhalb der veröffentlichten Obergrenze für Isolatsicherheit. Senden Sie einen JSON-Körper mit den Pflichtfeldern value und direction, oder nutzen Sie die dokumentierten Aliasse, wenn Ihr Client sie bereits anders benennt. Nutzen Sie die vorausbezahlte API, wenn eine Tutorenplattform, eine Coding-Assessment-Sandbox, eine Firmware-Toolchain oder ein Dokumentationsgenerator einen stabilen Vertrag unter KIT-Guthaben zu $0.002 pro erfolgreichem Element braucht; Validierungsfehler verbrauchen nie Guthaben. Kombinieren Sie diesen Endpoint mit binären oder hexadezimalen Formatierern, wenn eine Lektion mehrere Kodierungen durchläuft, oder mit Wahrheitstabellen- und Karnaugh-Werkzeugen, wenn Lernende Gray-Adjazenz mit Ein-Bit-Übergängen verbinden. Autoren, die SDKs ausliefern, können bits_out direkt in UI-Beschriftungen, CLI-Flags oder generierte Kommentare mappen, die die Gray-Form neben der originalen Binärkonstante zeigen.