Avatar billede morgan_freeman Nybegynder
06. marts 2015 - 14:50 Der er 11 kommentarer og
1 løsning

Lagring af danske tegn

Jeg har webhotel hos one.com og har en sag med danske special-tegn i database. Indtil seneste php-update kunne jeg smide special-tegn ind i en utf-8 tabel og de blev lagret som special-tegn. Altså når jeg gik ind i phpMyAdmin kunne jeg se ø,æ,å som jeg havde skrevet dem i mit cms.
Nu - efter update - indsættes tegnene som utf-8 (æ / ø Ã¥). Mine html-input- og output-sider er uft-8, så nu vises de senest indsatte tegn korrekt, men alle de tidligere vises som spørgsmålstegn på output-sider.
Spørgsmålet er så, om det er "meningen" at special-tegn skal lagres som utf-8 eller om man kan smide special-tegn direkte i databasen?
Det har betydning for om jeg skal forsøge at finde en måde at lave mine sider om (har allerede kigget en del på det, men uden held) ELLER om jeg skal rette alle de gamle inputs, så special-tegn laves om til utf-8.
Og hvis svaret er at bruge utf-8-tegn i databasen - er der så en god grund til det?
Avatar billede erikjacobsen Ekspert
06. marts 2015 - 17:31 #1
UTF-8 er ganske fint. Det eneste, der set ud til at være sket, er at dine sider nu opfattes som iso-8859-1. Men det er jo noget du bestemmer (og som din webhost egentlig ikke skal blande sig i).

Så det er vel nogle PHP-sider, der skal rettes lidt i, måske. Hvad har du?
Avatar billede erikjacobsen Ekspert
06. marts 2015 - 17:34 #2
Eller også - ved nærlæsning - er det omvendt.
Avatar billede morgan_freeman Nybegynder
08. marts 2015 - 15:17 #3
Tak, såvidt
Jeg tror også det er i php den er gal, men har svært ved 1. at forstå hvorfor/hvordan 'updaten' har ændret funktionaliteten i mine sider - og hvori fejlen består.

Jeg deklarer utf-8 både i php-header og html-meta på den helt klassiske facon. Men det er (åbenbart) ikke nok...?
Avatar billede erikjacobsen Ekspert
08. marts 2015 - 15:50 #4
Altså som udgangspunkt: Vises et æ, eller ø, eller å, som 2 tegn  (æ ø Ã¥) er det fordi de er i utf-8 format, men vises som ISO-8859-1 (ANSI)

Vises et æ, eller ø, eller å, som en firkant, eller diamant, måske med spørgsmålstegn, så er det i ISO-8859-1 (ANSI), men vises som UTF-8.

(og det kan være mere komplekst)

Blander man, frivilligt eller ufrivilligt, de 2 tegnsæt, så er der bøvl.

Har du valgt UTF-8 på alle dine sider, så er det jo fint, og det er ikke noget som dit webhotel har noget imod.

Men er det du så skriver, at dit webhotels phpmyadmin pludselig viser æ ø Ã¥ i stedet for æøå, så er det måske bare fordi phpmyadmin har fået sat visningen til ISO-8859-1. Der kan du blot vælge om.

Men så siger du, indirekte, at der også er nogle tidligere data, der må være i ISO-8859-1. Og det giver jo bøvl.

Hvad du skal gøre afhænger af hvad du tidligere har gjort, men det fremgår ikke spor klart.
Avatar billede morgan_freeman Nybegynder
08. marts 2015 - 22:32 #5
Right. Der er sket en besynderlig udvikling!

Efter diverse forsøg og googlings gjorde jeg noget, der tilsyneladende har fået mit problem til at forsvinde.
Jeg smed "mysql_set_charset('utf8', $connection)" ind i en af mine php-sider - og så skete miraklet. Alting stod som det burde - lige på nær de seneste posteringer, der nu vises med disse besynderlige latinos.

Hvad der forekommer mig ekstra besynderligt er, at det har effekt på alle mine sider! Så jeg går ud fra, at jeg har lavet en form for global forandring der gælder hele min mySQL-forbindelse (hos one.com). Det var sådan set ikke tilsigtet. Jeg troede denne "mysql_set_charset" gjaldt for den aktive side, men det må forholde sig anderledes. Og effekten fortsætter selvom jeg fjerner denne linie i mit php-dokument.

Dermed kan jeg formode, at one.com's php-update har sat et latin/iso-flueben i en fil der ligger hos dem - og som jeg nu har ændret. Men kan det passe? Og har jeg muligvis overskredet mine kundebeføjelser?... Så mange nye spørgsmål, men jeg er glad såvidt ;-)

@erikjacobsen : Din brugerbeskrivelse antyder, at du ikke bekymrer dig om point - og jeg tænker ikke at du, som sådan, har givet mig endegyldigt svar. På den anden side har du gjort dig umage for at hjælpe mig - og det bør, i sig selv, være rigelig grund til at kaste (yderst værdifulde) point i din retning. Smid gerne et svar - så kan du inkassere 15 bob's (ja, jeg indrømmer, det er nærig sum, men mange bække :-) )
Avatar billede realweb Nybegynder
09. marts 2015 - 12:06 #6
UTF-8 er bestemt at foretrække:

- Sørg for at oprette databasen i UTF-8
- Alle filer på hjemmesiden skal være gemt i UTF-8
- Brug <meta charset="utf-8"> i toppen af hjemmesiden for at fortælle browserne, at der anvendes UTF-8

Så virker det altid :-)

Mvh.

Thomas Skytte
Webudvikler
www.realweb.dk
Avatar billede morgan_freeman Nybegynder
09. marts 2015 - 12:23 #7
Tak Realweb/Thomas, men jeg finder ikke dit svar rigtig brugbart.

- databasen er oprettet af one.com, og den genrelle collation både står og stod til UTF-8.
- Alle filer på hjemmesiden var allerede - og er stadig - gemt i UTF-8 (uden BOM)
- Og <meta charset="utf-8"> står og stod i toppen af hjemmesiderne.

Men trods disse faktorer, gik der ged i mine sider efter one.com's updatering.
Det jeg ikke forstår nu, er hvordan det er lykkedes at ændre det. Jeg har aldrig oprettet databasen - eller lavet indstillinger ud over hvad jeg kan se i phpMyAdmin (hvor alt både så og ser rigtigt ud). Jeg medgiver, at det der må være kernen er at fortælle databasen at alt skal foregå i utf-8, men du siger ikke hvordan - og tilsyneladende har jeg allerede gjort det, bare uden helt at vide jeg gjorde noget globalt med "mysql_set_charset('utf8', $connection)" .
Avatar billede realweb Nybegynder
09. marts 2015 - 13:43 #8
Hej Morgan,

Jeg fik ikke læst dit oplæg korrekt. Jeg kan se nu, at du ikke længere har problemer med in/out i utf-8, men kun med den gamle data. Det er fordi, at der sket en forkert konvertering af databasen, hvor den blot er kopieret over et nyt sted uden understøttelse af utf-8. Det er selvfølgelig  One, der er de skyldige. De har dumpet databasen og glemt at sætte utf-8 tagget på, så al dataen nu er fejlkonverteret. Normalt når man dumper en utf-8 database til en dump-fil mhp. kopiering/flytning af indholdet, så skal det ske sådan her:

mysqldump --default-character-set=utf8 --result-file=/tmp/database.sql database

Men nu ligger dataen simpelthen forkert i databasen. Og det er lige meget, hvad du gør, så kommer den forkert ud. Jeg foreslår, at du kontakter One, om hører dem om de kan fikse problemet. Det er jo deres skyld! Hvis de stadig har den gamle database, så kan de måske flytte indholdet korrekt. Ellers må du igang med at finde forkerte utf-8 værdier frem og lave "søg og erstat" på dem. Hvis det ikke er voldsomt mange poster, så kunne du gøre det manuelt. Evt. vi MysqlBuddy, hvorigennem du kan administrere indholdet. Det kan også lade sig gøre i et sql kald:

update table_name set field = replace(field, 'foo', 'bar') where instr(field, 'foo') > 0;

I denne sql bliver field "Hello foo" lavet om til "Hello bar". Så skal du ellers indsætte de forkerte tegn og erstatte dem med æ,ø og å og hvad der ellers måtte være.

Jeg håber, at mit svar kunne bruges denne gang :-)

Thomas Skytte
Webudvikler
www.realweb.dk
Avatar billede morgan_freeman Nybegynder
10. marts 2015 - 21:41 #9
THE FUN CONTINUES!

2 dage hvor alting fungerede efter hensigten - og jeg fik rettet de få nye latino's (Ã¥, ø etc.) manuelt i database. Og nu er balladen tilbage! Det hele ser rigtigt ud i phpMyAdmin (ALT er utf) og mine php-sider er ikke ændret siden jeg skrev seneste indlæg (ALT er utf). Alligevel vises alle danske special-tegn som hvide spørgsmålstegn på sort firkant. Tror det her er en sag for one.com support!
Avatar billede morgan_freeman Nybegynder
11. marts 2015 - 20:51 #10
Seneste udvikling

Jeg har benyttet lejligheden til at tage hul på mysqli - og når jeg gør det (og deklarerer utf-8) så spiller sagerne fint. Men mine gamle mysql-(mysql_query())-sider bliver stadig ved med at vise latin selvom utf er deklareret alle mulige steder! Det er både frustrerende OG uforståeligt.

Har stadig en plan om at kontakte one.com support, men jeg skal lige bygge en clear-cut-case hvor jeg kan henvise til to sider der gør præcis det samme, bare hhv. mysql/mysqli - og se hvad de siger.
Avatar billede morgan_freeman Nybegynder
02. april 2015 - 17:56 #11
one.com support var ikke vildt behjælpelig (men dog venlige)

Jeg tror jeg vil kalde sagen opklaret.

Nu har jeg (endelig(/foreløbig(?)) sider der virker, hvor jeg anvender "mySQLi OOP", alle tabeller i min database er utf8, og jeg deklarerer
1: utf8 i min php-header (header("Content-Type: text/html;charset=UTF-8");)
2: i min html-head (<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">)
3: i min html-form (<form action="" method="post" accept-charset="UTF-8">)
3+: og en slags uft8-tvangs-sneak/hack for I.E. (som jeg btw. aldrig selv bruger) (<input name="iehack" type="hidden" value="&#9760;" />)
4: utf8 i min mySQLi forbindelse ($mysqli->set_charset("utf8");)

Og det spiller (i hvert fald et par dage foreløbig)

@erikjacobsen du kan stadig høste point, men ellers smider jeg selv et svar og lukker (inden længe).
Avatar billede morgan_freeman Nybegynder
05. maj 2015 - 11:27 #12
lukker
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester