unicode

Le
test windows
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas l'interet
de stocker les données en unicode avec le préfixe N..merci
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fred.M.
Le #11851861
Bonjour,
Oui d'accord et... C'est quoi la question ??

Fred.M

"test windows" a écrit :

Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas l'interet
de stocker les données en unicode avec le préfixe N..merci


Patrice
Le #11851851
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !


"test windows" message de news:
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci


bruno reiter
Le #11851841
Il faut vraiment être sûr de l'avenir!

br

"Patrice" news:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !


"test windows" message de news:
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci






Patrice
Le #11851831
D'un autre côté, il est possible de "trainer" un choix qui ne sera
éventuellement jamais utile (et dans certains cas, nuisible). Ma préférence
personnelle est de travailler pour les situations actuelles et
"raisonnablement" prévisibles.

A l'OP de peser la probabilité de devoir passer un jour relativement pochain
à du texte unicode dans le cadre de son application.

Bon y sont pas prêts d'être mariés ;-)

---
Patrice

"bruno reiter" news:
Il faut vraiment être sûr de l'avenir!

br

"Patrice" news:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !


"test windows" message de news:
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci









Patrice
Le #11851821
D'un autre côté, il est possible de "trainer" un choix qui ne sera
éventuellement jamais utile (et dans certains cas, nuisible). Ma préférence
personnelle est de travailler pour les situations actuelles et
"raisonnablement" prévisibles.

A l'OP de peser la probabilité de devoir passer un jour relativement
prochain à du texte unicode dans le cadre de son application.

Bon y sont pas prêts d'être mariés ;-)

---
Patrice

"bruno reiter" news:
Il faut vraiment être sûr de l'avenir!

br

"Patrice" news:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !


"test windows" message de news:
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci









Sylvain Lafontaine
Le #11851801
Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page Windows
que le serveur SQL; au présent et dans le futur. Prenez pas exemple une
personne vivant en Grèce. Pensez-vous vraiment que son choix de vie est de
toujours avoir un code page français sur sa machine?

Deuxième exemple: j'ai vu dans le passé des gens perdrent un nombre
incalculable d'heures et d'argent à vouloir absolument stocker le symbole
Euro dans un champ varchar tout en restant compatible avec tous leurs
clients européens et internationaux; sans jamais y réussir pour autant.
Utiliser varchar va sauver de l'argent en économisant sur le stockage de
disque dur, qu'ils disaient! Je me demande combien de disques durs et de
barrettes-mémoire ils auraient pu acheter pour leur serveur avec l'argent
perdu à essayer de bidouiller leur histoire.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Patrice" news:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !


"test windows" message de news:
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci






Sylvain Lafontaine
Le #11851791
Quand vous aurez un client francophone du Québec ou en Grèce qui va appeler
votre boss pour savoir pourquoi les lettres accentuées ressemblent à du
chinois et que vous allez passer après pour un incompétent aux yeux de votre
employeur, vous saurez pourquoi.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"test windows" news:
Bonjour;
j'ai une donnée sql 2005 uniquement en français et je ne vois pas
l'interet
de stocker les données en unicode avec le préfixe N..merci


Pierre Goiffon
Le #11851781
Sylvain Lafontaine wrote:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !





Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page Windows
que le serveur SQL; au présent et dans le futur. Prenez pas exemple une
personne vivant en Grèce. Pensez-vous vraiment que son choix de vie est de
toujours avoir un code page français sur sa machine?



?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !

Un Windows asiatique dont le charset par défaut serait GB-2312 pourra
très bien accéder et afficher les données d'un varchar contenant des
données en français dans une table dont la collation est en windows-1252 !

Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée
sur cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.

Donc oui, si l'on a des données uniquement en langues latines, pas
besoin d'utiliser un stockage Unicode.
Sylvain Lafontaine
Le #11851761
Première des choses, vous ne pouvez pas avoir une table dont la collation
est en Windows-1252. Il y a bien des collations 1250 telles que
SQL_Latin1_General_CP1250_CI_AS mais quand MS a introduit la collaton 1252
afin de tenir compte du symbole Euro, cet ajout ne semble pas avoir été
introduit dans les vieilles collations de compatibilité de SQL-Server.
Cependant, je peux me tromper sur ce point particulier surtout que pour moi,
l'utilisation du symbole Euro n'a pas vraiment d'importance.

Pour ce qui est du charset par défaut de l'environmment, il n'y a en pas un
mais deux: il y a l'OEM (à ne pas confondre avec la vente de matériel OEM et
les versions OEM de Windows) et la Windows. Certains clients vont utiliser
l'OEM et d'autres (la majorité) la Windows. Pour ceux qui vont utiliser la
Windows, certains vont encoder les caractères et d'autres pas et parmi ceux
qui vont le faire, certains pourront le faire de façon facultative selon le
choix du mode d'affichage utilisé. Même pour ceux qui ne touchent pas à
l'encodage, certains pilotes pourront faire ou non l'encodage, de façon
obligatoire ou facultative seront un paramètre de configuration. (Cet
encodage par les pilotes est une des raisons majeures pour utiliser le
préfixe N' ). Lorsqu'il y a un paramètre de configuration, ce dernier peut
être situé quelquefois dans la chaîne de connexion; quelquefois dans la base
de registres et quelquefois dans les deux. Il y a aussi les paramètres dans
la base de registres pour d'autres programmes qui peuvent influencer le tout
(voilà quelques années, cela m'a pris plusieurs jours afin de déterminer
pourquoi l'importation à partir de fichiers Excel ne fonctionnait pas
correctement sur les machines sur lesquelles Interbase (la bdd de Borland)
avait aussi été installé avant de trouver qu'Interbase modifiait un
paramètre dans la base de registres pour JET et que la méthode utilisée pour
importer les données à partir d'Excel utilisait JET ODBC.

Vous dites que vous avez toutes les couches intermédiaires pour réaliser les
transcodages nécessaires; j'en suis bien content pour vous! Le problème
est, j'ai déjà appelé en consultation pour régler des problèmes d'encodages
sur des systèmes pour lesquelles le ou les développeurs me disaient qu'il
était impossible qu'il y ait le moindre problème puisqu'ils avaient
supposément toutes les couches nécessaires. S'il est impossible qu'il y ait
un problème, alors pourquoi y en a-t-il un???

La principale raison évoquée pour se casser la tête (et quelquefois les
coui**es) avec l'ANSI sur SQL-Server en est un de performance: on dit
souvent que cela va aller plus vite. Dans la plupart des cas, la différence
est imperceptible ou inutile (la seule différence notable que je connaisse
est avec l'utilisation de l'opérateur LIKE '%xxxx%' et même là, vous êtes
généralement mieux avec l'utilisation d'une deuxième colonne inversée que de
vous fier sur ANSI) et généralement, si vous avez un problème de performance
quelconque, vous êtes mieux d'analyser et de corriger votre design que de
vous fiez sur ANSI à la place d'Unicode.

La seule chose que j'ai vu dans le passé pour ceux qui s'obstinaient à
vouloir conserver l'ANSI à la place d'Unicode a été une perte de temps (et
considérable le plus souvent qu'autrement).

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Pierre Goiffon" news:46dd0f06$0$9225$
Sylvain Lafontaine wrote:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !





Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son choix
de vie est de toujours avoir un code page français sur sa machine?



?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !

Un Windows asiatique dont le charset par défaut serait GB-2312 pourra très
bien accéder et afficher les données d'un varchar contenant des données en
français dans une table dont la collation est en windows-1252 !

Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée sur
cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.

Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.


Patrice
Le #11851741
De mon côté, il me parait un peu extrème de préconiser une utilisation
*systématique* de unicode (ou j'ai mal compris) notamment sans que l'OP ait
précisé si c'est une base interne à l'entreprise, destinée à des clients
internationaux etc (à priori il n'envisage d'utiliser que du français et les
"clients" (au sens technique) ne sont pas précisés)...

De plus, le passage en unicode n'est pas spécialement compliqué à faire si
cela devenait réellement nécessaire un jour.

Ici on a les deux en fonction des besoins. Je ne m'"obstine" pas à garder
ANSI. Je préfère simplement choisir la solution la plus logique et donc pas
d'unicode quand je n'en ai aucunement besoin.

Après je suis d'accord aussi que le pb est parfois un manque de vision
d'ensemble (parfois des pbs lorsqu'on oublie que le codage se maitrise de
bout en bout et que ce n'est pas parce qu'on a de l'unicode en base, qu'il
ne faut pas s'occuper des écritures en fichier, vers les navigateurs etc...)

--
Patrice

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:
Première des choses, vous ne pouvez pas avoir une table dont la collation
est en Windows-1252. Il y a bien des collations 1250 telles que
SQL_Latin1_General_CP1250_CI_AS mais quand MS a introduit la collaton 1252
afin de tenir compte du symbole Euro, cet ajout ne semble pas avoir été
introduit dans les vieilles collations de compatibilité de SQL-Server.
Cependant, je peux me tromper sur ce point particulier surtout que pour
moi, l'utilisation du symbole Euro n'a pas vraiment d'importance.

Pour ce qui est du charset par défaut de l'environmment, il n'y a en pas
un mais deux: il y a l'OEM (à ne pas confondre avec la vente de matériel
OEM et les versions OEM de Windows) et la Windows. Certains clients vont
utiliser l'OEM et d'autres (la majorité) la Windows. Pour ceux qui vont
utiliser la Windows, certains vont encoder les caractères et d'autres pas
et parmi ceux qui vont le faire, certains pourront le faire de façon
facultative selon le choix du mode d'affichage utilisé. Même pour ceux
qui ne touchent pas à l'encodage, certains pilotes pourront faire ou non
l'encodage, de façon obligatoire ou facultative seront un paramètre de
configuration. (Cet encodage par les pilotes est une des raisons majeures
pour utiliser le préfixe N' ). Lorsqu'il y a un paramètre de
configuration, ce dernier peut être situé quelquefois dans la chaîne de
connexion; quelquefois dans la base de registres et quelquefois dans les
deux. Il y a aussi les paramètres dans la base de registres pour d'autres
programmes qui peuvent influencer le tout (voilà quelques années, cela m'a
pris plusieurs jours afin de déterminer pourquoi l'importation à partir de
fichiers Excel ne fonctionnait pas correctement sur les machines sur
lesquelles Interbase (la bdd de Borland) avait aussi été installé avant de
trouver qu'Interbase modifiait un paramètre dans la base de registres pour
JET et que la méthode utilisée pour importer les données à partir d'Excel
utilisait JET ODBC.

Vous dites que vous avez toutes les couches intermédiaires pour réaliser
les transcodages nécessaires; j'en suis bien content pour vous! Le
problème est, j'ai déjà appelé en consultation pour régler des problèmes
d'encodages sur des systèmes pour lesquelles le ou les développeurs me
disaient qu'il était impossible qu'il y ait le moindre problème puisqu'ils
avaient supposément toutes les couches nécessaires. S'il est impossible
qu'il y ait un problème, alors pourquoi y en a-t-il un???

La principale raison évoquée pour se casser la tête (et quelquefois les
coui**es) avec l'ANSI sur SQL-Server en est un de performance: on dit
souvent que cela va aller plus vite. Dans la plupart des cas, la
différence est imperceptible ou inutile (la seule différence notable que
je connaisse est avec l'utilisation de l'opérateur LIKE '%xxxx%' et même
là, vous êtes généralement mieux avec l'utilisation d'une deuxième colonne
inversée que de vous fier sur ANSI) et généralement, si vous avez un
problème de performance quelconque, vous êtes mieux d'analyser et de
corriger votre design que de vous fiez sur ANSI à la place d'Unicode.

La seule chose que j'ai vu dans le passé pour ceux qui s'obstinaient à
vouloir conserver l'ANSI à la place d'Unicode a été une perte de temps (et
considérable le plus souvent qu'autrement).

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Pierre Goiffon" news:46dd0f06$0$9225$
Sylvain Lafontaine wrote:
Que celui qui s'oppose à utiliser VARCHAR pour le stockage de texte
uniquement en français parle maintenant ou se taise à jamais !





Tout simplement parce que vous ne pouvez pas garantir que toutes les
personnes accédant à votre base de données auront le même code page
Windows que le serveur SQL; au présent et dans le futur. Prenez pas
exemple une personne vivant en Grèce. Pensez-vous vraiment que son
choix de vie est de toujours avoir un code page français sur sa machine?



?!!?!!!!!!!
Vous n'avez pas beaucoup développé alors peut être que je rate quelque
chose, mais ce que vous écrivez n'est pas du tout correct !

Un Windows asiatique dont le charset par défaut serait GB-2312 pourra
très bien accéder et afficher les données d'un varchar contenant des
données en français dans une table dont la collation est en windows-1252
!

Il ne faut pas confondre le charset par défaut de l'environnement, le
codage paramétré pour la connexion à la base, et la collation utilisée
sur cette dernière.
On a tous les midleware qui vont bien pour réaliser les transcodages
nécessaires, avec un minimum de compétences et de rigueur cela ne
représente aucun prb.

Donc oui, si l'on a des données uniquement en langues latines, pas besoin
d'utiliser un stockage Unicode.






Publicité
Poster une réponse
Anonyme