Gå til innhold

Problemer med charset.


Anbefalte innlegg

Hei :p

 

Jeg har problemer med charset. Det blir slike rare bokstaver aav øæå: øæå

 

 

Jeg har en slik i headeren min:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

 

 

Og i databasen har jeg byttet charsette til: utf8_unicode_ci

 

 

Men det fungerer likevell ikke. Hvorfor ?

Lenke til kommentar
Videoannonse
Annonse

Du vil uansett ikke få native utf-8-støtte med å endre charsets. Å bruke utf8 i phpapplikasjoner er nok ikke det mest heldige med mindre du lager egne multi byte-funksjoner (og enn da er det potensiale for det er usikkert). De fleste funksjonene du bruker i PHP støtter ikke multi byte, og mb-funksjonene er eeeelendige (funker egentlig ikke).

Lenke til kommentar

Har du satt header? (må ligge "først" i koden din)

 

<?php header("Content-Type: text/html;charset=utf-8"); ?>

 

Du kan ogs spesifisere database (gjøres etter at koblingen er opprettet, men før du sender den queries.):

 

mysql_query("SET NAMES 'utf8'");

mysql_query("SET CHARACTER SET utf8");

 

Pass også på at filene dine er lagret i utf8, så burde alt gå veldig bra :)

Lenke til kommentar
Har du satt header? (må ligge "først" i koden din)

 

<?php header("Content-Type: text/html;charset=utf-8"); ?>

 

Du kan ogs spesifisere database (gjøres etter at koblingen er opprettet, men før du sender den queries.):

 

mysql_query("SET NAMES 'utf8'");

mysql_query("SET CHARACTER SET utf8");

 

Pass også på at filene dine er lagret i utf8, så burde alt gå veldig bra :)

 

Husk at du ikke JOBBER i UTF-8 hvis du gjør dette. Potensiale for store sikkerhethetsbrudd og feil i output er særs store.

Lenke til kommentar
...Potensiale for store sikkerhethetsbrudd...

Dette var nytt for meg, og sansynligvis noe jeg burde lære mer om (vil jo ikke ha usikre nettsider) har du noen link til mer utfyllende info om emnet? Har googlet, men finner bare info om hvorfor man burde bytte til utf-8 ....

Lenke til kommentar
...Potensiale for store sikkerhethetsbrudd...

Dette var nytt for meg, og sansynligvis noe jeg burde lære mer om (vil jo ikke ha usikre nettsider) har du noen link til mer utfyllende info om emnet? Har googlet, men finner bare info om hvorfor man burde bytte til utf-8 ....

Problemet er nok at ingen eller få av de som snakker om UTF-8 i forbindelse med PHP egentlig kan Unicode eller UTF-8 godt nok til å være klar over problemene. PHP støtter IKKE UTF-8 eller Unicode på noen som helst måte. Mbstring gir litt støtte, men den er mangelfull, buggy og ærligtalt litt amatørmessig for å si det pent. Det virker nesten som mbstring implementerer Unicode slik det var før PHP kom.

 

Mer eller mindre potensielle sikkerhetsproblemer i forbindelse med Unicode:

  • U+D800 - U+DFFF er såkalte «surrogates» og er IKKE gyldige Unicode «code points». Disse brukes bare i UTF-16 til støtte såklalte «astral planes», altså «code points» over U+FFFF (som forøvrig heller ikke er et gyldig «code point»). Å tillate dette regnes som et mulig sikkerhetsproblem. Mbstring regner dette som gyldige «code points».
  • U+FFFE er en «omvent» BOM (BOM=Byte Order Mark, U+FEFF), og bør aldri i verden være gyldig. Konverterer man til stort sett enhver annen Unicode encoding vil man mer eller mindre garantert få problemer med big ending/little endian forutsatt at det er første «tegn» i en string (les: stringen blir korrupt). Igjen, mbstring synes dette er helt gyldig.
  • «Overlong forms» av et «code point». Unicode spesifiserer (tror det er i 3.1 og seinere) at det til enhver tid bare skal være den korteste formen å representere et «code point» på som er gyldig. Dette er utrolig nok noe mbstring fanger opp. Hvis man f.eks tar «line feed», altså 0x0A. Eksempler på «overlong form» av det i UTF-8 er 0xC0 0x8A, 0xE0 0x80 0x8A og 0xF0 0x80 0x80 0x8A. Er du som programmerer korka nok til å ikke sjekket dette samtidig som f.eks databasen du bruker er like korka og gjør om dette til UCS-2 eller ev. UTF-16 (noe som ikke er utenkelig) vil man med dette kunne lure inn tegn du ikke ønsker med medførende fare for SQL-injection.

Det er kanskje de 3 viktigste grunnene til å enten holde snuten unna UTF-8 og Unicode eller validere alt av input. Dette tror jeg ytterst, ytterst få faktisk gjør. Strengt tatt bør man tenke litt igjennom om man faktisk trenger Unicode. På en norsk eller engelsk side rettet mot et norsk og/eller engelsk publikum vil jeg si det er ren galskap å begi seg ut i Unicode-verden med mindre man faktisk skaffer seg noe litt mer solid enn mbstring.

 

Red.: Dette er såklart før man begir seg ut på lite gjennomtenkt bruk av UTF-8 og Unicode gjennom bruk av funksjoner som f.eks strlen. Altså, sikkerhetsmessig operasjoner hvor man sjekker minimumslengden av passord, brukernavn etc. vil kunne gi feil resultat. Så kommer jo også ørten str-funksjoner som potensielt gjør en UTF-8-string korrupt, eller gir feil resultat.

Endret av Ernie
Lenke til kommentar
...Potensiale for store sikkerhethetsbrudd...

Dette var nytt for meg, og sansynligvis noe jeg burde lære mer om (vil jo ikke ha usikre nettsider) har du noen link til mer utfyllende info om emnet? Har googlet, men finner bare info om hvorfor man burde bytte til utf-8 ....

***

MYE tekst ...

***

Bare ut av nysgjerrighet: Du sier at PHP har lite til ingen støtte for Unicode/UTF-8. Har Microsoft sitt alternativ, ASP, bedre støtte enn PHP?

Lenke til kommentar

Jeg kjenner ikke så godt til ASP-verdenen, så jeg veit strengt tatt ikke. Hvis du tenker på ASP som i VBScript så tror jeg ikke det. Er det derimot ASP som i ASP.net og f.eks C#, vil det være betydelig bedre. Betydelig som i en ordentlig, fullverdig implementasjon.

 

Red.: Verdt å merke seg at PHP6 vil tilby endel bedre støtte for Unicode, selv om jeg ikke er helt overbevist om at det er perfekt.

Endret av Ernie
Lenke til kommentar
Jeg er heller ikke særlig godt kjent med ASP. Er ASP i VBScript eller ASP.net mest utbredt på webservere? Og når er PHP6 planlagt?

Som sagt, jeg kjenner ikke så veldig til det. Det er knyttet veldig opp mot Windows og IIS, noe som gjør det automatisk helt uaktuelt for min del.

 

Mener å huske PHP6 skal komme ut en eller annen gang neste år. Deretter vil det ta tid før det faktisk er tilgjengelig hos webhostene. Jeg forventer det ikke utbredt før om drøyt 2-3 år, i bestefall kanskje om 1.5 år.

Endret av Ernie
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...