Coderingsketen-decoder

Tekst die door meer dan één encoder is gegaan is het normale geval, niet het exotische: een JSON-body in een Base64-token, een URL in een logregel, een formulierwaarde die eerst procentueel is ge-escaped en daarna Base64-gecodeerd zodat hij in een header past. Deze pagina rolt die lagen één voor één af, benoemt bij elke stap de techniek die is gebruikt, toont hoe zeker die is en waarom, en somt de technieken op die hij bij die stap heeft verworpen, zodat u het ermee oneens kunt zijn. Hij stopt wanneer de tekst niet meer gecodeerd lijkt, wanneer hij de stapgrens bereikt, of wanneer de volgende stap tekst terugbrengt die hij al eerder heeft gezien. Er wordt niets stilzwijgend geraden: een techniek waarvan het alfabet overlapt met gewone woorden wordt nooit alleen toegepast, alleen aangeboden.
Alle verwerking gebeurt lokaal in uw browser — uw gegevens worden nooit naar een server geüpload.

Nieuw hiermee? Coderingsketens uitgelegd in gewoon Nederlands — wat een laag is, waarom codering geen versleuteling is, en waarom de volgorde van de stappen ertoe doet.
Pas een laag alleen toe wanneer de zekerheid ten minste is:
Stop na
Voert de hierboven ingestelde lagenlimiet in één keer uit. Dezelfde tabel wordt in beide gevallen opgebouwd, dus u kunt op elk moment overschakelen naar stap-voor-stap.
Of kies handmatig een techniek:
Deze lijst is wat de pagina nu in de tekst kan zien. De rotatie-ciphers staan er altijd in, omdat ze helemaal niet kunnen worden gedetecteerd; ook alles dat pas herkenbaar wordt wanneer de witruimte uit een afgebroken tekst is gehaald, staat erin, en dat is als zodanig gemarkeerd en wordt nooit alleen toegepast.
Gecodeerde tekst
Deze invoer is langer dan deze pagina graag zonder te vragen uitvoert, en de schatting hierboven zegt dat het kan duren. Klik nogmaals op De hele keten afrollen om toch door te gaan, of kort de tekst eerst in.
Wat de pagina nu in de tekst ziet
(typ of plak eerst iets)
(de keten verschijnt hier)
Wat is een coderingsketen, en waarom heeft die een eigen decoder nodig?

Een laag is één encoder toegepast op tekst. Een keten is twee of meer van die encoders die na elkaar worden toegepast. Bijna elk alledaags voorbeeld ziet er zo uit: iemand moet een stuk binaire gegevens — een afbeelding, een ondertekend token — in een plek stoppen die alleen tekst draagt, dus codeert die het in Base64. Dat Base64-resultaat moet dan in een URL reizen, dus wordt het procentueel ge-escaped. Die hele URL komt dan in een logregel of een configuratiebestand, dus worden de backslashes of de aanhalingstekens ook ge-escaped. Wat u ziet wanneer u het probleem tegenkomt is de buitenste laag, en die is onleesbaar om de eenvoudige reden dat de binnenste lagen er nog op zitten.

Decoders met één doel helpen daarbij niet. Een Base64-decoder die JTI2bHQlM0JiJTI2Z3QlM0JoaSUyNmx0JTNCJTJGYiUyNmd0JTNC krijgt, levert een perfect correct antwoord dat nog steeds onleesbaar is, omdat de procentuele escapes en de tekenverwijzingen er nog bovenop zitten bij de tekst die u wilde. Wat u werkelijk nodig hebt is iets dat bij elke stap beslist welke encoder eraf moet — en deze pagina is die beslissing, zichtbaar gemaakt.

Codering is geen versleuteling, en deze pagina breekt niets. Elke techniek op deze pagina is een openbare, omkeerbare manier om dezelfde informatie op te schrijven. Base64 heeft geen sleutel. Procentuele escaping heeft geen sleutel. Als de binnenste laag versleuteld is, decodeert deze pagina de buitenste lagen en geeft u de cijfertekst, wat hij duidelijk zegt in plaats van te doen alsof het een resultaat is. Er is hier niets om uit te voeren en niets om te verbergen.
De uitgewerkte voorbeelden op deze pagina

Elke rij hieronder is een echte invoer uit het gegevensbestand van deze pagina, en de middelste kolom is wat de eigen unwinder van de pagina erin vindt. De laatste kolom is de tekst die overblijft wanneer hij stopt.

Wat de invoer is Gevonden lagen Invoer, geciteerd zoals hij binnenkwam Overgebleven bij stoppen

Deze rijen worden door de pagina weergegeven vanuit de eigen caselijst en bij elk bezoek opnieuw uitgevoerd, zodat ze niet kunnen afwijken van wat de code doet. De zelftest hieronder controleert elk ervan.

Hoe de pagina bepaalt welke laag eraf gaat
  1. Kijk naar de vorm, niet naar de betekenis. Elke techniek heeft een kenmerk — een procentuele escape, een even reeks hexadecimale cijfers, een alfabet en een lengte die bij Base64 passen. De pagina somt elke techniek op wier kenmerk bij de tekst past, met een zekerheid tussen 0 en 1.
  2. Decodeer, en controleer daarna of het resultaat tekst is. Een techniek is alleen de moeite waard als ze iets leesbaars oplevert. Elke kandidaat wordt werkelijk uitgevoerd, en de uitvoer wordt gescoord op hoeveel afdrukbare tekens erin zitten.
  3. Pas alleen toe wat de lat haalt, in volgorde van zekerheid. De kandidaat met de hoogste zekerheid boven uw drempel wordt toegepast, en het proces herhaalt zich op het resultaat. Onder de drempel worden technieken weergegeven maar niet toegepast.
  4. Eén regel die deze pagina daarbovenop toevoegt. Zelfs wanneer een techniek de drempel haalt, past deze pagina haar niet alleen toe tenzij het resultaat werkelijk leesbare tekst is — vervangingstekens en besturingstekens tellen er tegen. Zonder die regel zou het gewone woord cafe geldig worden gedecodeerd als drie bytes die alleen in Latijn-1 afdrukbaar zijn, en getUserName als acht bytes ruis. De detector heeft gelijk dat die strings in het alfabet passen; deze pagina bepaalt dat in het alfabet passen niet genoeg is. U kunt ze nog steeds met de hand toepassen, en de kandidatenlijst vertelt u dat hij het heeft geweigerd en waarom.
  5. Stop, bewust. Wanneer geen enkele techniek de lat haalt, wanneer de tekst niet meer verandert, wanneer de stapgrens is bereikt, of wanneer de volgende stap tekst zou terugbrengen die al in deze keten is verschenen. Dat laatste is belangrijk: ROT13 is zijn eigen inverse, dus een keten die die stap twee keer mag nemen zou nooit eindigen.
  6. Een afgebroken tekst wordt aangeboden, nooit toegepast. Als de tekst over meerdere regels is verdeeld, ziet de detector witruimte, leest gewone proza en vindt niets. Dus haalt de pagina de witruimte uit een kopie van de tekst, vraagt de detector opnieuw, en biedt wat hij vindt aan als een stap die met de hand moet worden gekozen. De witruimte uit uw tekst halen is een herschrijving van uw tekst, en deze pagina herschrijft niets dat u niet hebt gevraagd.
Wat deze pagina niet doet
Het decodeert, en verder niets. De tekst die u plakt wordt nooit uitgevoerd: geen eval, geen new Function, geen scriptinjectie, geen document openen. Hij wordt nooit ergens naartoe gestuurd: geen upload, geen verzoek, geen analyse. Behalve het advertentievak onderaan de pagina en de rij met deelknoppen (dat zijn de enige twee externe widgets die deze pagina laadt), wordt geen lettertype of script van een andere host opgehaald. Gedecodeerde uitvoer wordt als tekst op de pagina geschreven, dus een HTML-tag die uit een laag komt wordt als tag weergegeven in plaats van er een te worden. U kunt dat allemaal controleren: druk op Zelftest en die controleert de eigen broncode van deze pagina op een van die constructies en faalt als hij er een vindt.
Wat hij kan herkennen, en wat niet
Techniek Hoe zeker, op zichzelf De adder

Tekst die op deze pagina wordt geciteerd is voor deze site geschreven. De alfabetten van Base64, Base32, Base58, Base91 en quoted-printable en het uuencode-blokformaat zijn de gepubliceerde; het decoderen volgt die definities en niet de eigenaardigheden van een bepaalde tool. Referentievectoren voor de alfabetten staan op de zusterpagina's, die de RFC 4648-testvectoren bevatten.

Tekst die over meerdere regels is verdeeld

Een blob die door een e-mailbericht, een PEM-bestand, een token in een header of een hash die uit een terminal is geplakt is gegaan, is meestal afgebroken: de encoder heeft hem op een vaste kolom gebroken — 76 tekens is de MIME-conventie — en heeft een regeleinde gezet waar de kolom eindigde. Die regeleindes horen niet bij de gegevens. Ze bestaan zodat een lange regel het transport overleeft, en elke decoder die zo'n blob leest moet ze negeren.

Deze pagina negeert ze niet op eigen houtje, en de reden is de regel die hij overal anders gebruikt. Witruimte is het sterkste afzonderlijke teken dat een tekenreeks proza is in plaats van gegevens, en dat is de toets die voorkomt dat The quick brown fox jumps over the lazy dog. als iets wordt gelezen. Een afgebroken blob ziet er voor die toets precies uit als proza, dus de pagina vindt er niets in — en doet dan het eerlijke deel van het werk: hij berekent wat hij zou vinden als de witruimte eruit was, zet dat in de handmatige keuzelijst met het label eerst witruimte eruit, en stopt daar. Het wordt vermeld in plaats van toegepast omdat witruimte verwijderen uw tekst verandert, en deze pagina verandert alleen tekst wanneer hij kan bewijzen wat de wijziging is. Hier kan hij dat bewijzen, en toch weigert hij het voor u te doen, omdat een tekst met een regeleinde midden in een waarde en een tekst met een regeleinde tussen twee velden van binnenuit hetzelfde eruitzien.

De twee stappen wanneer de pagina stopt bij een afgebroken tekst. Schakel over naar Stap voor stap met de hand, druk eenmaal op Pas de volgende laag toe (dat geeft de pagina een keten om aan toe te voegen, en het verandert niets), kies daarna het item met het label eerst witruimte eruit en druk op Pas toe. De rij die eraf komt zegt hoeveel witruimtetekens zijn verwijderd, en meldt zijn invoergrootte als de tekst die u heeft geplakt, zodat het verschil tussen de twee getallen in die rij precies de witruimte is die eruit is gehaald.

Dezelfde redenering geldt voor de gevallen die de andere kant op gaan. Een uuencode-blok heeft op elke regel een begin-regel en een lengteteken, dus het is als zodanig herkenbaar en wordt op zichzelf toegepast; een quoted-printable-body houdt zijn eigen zachte regeleinden en wordt door zijn eigen decoder gedecodeerd, die weet dat een enkel afsluitend = aan het eind van een regel een voortzetting is en geen gegevens. Waar een vormtest proza niet van gegevens kan onderscheiden, weigert de pagina en laat hij u het alternatief zien in plaats van voor u te kiezen.

Wat deze pagina uitvoert, en wat hij weigert

De onderstaande tabel is opgebouwd uit dezelfde constanten die de pagina afdwingt, zodat een rij en een waarschuwing op deze pagina elkaar niet kunnen tegenspreken. De twee cijfers die mensen verrassen zijn de rijen Base58 en Base62: die twee technieken worden omgezet met lange deling waarvan de kosten kwadratisch met de lengte groeien, dus deze pagina draait ze alleen op een korte tekenreeks en zegt dat in de stap, in plaats van te lijken vast te lopen.

De schattingen zijn bewust pessimistisch. Ze komen uit een timingharnas en niet uit uw computer, en een desktopbrowser is meestal meerdere keren sneller dan het getoonde cijfer.