Karaktersets & collation (MySQL): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
(Nieuwe pagina aangemaakt met '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...')
 
Regel 9: Regel 9:
  
 
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.
 
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/

Versie van 12 dec 2015 22:22

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