Teckenkodning i svaret från reseplanerare 2
Hej, jag får UTF-8-kodat svar (t.ex. "Vanadisvägen") med anropet:
https://api.sl.se/api2/TravelplannerV2/trip.jso...<nyckel>&originCoordLong=18.043478&originCoordLat=59.329468&originCoordName=startText&destCoordLong=18.045001&destCoordLat=59.346189&destCoordName=destText&unsharp=1&numChg=0&maxWalkDist=1000&date=2015-06-04&time=13:54&searchForArrival=0
Det står att ISO-8859-1 ska vara standard. Jag ser inga tecken som måste kodas om i anropet, så jag frågar här varför jag ändå får fel teckenkodning tillbaka.
Tack på förhand
Följ inlägget
0
följare
Hej,
När jag kollar på det svar man får ut från den url'n så ser det rätt ut.
Du förser inte heller i exemplet åäö i url'n så det borde inte vara några problem?
Jag undrar om du blandat ihop gällande standard för inmatning och standard för svarsdata som det inte finns någon info om?
Encoding parametern som man anger i url'n gäller det format som man skickar in i destCoordName och originCoordName.
Detta är en del av det som står i dokumentationen:
"Default är ISO-8859-1. Encoding påverkar svaret och det man skickar in i originCoordName och destCoordName.".
Om du skickar in Södertälje med utf-8 encoding i url-anropet men inte anger encoding iso-8859-1 så kan det i vissa fall bli fel i svaret man får tillbaka som då innehåller blandade åäö och felaktiga tecken.
T.ex. om du kollar på svaret för denna url i en browser, så ser du att Origin name i första delresan har felencodat tecken, medens det i Destination name i sista delresan har rätt encoding, då åäö har skickats in i iso-8859-1 format för destCoordName.
https://api.sl.se/api2/TravelplannerV2/trip.xml...<din nyckel>&originCoordName=%C3%A5%C3%A4%C3%B6startText&destCoordName=%e4%e5%f6destText&unsharp=1&numChg=0&maxWalkDist=1000&searchForArrival=0&originCoordLong=18.043478&originCoordLat=59.329468&destCoordLong=18.045001&destCoordLat=59.346189
//Daniel A
Hej, tack för svaret! Jag är inte säker på om jag förstått dig rätt.
Man kan ju få åäö tillbaka utan att ha matat in det, så visst kan det bli problem med fel kodning ändå.
Som du säger så står det att parametern "Encoding påverkar svaret och det man skickar in i originCoordName och destCoordName", men den meningen säger ärligt talat inte någon någonting. Man får anta att den "påverkar svarskodningen", dvs om jag anger 8859-1 (eller inget) så borde jag inte få ett svar i UTF8. Om en parameter som heter "encoding" ska påverka svaret på nåt sätt alls så borde det ju vara på det sättet.
"Encoding parametern som man anger i url'n gäller det format som man skickar in i destCoordName och originCoordName."
Men det står ju allra högst upp i dokumentationen att "Reseplaneraren tar emot ISO-8859-1 encodad input." Punkt. UTF8 nämns inte över huvud taget. Att det längre ner finns en parameter "encoding" som "påverkar svaret" har väl inget med indatan att göra tänker jag, det är ju redan fastslaget att APIet tar emot en sorts input—URL escaped 8859-1?
Det börjar kännas riktigt snårigt om "encoding" ska påverka både svaret och ange formatet på indatan på samma gång.
Lite bakgrund:
Jag är i färd med att översätta från Api1 till 2. När jag tog emot svar i api1 och avkodade det (hela svaret) som UTF8 så blev det fel tecken överallt. Provade då 8859 och det blev rätt. Minns inte vad dokumentationen sa.
När det nu står att 2an tar emot i 8859 så kan jag inte annat än att utgå ifrån att den också svarar med det. Ända tills man läser ner till "encoding", och tror att man får bestämma svarskodning själv.
Men det finns alltså ingen info om hur api2 svarar? Har jag missförstått något eller är det inte lite konstigt att svarskodningen inte ens nämns?
Dokumentationen är tyvärr precis som sin föregångare onödigt komplicerad och gör säkert att ni måste lägga alldeles för mycket tid på att besvara frågor om den. Varför inte lägga den tiden på att skriva om dokumentationen?
Jag har kringgått mitt problem genom att köra UTF8 överallt, men jag fattar som sagt inte hur det hela är tänkt.
Hej,
Jag kan förtydliga i dokumentationen att det format man får svar på är i utf-8. Jag tror dock de flesta utvecklare märker detta omgående. Antingen är det utf-8 eller så är det iso-8859-1 man testar med, precis såsom du har gjort.
Jag kan även förtydliga gällande encodingparametern.
Jag vet dock inte om det förtydligar dokumentationen i stort och gör den mindre onödigt komplicerad.
Jag tar gärna emot konkreta förslag på förbättringar som gör dokumentationen mindre komplicerad och mer användbar.
//Daniel A
Hej, tack för svaret
Det jag har gjort är ju inte "bara" att testa de två teckenkodningarna, utan också behövt gå in här och skriva i supporten, vänta på svar, tolka och förstå svaret, jämföra svaret med dokumentationen, osv. Jag tycker att det är en ganska så stor skillnad ifrån att ha förstått dokumentationen direkt när man läste den.
Några saker som skulle förbättra dokumentationen är:
mm.
Som du märker så handlar det mest om att ha en dokumentstruktur och en logisk ordning som gör att man orkar ta in informationen utan att behöva hoppa fram och tillbaka.
Hoppas återkopplingen kommer till användning
Hej!
Tack för återkopplingen.
/Martin