Karaktersets & collation (MySQL): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Regel 1: Regel 1:
Er zijn een paar situaties waarin ik in de knoop raak met verschillende karakterset-coderingen:
+
Amazon en Bol.com gebruiken uitsluitend ''ISO-8850-1 (Latin-1)-''karaktersets voor importbestanden. Ik hoef dus enkel in die karakterset te exporteren.
  
* Export Amazon in het Duits: Diakritische tekens
+
In MySQL wordt de gebruikte karakterset op twee plekken gespecificeerd:
* 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.
+
* Op tabelniveau
 +
* Per kolom.
  
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.
+
Het is goed mogelijk om in een tabel verschillende kolommen in verschillende tekencoderingen te hebben. Sterker nog: Dat gebeurt bij mij voortdurend.
 +
 
 +
== De oplossing - Wat ==
 +
 
 +
* Intern met UTF-8 werken, want open source
 +
* Tijdens exportprocedures wordt meestal een tabel aangemaakt zoals <code>amazon_export</code>. Als ik direct na aanmaken van deze tabel zorg dat-ie 100% Latin 1 is, ben ik klaar.
 +
 
 +
== De oplossing - Hoe ==
 +
 
 +
''' Codering van een tabel uitlezen '''
 +
 
 +
<pre>
 +
SELECT default_character_set_name
 +
FROM information_schema.SCHEMATA
 +
WHERE schema_name = "schemaname";
 +
</pre>
 +
 
 +
== Zie ook ==
 +
 
 +
* [[Bestandscodering achterhalen]]
  
 
== Bronnen ==
 
== Bronnen ==

Versie van 14 mei 2016 11:42

Amazon en Bol.com gebruiken uitsluitend ISO-8850-1 (Latin-1)-karaktersets voor importbestanden. Ik hoef dus enkel in die karakterset te exporteren.

In MySQL wordt de gebruikte karakterset op twee plekken gespecificeerd:

  • Op tabelniveau
  • Per kolom.

Het is goed mogelijk om in een tabel verschillende kolommen in verschillende tekencoderingen te hebben. Sterker nog: Dat gebeurt bij mij voortdurend.

De oplossing - Wat

  • Intern met UTF-8 werken, want open source
  • Tijdens exportprocedures wordt meestal een tabel aangemaakt zoals amazon_export. Als ik direct na aanmaken van deze tabel zorg dat-ie 100% Latin 1 is, ben ik klaar.

De oplossing - Hoe

Codering van een tabel uitlezen

SELECT default_character_set_name 
FROM information_schema.SCHEMATA 
WHERE schema_name = "schemaname";

Zie ook

Bronnen