Når man laver web-applikationer, ender man altid med at bruge hysterisk meget tid på teknologiske shortcomings i forskellige applikationer. Noget, som man burde være foruden.

Findvej var ingen undtagelse. I nogle tilfælde kan man diskutere, hvad browseren skal gøre, men i andre har det blot medført irritation, frustration og masser af tid spildt på af finde frem til en browsers præcise opførsel:

Internet Explorer og highbits i URL’en

På Findvej kan man som bekendt skrive adresser ud i ét, fx http://www.findvej.dk/Ørholmgade. Internet Explorer vælger vist som den eneste browser at sende highbits i URL’en som UTF8, når man selv indtaster adressen. Det gør andre browsere ikke.

Det bliver så mere forvirrende af, at det kun er adressen og ikke querystringen, der sendes utf8-encoded. Går man fx ind på “tæst?tæst=tæst” med IE, requestes der “t%C3%A6st?tæst=tæst” (hvor %C3%A6 så er den urlencodede udgave af utf8-udgaven af “æ”).

Det er ikke en løsning bare at hælde fx strengen igennem utf8_decode(), idet det vil ændre “Ørholmgade” til “?holmgade” for andre browsere. En mulighed er at søge på to highbits i træk og så antage, at det er ét utf8-tegn. Det kan dog give problemer med Svinøøstervej og Påøvej – et problem, der måske er så lille, at det kan accepteres. Jeg har dog i stedet valgt manuelt at søg&erstatte helt bestemte utf8-kombinationer af æ, ø, å, é, m.fl.

På den positive side har ingen browsere problemer med at man indtaster mellemrum i URL’en – den sørger selv for at encode det til %20. Det bør de i øvrigt heller ikke have problemer med, idet det alligevel ikke ville give nogen mening at sende mellemrummet med u-encoded (hvilket blot ville give en 400 Bad Request fra webserveren).

Internet Explorer og highbits i URL’en, take 2

Før jeg overhovedet nåede så langt, og da sitet i udviklingsfasen blot havde adressen findvej.dk og ikke www.findvej.dk, gav Internet Explorer nogle mærkelige problemer. Nogle adresser virkede fint, mens andre blot gav en søgeside i stedet for. Det betyder, at nogle direkte adresser virkede, mens andre ikke gjorde. Øvelsen er at lure hvorfor.

Følgende adresser virkede:

  • findvej.dk
  • findvej.dk/Nybrogade
  • findvej.dk/Øresundsvej 1
  • www.findvej.dk/Øresundsvej
  • www.findvej.dk/Øresundsvej 1

Følgende adresse virkede derimod ikke:

  • findvej.dk/Øresundsvej

Nogle gode bud? Ellers kan jeg fortælle, hvad jeg er nået frem til nu i min jagt på Internet Explorers regler, når man indtaster en adresse. Grundlæggende set forholder det sig på denne måde:

  1. Begynder adressen med www.? Så er det en webadresse
  2. Hvis ikke, indeholder adressen mellemrum i stien? Så skal specialtegn encodes, og så er det en webadresse.
  3. Hvis ikke, er der så highbits (som fx æøå) i stien? Så er det nok ikke en adresse, men en søgning, brugeren har gang i.
  4. Hvis ikke, så er det nok en hjemmesideadresse (med forbehold for domænenavnet i øvrigt)

Benytter man ikke IE, kan man dog stadigvæk nøjes med at indtaste adressen uden www – fx findvej.dk/Øresundsvej – uden problemer. Serveren redirecter blot requests på findvej.dk/… videre til www.findvej.dk/…

Denne IE-opførsel tog mildest talt lang tid at gennemskue. Specielt at mellemrummet gjorde forskel bragte blot mere forvirring på banen.

Safari, XML og forskellige tegnsæt

Jeg er ikke glad for Safari og dets XML-håndtering. Jeg hører nogle Safari/KHTML-brugere brokke sig over IE og den manglende mulighed for at sende sider som application/xhtml+xml. Men Safaris XML-håndtering lader nærmest til at være ikke-eksisterende. Rene XML-dokumenter vises ikke struktureret (men tilsyneladende som HTML), og XML-dokumenter, der refererer til et XSL-stylesheet, bliver heller ikke vist korrekt (hvilket IE og Firefox gør, men Opera tilsyneladende ikke gør).

Jeg vil gætte på, at den manglende implementering også er årsag til et andet problem, Safari-brugere oplever: Når der foretages et adresseopslag i baggrunden (vha. Google Maps APIets GDownloadUri-funktion), hentes der et XML-resultatsæt i UTF-8-format. Selve Findvej-hjemmesiden serveres dog i ISO-8859-1. Det burde ikke give nogen problemer (idet indhold altid skal holdes op imod en encoding, og den samme tekststreng, fx “æble”, kan skrives so to forskellige tekststrenge i forskellige encodings – det er stadigvæk den samme streng), men det gør det alligevel i Safari. Teksterne bliver vist “råt”, altså UTF-8-encoded på siden. Med måske for meget selvsikkerhed i stemmen vil jeg påstå, at det er en bug i Safari. Jeg har dog ikke testet om man finder den samme opførsel i Konquerer.

Mine tre bofæller benytter alle Macs, så Safari er ikke ukendt i hjemmet. Derfor prøvede jeg tidligt at rette jeg encodingen i XML-resultatsættet og angav samtidig explicit den anden encoding. Det betød dog, at IE pludselig ikke længere ville læse XML-filen… om det er IE, APIets XML-funktioner eller hvad, der var årsagen til det problem, har jeg ikke gravet dybere i.
Jeg tror, den bedste løsning/workaround er at lade den almindelige side ligeledes overgå til UTF-8. Det ville være en fin øvelse at vænne sig til at benytte UTF-8. Jeg frygter blot at diverse småværktøjer og editors lige hælder unicode-preamble (Byte Order Mark) ind i filerne eller glemmer at encode eller dobbelt-encoder highbits. Jeg benytter en række forskellige editors og værktøjer, og dette ville jeg gerne blive ved med. Jeg har blot en mistanke om at disse applikationer indeholder lige så mange fejl som browserne.