Az URL-kódolási hibák, amelyeket a fejlesztők továbbra is elkövetnek (és javítják)

Az URL-kódolási hibák finomak, tartósak, és gyakran felfedezhetők az éles környezetben. Egy rosszul elhelyezett %20, egy kettős kódolású "és" vagy egy összezavart + megszakíthatja az API-hívásokat, megsértheti a nyomkövetési adatokat, és biztonsági réseket okozhat. Javítsuk ki a leggyakoribbakat.

Tesztelje le kódolását URL kódoló/dekódoló eszközünkkel – illesszen be bármilyen karakterláncot, és azonnal megtekintheti a kódolt eredményt.

encodeURI vs encodeURIComponent

A JavaScript két beépített kódolási funkcióval rendelkezik, és a rossz kód használata az első számú hibaforrás:

// HIBA – az encodeURI megőrzi és a lekérdezésben lévő értékeket
const url = 'https://api.example.com/search?q=' + encodeURI('tom & jerry');
// Eredmény: https://api.example.com/search?q=tom%20&%20jerry
// A & megmarad – most úgy néz ki, mint egy külön paraméter! // HELYES
const url = 'https://api.example.com/search?q=' + encodeURIComponent('tom & jerry');
// Eredmény: https://api.example.com/search?q=tom%20%26%20jerry[[
Ökölszabály: Az egyes értékekhez használja az encodeURIComponent-et. A encodeURI-ot csak akkor használja, ha teljes URL-je van, amelyhez csak nem ASCII karakterek kódolása szükséges.
 
Kettős kódolási hibák
A kettős kódolás akkor történik meg, ha egy már kódolt karakterláncot újra kódolnak:
const name = 'hello világ';
const encoded = encodeURIComponent(name); // hello%20world
const doubled = encodeURIComponent(encoded); // hello%2520world
// A %25 magának a %nak a kódolása!
Ez általában akkor fordul elő, ha: 

Egy keretrendszer automatikusan kódolja a lekérdezési paramétereket, és Ön előre kódolja azokat is
Az URL kódolása tárolás előtt megtörténik, majd lekéréskor újra kódolásra kerül
A köztes szoftver több rétegben dolgozza fel az URL-t, mindegyikhez hozzáadva a kódolást 
Érzékelés
Keresse a %25-et az URL-ekben – ez szinte mindig a kettős kódolás jele. A %2520 (kettős kódolású szóköz) a klasszikus visszajelző.
 
A + vs %20 zűrzavar
A HTML űrlap benyújtásakor (application/x-www-form-urlencoded) a szóközök +. Szabványos százalékos kódolásban (RFC 3986) a szóközök %20.
Ez azért fontos, mert:

A 
decodeURIComponent  nem  dekódolja + vissza a térbe – literálként hagyja +
A háttér keretrendszerek az elemzőtől függően dekódolhatják a + 
Ha API-ja %20-t vár, de +, akkor a "red+car" kifejezésre keresi a "piros+autó" kifejezést (szó szerint pluszjellel) a "piros autó" helyett[[

// Biztonságos dekódolás, amely kezeli a + és a %20
függvény safeDecodeParam(érték) { return decodeURIComponent(value.replace(/\+/g, '%20'));
}
 
UTF-8 Edge tokok
A nem ASCII karakterek, mint például a é, ü[ 日本語[[ 日本語[[ kell lennie. bájt szekvenciák: 

encodeURIComponent('café') // caf%C3%A9
encodeURIComponent('日本語') // %E6%97%A5%E6%9C%AC%E8%AA%9E
encodeURIComponent('🔒') // %F0%9F%94%92
Problémák merülnek fel, ha: 

A szerver Latin-1-et vár, de UTF-8-at kap (mojibake – elrontott karakterek)
Az adatbázis oszlopai nem UTF-8-ra vannak állítva, csendesen csonkolják a többbájtos karaktereket
A naplófájlok rossz karakterkészlettel értelmezik a kódolt karakterláncokat
 
Átirányítási és visszahívási URL buktatói
Az OAuth visszahívások és az átirányítási URL-ek különösen hajlamosak a kódolási hibákra:
// OAuth-átirányítás létrehozása
const redirectUri = 'https://myapp.com/callback?source=oauth';
const authUrl = `https://provider.com/auth?redirect_uri=${encodeURIComponent(redirectUri)}`;
// Helyes: a teljes visszahívási URL (beleértve a saját ?-jét is) egyetlen paraméterértékként van kódolva 
Gyakori hibák:

A redirect_uri egyáltalán nincs kódolva – a ? a visszahívásban felosztja a szülő URL-t
A redirect_uri részleges kódolása — az elérési út kódolása, de a lekérdezés nem 
A teljes hitelesítési URL kódolása a paraméterérték helyett

Ezek a hibák gyakran nyílt átirányítási sebezhetőséget okoznak, amelyeket a támadók adathalászatra használnak ki.
 
Hibakeresési ellenőrzőlista
Ha egy URL nem a várt módon működik, ellenőrizze ezeket sorrendben:

Keresse meg a következőt: %25 – kettős kódolást jelez 
Check + vs %20 – következetesen kezelik a szóközöket?
Inspect raw request — use browser DevTools Network tab to see the actual encoded URL sent
Teszt speciális karakterekkel — próbálja meg a & = ? # / az értékekben, hogy megnézze, nem sértik-e az URL-struktúrát
Tartalomtípus ellenőrzése — a szerver a következőképpen értelmezi: application/x-www-form-urlencoded vagy alkalmazás/json?
Dekódolás ellenőrzése a szerveren — naplózza a nyers és dekódolt értékeket a szerver oldalon 
 
Biztonságos segédfunkciók
// Lekérdezési karakterlánc biztonságos létrehozása
function buildQueryString(params) { return Object.entries(params) .map(([kulcs, érték]) => `${encodeURIComponent(key)}=${encodeURIComponent(value)}` ) .join('&');
} // URLSearchParams használata (modern böngészők + Node.js)
const params = new URLSearchParams({ q: 'tom & jerry', page: '1' });
const url = `https://api.example.com/search?${params}`;
// Helyes: automatikusan kezeli a kódolást
Bevált gyakorlat:  Használjon URLSearchParams vagy URL konstruktort a kézi karakterlánc-konstrukció helyett. Alapértelmezés szerint megfelelően kezelik a kódolást.
 

GYIK
Miért lesz a + szóköz?
Ez a HTML űrlapkódolás öröksége (application/x-www-form-urlencoded), ahol a szóközök + kódolásúak. A szabványos százalékos kódolásban (RFC 3986) a szóközök %20. A [ konvenció csak az űrlapbeküldések lekérdezési karakterláncaira vonatkozik, az elérési út szegmenseire vagy más URL-részekre nem.
Hogyan kódolhatom helyesen a beágyazott URL-eket?
Használja az encodeURIComponent elemet a belső URL-en, mielőtt a külső URL lekérdezési paraméterébe helyezné. Ez olyan karaktereket kódol, mint a :/?, amelyeket egyébként a külső URL szerkezetének részeként értelmeznének.
Miért törnek meg az aláírások az URL-kódolás után?
Az aláírásokat pontos bájtsorozatok alapján számítják ki. Ha aláír egy karakterláncot a kódolás előtt (vagy dekódolás után), de kódolt formában ellenőrzi (vagy fordítva), akkor a bájtok eltérnek, és az aláírás meghiúsul. Aláírás előtt mindig normalizálja a kódolást.
 
Kapcsolódó eszközök és cikkek

URL kódoló/dekódoló — valós idejű kódolás tesztelése
JWT biztonsági hibák — a kódolás a tokenkezelésnél is fontos 
Checksum Mismatch Fix  – a kódolás megváltoztatásakor sérült fájlkivonat