05. december 2008 - 22:02Der er
15 kommentarer og 1 løsning
Webforms og UTF-8 encoding
Jeg har en UTF-8 encoded PHP side med et tekst inputfelt. Værdien af inputfeltet bliver sendt til siden selv via POST, hvor den gemmes i en mysql database og efterfølgende vist på siden selv.
Dette virker også fint men, hvis jeg anvender æ å ø bliver disse tegn til mærkelige tegn i databasen. Dog bliver de printet korrekt på siden efter at jeg har submittet webformen. Jeg kan via Firebug se i headeren at værdien af inputfeltet, når den bliver submittet, består af mærkelige tegn der hvor der skulle være æ ø å, hvilket også er det der bliver indsat i databasen.
Jeg har læst forskellige posts herinde og har derfor sikret mig følgende: - <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> er indsat i html headeren. - Min database anvender UTF-8 og utf8_unicode_ci. - Selve php filen er gemt som UTF-8.
Jeg har ikke så meget erfaring i at arbejde med UTF-8 og vil derfor høre om jeg skal forholde mig specielt til webforms når jeg arbejde med UTF-8? Eller hvad gør jeg galt siden at værdien af øæå i inputfeltet bliver til mærkelig tegn både i side-headeren og i databasen?
Jeg håber der er nogen der har nogle bud på hvad jeg gør galt.
"mærkelige tegn i databasen" - hvilket tegnsæt ser du det som? Der er intet mystisk i at æøå i utf-8 ser mærkelige ud, hvis du kigger på den som fx iso-8859-1
Når jeg skriver øæå bliver det til øæå både i headeren i Firebug og i databasen.
Ang. hvilket tegnsæt jeg ser det som, er jeg lidt usikker på hvad du mener. Altså min database er UTF-8 og collation er utf8_unicode_ci og i min html header står der også uft-8. Er det det du mener eller er jeg forkert på den?
Nej når jeg indsætter værdier med øæå i databasen bliver det til disse mærkelige tegn istedet for øæå på trods af at databasen har samme tekst encoding som filen (UTF-8).
Det første gang at jeg arbejdet med UTF-8 og tænkte om jeg skal behandle formdata på en bestemt måde, til forskel fra ISO-8859-1, for at det bliver indsat korrekt i DB'en?
Jeg har fundet ud af at, hvis jeg behandler input værdien med utf8_decode() funktionen bliver øæå indsat korrekt i databasen men til gengæld vist forkert på selve siden (som disse tegn ���).
Jamen, hvem siger det bliver indsat forkert i databasen. Sætter du tegn (æøå især) ind med som utf-8, men kigger på dem som iso-8859-1, så vil det se forkert ud (øæå). Men det betyder blot, at de er indsat korrekt.
Nej Ok, jeg tror også bare at jeg anvender ISO-8859-1. Det kan jeg se virker. Men mange tak for din hjælp erikjacobsen, hvis du smidder et svar så skal du få pointene som tak for din hjælpsomhed.
Nej tak, samler ikke. Svar selv, accepter dit eget svar.
Utf-8 er fint hvis man skal have russiske, arabiske, sanskrit, og vesteuropæiske bogstaver på samme side. Man kan i vores lille smørhul af verden sommetider nøjes med iso-8859-1.
- men vil du være på højde med WWW, bør du bruge utf-8 ... specielt, hvis du ønsker at bruge JavaScript/Ajax. I JavaScript er ANSI-funktionerne til encoding af URL'er og URL-komponenter forlængst deprecated og afløst af Unicode-funktioner.
Hvis du via phpMyAdmin indsætter specialtegn i tabeller, som har utf-8 collationer, og oplever omtalte fejl i et (korrekt kodet, korrekt gemt og korrekt served) utf-8 dokument, er jeg ikke i tvivl om, at der er noget galt med din phpMyAdmin ... uagtet, hvad du selv måtte tro.
På den anden side set er muligheden for, du selv laver fejl, meget stor =)
har lavet et php database script som konverterer alle tabellerne til utf8
<?php
// this script will output the queries need to change all fields/tables to a different collation // it is HIGHLY suggested you take a MySQL dump prior to running any of the generated // this code is provided as is and without any warranty
set_time_limit(0);
// collation you want to change: $convert_from = 'latin1_swedish_ci';
// collation you want to change it to: $convert_to = 'utf8_general_ci';
// character set of new collation: $character_set= 'utf8';
$rs_tables = mysql_query(" SHOW TABLES ") or die(mysql_error());
while ($row_tables = mysql_fetch_row($rs_tables)) { $table = mysql_real_escape_string($row_tables[0]);
// Alter table collation // ALTER TABLE `account` DEFAULT CHARACTER SET utf8 if ($show_alter_table) { echo("ALTER TABLE `$table` DEFAULT CHARACTER SET $character_set;\r\n");
}
$rs = mysql_query(" SHOW FULL FIELDS FROM `$table` ") or die(mysql_error()); while ($row=mysql_fetch_assoc($rs)) {
if ($row['Collation']!=$convert_from) continue;
// Is the field allowed to be null? if ($row['Null']=='YES') { $nullable = ' NULL '; } else { $nullable = ' NOT NULL'; }
// Does the field default to null, a string, or nothing? if ($row['Default']=='NULL') { $default = " DEFAULT NULL"; } else if ($row['Default']!='') { $default = " DEFAULT '".mysql_real_escape_string($row['Default'])."'"; } else { $default = ''; }
// Alter field collation: // ALTER TABLE `account` CHANGE `email` `email` VARCHAR( 50 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL if ($show_alter_field) { $field = mysql_real_escape_string($row['Field']); echo "ALTER TABLE `$table` CHANGE `$field` `$field` $row[Type] CHARACTER SET $character_set COLLATE $convert_to $nullable $default; \r\n";
} } } ?>
Synes godt om
Ny brugerNybegynder
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.