I PHP kör jag följande två frågor:

INSERT INTO PRODUCTS SET ID = 1, NAME = "Hammare"
INSERT INTO PRODUCTS SET ID = 2, NAME = "Målarpensel"

Den första frågan fungerar bra. Den andra ger inget felmeddelande. Men raden innehåller inte 2 och "Målarpensel" utan 2 och "" (tom sträng).

Som synes kan jag inte lägga till data som innehåller Å,Ä och Ö. Det blir bara tomma strängar istället för själva datan.

Tabellen har Character Set "latin1" och Collation "latin1_swedish_ci". Finns det någon annan inställning (i php eller Mysql) som kan påverka?

Mina tester visar att det endast är problem att lägga till text med Å, Ä och Ö när jag kör frågan från PHP. Kör jag samma fråga i en mysql-klient i windows så fungerar frågan prima...

Men vad jag vet kan man inte ställa in något default character set i PHP. Och texten ovan är ju uppenbarligen i iso-8859-1.

Jag kör väldigt nya versioner av både php och mysql.

Tacksam för tips om var jag skall börja leta.

Själva sidan måste skicka texten i latin1 också, kolla om den gör det eller om det är utf-8

För att styra upp teckenhanteringen i själva kontakten med Mysql så kan man utfärda följande sql-kommando:
set names='önskad_teckenuppsättning'
där önskad_tecken uppsättning kan till exempel vara:
utf8 eller
latin1

Wokioo: Vilken sida syftar du på? Ingen HTML är inblandad här. Det är ingenting som syns för någon...

Magnus_A: Går det att se vilket teckenuppsättning som jag har just nu?

Edit: Så här ser mina inställningarnai Mysql ut (vet ej om det är relevant):

character_set_client latin1
character_set_connection latin1
character_set_database latin1
character_set_filesystem latin1
character_set_results latin1
character_set_server latin1
character_set_system utf8
collation_connection latin1_swedish_ci
collation_database latin1_swedish_ci
collation_server latin1_swedish_ci

Kanske använder du en terminal i linux? Du måste i så fall ha samma teckenuppsättning i din terminal.

Standard i linux nu för tiden är att terminalerna använder utf-8 istället för iso-8859-1. Eftersom du använder latin1 på tabellerna blir det då naturligtvis fel när du skriver in texten i terminalen.

Det rätta, enligt mig, är att konvertera tabellerna till att använda utf-8. Iso-8859-1 är sakta (för sakta) på väg att fasas ut mot utf-8. Tyvärr innebär detta att verktyg och os från olika leverantörer ändras olika sakta beroende på vilken bakåtkompatibilitet de måste ta hänsyn till. Det måste ju även du och därmed kanske det andra alternativet, att ställa om terminalens teckenuppsättning, är mer rimligt.

Men för all nyutveckling bör man använda utf-8 enligt mig.

dotvoid: Ja, jag har ett batch-script i php som körs via cron.

Jag har plan på att byta till utf-8, men måste nog köra med iso-8859-1 ett tag till...

Hur kan jag ändra så att terminalen använder iso-8859-1, och hur kan jag se om det verkligen är inställt att vara utf-8 just nu?

För att det ska ge effekt i dina php-script ska du utfärda kommandot där ungefär så här, efter att du öppnat kontakten med din server:
mysql_query('set names "latin1"');


För att returnera nuvarande character set för mysql-anslutningen i php, pröva:
mysql_client_encoding()

Edit: Om du kör php som cli är det viktigt att du vet precis vilka character sets som används. Du kan inte räkna med att det är samma som om du kört webversionen

MySQL kan lagra utf8 i latin1 fält, har gjort det och det fungerade bra.

Enda som sker är att specialtecken (ÅÄÖ mfl) blir 2st konstiga tecken istället för 1.

Varför ska du ha två konstiga tecken istället för ett riktigt?

Ja du kan lagra vilka bytes som helst i ett vanligt varchar-fält i mysql. Det är bara bytes oavsett du kör utf-8 eller iso-8859-1 eller något annat. Men du kommer få problem vid visning av data, vid sortering mm. Så det är inte särskilt smart.

Eftersom det är ett batchscript betyder inte terminalens teckenuppsättning något. Det hade bara spelat roll om du skrev saker manuellt i mysql-klienten. Om det är ett batchscript - varifrån kommer datan? Du måste se till att data hela vägen är i iso-8859-1. Om datan finns i batchscriptet av någon anledning bör du kontrollera vilken teckenuppsättning den är sparad i. (Kan göras med utility-programmet "file" - om den bara rapporterar PHP-script kan du döpa om filen till fil.txt först). Du kan om så behövs använda programmet "iconv" för att konvertera filer mellan olika teckenuppsättningar. (cat minfil | iconv -f utf-8 -t iso-8859-1 > minnyafil).

Teckenuppsättningar är struliga innan man vant sig vid att alltid ha stenkoll på hela kedjan. Roligast blir det när utvecklare på gamla windows och utvecklare på linux jobbar i samma projekt...

Ok. Nu har jag provat mysql_query('set names "latin1"') precis i början på mitt script.

mysql_client_encoding() returnerar "latin1".

Men trots detta blir resultatet detsamma som jag beskrev i första posten.

Är det något mer jag kan prova?

Edit: jag har dubbelkollat att datan är i iso-8859-1. Jag är 100% säker.

Jag skrev detta eftersom alla i tråden påpekar att det är fel teckenuppsättning, eftersom mysql klarar av att skriva utf8 i latin1 så är det nog inte det som är felet.

Två konstiga tecken... jo UTF-8 använder ju två bytes för att lagra tecken som inte ingår i basen av iso-8859-1.

Finns bra beskrivningar av utf-8, iso-8859-1 och latin1 samt deras skillnader och förklaring på namngivning etc på wikipedia t ex. Kan vara bra att läsa på. Som programmerare eller utvecklare bör man ha lite koll på det.

Åter till topic:

Jag har nu provat att exekvera exakt samma php-kod, fast denna gång via webbläsaren. Allting fungerade perfekt. All data hamnade i tabellen precis som jag vill.

Det innebär att mitt problem har någonting med cli att göra. Frågan är bara vad...

Tja - någonstans är det högst troligen galet med teckenuppsättningen. PHP i sig har ingen uppfattning om teckenuppsättning. Allt är strängar av bytes. Däremot kan det bli galet om man blandar teckenuppsättningar i data och parametrar till funktioner för strängjämförelser, strängersättning och annat.

Tänk på att om du sitter i ett någolunda modernt linux så används och förutsätts att textfiler, output mm är i utf-8 - inte iso-8859-1. Så om du kör scriptet och printar ut i terminalen och allt ser fint ut så kanske det är utf-8? Se till att batchjobbet genererar en textfil också. Kontrollera den sedan med file.

Det ovan innebär också att om du sitter i mysql-klienten och kikar i databasen kommer strängar med åäö i iso-8859-1 ersättas med ? som standard.

ut.txt: ISO-8859 English text, with very long lines, with CRLF, LF line terminators

Nu har vi analyserat teckenuppsättningen fram och bak, men det har inte löst problemet. Som var att det inte skrevs något i databasen. Normalt ska det skrivas oavsett vilka tecken som strängen innehåller, och inget felmeddelande fanns det heller. Däremot fungerade det bra via terminal, vilket gör mig förbryllad. Här ligger nåt begravet som inte stämmer.

Allting som skrivs till databasen som innehåller Å,Ä och Ö blir istället tom sträng.

Det fungerar bra via windows klient och om man kör samma php-script på webbservern. Felet uppkommer endast om man kör det via kommandoraden.

Jag har kört php_info på både webbservern och från kommandoraden. Allting som har att göra med teckenuppsättningar ser exakt likadant ut.

Jag har kört frågan "SHOW VARIABLES LIKE 'c%'" från både webbservern och kommandoraden. Allt ser likadant ut.

Jag är 100% säker på att sql-frågan som innehåller å, ä och ö tecken är i iso-8859-1. Tabellen är satt till latin1 och mysql_client_encoding() returnerar "latin1" både från kommandoraden och från webbservern.

Jag glömde skriva in och berätta. I måndags när jag provade mitt script så fungerade det. Jag har gjorde inte några förändringar i det - så det är mysko att det bara började fungera hux flux. Men så är det. Måste vara ett tillfälligt fel. Det har fungerat sedan dess...

Tack för hjälpen allesammans!

Tja
Det har oxå betydelse vad filen är sparad i för kodning... Sitter du på en Windows blir kodningen på filen någon Windows iso... Sitter du i putty på en linux skapas filen säkert som UTF och då blir det lätt fel mot Mysql...

Öppna filen i notepad den kan spara i både ISO och UTF!

Annars kör UTF-8 rakt igenom om det går den klarar alla tecken i världen.