Afkodningskæde-decoder

Tekst, der har været igennem mere end én kodningsfunktion, er det normale tilfælde, ikke det eksotiske: en JSON-body inde i et Base64-token, en URL inde i en logbesked, en formularværdi, der blev procent-escaped og derefter Base64-kodet, så den kunne rejse i en header. Denne side pakker disse lag ud ét ad gangen, navngiver teknikken, den brugte i hvert trin, angiver hvor sikker den er og hvorfor, og lister de teknikker, den afviste i det trin, så man kan være uenig med den. Den stopper, når teksten holder op med at ligne kodet tekst, når grænsen for trin nås, eller når næste trin ville bringe tekst tilbage, som den allerede har set. Intet gættes stille: en teknik, hvis alfabet overlapper almindelige ord, anvendes aldrig alene, den tilbydes kun.
Al behandling sker lokalt i browseren — data uploades aldrig til nogen server.

Nyt til dette? Kodningskæder forklaret på almindeligt sprog — hvad et lag er, hvorfor kodning ikke er kryptering, og hvorfor rækkefølgen af trinene betyder noget.
Anvend kun et lag alene, når tilliden er mindst:
Stop efter
Kører lagbegrænsningen ovenfor i ét hug. Den samme tabel bygges under begge, så man kan skifte til trin-for-trin på et hvilket som helst tidspunkt.
Eller vælg en teknik manuelt:
Denne liste er det, siden kan se i teksten lige nu. Rotationschifrene er altid med, fordi de slet ikke kan detekteres; det samme gælder alt, der først bliver genkendeligt, når mellemrum er fjernet fra en indpakket tekst, og det er markeret som sådan og anvendes aldrig alene.
Kodet tekst
Dette input er længere, end denne side normalt kører uden at spørge, og estimatet ovenfor siger, at det kan tage . Klik på Pak hele kæden ud igen for at fortsætte alligevel, eller forkort teksten først.
Det siden ser i teksten lige nu
(skriv eller indsæt først noget)
(kæden vises her)
Hvad er en kodningskæde, og hvorfor behøver den sin egen dekoder?

Et lag er én koder anvendt på tekst. En kæde er to eller flere af dem anvendt efter hinanden. Næsten alle hverdagseksempler ser sådan ud: nogen skal putte et stykke binære data — et billede, et signeret token — ind et sted, der kun bærer tekst, så de Base64-koder det. Det Base64-resultat skal så rejse i en URL, så det procent-escapes. Hele den URL lægges derefter i en logbesked eller en konfigurationsfil, så backslashes eller anførselstegn også escapes. Det, man ser, når man rammer problemet, er det yderste lag, og det er ulæseligt af den simple grund, at de indre lag stadig er påsat.

Enkeltformålsdekodere hjælper ikke med det. En Base64-dekoder, der får JTI2bHQlM0JiJTI2Z3QlM0JoaSUyNmx0JTNCJTJGYiUyNmd0JTNC, vil give et helt korrekt svar, der stadig er ulæseligt, fordi procent-escapes og tegnreferencer stadig ligger ovenpå den tekst, man ville have. Det, man faktisk har brug for, er noget, der afgør på hvert trin, hvilken koder der skal fjernes — og denne side er den beslutning, gjort synlig.

Kodning er ikke kryptering, og denne side knækker ikke noget. Hver teknik på denne side er en offentlig, reversibel måde at skrive den samme information ned på. Base64 har ingen nøgle. Procent-escaping har ingen nøgle. Hvis det inderste lag er krypteret, vil denne side afkode de ydre lag og give chiffertekst, som den siger klart i stedet for at lade som om, det er et resultat. Der er intet her at køre og intet at skjule.
De gennemarbejdede eksempler på denne side

Hver række nedenfor er et ægte input fra denne sides datafil, og den midterste kolonne er det, sidens egen udpakker finder i det. Den sidste kolonne er teksten, der er tilbage, når den stopper.

Hvad inputtet er Fundne lag Input, citeret som det kom Tilbage når den stopper

Disse rækker gengives af siden fra dens egen sagsliste og køres igen ved hvert besøg, så de ikke kan glide væk fra, hvad koden gør. Selvtesten nedenfor kontrollerer hver af dem.

Sådan afgør siden, hvilket lag der skal fjernes
  1. Kig på formen, ikke betydningen. Hver teknik har en signatur — en procent-escape, et lige antal hex-cifre, et alfabet og en længde, der passer til Base64. Siden lister hver teknik, hvis signatur matcher teksten, med en tillid mellem 0 og 1.
  2. Afkod, og tjek derefter, om resultatet er tekst. En teknik er kun værd at anvende, hvis den giver noget læseligt. Hver kandidat køres faktisk, og dens output scores på, hvor meget af det der er udskrivbare tegn.
  3. Anvend kun det, der består kravet, i rækkefølge efter tillid. Kandidaten med højest tillid over tærsklen anvendes, og processen gentages på resultatet. Under tærsklen listes teknikkerne, men anvendes ikke.
  4. En regel, som denne side tilføjer oven i det. Selv når en teknik består tærsklen, anvender denne side den ikke alene, medmindre resultatet er ægte læselig tekst — erstatningstegn og kontroltegn trækker fra. Uden den regel ville det almindelige ord cafe blive gyldigt afkodet som tre bytes, der kun er udskrivbare i Latin-1, og getUserName ville blive gyldigt afkodet som otte bytes støj. Detektoren har ret i, at disse strenge passer til alfabetet; denne side afgør, at det at passe til alfabetet ikke er nok. Det er stadig muligt at anvende dem manuelt, og kandidatlisten fortæller, at den afviste det og hvorfor.
  5. Stop, bevidst. Når ingen teknik består kravet, når teksten holder op med at ændre sig, når grænsen for trin nås, eller når næste trin ville bringe tekst tilbage, som allerede er dukket op i denne kæde. Det sidste betyder noget: ROT13 er sin egen inverse, så en kæde, der tillod det trin to gange, aldrig ville stoppe.
  6. En indpakket tekst tilbydes, anvendes aldrig. Hvis teksten er skåret over flere linjer, ser detektoren mellemrum, læser almindelig prosa og finder intet. Så siden fjerner mellemrummet fra en kopi af teksten, spørger detektoren igen og tilbyder det, den finder, som et trin, der skal vælges manuelt. At fjerne mellemrum fra teksten er en omskrivning af teksten, og denne side omskriver ikke noget, der ikke er bedt om at omskrive.
Hvad siden ikke vil gøre
Den afkoder, og intet andet. Teksten, der indsættes, køres aldrig: ingen eval, ingen new Function, ingen script-injektion, ingen åbning af et dokument. Den sendes aldrig nogen steder: ingen upload, ingen forespørgsel, ingen analyse. Bortset fra annonceplaceringen nederst på siden og rækken med delingsknapper (det er de eneste to tredjepartswidgets, denne side indlæser), hentes ingen skrifttype eller ingen script fra en anden vært. Dekodet output skrives ind på siden som tekst, så et HTML-tag, der kommer ud af et lag, vises som et tag og ikke gøres til et. Det kan kontrolleres: tryk på Selvtest, og den tjekker denne sides egen kildekode for enhver af disse konstruktioner og fejler, hvis den finder en.
Hvad den kan genkende, og hvad den ikke kan
Teknik Hvor sikker, alene Haken

Tekst citeret på denne side er skrevet til denne side. Alfabetterne for Base64, Base32, Base58, Base91 og quoted-printable samt uuencode-blokformatet er de publicerede; afkodningen følger disse definitioner snarere end nogen bestemt værktøjs særheder. Referencevektorer for alfabetterne findes på søstersiderne, som indeholder RFC 4648-testvektorerne.

Tekst, der er brudt over flere linjer

Et blob, der har været igennem en e-mailbesked, en PEM-fil, et token i en header eller en hash kopieret fra en terminal, er normalt indpakket: kodningen brød det ved en fast kolonne — 76 tegn er MIME-konventionen — og satte et linjeskift, hvor kolonnen sluttede. Disse linjeskift er ikke en del af dataene. De findes, så en lang linje overlever transport, og enhver dekoder, der læser sådan et blob, forventes at ignorere dem.

Denne side ignorerer dem ikke af sig selv, og grunden er reglen, den bruger alle andre steder. Mellemrum er det stærkeste enkelte tegn på, at en streng er prosa snarere end data, og det er testen, der forhindrer The quick brown fox jumps over the lazy dog. i at blive læst som noget som helst. Et indpakket blob ser præcis ud som prosa for den test, så siden finder intet i det — og gør så den ærlige halvdel af arbejdet: den regner ud, hvad den ville finde, hvis mellemrummet blev fjernet, lister det i vælgeren for hånd markeret mellemrum ud først, og stopper der. Det er listet frem for anvendt, fordi fjernelse af mellemrum ændrer teksten, og denne side ændrer kun tekst, når den kan bevise, hvad ændringen er. Her kan den bevise, hvad ændringen er, og nægter alligevel at lave den, fordi en tekst med et linjeskift midt i en værdi og en tekst med et linjeskift mellem to felter ser ens ud indefra.

De to trin, når siden stopper på en indpakket tekst. Skift til Gennemgå manuelt, tryk på Anvend det næste lag én gang (det er det, der giver siden en kæde at tilføje til, og det ændrer intet), vælg derefter posten markeret mellemrum ud først og tryk på Anvend den. Rækken, der kommer af, siger, hvor mange mellemrumstegn der blev fjernet, og den angiver sin inputstørrelse som den tekst, der blev indsat, så forskellen mellem de to tal i rækken præcis er det mellemrum, der blev fjernet.

Det samme ræsonnement dækker de tilfælde, der går den anden vej. Et uuencode-blok bærer en begin-linje og et længdetegn på hver linje, så det kan genkendes, som det står, og anvendes alene; en quoted-printable-krop beholder sine egne bløde linjeskift og afkodes af sin egen dekoder, som ved at et enkelt efterstillet = i enden af en linje er en fortsættelse og ikke data. Hvor en formtest ikke kan skelne prosa fra data, afviser siden og viser alternativet i stedet for selv at vælge.

Hvad denne side kører, og hvad den nægter

Tabellen nedenfor er bygget af de samme konstanter, som siden håndhæver, så en række og en advarsel på denne side ikke kan være uenige. De to tal, der overrasker folk, er rækkerne for Base58 og Base62: de to teknikker konverteres med lang division, hvis omkostning vokser med kvadratet af længden, så denne side kører dem kun på en kort streng og siger det i trinnet i stedet for at virke, som om den hænger.

Estimaterne er bevidst pessimistiske. De kommer fra en timing-harness snarere end fra maskinen, og en desktop-browser er normalt flere gange hurtigere end det viste tal.