Le principe est simple: SQlite3 ne connait que 2 encodages: unicode et utf-8.

Rappel: l'encodage 'utf-8' est aussi un 'unicode', mais Python ne le reconnait que comme un type 'str' et pas un type 'unicode'!

Dans le code Python, tout se passera selon que la ligne suivante existera ou non à la suite de la ligne d'établissement de la connexion:

cnx.text_factory = str

Sans cette ligne pour les chaines de caractères:

• On ne peut écrire que de l'unicode (erreur sinon)

• On ne lit que de l'unicode

Avec cette ligne pour les chaines de caractères:

• On peut écrire de l'unicode ou de l'utf-8

• On ne lit que de l'utf-8 (même pour les données initialement écrites en unicode)

En principe, quand on lit un enregistrement, on récupère les données avec le bon type Python (str ou unicode, int, float, etc…) selon ce qui a été déclaré par le script SQL à la création de la table (TEXT, INTEGER, FLOAT, etc…).

Vis à vis, par exemple, des types SQL: INTEGER, SQlite3 a un comportement curieux dont il faut tenir compte:

• On peut écrire un entier sous forme d'entier (ex: 23) ou sous forme de chaine de caractères (ex: '23'). Dans les 2 cas, on relira un entier, conformément au type SQL.

• On peut écrire une chaine de caractère qui ne soit pas un entier dans un champ entier (ex: 'ZZ'), mais la chaine ne sera pas enregistrée!

Amusez-vous bien!