Ett Base64-värde kan innehålla +, / och =. En parser för frågesträngar kan tolka ett rått + som ett blanksteg. Att ersätta tecken på måfå kan dölja det ursprungliga felet.
Använd ett ofarligt exempel, aldrig ett riktigt lösenord, en token eller en personlig post. UTF-8-texten a?b kodas som YT9i. Det första exemplet kontrollerar tur-och-retur-omvandlingen men innehåller inte de besvärliga tecknen. Ett separat bokstavligt testvärde, a+b/c=, är användbart för att kontrollera escaping av URL-komponenter; det presenteras inte som giltig Base64.
I URL Encoder & Decoder ska du bara koda parameterns VÄRDE. Det bokstavliga a+b/c= blir a%2Bb%2Fc%3D. Placera det kodade värdet efter en vald nyckel, till exempel ?value=a%2Bb%2Fc%3D. Mata inte in hela adressen https://... i en komponentkodare och förvänta dig att URL-avgränsarna förblir oförändrade.
Avkoda URL-komponenten en gång hos mottagaren. Resultatet ska fortfarande vara a+b/c=. Om mottagaren tolkar application/x-www-form-urlencoded-data skiljer sig reglerna för ett rått + från decodeURIComponent. FrAIFlows komponentavkodare behåller ett bokstavligt + och tillämpar inte formuläravkodningsregler automatiskt. Skillnaden är en del av felsökningen, inte bevis för att något verktyg är trasigt.
Base64-avkoda först när du har återställt ett faktiskt giltigt Base64-värde. Om du får fel om ogiltig utfyllnad eller UTF-8 ska du stanna och kontrollera originalets representation och valt format. Att avkoda upprepade gånger tills strängen ser läsbar ut är ingen säker reparation. Ett oväntat %252B kan tyda på ytterligare ett kodningslager, men bevisar inte ensamt vilket system som lade till det.
Kodning är inte kryptering. URL:er kan lagras i historik och serverloggar. Att hålla en hemlighet utanför frågesträngen är därför säkrare än att koda den för överföring.
Använd relaterade verktyg
Indata och resultat stannar i den här webbläsaren. Inget konto eller uppladdningar.