Prosenttikoodauksen tarkastaja

Prosenttikoodaus — kutsutaan myös URL-koodaukseksi ja vanhemmissa asiakirjoissa escapeksi — on sääntö, joka antaa URL-osoitteen kantaa merkkejä, joita sillä ei saisi olla. Prosentti-escape on kolme ASCII-merkkiä: prosenttimerkki ja kaksi heksanumeroa, jotka tarkoittavat yhtä tavua. %20 on tavu 0x20, eli välilyönti. %2F on tavu 0x2F, eli kauttaviiva. Muuta ei ole: escape nimeää tavun, ei merkkiä.

Koska se nimeää tavuja, teksti on ensin muutettava tavuiksi, ja tavukoodaus on UTF-8. Siitä pitkät escapet tulevat: yksi kiinalainen merkki on kolme UTF-8-tavua ja siten kolme escapea, ja yksi emoji on neljä tavua ja kaksitoista ASCII-merkkiä.

URI määritellään ASCII-merkkien sarjana (RFC 3986 -kohta 2.1), ja tuon ASCII-alueen sisällä osa merkeistä on varattuja: ne ovat välimerkkejä, jotka antavat URL-osoitteelle sen rakenteen. Kaksoispiste ja kaksi kauttaviivaa erottavat skeeman, @-merkki erottaa käyttäjätiedot isännästä, kysymysmerkki aloittaa kyselyn, risuaita aloittaa fragmentin, &-merkki erottaa kyselyparametrit, ja prosenttimerkki johdattaa escapen.

Se luo yhden ongelman ja yhden aukon. Ongelma: arvo, joka sisältää itsessään yhden noista merkeistä — hakukenttä, jossa on "a&b", tiedostonimi kauttaviivalla, salasana kaksoispisteellä — muuttaisi muuten URL-osoitteen rakennetta, jossa se kulkee. Aukko: prosenttimerkki itse, joten koodain voi yksinkertaisesti laajentaa omaa aakkostoaan. % kirjoitetaan muodossa %25, ja sen jälkeiset kaksi heksanumeroa ovat tavallisia varaamattomia merkkejä.

Nämä ovat niiden kolmen koodaimen tarkkoja tuloksia, joita tämä sivu ajaa, syötteillä, jotka on valittu, koska ne käyttäytyvät eri tavoin. Sivu laskee ne uudelleen näkyviin, ja sen Itsetesti tarkistaa jokaisen rivin alustan omia toteutuksia vastaan.

Lyhyt versio, joka säästää useimmat virheet: kaikki, mikä menee yhteen parametriarvoon, kulkee encodeURIComponent-funktion läpi (tai lomakesarjoittajan, joka tekee saman työn eri turvallisella joukolla), ja valmiiksi kootun täydellisen URL-osoitteen, joka tarvitsee escapeja lainkaan, kulkee encodeURI-funktion läpi. Näiden kahden väärän valinta on web-koodin yleisin prosenttikoodausvirhe.

Välilyönti on ainoa merkki, jonka koodaus riippuu siitä, mihin teksti on menossa, ja plusmerkki on syy siihen.

Ansa on tuon taulukon keskellä. Lomakedatassa plusmerkki tarkoittaa välilyöntiä, joten arvo, joka todella sisältää plusmerkin — puhelinnumero kirjoitettuna +44 20 7946 0958, laskulauseke, sähköpostiosoite plusmerkillä varustetulla tunnisteella — on kuljetettava muodossa %2B. Jos se kulkee kirjaimellisena plusmerkkinä, vastaanottaja lukee sen välilyöntinä, ja +44 saapuu muodossa " 44".

Kaksinkertainen koodaus tapahtuu, kun merkkijono on jo escapeoitu ja escapeoidaan sitten uudelleen. Ensimmäisen escapen prosenttimerkki on kuin mikä tahansa muu merkki, joten siitä tulee %25, ja sen alla oleva kerros säilyy näkyvänä tekstinä.

Tunnistaminen on laskemista: pura merkkijono kerran ja katso tulosta. Jos se sisältää yhä näyttävästi tarkoituksellisia escapeja — kelvollisen %XX-muodon tai lomakkeen plusmerkin siinä, missä odotetaan välilyöntiä — on vielä yksi kerros. Jos siinä on %25 ja sen perässä kaksi heksanumeroa, seuraava kerros on varmasti escape.

Kaksi käytännön huomiota. Ensinnäkin kahdesti purkaminen ei ole vaaratonta: se on tunnettu tapa saada turvasuodatin ja sen takana oleva koodi näkemään eri merkkijonoja, joten suodatin, joka ajetaan ennen toista purkua, suodattaa väärää tekstiä. Toiseksi kerrosluku tässä on merkkijonon ominaisuus, ei lupaus tarkoituksesta: laillinen arvo voi olla yhden kerroksen syvyinen ja rikkinäinen kaksi.

• Arvo koodattu encodeURI-funktiolla. Erottimet säilyvät, joten arvo, joka sisältää &- tai =-merkin, jakautuu toisella puolella useaksi parametriksi. Vertaa tämän sivun yläosan kahta saraketta syötteellä a&b=c: komponenttisarake escapeaa molemmat merkit, encodeURI-sarake säilyttää ne.
• Kirjaimellinen plusmerkki lähetettynä lomakedatana. Se saapuu välilyöntinä. Käytä %2B.
• Arvo escapeoitu kahdesti "varmuuden vuoksi". Se ei ole turvallisempi. Vastaanottaja purkaa kerran ja saa merkkijonon, joka sisältää yhä prosenttiescapeja - sama virhe kuin väärä merkistö, yhtä kerrosta alempana.
• Sellaisen purkaminen, mitä ei ole koskaan koodattu. Kirjaimellinen prosenttimerkki tekstissä — 100% sure — ei ole escape. Tiukassa lukutavassa se on rikkinäinen escape siinä kohdassa, jonka tämä sivu raportoi; löysässä lukutavassa se säilyy, minkä vuoksi löysä on tämän sivun oletus eikä päinvastoin.
• Oletus, että escapen on oltava isoilla kirjaimilla. Purku käsittelee %2f- ja %2F-muodot samana tavuna, ja molemmat ovat kelvollisia. Isot kirjaimet ovat vain RFC 3986:n suosittelema kanoninen kirjoitusasu, ja sen muut työkalut tuottavat.
• Oletus, että prosenttikoodaus tekee tekstistä turvallisen. Se tekee tekstistä yksiselitteisen URL-osoitteen sisällä. Se ei estä injektiota, se ei ole salausta eikä puhdistusta: escapen on oltava viimeinen vaihe ennen kokoamista siihen kontekstiin, johon teksti menee.

“Onko plusmerkki URL-osoitteessa välilyönti?”

Vain lomakedatassa, ja vain lomakelähetyksen kyselyosassa. Polussa, fragmentissa ja tavallisen linkin kyselyssä plusmerkki on kirjaimellinen plusmerkki. Siksi tällä sivulla on kytkin siihen sen sijaan, että se arvattaisiin.

“Miksi linkkini näyttää %25?”

Koska jokin on koodannut prosenttimerkin. Joko kirjaimellinen prosenttimerkki meni koodaimen läpi — 100% sure muuttuu muotoon 100%25%20sure — tai jo escapeja sisältävä merkkijono koodattiin toisen kerran. Pura merkkijono kerran ja katso, mitä tulee takaisin: jos tulos sisältää yhä %XX-muotoja, on vielä yksi kerros.

“Onko sillä merkitystä, onko kyselyarvon sisällä oleva kauttaviiva %2F vai /?”

URL-jäsentimelle ei: molemmat saapuvat palvelimelle kauttaviivana, ja WHATWG:n kyselyjoukko jättää kauttaviivan rauhaan. Yhteentoimivuudelle joskus: monet palvelinkehykset tekevät omaa purkua raakaan kyselymerkkijonoon, ja muutamat ovat eri mieltä merkeistä, joita ei koskaan escapeoitu. Kun arvo kootaan käsin eikä sarjoittajalla, varattujen merkkien eksplisiittinen escapeaminen on turvallisempi tapa.

“Miksi lomakesarake escapeaa tildin, jonka kaksi muuta jättävät rauhaan?”

Koska lomakekoodaajan turvallinen joukko on kapeampi: siinä ovat vain kirjaimet, numerot ja -_.*. WHATWG:n lomakekoodaaja escapeaa merkit ~ ! ' ( ), vaikka RFC 3986 luettelee ~-merkin varaamattomana. Molemmat kirjoitusasut purkautuvat samaksi arvoksi; ero merkitsee vain silloin, kun merkkijonoja verrataan tavu tavulta.

“Voivatko samat merkit esiintyä escapeamattomina selaimen osoitepalkissa?”

Kyllä, ja se on osoitepalkki, ei URL-osoite. Selaimet näyttävät URL-osoitteen luettavassa muodossa ja koodaavat sen lähettäessään, joten 中文 linkissä muuttuu langalla muotoon %E4%B8%AD%E6%96%87. Jos kopioit URL-osoitteen osoitepalkista, saadaan riippuen selaimesta jommankumman muodon.

“Jokainen escape täällä näyttää kelvolliselta, mutta ulos tuleva merkki ei ole se, jonka odotin. Miksi?”

Kahden eri virheen takana on "purkaminen meni väärin", ja tämä sivu raportoi ne eri tavalla. Ensimmäinen on rikkinäinen escape: prosenttimerkki, jota ei seuraa kaksi heksanumeroa, kuten loppuun jäävä 100% tai %zz. Se on syntaksiongelma: tiukka lukutapa hylkää sen ja kertoo sijainnin, kun löysä lukutapa säilyttää sen kirjaimellisena tekstinä ja luettelee sen. Toinen on escape, jonka tavu on täysin laillinen, mutta tavut eivät muodosta kelvollista UTF-8-merkkiä, kuten yksittäinen %FF tai kolmitavuinen merkki katkaistuna muotoon %E4%B8. Se ei ole syntaksiongelma, joten molemmat lukutavat palauttavat tekstin, korvaavat purkamattomat tavut korvausmerkillä U+FFFD ("�") ja luettelevat varoituksen, joka kertoo sen. Varoitus on hyödyllinen osa: teksti, joka saapuu korvausmerkkeinä, tarkoittaa yleensä, että lähettäjä käytti eri merkistöä tai että merkkijono escapeoitiin yhden kerran liian monta. Prosenttikoodaus nimeää tavuja, ja tämä sivu lukee nuo tavut aina UTF-8:na, kuten URL-standardi.

“Mitä tämä sivu ei tee?”

Se ei jaa URL-osoitetta skeemaan, isäntään, polkuun ja kyselyyn — siihen on URL-jäsennin. Se ei tarkista, onko linkki turvallinen avata, ei ota yhteyttä mihinkään, eikä arvaa escapen takana olevien tavujen merkistöä: se lukee ne aina UTF-8:na, kuten URL-standardi vaatii.

“Mitä varasarjaa purku tarvitsee, ja mistä tiedän, että se on oikein?”

Paina Itsetesti. Se vertaa sivun omia koodaimia alustan encodeURIComponent-, encodeURI- ja URLSearchParams-funktioihin jokaisen tulostettavan ASCII-merkin kohdalla, ajaa uudelleen kaikki yllä olevien taulukoiden esimerkit, tarkistaa kirjatut kerrosketjut ja raportoi tarkistusten määrän tässä.

Prosenttikoodaus on määritelty RFC 3986 -kohdassa 2.1, varattujen ja varaamattomien merkkien määritelmä on kohdissa 2.2 ja 2.3 ja kirjainkokosääntö kohdassa 6.2.2.1. Joukot, joita selain todella käyttää URL-osoitteen rakentamisessa, ovat WHATWG URL -standardissa, joka jakaa ne kontekstin mukaan: yksi fragmentille, yksi kyselylle, yksi erikoiskyselylle, yksi polulle, yksi käyttäjätiedoille ja kapeampi yhden osan koodaukseen. Lomakelähetys, plusmerkki mukaan lukien, on HTML-standardissa kohdassa application/x-www-form-urlencoded. Funktiot encodeURI ja encodeURIComponent ovat osa ECMAScriptiä itseään.

Tämä sivu täyttää polku-, kysely- ja fragmenttisarakkeet omista kontekstikohtaisista joukoistaan ja tulostaa jokaiselle kontekstille tarkan luettelon tuloksen viereen. Nuo joukot on johdettu WHATWG:n joukoista ja eroavat niistä kahdessa tarkoituksellisessa kohdassa: risuaita escapeaan kyselyn sisällä, koska raaka risuaita aloittaisi fragmentin, ja komponenttijoukko on lukittu täsmälleen niihin merkkeihin, joita encodeURIComponent escapeaa. Kohdissa, joissa alustan funktio on vastauksen määritelmä — encodeURIComponent, encodeURI ja lomakesarjoitus — kyseinen funktio kutsutaan suoraan, joten ne sarakkeet ovat selaimen omaa toimintaa eivätkä sen uudelleentoteutusta.

Teksti sivulla on kirjoitettu tälle sivustolle. Jokainen yllä olevien taulukoiden arvo tuotetaan sivun omalla koodilla latausaikana, ja se on tarkistettu alustan toteutuksia vastaan tämän sivuston testityökaluissa; Itsetesti toistaa vertailun selaimessa.