En Base64-værdi kan indeholde +, / og =. En parser til forespørgselsstrenge kan fortolke et råt + som et mellemrum. Tilfældig udskiftning af tegn kan skjule den oprindelige fejl.
Brug et harmløst eksempel, aldrig en rigtig adgangskode, token eller personlig registrering. UTF-8-teksten a?b kodes som YT9i. Det første eksempel kontrollerer konverteringen frem og tilbage, men indeholder ikke de problematiske tegn. En separat bogstavelig testværdi, a+b/c=, er nyttig til at kontrollere escaping af URL-komponenter; den præsenteres ikke som gyldig Base64.
I URL Encoder & Decoder skal du kun kode parameterens VÆRDI. Den bogstavelige a+b/c= bliver a%2Bb%2Fc%3D. Sæt den kodede værdi efter en valgt nøgle, for eksempel ?value=a%2Bb%2Fc%3D. Send ikke hele adressen https://... gennem en komponentkoder og forvent, at URL-separatorerne bevares uændret.
Hos modtageren skal URL-komponenten afkodes én gang. Resultatet bør stadig være a+b/c=. Hvis modtageren fortolker application/x-www-form-urlencoded-data, er reglerne for et råt + anderledes end decodeURIComponent. FrAIFlows komponentafkoder bevarer et bogstaveligt + og anvender ikke automatisk regler for formularafkodning. Forskellen er en del af diagnosen, ikke bevis for at et værktøj er defekt.
Base64-afkod først, når du har genskabt en faktisk gyldig Base64-værdi. Ved en fejl om ugyldig udfyldning eller UTF-8 skal du stoppe og undersøge den oprindelige repræsentation og det valgte format. Gentagen afkodning, indtil en streng ser læselig ud, er ikke en sikker reparation. Et uventet %252B kan tyde på et ekstra kodningslag, men beviser ikke alene, hvilket system der tilføjede det.
Kodning er ikke kryptering. URL'er kan gemmes i historik og serverlogfiler. Det er derfor sikrere at holde en hemmelighed ude af forespørgselsstrengen end at kode den til transport.
Brug relaterede værktøjer
Input og resultater bliver i denne browser. Ingen konto eller uploads.