Permalänk
Medlem

Charset PHP & MySQL

Är det någon som kan förklara EXAKT hur man skall få charset utf8 att fungera vid överföringen av data från ett formulär till en databas ?

Svenska tecken blir förvrängda när jag fyller i formuläret och trycker på skicka knappen.

HTML dokumentet har utf-8 som charset, PHP filen har UTF-8 som charset, (och tecken på sidan visas korrekt, vilket de annars inte gör om jag tar väck charset).

När jag fyller in värden i datbasen manuellt via php myadmin så visas Å Ä och Ö korrekt i tabellen, men inte om jag skickar formuläret.

Vad gör jag för fel ?
Jag har letat runt på nätet och hittat många som har problem, och alla lösningar verkar vara olika, och det verkar vara olika resultat, det fungerar för vissa men inte andra och så vidare.

Är det fel på mitt html dokument ? Eller mitt php script ? eller min webbläsare? (Har provat både chrome och firefox, får samma resultat)
Förklaring mottages tacksamt

Permalänk
Relik 📜

Testa att slänga in..

mysql_query("SET NAMES utf8"); mysql_query("SET CHARACTER SET utf8");

..i samband med databasanslutningen för att verkligen tvinga utf8.

Visa signatur

För övrigt anser jag att Karthago bör förstöras.
▪ Nöje #1 -> i5-11400F - B560M-ITX/ac - RTX 3070 - 16 GB DDR4
▪ Nöje #2 -> R5 5600 - Prime B450-Plus - GTX 1080 Ti - 16 GB DDR4
▪ Mobilt -> Surface Pro 7 - i5-1035G4 - 8 GB DDR4
▪ Konsol -> Steam Deck, Xbox Series S

Permalänk
Medlem

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf8">
<title>TEST</title>
</head>
<body>
<h2>Teckentest</h2>
<?php

$kommentar = $_POST['kommentar'];

$dbc = mysqli_connect('localhost', 'anvandare', 'losen', 'databas')
or die('Error connecting to MySQL server.');

mysql_query("SET NAMES 'utf8'", $dbc);
mysql_query("SET CHARACTER SET utf8");

$query = "INSERT INTO tabell (kommentar)" .
"VALUES ('$kommentar')";

mysqli_query($dbc, $query)
or die('Error querying database.');

mysqli_close($dbc);

Provade ovanstående, utan resultat igen.

Permalänk
Relik 📜

Du kör ju med mysqli, då får du modifiera mina två strängar med.

Visa signatur

För övrigt anser jag att Karthago bör förstöras.
▪ Nöje #1 -> i5-11400F - B560M-ITX/ac - RTX 3070 - 16 GB DDR4
▪ Nöje #2 -> R5 5600 - Prime B450-Plus - GTX 1080 Ti - 16 GB DDR4
▪ Mobilt -> Surface Pro 7 - i5-1035G4 - 8 GB DDR4
▪ Konsol -> Steam Deck, Xbox Series S

Permalänk
Medlem

Tyvärr fungerade det heller inte.

mysqli_query("SET NAMES 'utf8'", $dbc);
mysqli_query("SET CHARACTER SET utf8");

Permalänk
Relik 📜

Om allt stämmer som du säger, alltså rätt charset överallt, finns det ingen rimlig anledning till att det inte ska fungera. Fyra komponenter måste stämma..
* Dokumentet måste vara sparat med rätt kodning (notepad sparar som ANSI default, t.ex.).
* Rätt teckenkodning måste vara angiven i koden.
* Databasen måste ha rätt kodning angiven.
* Anslutningen måste använda rätt kodning.

Vad jag kan se uppfyller du alla, det är rätt skumt. Vanligt är att faila på första, alltså spara filen som ANSI men ange utf8.. Men, då ska ju alla statiska "specialtecken" bli fel.

Visa signatur

För övrigt anser jag att Karthago bör förstöras.
▪ Nöje #1 -> i5-11400F - B560M-ITX/ac - RTX 3070 - 16 GB DDR4
▪ Nöje #2 -> R5 5600 - Prime B450-Plus - GTX 1080 Ti - 16 GB DDR4
▪ Mobilt -> Surface Pro 7 - i5-1035G4 - 8 GB DDR4
▪ Konsol -> Steam Deck, Xbox Series S

Permalänk
Medlem

Dokument med rätt koding: Jag skapade txt dokument och sparade dessa som utf-8. Jag testade även att göra ett nytt dokument i dreamweaver, det hjälpte heller inte.

Rätt teckenkoding måste vara angiven i koden: Lite osäker, men min kod har jag postat.

Databasen: Den har koding uft8_swedish_ci både i databasen och tabellen.

Anslutningen: Här misstänker jag att felet ligger, men frågan är hur tar jag reda på detta ?

Permalänk
Relik 📜

Det är precis vad "SET NAMES" gör.
MySQL :: MySQL 5.5 Reference Manual :: 9.1.4 Connection Character Sets and Collations

Citat:

SET NAMES indicates what character set the client will use to send SQL statements to the server. Thus, SET NAMES 'cp1251' tells the server, “future incoming messages from this client are in character set cp1251.” It also specifies the character set that the server should use for sending results back to the client. (For example, it indicates what character set to use for column values if you use a SELECT statement.)

EDIT: Verkar som om ditt phpmyadmin är lite felkonfigurerat? Tillåter webbservern du har utf8? Kanske är spärrad till iso-8859-1 eller liknande?

Visa signatur

För övrigt anser jag att Karthago bör förstöras.
▪ Nöje #1 -> i5-11400F - B560M-ITX/ac - RTX 3070 - 16 GB DDR4
▪ Nöje #2 -> R5 5600 - Prime B450-Plus - GTX 1080 Ti - 16 GB DDR4
▪ Mobilt -> Surface Pro 7 - i5-1035G4 - 8 GB DDR4
▪ Konsol -> Steam Deck, Xbox Series S

Permalänk
Medlem

Har varit inne i php.ini filen och ändrat till default_charset = "utf8" och provat även utf-8 (Startat om servern emellan varje sådan här ändring)

Om du råkade se de två bilderna jag laddade upp så var det fel av mig, jag råkade ta det fältet som var rätt och granskade det. (De som är förvrängda är fortfarande förvrängda när jag går in i själva cellen).

Datorn kör Windows Server 2008 Standard (Student edition). Finns det någon spärr där tro ?

Permalänk
Medlem

denna ska du använda: PHP: mysql_set_charset - Manual

samt att databasen måste vara i utf8, fälten måste vara i utf8 och apache måste vara konfat i utf8 och din sida måste vara encodad så att webbbläsaren tolkar den som utf8

tror inte jag glömt något

Permalänk
Medlem

Tack för din hjälp, det löste dock inte problemet, men nu gjorde jag följande sak:

Körde denna:
<?php
$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
$charset = mysql_client_encoding($link);

echo "The current character set is: $charset\n";
?>

Svaret jag får är: The current character set is: latin1

Detta är trots att jag kör med UTF-8 kodad sida.
Det som gör det lite svårt för mig nu är att jag måste ta reda på vad exakt som styr detta.
Har gått in i httpd.conf och lagt till följande rad IndexOptions Charset=UTF-8. Detta hjälpte heller inte.

Om jag går in på servervariabler och inställningar hittar jag följande:

collation connection utf8_swedish_ci
(Globalt värde) latin1_swedish_ci
collation database latin1_swedish_ci
collation server latin1_swedish_c

Hur kollar jag upp vad min databas har för koallitionering, jag kan se vad tabellen har men inte databasen ?

Hittade hur man ändrar ovanstående och nu har jag fått:
collation connection utf8_swedish_ci
(Globalt värde) utf8_general_ci
collation database utf8_general_ci
collation server utf8_general_ci

Men fortfarande när jag ansluter med testfrågan så får jag till svar: latin1 (Servern är omstartad)

Permalänk
Medlem

Äntligen fick jag det att fungera

Av någon anledning så översätts alla queries till latin1, webformulär och alla förfrågningar, trots att det sparas i utf-8.

Gick in i my.ini (Mysql) och la till följande rad init_connect="SET NAMES utf8"
Detta gjorde susen, dock vet jag inte vilka andra följder det kommer att få, då jag inte kan göra ett test och se vad jag får för charset, den funktionen upphör att fungera.

Permalänk
Medlem

Om nu din information är lagrad i databasen som encoding ISO 8859-1 och din sida använder UTF8 så kan du kika på följande funktioner:

utf8_encode()
PHP: utf8_encode - Manual

och

utf8_decode()
PHP: utf8_decode - Manual

Vilket betyder att all data du hämtar ur din databas för utskrift i din sida behöver du använda utf8_encode() på.
Och all data du LAGRAR i din databas eller redigerara och sparar om måste avkodas med utf8_decode() när du skickar in data
i ditt UPDATE eller INSERT statement.

Så har jag jobbat ibland med besvärliga databaser när man inte velat ändra och joxa med encoding i databasen.

Visa signatur

Fractal Design Arc Svart | MSI Z68A-GD55 G3 REV B3 | Intel® Core i7 2600K, 3.4GHz, 8MB | Corsair 16GB (4x4096MB) CL9 1600Mhz VENGEANCE LP | MSI GeForce GTX 670 | Phanteks PH-TC14PE CPU Cooler (vit) | Corsair Power Supply 650W TX M, Modular, ATX, PS/2 | SSD (okänd tillverkare) + 2 äldre SATA2 diskar på 750 Gb, 350 gb. | OS: Microsoft Windows 10 home.

Permalänk
Medlem
Skrivet av BlueEyes:

Om nu din information är lagrad i databasen som encoding ISO 8859-1 och din sida använder UTF8 så kan du kika på följande funktioner:

utf8_encode()
PHP: utf8_encode - Manual

och

utf8_decode()
PHP: utf8_decode - Manual

Vilket betyder att all data du hämtar ur din databas för utskrift i din sida behöver du använda utf8_encode() på.
Och all data du LAGRAR i din databas eller redigerara och sparar om måste avkodas med utf8_decode() när du skickar in data
i ditt UPDATE eller INSERT statement.

Så har jag jobbat ibland med besvärliga databaser när man inte velat ändra och joxa med encoding i databasen.

Jag läste lite granna och började misstänka att det var något sådant som kunde röra sig om.
Jag har UTF8 i databasen, men i själva överföringen sker något konstigt, det blir latin1. Då kanske en översättare borde lösa problemet. Skall prova detta, får återkomma med svar!

Permalänk
Medlem

Sätter du HTTP headers så att webläsaren tolkar det som UTF-8? Det ska man också göra.
header("Content-Type: text/html; charset=utf-8");

Permalänk
Medlem

Ja det gör jag, det är det som gör att den vanliga texten blir rätt. Tyvärr verkade inte PHP koden och MySQL följa charset.

Permalänk
Medlem

Använd Notepad++ och ta "Format" -> "Encode in UTF-8 (without BOM)" på de dokument som problemet uppstår. Om man använder vissa andra editors så händer det att de lägger till BOM-tecken innan header-informationen.
Om du har HTML-kod innan du tar "Notepad++-vägen", så måste du ändra om alla å, ä och ö i dokumentet efter att du har markerat "Encode in UTF-8 (without BOM)".

Om du bara har "Encode in UTF-8" i Notepad++ så tolkar den det på något sätt fel, så alla formulärvärden såsom å, ä och ö blir tokiga.

Detta problem brukar även stå som en "varning" vid validering av webbsidan (om dokumentet innehåller HTML-kod).

EDIT: Glömde säga att du kan sedan skippa alla charsetfunktioner i PHP-dokumenten efter detta, både vid inputdelen och outputdelen.

Visa signatur

POSTCARDS FROM ITALY

Permalänk
Medlem
Skrivet av ViLANDER:

EDIT: Glömde säga att du kan sedan skippa alla charsetfunktioner i PHP-dokumenten efter detta, både vid inputdelen och outputdelen.

Fel! Låt mig förklara ännu en gång.

Det hjälper icke att enbart filen i sig är encodad till låt oss säga UTF8 samt att det i header information anges som encoding UTF8.

Hämtar du då information ifrån en databas där data lagras i låt oss säga ISO-8859-1 format och visar denna i sidan ovan, ja då får du problem garanterat vad det gäller svenska tecken osv.

Då behöver du använda först utf8_encode() på din information innan det "skrivs" ut i sidan som är i UTF8 format.

Detsamma gäller tvärtom då.

Så allt är inte så enkelt som det verkar alla gånger.

Visa signatur

Fractal Design Arc Svart | MSI Z68A-GD55 G3 REV B3 | Intel® Core i7 2600K, 3.4GHz, 8MB | Corsair 16GB (4x4096MB) CL9 1600Mhz VENGEANCE LP | MSI GeForce GTX 670 | Phanteks PH-TC14PE CPU Cooler (vit) | Corsair Power Supply 650W TX M, Modular, ATX, PS/2 | SSD (okänd tillverkare) + 2 äldre SATA2 diskar på 750 Gb, 350 gb. | OS: Microsoft Windows 10 home.

Permalänk
Medlem
Skrivet av BlueEyes:

Fel! Låt mig förklara ännu en gång.

Det hjälper icke att enbart filen i sig är encodad till låt oss säga UTF8 samt att det i header information anges som encoding UTF8.

Hämtar du då information ifrån en databas där data lagras i låt oss säga ISO-8859-1 format och visar denna i sidan ovan, ja då får du problem garanterat vad det gäller svenska tecken osv.

Då behöver du använda först utf8_encode() på din information innan det "skrivs" ut i sidan som är i UTF8 format.

Detsamma gäller tvärtom då.

Så allt är inte så enkelt som det verkar alla gånger.

Inte fel någonstans. Självklart utgick jag ifrån att han hade rätt charset i MySQL.

Visa signatur

POSTCARDS FROM ITALY

Permalänk
Medlem
Skrivet av ViLANDER:

Inte fel någonstans. Självklart utgick jag ifrån att han hade rätt charset i MySQL.

Tyvärr så får man inte enbart förlita sig på att alla andra tänker i samma bana som en själv.
När det gäller rådgivning i forum så får man vara utförlig och ibland övertydlig då alla inte är veteraner som du och jag.

Det finns en hel del nybörjare och om man kan hjälpa dom att inte hamna i för mycket trubbel genom att vara lite tydligare. Ja då är det ju bara ett plus eller hur.

Visa signatur

Fractal Design Arc Svart | MSI Z68A-GD55 G3 REV B3 | Intel® Core i7 2600K, 3.4GHz, 8MB | Corsair 16GB (4x4096MB) CL9 1600Mhz VENGEANCE LP | MSI GeForce GTX 670 | Phanteks PH-TC14PE CPU Cooler (vit) | Corsair Power Supply 650W TX M, Modular, ATX, PS/2 | SSD (okänd tillverkare) + 2 äldre SATA2 diskar på 750 Gb, 350 gb. | OS: Microsoft Windows 10 home.

Permalänk
Medlem
Skrivet av BlueEyes:

Tyvärr så får man inte enbart förlita sig på att alla andra tänker i samma bana som en själv.
När det gäller rådgivning i forum så får man vara utförlig och ibland övertydlig då alla inte är veteraner som du och jag.

Det finns en hel del nybörjare och om man kan hjälpa dom att inte hamna i för mycket trubbel genom att vara lite tydligare. Ja då är det ju bara ett plus eller hur.

Helt korrekt, dock märker man när man läser igenom tråden hur TS fifflar med charset i MySQL.
Strunt i det nu.

Till topic; har TS fortfarande problem?

Visa signatur

POSTCARDS FROM ITALY

Permalänk
Medlem
Skrivet av Ghosty:

Tyvärr fungerade det heller inte.

mysqli_query("SET NAMES 'utf8'", $dbc);
mysqli_query("SET CHARACTER SET utf8");

Läs på manualen om mysqli_query och se vilket argument du har missat.

Permalänk
Medlem

Oj detta utvecklades vidare!

Ja jag har faktiskt problem, jag får ju allt att fungera, men när jag sen skall flytta projektet till en färdig server så har jag fortfarande inte en aning om hur det fungerar.

Vi kan utgå från följande saker:

1. Jag har skapat dokument och testat dessa i Notepad (Som UTF-8), och även skapat dokument i Dreamweaver som UTF-8.
2. Jag får tecken att visas korrekt på själva hemsidan, (å, ä, ö).
3. Jag har korrekt konfigurerat själva databasen för UTF-8, och kan manuellt skriva in å, ä och ö, och det visas korrekt.
4. Har kört "<?php
$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
$charset = mysql_client_encoding($link);

echo "The current character set is: $charset\n";
?>"

Det har hittils resulterat ALLTID latin1, fram tills jag satte följande rad i my.ini (MySQL databasen)
init_connect="SET NAMES utf8"

Detta fick information från formulär att skrivas in rätt i databasen.
5. Detta har då en oanad effekt, jag kan ej längre köra fråga om vilken koding som används får blank sida.
6. Jag förstår fortfarande inte varför problemet uppstår, och varför så många olika människor har problem, och så många olika lösningar löser dessa.
7. Alla försök som syftar till att ange "korrekt" anslutningsmetod fungerar ej, det spelar absolut ingen roll vad jag skriver i själva php koden, informationen blir ändå fel. (Tills jag skrev in raden i my.ini).
8. Jag har läst manualerna både för php, MySQL, Apache utan att bli något klokare på detta, det må vara så enkelt som att mitt förstånd inte klarar detta, men jag misstänker att det är något större än så som är orsaken till problemet.

9.

Skrivet av Elactos:

Läs på manualen om mysqli_query och se vilket argument du har missat.

Jag har varit där och surrat väldigt länge, utan att bli klok på detta, och dessa lösningar har heller ej fungerat för alla som har samma problem som jag.

Servern kör följande:
Windows Server 2008 x86 Student edition.
Apache 2.2.15 (NO SSL)
MySQL 5.1.44
PHP 5.2.13

Så statusen idag är att jag får informationen att infogas rätt i databasen, dock har jag ingen aning om vilka effekter det jag har gjort kommer att ge på sikt i en annan servermiljö, detta är väldigt frustrerande, och jag har ingen riktig lösning som jag känner är 100 % klockren.

Permalänk
Medlem

Har nu verifierat att det inte bara är init_connect="SET NAMES utf8" som gör att det fungerar.
Det är något annat, vet fortfarande inte vad.

Har provat en instans av wordpress på servern bara för skojs skull, och där hamnar alla data rätt, och det visas rätt.
Uppenbarligen gör jag något fel, men jag hittar inte felet.

Jag vill göra ett enkelt formulär och fylla i kommentarer i det formuläret, skicka det till databasen.

Permalänk
Medlem

Sitter i samma båt som Ghosty här. Har gjort precis samma saker innan jag kom till denna tråd. däremot har jag en sida som måste visas bägge svenska och kinesiska.

Permalänk
Medlem

[client]
default-character-set=utf8
[mysqld]
default-character-set=utf8

la in detta i my.ini fick; The current character set is: utf8

riktigt irriterande att detta problem finns fortfarande efter så många år.

EDIT: kom fram till att man behöver bara:

[mysqld]
default-character-set=utf8

inte clientens. verka som allt ligger på mysql sidan?

Permalänk
Medlem

Har ni som har problem testat att göra ett enkelt input.php med Notepad++ istället för att använda andra editors? Har ni testat någon annan lokal webbserver? XAMPP, WAMP etc...

Visa signatur

POSTCARDS FROM ITALY

Permalänk
Medlem
Skrivet av ViLANDER:

Använd Notepad++ och ta "Format" -> "Encode in UTF-8 (without BOM)" på de dokument som problemet uppstår. Om man använder vissa andra editors så händer det att de lägger till BOM-tecken innan header-informationen.
Om du har HTML-kod innan du tar "Notepad++-vägen", så måste du ändra om alla å, ä och ö i dokumentet efter att du har markerat "Encode in UTF-8 (without BOM)".

Om du bara har "Encode in UTF-8" i Notepad++ så tolkar den det på något sätt fel, så alla formulärvärden såsom å, ä och ö blir tokiga.

Detta problem brukar även stå som en "varning" vid validering av webbsidan (om dokumentet innehåller HTML-kod).

EDIT: Glömde säga att du kan sedan skippa alla charsetfunktioner i PHP-dokumenten efter detta, både vid inputdelen och outputdelen.

Skrivet av ViLANDER:

Har ni som har problem testat att göra ett enkelt input.php med Notepad++ istället för att använda andra editors? Har ni testat någon annan lokal webbserver? XAMPP, WAMP etc...

Jag har nu hittat orsaken till problemet.
Det visar sig att "filens" koding har med detta att göra. Men det blir komplicerat.

1. Använder jag UTF-8 format på filen (Dreamweaver, Notepad++, Notepad) så får jag fel när jag skall lägga in värden i tabellen. (Å, Ä, Ö blir förvrängda) (Trots att tabellen är på UTF-8)
2. Använder jag ANSI i filen, då får jag Å, Ä, Ö att skickas korrekt till databasen, men då visas alla tecken fel i själva webbläsaren!
3. Det hjälper INTE att sätta doctype, det löser ej problemet, om doctype inte stämmer överens med filen så visas tecken fel ändå i webbläsaren.

(Edit: Jag har även provat att spara som UTF8 utan BOM)

Frågan är, hur får jag servern att hantera filer i UTF-8 ?

Permalänk
Medlem
Skrivet av Ghosty:

Jag har nu hittat orsaken till problemet.
Det visar sig att "filens" koding har med detta att göra. Men det blir komplicerat.

1. Använder jag UTF-8 format på filen (Dreamweaver, Notepad++, Notepad) så får jag fel när jag skall lägga in värden i tabellen. (Å, Ä, Ö blir förvrängda) (Trots att tabellen är på UTF-8)
2. Använder jag ANSI i filen, då får jag Å, Ä, Ö att skickas korrekt till databasen, men då visas alla tecken fel i själva webbläsaren!
3. Det hjälper INTE att sätta doctype, det löser ej problemet, om doctype inte stämmer överens med filen så visas tecken fel ändå i webbläsaren.

Frågan är, hur får jag servern att hantera filer i UTF-8 ?

Motfråga: var visas tecknena fel om du använder dig av UTF-8 hela vägen? Om du kör med ett CLI-verktyg så är det antagligen terminalfönstret som använder sig av ett dåligt teckensnitt (detta drabbar cmd.exe i Windows-miljöer).

För att allting ska klaffa utan problem skall databasen, samt alla tabeller i den, lämpligtvis ha collation utf8_unicode_ci. Alla filer, HTML som PHP, ska sparas i UTF8 utan BOM (byte-order mark), HTML-filer ska ha meta-tag med utf8-charset. Ingen encoding eller decoding av unicode skall behövas om detta följs. Det kan hända att någon inställning på webservern omvandlar inkommande data till någon 8-bitars encoding, kolla upp det ifall ovanstående inte fungerar.

För övrigt har doctype ingenting med encoding att göra; det är en finess som visar vilken HTML-dialekt sidan säger sig följa.

Visa signatur

Kom-pa-TI-bilitet

Permalänk
Medlem
Skrivet av Teknocide:

Motfråga: var visas tecknena fel om du använder dig av UTF-8 hela vägen? Om du kör med ett CLI-verktyg så är det antagligen terminalfönstret som använder sig av ett dåligt teckensnitt (detta drabbar cmd.exe i Windows-miljöer).

Jag är inte riktigt säker på vad du menar. Jag använder mig inte av några CLI verktyg (Command Line input). Använder PhpMyAdmin för att visa tabellerna.
Det jag gjort är ett enkelt dokument som innehåller en kort "Insert" till databasen, för att kunna experimentera.
Jag skriver PHP kod, senaste testet är två filer en med ansi koding och en med utf8.
Nu fick jag plötsligt ansi att visas korrekt i webbläsaren och i databasen.
UTF8 visas bara rätt i webbläsaren.

[QUOTE=För att allting ska klaffa utan problem skall databasen, samt alla tabeller i den, lämpligtvis ha collation utf8_unicode_ci. Alla filer, HTML som PHP, ska sparas i UTF8 utan BOM (byte-order mark), HTML-filer ska ha meta-tag med utf8-charset. [/QUOTE]

Det är just detta som jag inte riktigt vet om det funkar eller ej.

<?php $kommentar = "Test Å,Ä,Ö å,ä,ö"; $dbc = mysqli_connect('localhost', 'testare', 'testar', 'test') or die('Error connecting to MySQL server.'); $query = "INSERT INTO testtabell (kommentar)" . "VALUES ('$kommentar')"; mysqli_query($dbc, $query) or die('Error querying database.'); echo 'Webläsartest Å, Ä, Ö, å ä ö Du har skrivit in följande' . $kommentar.'<br />'; mysqli_close($dbc); ?>

Den koden ovan använder jag.

Men gör jag följande:

<?php $link = mysql_connect('localhost', 'testare', 'testar'); $charset = mysql_client_encoding($link); echo "The current character set is: $charset\n"; ?>

Kör jag den i en UTF8-Kodad fil så får jag svar "latin1" trots att både databasen och tabellen är utf8

Följande gäller också:
Chrome ANSI filen: Fungerar både i databasen och i webbläsaren.
Chrome UTF8 Bom: Fungerar i webbläsaren men inte i databasen.
Chrome UTF8: Fungerar inte i webbläsaren och fungerar inte i databasen.

Firefox ANSI: Fungerar (nu) både webläsare och databas.
Firefox UTF8 BOM: Fungerar i webbläsare men inte databas.
Firefox UTF8: Fungerar i webbläsare men inte i databas.

Internet explorer ANSI: Fungerar i både webbläsare och databas.
Internet explorer UTF8 Bom: Fungerar i webbläsare men inte databas.
Internet explorer UTF8: Fungerar inte i både webbläsare och databas