Är MyISAM + latin1 standard? Eller borde jag ändra CHARSET=utf8, hur gör man det isåfall anger man bara den röda koden i sitt MySQL Query Browser script?

Om du ändrar till UTF8, så får du ändra anslutning, filer, alla teckenkodningar till UTF8.


latin1 är i princip standard i sverige.

Alla mina html/css sidor använder och sparas i UTF8. Mina SQL script filer sparas också i UTF8 automatiskt i min texteditor.
Men vad menar du med att jag måste ändra anslutning? Syftar du på MySQL anslutningen i min <?php ... ?> kodsnutt.

Typ:

Ojdå lite för avancerad programmeringssyntax för min smak. Är rädd för att jag inte kan kontrollera och testa den här typen av kodning ännu. Tack för tipset iallafall.

Teckenkodningen i PHP är standard iso-8859-1, därför är latin1 standard i mysql kopplingen från PHP.
Du kan använda vilken teckenkodning som helst när du sparar data i php, är htmlsidan i latin1, och du sparar text i utf8 så kommer tecken att se lite skum ut i mysql, men den kommer att visas rätt på sidan.

Det hnn menar är att den första frågan till mysql efter anslutningen och val av databas skall vara:
Vilket kommer att ställa om php's teckenkodning i anslutningen till utf8 (MySQL 4.0 eller senare)

Jag blir inte mycket klokare på det hela efter att ha läst en del om Characters sets och Collations på MySQLs hemsida. Bl.a. det här.
http://dev.mysql.com/doc/refman/5.0/en/cha...t-database.html

När vet man när man ska välja ett specifikt Character set och Collations istället för default som kommer med installationen?
Om jag kör med nedanstående default värden kommer jag få problem med min databas ifall jag nån gång i framtiden ska flytta över databasen till ett webbhotell som inte har sina servrar och kontor i Sverige?
Vad för Character set + Collation bör man köra med för att göra sin databas internationell? Dvs. den ska kunna flyttas mellan olika länders webbhotell utan att det blir problem med datat i databaserna samt databasens skelett.

UTF-8 bör absolut användas som standard åtminstone i alla nya projekt.
Varför: Det är inte svårare, bara man ställer in rätt från början. Det är framtidssäkert, eftersom det fungerar nu och kommer att fungera i alla webbläsare. Och det är synkroniserat med officiell ISO-standard för teckenkodningar ISO/IEC 10646

Den största omedelbara fördelen med att använda UTF-8 är att du t.ex. slipper använda &auml; och kan köra med åäö som vanligt. Däremot så använder du helt andra strängjämförelsefunktioner i PHP (mb_string) vilket gör att du inte helt lätt bara kan gå över till UTF-8. Men vid nya projekt är det värt att överväga.

Ny fråga.

1.) Språk drop down lista.
När man loggar in i phpmyadmin då får man frågan "Språk" med en drop down lista. I listan finns UTF8 i alla möjliga språk om jag idag loggar in med "Swedish UTF8" och lägger in lite tabeller och data. Sedan om en vecka då råkar jag logga in med "Arabic UTF8" och lägger in lite tabeller och data. Får jag en korrupt databas med en massa konflikter i slutändan?

2.) Olika kollationering i en tabell eller mellan tabeller.
Som rubriken säger vad för konsekvenser råkar man ut för då om man har en stor databas med olika kollationering mellan tabeller?

3.) Vad är skillnaden mellan dessa kollationeringar gör dem inte samma sak?
utf8_bin Unicode (flerspråkig), Binär
utf8_general_ci Unicode (flerspråkig), skiftlägesokänsligt
utf8_unicode_ci Unicode (flerspråkig), skiftlägesokänsligt
utf8_swedish_ci Svensk, skiftlägesokänsligt

4.) Webhosten har skapat dessa kollationeringar.
Behöver jag synkronisera alla deras förinstallerade databaser så att dem antingen lyder under "UFT8_general_ci" respektive "LATIN1_swedish_ci" för att saker och ting ska stämma överens med mina egenskapade UTF8 databaser/tabeller?

ÅÄÖ ingår i latin1 så man behöver inte hålla på och mecka med html-entiteter i det fallet.

Haha, sant! :)

Antagligen lär det bli galet, ja, men korrupt? Det kommer nog inte vara troligt att du får rätt resultat i varje fall. Jag har inte använt phpmyadmin själv men det är väl inte helt otroligt om det används en relaterad collation för vald charset och då lär det ju bli knas om du sparar svenska tecken med arabiska sorteringsalgoritmer och regler.

Följande länk ger exempel där det kan bli "fel" resultat om man väljer "fel" collation: http://dev.mysql.com/doc/refman/5.0/...code-sets.html

Fråga #3 får någon annan ta. ;)
(Jag vet inte).


Det ska gå att konvertera från en collation till ett annan i SQL-frågorna, men det är typ allt jag vet. I alla fall, jag hade nog tagit mig tid och gjort det på riktigt (dvs ändra så att det blir rätt i databasen) istället för att hålla på och konvertera mellan olika charsets i applikationen eller i datalagret. På samma sätt som det blir fel när man har en encoding i databasen och en annan i applikationen kan jag tänka mig att det blir knas vid sorteringen, men jag vet inte säkert. Hoppas att någon annan kan hjälpa dig mer.

SELECT * FROM `tabell` order by tabell
utf8_bin Unicode (flerspråkig), Binär =>
+-----+
| A |
| a |
| Ä |
| Å |
| ä |
| å |
+-----+
utf8_general_ci Unicode (flerspråkig), skiftlägesokänsligt 0>
+-----+
| å |
| ä |
| Å |
| Ä |
| a |
| A |
+-----+
utf8_unicode_ci Unicode (flerspråkig), skiftlägesokänsligt =>
+-----+
| å |
| ä |
| Å |
| Ä |
| a |
| A |
+-----+
utf8_swedish_ci Svensk, skiftlägesokänsligt =>
+-----+
| a |
| A |
| å |
| Å |
| ä |
| Ä |
+-----+

ic då kör jag nog med samma kollationering som webhosten har gjort så slipper man tänka så mycket.