Karaktersets & collation (MySQL): verschil tussen versies
Naar navigatie springen
Naar zoeken springen
| Regel 17: | Regel 17: | ||
* http://www.garethsprice.com/blog/2011/fix-mysql-latin1-utf-character-encoding/ | * http://www.garethsprice.com/blog/2011/fix-mysql-latin1-utf-character-encoding/ | ||
* http://blog.codekills.net/2012/03/20/in-mysql-latin1-isnt-actually-latin1/ → Oei, moeilijk! | * http://blog.codekills.net/2012/03/20/in-mysql-latin1-isnt-actually-latin1/ → Oei, moeilijk! | ||
| + | * http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html | ||
Versie van 12 dec 2015 20:30
Er zijn een paar situaties waarin ik in de knoop raak met verschillende karakterset-coderingen:
- Export Amazon in het Duits: Diakritische tekens
- Export Bol.com of Amazon: Bijzondere symbolen zoals ø (doorsnede)
- Import Spaanstalig sjabloon Amazon: Diakritische tekens
- Export Amazon in het Spaans: Diakritische tekens.
Voor een deel is dit, omdat zowel Bol.com als Amazon ISO-8859-1 gebruikt, en MySQL iets anders.
Geprefereerde aanpak: Alles in UTF8 doen (of datgene wat het meest universeel en open-source is), en alleen bij exports/imports op het laatste moment van karakterset wisselen. Ik wil zo min mogelijk met die 8859-Microsoft-shit te maken hebben.
Bronnen
- http://mysql.rjweb.org/doc.php/charcoll → Leuk achtergrondartikel + practisch, maar beetje oud
- https://docs.python.org/2/howto/unicode.html → Leuk achtergrondartikel
- http://www.whitesmith.co/blog/latin1-to-utf8/ → Leuk geschreven en mooie vormgeving
- http://www.garethsprice.com/blog/2011/fix-mysql-latin1-utf-character-encoding/
- http://blog.codekills.net/2012/03/20/in-mysql-latin1-isnt-actually-latin1/ → Oei, moeilijk!
- http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html