Nytt teckenkodningsfel i SLs reseplanerare
Hej!
Har testat lite med att söka resor till adresser med SLs api och har stött på ett nytt teckenkodningsproblem. Vet inte om ni bytt ut allt till nya proxyn nu eller kör på den gamla, men problemet är i alla fall som följer:
- Gör en reseförfrågan med ZID som innehåller ett O-värde med svenska tecken
- Escape:a din url-sträng i utf-8/isolatin1 (båda funkar som invärden men ger olika felaktiga tecken i svaret)
- När resesvaret returneras har destinationsadressen fel tecken för åöä, (alltså #text-värdet för Destination för den sista Subtripen som tar en till den sökta adressen)
Alla andra svenska tecken är korrekta.
Felet går att reproducera i api-konsolen för reseplaneraren. Här är en exempellänk som api-konsolen genererat:
https://api.trafiklab.se/sl/reseplanerare.json?.....
Ursprungsvärden:
S=9432
ZID=@Y=59335933@X=18072767@O=ÅÄÖåäö
För övrigt får alla adresser man skickar in på detta sätt ett utropstecken tillagt på slutet, så om man t.ex. skickar in "O=Stureplan,%20Stockholm" så blir destinationen för sista subTripen "Stureplan, Stockholm!". Kanske är för att det känns skönt att komma fram, i och för sig. 😀
Mvh
Torsten
Hej!
Nu ska vår leverantör ändrat så svaret är i UTF-8.
/Martin
Hej Martin!
Problemet kvarstår, men de kanske inte hunnit pusha ut ändringen i drift än?
Bifogar två screenshots från appen jag utvecklat. I det första har koordinaternas namn skickats in till reseplaneraren kodat i utf-8 och i det andra som isolatin1 (8859-1)
http://freyhall.se/filer/teckenfel_utf8input.png
http://freyhall.se/filer/teckenfel_isolatininpu...
Som du ser så är all utdata från reseplaneraren förutom den för start och destinationsadresserna i rätt teckenkodning.
Notera även att utropstecknen efter koordinaternas namn är kvar.
Här är sökfrågan i det översta fallet:
https://api.trafiklab.se/sl/reseplanerare.json?...
Mvh,
Torsten
Hej!
Testa att köra anropet med ä,ö och se om det blir annorlunda. Annars får det undersökas i mer detalj.
https://api.trafiklab.se/sl/reseplanerare.json?Time=11:12&Date=27.02.2014&SID=@Y=59344087@X=18035956@O=Rödabergsgatan,Stockholm&ZID=@Y=59610985@X=18906004@O=Förängsudden,Blidö&key=
/Martin
När man skickar åäö och andra "specialtecken" i en URL kodas de om till %XX där XX är tecknets värde i en teckenuppsättning, oftast UTF-8. Det går alltså inte att skicka åäö över internet i url:er.
Kolla t.ex. här: http://www.w3schools.com/TAGs/ref_urlencode.asp
Enligt url-standard blir:
Rödabergsgatan: R%C3%B6dabergsgatan
Förängsudden: F%C3%B6r%C3%A4ngsudden
Hela svaret ni skickar ut från reseplaneraren är, i den senaste proxyändringen, kodat i ISO 8859-1 (kallas Latin1), och för att den adress man skickar in ska bli korrekt måste inputen i UTF-8 kodas om till latin1 när den skickas ut i svaret.
Det verkar ske någon slags omkodning på vägen, eftersom adresserna i svaret även blir fel när jag skickar in adressens namn kodat i latin1, vilket borde bli korrekt om ingen konvertering alls sker.
Eftersom man skickar ett gäng parametrar i en parameter (X,Y och O i ZID/SID) så kanske det även kan ske en dubbel konvertering någonstans?
Sökfrågan jag länkade i inlägget ovan var visst för latin1 (screenshot 2), här är den fråga som jag normalt skickar (kodad i UTF-8, argumenten överensstämmer med url-standard enligt ovan):
https://api.trafiklab.se/sl/reseplanerare.json?...
Hej!
Vi får kolla vidare på detta. Det finns en tillfällig lösning som gör att det ser bra ut och det är om du tar input parametrarna:
och använder dessa där encodingen blir felaktig.
Det har varit en del strul med encoding på olika proxys. Vi måste undersöka vidare om allt är gjort hos vår leverantör.
/Martin