En Base64-verdi kan inneholde +, / og =. En parser for spørringsstrenger kan tolke et rått + som mellomrom. Å erstatte tegn tilfeldig kan skjule den opprinnelige feilen.
Bruk et ufarlig eksempel, aldri et ekte passord, token eller en personlig oppføring. UTF-8-teksten a?b kodes som YT9i. Det første eksemplet kontrollerer konverteringen begge veier, men inneholder ikke de vanskelige tegnene. En egen bokstavelig testverdi, a+b/c=, er nyttig for å kontrollere escaping av URL-komponenter; den presenteres ikke som gyldig Base64.
I URL Encoder & Decoder skal du bare kode parameterens VERDI. Den bokstavelige a+b/c= blir a%2Bb%2Fc%3D. Sett den kodede verdien etter en valgt nøkkel, for eksempel ?value=a%2Bb%2Fc%3D. Ikke send hele adressen https://... til en komponentkoder og forvent at URL-skilletegnene forblir uendret.
Hos mottakeren dekoder du URL-komponenten én gang. Resultatet skal fortsatt være a+b/c=. Hvis mottakeren tolker application/x-www-form-urlencoded-data, avviker reglene for et rått + fra decodeURIComponent. FrAIFlows komponentdekoder beholder et bokstavelig + og bruker ikke automatisk reglene for skjemadekoding. Denne forskjellen er en del av diagnosen, ikke bevis for at et verktøy er ødelagt.
Base64-dekod først etter at du har gjenopprettet en faktisk gyldig Base64-verdi. Ved feil om ugyldig utfylling eller UTF-8 stopper du og undersøker den opprinnelige representasjonen og valgt format. Gjentatt dekoding til en streng ser leselig ut, er ingen trygg reparasjonsmetode. En uventet %252B kan tyde på et ekstra kodingslag, men beviser ikke alene hvilket system som la det til.
Koding er ikke kryptering. URL-er kan lagres i historikken og serverlogger. Å holde en hemmelighet utenfor spørringsstrengen er derfor tryggere enn å kode den for overføring.
Bruk relaterte verktøy
Inndata og resultater blir i denne nettleseren. Ingen konto eller opplastinger.