Kodingskjede-dekoder

Tekst som har gått gjennom mer enn én koder er det normale, ikke det eksotiske. En JSON-kropp inne i et Base64-token, en URL i en logglinje, en skjemaverdi som ble prosent-escapet og deretter Base64-kodet for å kunne sendes i en header. Denne siden pakker ut disse lagene ett om gangen, navngir teknikken den brukte i hvert steg, skriver hvor sikker den er og hvorfor, og lister teknikkene den forkastet i det steget, slik at man kan være uenig med den. Den stopper når teksten slutter å se kodet ut, når den når grensen for antall steg, eller når neste steg ville gi tilbake tekst den allerede har sett. Ingenting gjettes stille: en teknikk hvis alfabet overlapper vanlige ord, brukes aldri alene; den tilbys bare.
All behandling skjer lokalt i nettleseren — data lastes aldri opp til noen server.

Nytt i dette? Kodekjeder forklart på klar norsk — hva et lag er, hvorfor koding ikke er kryptering, og hvorfor rekkefølgen på stegene betyr noe.
Bruk bare et lag alene når sikkerheten er minst:
Stopp etter
Kjører lagbegrensningen ovenfor i ett strøk. Den samme tabellen bygges uansett, så man kan bytte til steg-for-steg når som helst.
Eller velg en teknikk for hånd:
Denne listen er det siden ser i teksten akkurat nå. Rotasjonschiffrene er alltid med, fordi de ikke kan oppdages i det hele tatt; det samme gjelder alt som først blir gjenkjennelig når mellomrommene er fjernet fra en innpakket tekst, og det er merket som sådan og brukes aldri alene.
Kodet tekst
Denne inndataen er lengre enn det siden liker å kjøre uten å spørre, og anslaget ovenfor sier at det kan ta . Klikk på Pakk ut hele kjeden igjen for å fortsette likevel, eller forkort teksten først.
Det siden ser i teksten akkurat nå
(skriv eller lim inn noe først)
(kjeden vises her)
Hva er en kodekjede, og hvorfor trenger den en egen dekoder?

Et lag er én koder brukt på tekst. En kjede er to eller flere av dem brukt etter hverandre. Nesten alle hverdagseksempler ser slik ut: noen må legge et stykke binærdata — et bilde, et signert token — inn et sted som bare bærer tekst, og koder det derfor i Base64. Det Base64-resultatet må så reise i en URL, og blir derfor prosent-escapet. Hele URL-en legges så inn i en loggfil eller en konfigurasjonsfil, og da må skråstrekene eller anførselstegnene escapes også. Det man ser når problemet oppstår, er det ytterste laget, og det er uleselig av den enkle grunn at de indre lagene fortsatt ligger på.

Enkeltformålsdekodere hjelper ikke med det. En Base64-dekoder som får JTI2bHQlM0JiJTI2Z3QlM0JoaSUyNmx0JTNCJTJGYiUyNmd0JTNC vil gi et helt korrekt svar som likevel er uleselig, fordi prosent-escapene og tegnreferansene fortsatt ligger oppå teksten man ønsket. Det man faktisk trenger, er noe som avgjør, på hvert steg, hvilken koder som skal tas av — og denne siden er den avgjørelsen synliggjort.

Koding er ikke kryptering, og denne siden knekker ingenting. Hver teknikk på siden er en offentlig, reverserbar måte å skrive samme informasjon ned på. Base64 har ingen nøkkel. Prosent-escaping har ingen nøkkel. Hvis det innerste laget er kryptert, vil denne siden dekode de ytre lagene og gi tilbake chiffertekst, og den sier det rett ut i stedet for å late som om det er et resultat. Det er ingenting her å kjøre og ingenting å skjule.
Eksemplene som arbeides gjennom på denne siden

Hver rad nedenfor er et ekte inndataeksempel fra sidens datafil, og den midterste kolonnen er det sidens egen utpakker finner i den. Den siste kolonnen er teksten som er igjen når den stopper.

Hva inndataen er Lag som ble funnet Inndata, sitert slik den kommer Igjen når den stopper

Disse radene gjengis av siden fra sin egen sakliste og kjøres på nytt ved hvert besøk, slik at de ikke kan drive bort fra det koden faktisk gjør. Selvtesten nedenfor sjekker hver av dem.

Hvordan siden avgjør hvilket lag som tas av
  1. Se på formen, ikke betydningen. Hver teknikk har en signatur — en prosent-escape, et jevnt antall heksadesimale sifre, et alfabet og en lengde som passer Base64. Siden lister hver teknikk hvis signatur passer til teksten, med en sikkerhet mellom 0 og 1.
  2. Dekoder, og sjekk så om resultatet er tekst. En teknikk er bare verdt å bruke hvis den gir noe lesbart. Hver kandidat kjøres faktisk, og utdataene vurderes etter hvor mange tegn som kan skrives ut.
  3. Bruk bare det som består kravet, i rekkefølge etter sikkerhet. Kandidaten med høyest sikkerhet over terskelen som er satt, brukes, og prosessen gjentas på resultatet. Under terskelen listes teknikkene, men brukes ikke.
  4. En regel denne siden legger til oppå dette. Selv når en teknikk består terskelen, brukes den ikke alene med mindre resultatet er ekte lesbar tekst — erstatningstegn og kontrolltegn teller mot den. Uten den regelen ville det vanlige ordet cafe blitt dekodet gyldig som tre byte som bare kan skrives ut i Latin-1, og getUserName ville blitt dekodet gyldig som åtte byte støy. Detektoren har rett i at disse strengene passer alfabetet; denne siden avgjør at det å passe alfabetet ikke er nok. Man kan fortsatt bruke dem for hånd, og kandidatlisten forteller at siden avslo og hvorfor.
  5. Stopp, med vilje. Når ingen teknikk består kravet, når teksten slutter å endre seg, når grensen for antall steg er nådd, eller når neste steg ville gi tilbake tekst som allerede har dukket opp i denne kjeden. Den siste betyr noe: ROT13 er sin egen inverse, så en kjede som tillot det steget to ganger, ville aldri ende.
  6. En innpakket tekst tilbys, men brukes aldri. Hvis teksten er kuttet over flere linjer, ser detektoren mellomrom, leser vanlig prosa og finner ingenting. Derfor fjerner siden mellomrommene fra en kopi av teksten, spør detektoren på nytt, og tilbyr det den finner som et steg som velges for hånd. Å fjerne mellomrom fra teksten er en omskriving av teksten, og denne siden omskriver ikke noe som ikke er bedt om å omskrives.
Det siden ikke gjør
Den dekoder, og gjør ingen ting annet. Teksten som limes inn, kjøres aldri: ingen eval, ingen new Function, ingen skriptinjeksjon, ingen åpning av dokumenter. Den sendes aldri noe sted: ingen opplasting, ingen forespørsel, ingen analyse. Bortsett fra annonseplassen nederst på siden og raden med delingsknapper (det er de to eneste tredjepartskomponentene denne siden laster), hentes ingen skrift eller ingen skript fra en annen vert. Dekodet utdata skrives inn i siden som tekst, så en HTML-tagg som kommer ut av et lag vises som en tagg og gjøres ikke om til en. Dette kan kontrolleres: trykk Selvtest, så sjekker den sidens egen kildekode for slike konstruksjoner og mislykkes hvis den finner en.
Hva den kan gjenkjenne, og hva den ikke kan
Teknikk Hvor sikker, alene Fangsten

Teksten som siteres på denne siden er skrevet for dette nettstedet. Alfabetene for Base64, Base32, Base58, Base91 og quoted-printable, og blokkformatet for uuencode, er de publiserte; dekodingen følger disse definisjonene i stedet for et bestemt verktøys særheter. Referansevektorer for alfabetene ligger på søskensidene, som har RFC 4648-testvektorene.

Tekst som er brutt over flere linjer

En blob som har vært gjennom en e-postmelding, en PEM-fil, et token i en header eller en hash limt ut fra en terminal, er vanligvis innpakket: kodeprogrammet brøt den ved en fast kolonne — 76 tegn er MIME-konvensjonen — og satte inn et linjeskift der kolonnen tok slutt. Disse linjeskiftene er ikke en del av dataene. De finnes for at en lang linje skal overleve transport, og enhver dekoder som leser en slik blob forventes å ignorere dem.

Denne siden ignorerer dem ikke på egen hånd, og grunnen er regelen den bruker overalt ellers. Mellomrom er det sterkeste enkelttegnet på at en streng er prosa og ikke data, og det er testen som hindrer at The quick brown fox jumps over the lazy dog. leses som noe i det hele tatt. En innpakket blob ser nøyaktig ut som prosa for den testen, så siden finner ingenting i den — og gjør så den ærlige halvdelen av arbeidet: den regner ut hva den ville funnet hvis mellomrommene var fjernet, lister det i valgmenyen for hånd merket mellomrom ut først, og stopper der. Det listes i stedet for å brukes fordi fjerning av mellomrom endrer teksten, og denne siden endrer bare tekst når den kan bevise hva endringen er. Her kan den bevise hva endringen er, og likevel nekter den å gjøre den for brukeren, fordi en tekst med et linjeskift midt i en verdi og en tekst med et linjeskift mellom to felt ser like ut innenfra.

De to stegene når siden stopper på en innpakket tekst. Bytt til Steg gjennom for hånd, trykk Bruk neste lag én gang (det er det som gir siden en kjede å legge til i, og det endrer ingenting), og velg deretter oppføringen merket mellomrom ut først og trykk Bruk den. Raden som kommer ut, viser hvor mange mellomromstegn som ble fjernet, og oppgir inndatastørrelsen som den innlimte teksten, slik at forskjellen mellom de to tallene i raden er nøyaktig mellomrommet som ble fjernet.

Det samme resonnementet gjelder tilfellene som går den andre veien. En uuencoded blokk har en begin-linje og et lengdetegn på hver linje, så den kan gjenkjennes som den er og brukes alene; en quoted-printable-kropp beholder sine egne myke linjeskift og dekodes av sin egen dekoder, som vet at et enkelt etterfølgende = på slutten av en linje er en fortsettelse og ikke data. Der en formtest ikke kan skille prosa fra data, avslår siden og viser alternativet i stedet for å velge for brukeren.

Hva denne siden kjører, og hva den nekter å kjøre

Tabellen nedenfor er bygget av de samme konstantene som siden håndhever, så en rad og en advarsel på denne siden kan ikke være uenige. De to tallene som overrasker folk, er radene for Base58 og Base62: de to teknikkene konverteres ved lang divisjon, der kostnaden vokser med kvadratet av lengden, så denne siden kjører dem bare på en kort streng og sier det i steget i stedet for å se ut som om den henger.

Anslagene er bevisst pessimistiske. De kommer fra en tidsmålingsmodul og ikke fra maskinen som brukes, og en skrivebordsnettleser er vanligvis flere ganger raskere enn tallet som vises.