Bei einer Eingabe eines Strings mit Bytes, die entweder binär, oktal oder hexadezimal sein können, wird das ASCII-Äquivalent des Strings ausgegeben.
Die Eingabe erfolgt beispielsweise im folgenden Format:
501200100001147
welcher ... repräsentiert
0x50 0o120 0b01000011 0x47
Das entspricht (in ASCII)
PPCG
Binär, Oktal und Hex werden immer mit 8, 3 bzw. 2 Ziffern versehen.
Für diese Herausforderung muss nur druckbares ASCII unterstützt werden. Dies ist der Bereich 32..126
inklusive. Daher ist es unmöglich, dass es Mehrdeutigkeiten gibt. Beachten Sie, dass
Ein String steht genau dann für binär, wenn er mit a beginnt
0
und sein zweites Zeichen entweder a0
oder a ist1
. Bei allen druckbaren ASCII-Zeichen ist das High-Bit in Binärform deaktiviert (dh mit a beginnen0
), und keines von ihnen beginnt mit00
oder01
in Hex oder Oktal.Beachten Sie, dass alle druckbaren ASCII-Zeichen mit
2
-7
in hexadezimal und0
-1
in oktal beginnen. Daher ist es auch möglich, eindeutig zwischen hex und oktal zu unterscheiden.
Sie können davon ausgehen, dass die Hex-Eingabe entweder in Klein- oder Großbuchstaben erfolgt, je nachdem, was bequemer ist.
Regex macht den Parsing-Teil der Herausforderung halbtrivial. Ich möchte die Verwendung von Regex nicht sofort verbieten, aber wenn Sie eine Nicht-Regex-Lösung haben, die länger ist als das Gegenstück, das Regex verwendet, können Sie sie trotzdem zusammen mit der "echten" Antwort posten, da ich interessiert wäre um es auch zu sehen. :) :)
Da dies Code-Golf ist , gewinnt der kürzeste Code in Bytes.
Testfälle:
In Out
-----------------------------------
501200100001147 | PPCG
5C01101111100 | \o@
313206306400110101 | 12345
2A200530402C | * + ,
0011111100111111 | ??
<empty string> | <empty string>
0[01]{7}
anstelle von verwenden0[01].{6}
.