Thomas. Skrevet 26. april 2008 Del Skrevet 26. april 2008 Hei 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
allyse Skrevet 26. april 2008 Del Skrevet 26. april 2008 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
Thomas. Skrevet 26. april 2008 Forfatter Del Skrevet 26. april 2008 Jaha. Det var ikke akkurat forståelig Lenke til kommentar
pulse Skrevet 26. april 2008 Del Skrevet 26. april 2008 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
Hallonen Skrevet 26. april 2008 Del Skrevet 26. april 2008 Det kan og være at det lønner seg å bytte ut UTF-8 med ISO-8859-1 - Spesielt hvis det er snakk om en apache2 server. Den har problemer med å vise æøå riktig ellers. Lenke til kommentar
allyse Skrevet 26. april 2008 Del Skrevet 26. april 2008 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
pulse Skrevet 26. april 2008 Del Skrevet 26. april 2008 ...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
Ernie Skrevet 26. april 2008 Del Skrevet 26. april 2008 (endret) ...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 26. april 2008 av Ernie Lenke til kommentar
pedervl Skrevet 26. april 2008 Del Skrevet 26. april 2008 ...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
Ernie Skrevet 26. april 2008 Del Skrevet 26. april 2008 (endret) 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 26. april 2008 av Ernie Lenke til kommentar
pedervl Skrevet 26. april 2008 Del Skrevet 26. april 2008 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? Lenke til kommentar
Ernie Skrevet 26. april 2008 Del Skrevet 26. april 2008 (endret) 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 26. april 2008 av Ernie Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå