Discussion :

[freud]

Bonjour tout le monde,

Artemus24 merci pour tes tests.

Alors comme résoudre ce problème ? En mettant le bon caractère !
C'est le caractère qui se trouve sur la touche 4 de ton clavier "azerty".

C'est vrai j'ai reproduit la chaine depuise le clavier et c'est Ok. Ayant omis de mentionner que le problème est survenu suite à un copier/coller depuis une page web (avec WIN1252), oui pour moi ca ne pose pas de problème mais si l'utilisateur fait la même chose que moi ? Peut-être bien qu'il ne le fera pas mais peut-être que oui et combien y a t -il de caractères pareils qui peuvent poser problème ? Tandis qu'en ISO_8859_1 y a pas ce problème en copiant/collant ce caractère.

C'est le caractère qui se trouve sur la touche 4 de ton clavier "azerty".
Si vous désirez mettre une apostrophe dans une chaîne de caractères, il faut la doubler !

Je n'ai pas de problème avec les apostrophes sauf qu'avec ce copier/coller je n'ai pas fait attention que ce n'etait pas une apostrophe, ce n'etait pas bien visible il a fallut que je post ici pour me rendre compte de la différence.

Utiliser au maximum les caractères de la table ascii car ils sont présents dans tous les charset.

Tu veux dire le charset ASCII ?

[Artemus24]

Salut Freud.

je n'ai pas fait attention que ce n'etait pas une apostrophe

C'est une apostrophe, sauf qu'il existe différent dessin (graphie) pour la représenter.
Il y a l'apostrophe anglaise qui est droite.
Il y a l'apostrophe ouverte ou oblique et fermante qui sont de type française.
ET je parle même pas des apostrophes typographiques.

C'est pareil avec les guillemets.

Tu veux dire le charset ASCII ?

Non, je parle du code allant de 0 à 127 en décimal qui correspond à la table ascii ou alphabet international N°5, et qui est commun à tous les charset.

Problème résolu ou pas ?

@+

[freud]

Ah oui, ah oui, c'est résolu. Le bouton RESOLU à même été activer
Sauf que pour le copier/coller il va falloir soit l'interdire pour ne pas tomber sur ce type d'erreur soit .... bon allez ca suffit comme ça. A chaque chose suffit sa peine. Merci à toi et à tout le monde pour ces participations fructueuses et bonne journée à vous tous.

[alanglet]

Si vous voulez vraiment être tranquille, vous pouvez opter pour l'UTF8. Mais alors il ne faut pas en oublier les conséquences, certaines fonctions manipulant les caractères "uni-octets" qui ne sont plus utilisables, taille du champ en octets multipliée par 4. Ce dernier point n'est pas grave si le champ de ce type est unique, mais si tous les Varchar sont de ce type, les index complexes peuvent devenir trop longs et contraindre à l'adoption d'une taille de page supérieure.

André

[freud]

Bonjour alanglet,

Justement, j'ai démarrer le dev de la BDD avec UTF8 j'ai vu que ca grossissait rapidement je ne me souviens plus comment peut-être en faisant des testes d'import de données alors pour simplifier le travail j'ai opter pour l'ISO_8859_1 tout en gardant en vu le WIN1252. Bon maintenant puisque c'est régler alors le choix est pour le deuxieme. Merci quand même c'est trés gentil.

[Artemus24]

Salut à tous.

Il y a une mauvaise habitude concernant le choix du charset où les débutants préfèrent utiliser de l'UTF-8.
Je rappelle que c'est utf8mb4 qui est sur 4 octets au maximum, et non utf8 qui est au maximum sur 3 octets.

Si vous utilisez du français et accessoirement de l'anglais, pourquoi utiliser de l'UTF-8 alors que de l'ISO-8859-15 ou encore WINDOWS-1252 conviendrai parfaitement.
Il ne faut pas oublier le taux d'occupation qui peut considérablement augmenter.
Les problèmes de débordement des chaînes de caractères variables, calculées sur le nombre de caractères et non sur le nombre d'octets.

Je recommande d'utiliser de bout en bout le même charset.
Ce n'est pas toujours évident car il existe un flou sous windows entre le latin1, l'ansi, le windows-1252 et le iso-8859-1.
La différence repose sur quelques caractères, mais il suffit de les connaitre et de ne pas les utiliser.
Ou encore, d'utiliser la codification HTML mais cela risque de soulever des problèmes pour le collate.

En ce qui concerne le charset, il faut tenir compte de :
--> l'affichage.
--> de l'éditeur de texte.
--> du stockage dans les bases de données.
--> de son transfert entre serveur.
--> de l'usage de certains outils qui par défaut fonctionne dans un autre charset.
--> et je ne parle même pas des polices de caractères.

Les charsets, c'est une casse-tête où parfois, je regrette de ne pas encore travailler avec l'ascii ou l'ebcdic.

@+

[SQLpro]

Salut à tous.

Ça nous fait trois apostrophes différentes à gérer :
--> 0x27 (déci 39) --> table ASCII
--> 0x92 (déci 146) --> WINDOWS_1252
--> 0xB4 (déci 180) --> ISO_8859_1

Le mieux est d'utiliser l'apostrophe de la table ascii.

Utiliser au maximum les caractères de la table ascii car ils sont présents dans tous les charset.

@+

Pour information, la norme SQL à prévue la notion de collation rarement implémentée dans les SGBDR dans son intégralité, sauf sous MS SQL Server.
Rappelons que la notion de collation permet deux niveaux d'interprétation des caractères :
1) collation propre aux jeux de caractères, dites collations "SQL"
2) collation indépendantes des jeux de caractères (dans ce cas le jeux de caractères est par défaut "ISO_1") pour manipuler les particularité des différentes langues
Pour information il y a près de 4000 collations disponible dans SQL Server...

En utilisatant l'opérateur de collation et la bonne collation, ces différences de caractères n'ont aucune importance pour la recherche.

Exemple (sous MS SQL Server) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
WITH T AS
(
SELECT CHAR(39)  AS APOS1, 
       CHAR(146) AS APOS2,
       CHAR(180) AS APOS3
)
SELECT 1 AS APOS FROM T WHERE APOS1 = '''' COLLATE SQL_Latin1_General_CP437_CI_AI
UNION  ALL
SELECT 2 AS APOS FROM T WHERE APOS2 = '''' COLLATE SQL_Latin1_General_CP437_CI_AI
UNION ALL
SELECT 3 AS APOS FROM T WHERE APOS3 = '''' COLLATE SQL_Latin1_General_CP437_CI_AI;

Résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
APOS
-----------
1
2
3

Bref, changez pour un vrai SGBD relationel et non pour un ersatz !

Version gratuite de SQL Server :
Developpeur (pour le développement (aucune limitation) : https://www.microsoft.com/fr-fr/sql-...ons-developers
Experss pour la production : https://www.microsoft.com/fr-fr/sql-...itions-express
Et la version Linux en béta test : https://www.microsoft.com/en-us/sql-...ql-server-2017

Et je confirme ce que dit Artemus, l'utilisation systématique par les développeurs de l'UTF8 est une imbécilité flagrante. Ce type d’encodage a été décidé par les américains pour compresser les flux de données littéraux de la langue anglaise dénuée d’accents et défavoriser les performances de toutes les langues comprenant des accents...

A +

[freud]

Bonjour Artemus24,

Si vous utilisez du français et accessoirement de l'anglais, pourquoi utiliser de l'UTF-8

Parce que je devais aussi utiliser la langue arabe qui nécéssite l'UTF-8 au coté de la langue française. Sinon, pourquoi devrais-je tirer le diable par les cornes avec ce charset ? Bon, après j'ai laisser tomber pour éviter des complications.

En ce qui concerne le charset, il faut tenir compte de :
--> l'affichage.
--> de l'éditeur de texte.
--> du stockage dans les bases de données.
--> de son transfert entre serveur.
--> de l'usage de certains outils qui par défaut fonctionne dans un autre charset.
--> et je ne parle même pas des polices de caractères.

Merci Artemus24 pour tes précieux conseils.