Med Bouchenafa wrote:Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté la
compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Bonjour Med, merci de ces 2 liens (juste une remarque, ils sont inversés)
très instructifs.
Le 2eme lien (Storage and Performance Effects of Unicode) amène
directement vers un document instructif :
http://msdn.microsoft.com/en-us/library/ms186356.aspx
Qui commence par :
"Collations control the physical storage of character strings in SQL
Server. A collation specifies the bit patterns that represent each
character and the rules by which characters are sorted and compared."
Le codage utilisé pour le stockage fait donc bien partit de la collation
dans SQL Server 2008. Et comme c'était le cas pour SQL Server 2000, je
suppose que c'est le cas pour toutes les versions de SQL Server ?
Tel que je le comprend donc, toutes les collations stockent dans des
codages non Unicode. Si on veut passer par Unicode, il faut utiliser les
nchar/nvarchar, et dans ce cas les "Unicode sorting rules" s'appliquent.
Le document suivant me laisse à penser qu'il y aurait en plus des
collations ne s'appliquant qu'à ces types de champs (et qui permettraient
d'indiquer un ordre de tri / comparaison défini ?) :
http://msdn.microsoft.com/en-us/library/cc879307.aspx
La liste des collations Windows contient de ces "unicode only collations"
:
http://msdn.microsoft.com/en-us/library/ms188046.aspx
Je lis "Unicode-only Windows collations can only be applied to
column-level or expression-level data". ok pour column, mais que veux dire
'expression-level data' ?
Med Bouchenafa wrote:
Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté la
compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Bonjour Med, merci de ces 2 liens (juste une remarque, ils sont inversés)
très instructifs.
Le 2eme lien (Storage and Performance Effects of Unicode) amène
directement vers un document instructif :
http://msdn.microsoft.com/en-us/library/ms186356.aspx
Qui commence par :
"Collations control the physical storage of character strings in SQL
Server. A collation specifies the bit patterns that represent each
character and the rules by which characters are sorted and compared."
Le codage utilisé pour le stockage fait donc bien partit de la collation
dans SQL Server 2008. Et comme c'était le cas pour SQL Server 2000, je
suppose que c'est le cas pour toutes les versions de SQL Server ?
Tel que je le comprend donc, toutes les collations stockent dans des
codages non Unicode. Si on veut passer par Unicode, il faut utiliser les
nchar/nvarchar, et dans ce cas les "Unicode sorting rules" s'appliquent.
Le document suivant me laisse à penser qu'il y aurait en plus des
collations ne s'appliquant qu'à ces types de champs (et qui permettraient
d'indiquer un ordre de tri / comparaison défini ?) :
http://msdn.microsoft.com/en-us/library/cc879307.aspx
La liste des collations Windows contient de ces "unicode only collations"
:
http://msdn.microsoft.com/en-us/library/ms188046.aspx
Je lis "Unicode-only Windows collations can only be applied to
column-level or expression-level data". ok pour column, mais que veux dire
'expression-level data' ?
Med Bouchenafa wrote:Voici ce que Microsoft dit sur le sujet
http://msdn.microsoft.com/en-us/library/ee240835%28SQL.105%29.aspx
Il est cependant certain que l'espace peut-etre est un probleme dans
certains cas.
Sinon comment expliquer que SQL Server 2008 R2 apporte comme nouveauté la
compression Unicode
http://msdn.microsoft.com/en-us/library/ms189617.aspx
Bonjour Med, merci de ces 2 liens (juste une remarque, ils sont inversés)
très instructifs.
Le 2eme lien (Storage and Performance Effects of Unicode) amène
directement vers un document instructif :
http://msdn.microsoft.com/en-us/library/ms186356.aspx
Qui commence par :
"Collations control the physical storage of character strings in SQL
Server. A collation specifies the bit patterns that represent each
character and the rules by which characters are sorted and compared."
Le codage utilisé pour le stockage fait donc bien partit de la collation
dans SQL Server 2008. Et comme c'était le cas pour SQL Server 2000, je
suppose que c'est le cas pour toutes les versions de SQL Server ?
Tel que je le comprend donc, toutes les collations stockent dans des
codages non Unicode. Si on veut passer par Unicode, il faut utiliser les
nchar/nvarchar, et dans ce cas les "Unicode sorting rules" s'appliquent.
Le document suivant me laisse à penser qu'il y aurait en plus des
collations ne s'appliquant qu'à ces types de champs (et qui permettraient
d'indiquer un ordre de tri / comparaison défini ?) :
http://msdn.microsoft.com/en-us/library/cc879307.aspx
La liste des collations Windows contient de ces "unicode only collations"
:
http://msdn.microsoft.com/en-us/library/ms188046.aspx
Je lis "Unicode-only Windows collations can only be applied to
column-level or expression-level data". ok pour column, mais que veux dire
'expression-level data' ?
Je ne suis pas certain de te suivre
Une collation n'a rien á voir avec la presence ou l'absence de l'Unicode
J'ignorais l'existence de ces "Unicode-only Windows" collations.
Elles sont valables uniquement pour des colonnes et expressions *Unicodes*
Tu ne peux pas les utiliser au niveau d'une base sinon quels seraient la
page de code et l'ordre de tri des données non Unicodes
Je ne suis pas certain de te suivre
Une collation n'a rien á voir avec la presence ou l'absence de l'Unicode
J'ignorais l'existence de ces "Unicode-only Windows" collations.
Elles sont valables uniquement pour des colonnes et expressions *Unicodes*
Tu ne peux pas les utiliser au niveau d'une base sinon quels seraient la
page de code et l'ordre de tri des données non Unicodes
Je ne suis pas certain de te suivre
Une collation n'a rien á voir avec la presence ou l'absence de l'Unicode
J'ignorais l'existence de ces "Unicode-only Windows" collations.
Elles sont valables uniquement pour des colonnes et expressions *Unicodes*
Tu ne peux pas les utiliser au niveau d'une base sinon quels seraient la
page de code et l'ordre de tri des données non Unicodes
En 2009, c'est maintenant rendu plus une question de sécurité et de prudence
envers le présent et le futur qu'une question de performance.
Maintenant, on retrouve souvent l'argument qu'avec l'utilisation du code
Windows-1252 (qui corrige le problème du symbole de l'Euro présent dans le
code 1251)
Par example, dans le
newsgroup anglais m.p.sqlserver.programming, il y a ce message posté le
2009/10/06 au sujet d'un problème avec le symbole de la livre britannique £
et le code page SQL_Latin1_General_CP1_CI_AS.
Comme autre example, voici un
extrait d'un courriel reçu d'un client voilà moins de deux semaines:
« ... Il va rester ? vérifier le menu de Notre -Dame-De-Sion (un m?me prix
pour les repas) comme on avais discuté. ... »
Étrangement, le e avec l'accent aigu apparaît correctement mais les
caractères accentués à et ê (ainsi que les è) ont été remplacé par un point
d'interrogation ? et cela était de même pour le reste du message également.
À cela, vous devez ajouter le problème potentiel d'un utilisateur
utilisant une machine configurée de base pour une autre langue que
l'alphabet latin de base; c'est-à-dire le latin étendu ou pire encore,
non-latin. Sur l'internet, les frontières aujourd'hui ont tendance à
s'abattre, pas à s'élever (sauf exception).
2- En 2009, vous avez simplement l'air complètement ridicule si vous n'êtes
pas encore capable de stocker le nom d'un usager utilisant des caractères
latins accentués non-français. Pas besoin d'aller chercher le japonais
comme example pour ça.
Je n'ai jamais dit qu'il ne fait plus utiliser l'ascii mais que
si vous ne connaissez pas la différence entre les deux ou que vous ne savez
pas quoi faire ou que si les besoins sont indéfinies ou que vous ne savez
pas dans quoi vous vous embarquez exactement (genre le client vous jure la
main sur le coeur qu'il n'y aura jamais besoin d'utiliser autre chose que le
code Windows-1252 mais qu'en cas de problème, c'est vous qui allez êtes le
responsable pour corriger le problème à vos frais), l'unicode doit être le
choix par défaut et non pas le contraire.
En 2009, c'est maintenant rendu plus une question de sécurité et de prudence
envers le présent et le futur qu'une question de performance.
Maintenant, on retrouve souvent l'argument qu'avec l'utilisation du code
Windows-1252 (qui corrige le problème du symbole de l'Euro présent dans le
code 1251)
Par example, dans le
newsgroup anglais m.p.sqlserver.programming, il y a ce message posté le
2009/10/06 au sujet d'un problème avec le symbole de la livre britannique £
et le code page SQL_Latin1_General_CP1_CI_AS.
Comme autre example, voici un
extrait d'un courriel reçu d'un client voilà moins de deux semaines:
« ... Il va rester ? vérifier le menu de Notre -Dame-De-Sion (un m?me prix
pour les repas) comme on avais discuté. ... »
Étrangement, le e avec l'accent aigu apparaît correctement mais les
caractères accentués à et ê (ainsi que les è) ont été remplacé par un point
d'interrogation ? et cela était de même pour le reste du message également.
À cela, vous devez ajouter le problème potentiel d'un utilisateur
utilisant une machine configurée de base pour une autre langue que
l'alphabet latin de base; c'est-à-dire le latin étendu ou pire encore,
non-latin. Sur l'internet, les frontières aujourd'hui ont tendance à
s'abattre, pas à s'élever (sauf exception).
2- En 2009, vous avez simplement l'air complètement ridicule si vous n'êtes
pas encore capable de stocker le nom d'un usager utilisant des caractères
latins accentués non-français. Pas besoin d'aller chercher le japonais
comme example pour ça.
Je n'ai jamais dit qu'il ne fait plus utiliser l'ascii mais que
si vous ne connaissez pas la différence entre les deux ou que vous ne savez
pas quoi faire ou que si les besoins sont indéfinies ou que vous ne savez
pas dans quoi vous vous embarquez exactement (genre le client vous jure la
main sur le coeur qu'il n'y aura jamais besoin d'utiliser autre chose que le
code Windows-1252 mais qu'en cas de problème, c'est vous qui allez êtes le
responsable pour corriger le problème à vos frais), l'unicode doit être le
choix par défaut et non pas le contraire.
En 2009, c'est maintenant rendu plus une question de sécurité et de prudence
envers le présent et le futur qu'une question de performance.
Maintenant, on retrouve souvent l'argument qu'avec l'utilisation du code
Windows-1252 (qui corrige le problème du symbole de l'Euro présent dans le
code 1251)
Par example, dans le
newsgroup anglais m.p.sqlserver.programming, il y a ce message posté le
2009/10/06 au sujet d'un problème avec le symbole de la livre britannique £
et le code page SQL_Latin1_General_CP1_CI_AS.
Comme autre example, voici un
extrait d'un courriel reçu d'un client voilà moins de deux semaines:
« ... Il va rester ? vérifier le menu de Notre -Dame-De-Sion (un m?me prix
pour les repas) comme on avais discuté. ... »
Étrangement, le e avec l'accent aigu apparaît correctement mais les
caractères accentués à et ê (ainsi que les è) ont été remplacé par un point
d'interrogation ? et cela était de même pour le reste du message également.
À cela, vous devez ajouter le problème potentiel d'un utilisateur
utilisant une machine configurée de base pour une autre langue que
l'alphabet latin de base; c'est-à-dire le latin étendu ou pire encore,
non-latin. Sur l'internet, les frontières aujourd'hui ont tendance à
s'abattre, pas à s'élever (sauf exception).
2- En 2009, vous avez simplement l'air complètement ridicule si vous n'êtes
pas encore capable de stocker le nom d'un usager utilisant des caractères
latins accentués non-français. Pas besoin d'aller chercher le japonais
comme example pour ça.
Je n'ai jamais dit qu'il ne fait plus utiliser l'ascii mais que
si vous ne connaissez pas la différence entre les deux ou que vous ne savez
pas quoi faire ou que si les besoins sont indéfinies ou que vous ne savez
pas dans quoi vous vous embarquez exactement (genre le client vous jure la
main sur le coeur qu'il n'y aura jamais besoin d'utiliser autre chose que le
code Windows-1252 mais qu'en cas de problème, c'est vous qui allez êtes le
responsable pour corriger le problème à vos frais), l'unicode doit être le
choix par défaut et non pas le contraire.
dans le cas de SQL-Server, toutes les collations
Unicode utilisent le même sous-ensemble (UCS16) d'environ 45 000 caractères.
Il n'y a donc pas de différence de stockage entre les différents collations
unicodes. (Noter que l'unicode complet (non-supporté directement par
SQL-Server) fait au-delà de 350 000 caractères (genre incluant toutes les
langues aborigènes de l'Amérique, etc.) mais ces caractères étendus sont
limités à des besoins particuliers et requièrent des applications
spécialisées.).
Par example,
l'année passée, j'ai rencontré le problème où quelqu'un voulait utiliser
ODBC sur une machine en grec contre un serveur sql en grec avec une base de
donnée en grec mais situés sur un serveur Windows qui lui, n'était pas en
grec et il se retrouvait avec des problèmes d'encodage qui ne pouvait être
résolus qu'en changeant la collation OEM du serveur Windows lui-même
http://msdn.microsoft.com/en-us/library/ms188046.aspx
Je lis "Unicode-only Windows collations can only be applied to
column-level or expression-level data". ok pour column, mais que veux dire
'expression-level data' ?
Par expression-level data, j'imagine qu'il s'agit ici de l'utilisation de la
clause COLLATE directement dans une expression t-sql comme je l'ai fait dans
mon example ci-haut.
dans le cas de SQL-Server, toutes les collations
Unicode utilisent le même sous-ensemble (UCS16) d'environ 45 000 caractères.
Il n'y a donc pas de différence de stockage entre les différents collations
unicodes. (Noter que l'unicode complet (non-supporté directement par
SQL-Server) fait au-delà de 350 000 caractères (genre incluant toutes les
langues aborigènes de l'Amérique, etc.) mais ces caractères étendus sont
limités à des besoins particuliers et requièrent des applications
spécialisées.).
Par example,
l'année passée, j'ai rencontré le problème où quelqu'un voulait utiliser
ODBC sur une machine en grec contre un serveur sql en grec avec une base de
donnée en grec mais situés sur un serveur Windows qui lui, n'était pas en
grec et il se retrouvait avec des problèmes d'encodage qui ne pouvait être
résolus qu'en changeant la collation OEM du serveur Windows lui-même
http://msdn.microsoft.com/en-us/library/ms188046.aspx
Je lis "Unicode-only Windows collations can only be applied to
column-level or expression-level data". ok pour column, mais que veux dire
'expression-level data' ?
Par expression-level data, j'imagine qu'il s'agit ici de l'utilisation de la
clause COLLATE directement dans une expression t-sql comme je l'ai fait dans
mon example ci-haut.
dans le cas de SQL-Server, toutes les collations
Unicode utilisent le même sous-ensemble (UCS16) d'environ 45 000 caractères.
Il n'y a donc pas de différence de stockage entre les différents collations
unicodes. (Noter que l'unicode complet (non-supporté directement par
SQL-Server) fait au-delà de 350 000 caractères (genre incluant toutes les
langues aborigènes de l'Amérique, etc.) mais ces caractères étendus sont
limités à des besoins particuliers et requièrent des applications
spécialisées.).
Par example,
l'année passée, j'ai rencontré le problème où quelqu'un voulait utiliser
ODBC sur une machine en grec contre un serveur sql en grec avec une base de
donnée en grec mais situés sur un serveur Windows qui lui, n'était pas en
grec et il se retrouvait avec des problèmes d'encodage qui ne pouvait être
résolus qu'en changeant la collation OEM du serveur Windows lui-même
http://msdn.microsoft.com/en-us/library/ms188046.aspx
Je lis "Unicode-only Windows collations can only be applied to
column-level or expression-level data". ok pour column, mais que veux dire
'expression-level data' ?
Par expression-level data, j'imagine qu'il s'agit ici de l'utilisation de la
clause COLLATE directement dans une expression t-sql comme je l'ai fait dans
mon example ci-haut.
Sylvain Lafontaine wrote:dans le cas de SQL-Server, toutes les collations Unicode utilisent le
même sous-ensemble (UCS16) d'environ 45 000 caractères. Il n'y a donc pas
de différence de stockage entre les différents collations unicodes.
(Noter que l'unicode complet (non-supporté directement par SQL-Server)
fait au-delà de 350 000 caractères (genre incluant toutes les langues
aborigènes de l'Amérique, etc.) mais ces caractères étendus sont limités
à des besoins particuliers et requièrent des applications spécialisées.).
Vous me semblez commettre quelques erreurs.
UCS-16 n'existe pas. UCS, ça renvoie à ISO-10646, jeux de caractère
compatible avec celui de l'Unicode
(http://www.unicode.org/faq/basic_q.html#6). Et UCS-2 est un codage de
ISO-10646 compatible avec UTF-16, codage du jeux de caractère Unicode.
Les 45k caractères auxquels vous faites référence me semblent correspondre
à UTF-16 moins les surrogate caracters : 63k caractères
(http://www.unicode.org/faq/utf_bom.html#utf16-1), soit UCS-2
(http://www.unicode.org/faq/basic_q.html#14).
Le jeux de caractère Unicode contient dans sa dernière version (5.2)
contient 107 296 caractères
(http://www.unicode.org/versions/Unicode5.2.0/ch01.pdf, chapitre 1.1)Par example, l'année passée, j'ai rencontré le problème où quelqu'un
voulait utiliser ODBC sur une machine en grec contre un serveur sql en
grec avec une base de donnée en grec mais situés sur un serveur Windows
qui lui, n'était pas en grec et il se retrouvait avec des problèmes
d'encodage qui ne pouvait être résolus qu'en changeant la collation OEM
du serveur Windows lui-même
Je suis surpris de voir le codage du serveur intervenir. Avez-vous plus de
détails ?
Sylvain Lafontaine wrote:
dans le cas de SQL-Server, toutes les collations Unicode utilisent le
même sous-ensemble (UCS16) d'environ 45 000 caractères. Il n'y a donc pas
de différence de stockage entre les différents collations unicodes.
(Noter que l'unicode complet (non-supporté directement par SQL-Server)
fait au-delà de 350 000 caractères (genre incluant toutes les langues
aborigènes de l'Amérique, etc.) mais ces caractères étendus sont limités
à des besoins particuliers et requièrent des applications spécialisées.).
Vous me semblez commettre quelques erreurs.
UCS-16 n'existe pas. UCS, ça renvoie à ISO-10646, jeux de caractère
compatible avec celui de l'Unicode
(http://www.unicode.org/faq/basic_q.html#6). Et UCS-2 est un codage de
ISO-10646 compatible avec UTF-16, codage du jeux de caractère Unicode.
Les 45k caractères auxquels vous faites référence me semblent correspondre
à UTF-16 moins les surrogate caracters : 63k caractères
(http://www.unicode.org/faq/utf_bom.html#utf16-1), soit UCS-2
(http://www.unicode.org/faq/basic_q.html#14).
Le jeux de caractère Unicode contient dans sa dernière version (5.2)
contient 107 296 caractères
(http://www.unicode.org/versions/Unicode5.2.0/ch01.pdf, chapitre 1.1)
Par example, l'année passée, j'ai rencontré le problème où quelqu'un
voulait utiliser ODBC sur une machine en grec contre un serveur sql en
grec avec une base de donnée en grec mais situés sur un serveur Windows
qui lui, n'était pas en grec et il se retrouvait avec des problèmes
d'encodage qui ne pouvait être résolus qu'en changeant la collation OEM
du serveur Windows lui-même
Je suis surpris de voir le codage du serveur intervenir. Avez-vous plus de
détails ?
Sylvain Lafontaine wrote:dans le cas de SQL-Server, toutes les collations Unicode utilisent le
même sous-ensemble (UCS16) d'environ 45 000 caractères. Il n'y a donc pas
de différence de stockage entre les différents collations unicodes.
(Noter que l'unicode complet (non-supporté directement par SQL-Server)
fait au-delà de 350 000 caractères (genre incluant toutes les langues
aborigènes de l'Amérique, etc.) mais ces caractères étendus sont limités
à des besoins particuliers et requièrent des applications spécialisées.).
Vous me semblez commettre quelques erreurs.
UCS-16 n'existe pas. UCS, ça renvoie à ISO-10646, jeux de caractère
compatible avec celui de l'Unicode
(http://www.unicode.org/faq/basic_q.html#6). Et UCS-2 est un codage de
ISO-10646 compatible avec UTF-16, codage du jeux de caractère Unicode.
Les 45k caractères auxquels vous faites référence me semblent correspondre
à UTF-16 moins les surrogate caracters : 63k caractères
(http://www.unicode.org/faq/utf_bom.html#utf16-1), soit UCS-2
(http://www.unicode.org/faq/basic_q.html#14).
Le jeux de caractère Unicode contient dans sa dernière version (5.2)
contient 107 296 caractères
(http://www.unicode.org/versions/Unicode5.2.0/ch01.pdf, chapitre 1.1)Par example, l'année passée, j'ai rencontré le problème où quelqu'un
voulait utiliser ODBC sur une machine en grec contre un serveur sql en
grec avec une base de donnée en grec mais situés sur un serveur Windows
qui lui, n'était pas en grec et il se retrouvait avec des problèmes
d'encodage qui ne pouvait être résolus qu'en changeant la collation OEM
du serveur Windows lui-même
Je suis surpris de voir le codage du serveur intervenir. Avez-vous plus de
détails ?
Sylvain Lafontaine wrote:En 2009, c'est maintenant rendu plus une question de sécurité et de
prudence envers le présent et le futur qu'une question de performance.
J'avais posé la question des manipulations à effectuer pour transformer
des données stockées en charset 8 bit vers de l'Unicode et je ne me
souviens pas avoir vu de réponse (et en rebalayant rapidement je n'en vois
toujours pas). Ce serait bien d'étayer la discussion de données précises
sur ce point crucial!
Tel que je le comprend, on ajoute un champ nchar ou nvarchar, on fait une
copie de l'ancien champ, on supprime l'ancien, on renomme le nouveau ? Et
après évidemment adaptation des applications clientes (mais je ne connais
pas de langage moderne qui auraient des prb avec ça ?)
Ca ne parait pas insurmontable ? Mais je dois rater des choses à vous
lire...
Maintenant, on retrouve souvent l'argument qu'avec l'utilisation du code
Windows-1252 (qui corrige le problème du symbole de l'Euro présent dans
le code 1251)
Vous semblez faire une confusion : si 1251 est pour Windows-1251, c'est un
codage dédié aux langues d'Europe de l'est (liste caractères contenus sur
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT -
au passage si vous connaissez de tels documents disponibles chez
Microsoft, je suis preneur)
Par example, dans le newsgroup anglais m.p.sqlserver.programming, il y a
ce message posté le 2009/10/06 au sujet d'un problème avec le symbole de
la livre britannique £ et le code page SQL_Latin1_General_CP1_CI_AS.
La livre anglaise (U+0031) est bien inclue dans ISO Latin-1 :
http://www.miakinen.net/vrac/charsets/?hv=h&o6=MacRoman&or=2&pr3
Je ne sais pas quelle était la source de ce prb (je ne suis pas abonné à
ce newsgroup te j'ai la flemme d'aller chercher sur google groups,
auriez-vous au moins un message-id ?) mais il me parait excessif d'accuser
le stockage sur un charset 8 bits.
Comme autre example, voici un extrait d'un courriel reçu d'un client
voilà moins de deux semaines:
« ... Il va rester ? vérifier le menu de Notre -Dame-De-Sion (un m?me
prix pour les repas) comme on avais discuté. ... »
Étrangement, le e avec l'accent aigu apparaît correctement mais les
caractères accentués à et ê (ainsi que les è) ont été remplacé par un
point d'interrogation ? et cela était de même pour le reste du message
également.
Je ne comprend pas ce que vous voulez démontrer ? Que lorsque les choses
sont mal faites et/ou mal maîtrisées on a des prb ? Ce n'ets pas une
découverte...À cela, vous devez ajouter le problème potentiel d'un utilisateur
utilisant une machine configurée de base pour une autre langue que
l'alphabet latin de base; c'est-à-dire le latin étendu ou pire encore,
non-latin. Sur l'internet, les frontières aujourd'hui ont tendance à
s'abattre, pas à s'élever (sauf exception).
Je ne comprend pas du tout votre propos. "Configuré de base" ne m'évoque
rien de bon, car lorsque l'on envoi un flux de données à une machine on
doit *toujours* préciser la nature de ce que l'on envoie, et le codage
notamment. Ce "configuré de base" me laisse à penser à un envoi sans
charset précisé, ce qui est plus qu'une mauvaise pratique, une faute.
2- En 2009, vous avez simplement l'air complètement ridicule si vous
n'êtes pas encore capable de stocker le nom d'un usager utilisant des
caractères latins accentués non-français. Pas besoin d'aller chercher le
japonais comme example pour ça.
??Je n'ai jamais dit qu'il ne fait plus utiliser l'ascii mais que si vous
ne connaissez pas la différence entre les deux ou que vous ne savez pas
quoi faire ou que si les besoins sont indéfinies ou que vous ne savez pas
dans quoi vous vous embarquez exactement (genre le client vous jure la
main sur le coeur qu'il n'y aura jamais besoin d'utiliser autre chose que
le code Windows-1252 mais qu'en cas de problème, c'est vous qui allez
êtes le responsable pour corriger le problème à vos frais), l'unicode
doit être le choix par défaut et non pas le contraire.
Vous m'inquiétez énormément en évoquant un choix par défaut si l'on ne
sait pas ce qu'est ascii et unicode. Que dans le monde réel de nombreux
développeurs et administrateurs ne se soucient pas de charset et fassent
au petit bonheur la chance, c'est une réalité. Mais je ne recommanderai
jamais un choix sans expliquer la raison dudit choix ! Et donc, tout le
monde devrait avoir un minimum de culture dans le domaine des charset, et
choisir de manière éclairée.
En ce qui concerne l'inconnu de ce que l'on va stocker à terme, j'en
convient avec vous, il faut en effet souvent privilégier l'ouverture car
il a fort à parier que si l'on ne sait pas aujourd'hui si l'on va s'ouvrir
à un marché asiatique par exemple ça arrivera demain.
Sylvain Lafontaine wrote:
En 2009, c'est maintenant rendu plus une question de sécurité et de
prudence envers le présent et le futur qu'une question de performance.
J'avais posé la question des manipulations à effectuer pour transformer
des données stockées en charset 8 bit vers de l'Unicode et je ne me
souviens pas avoir vu de réponse (et en rebalayant rapidement je n'en vois
toujours pas). Ce serait bien d'étayer la discussion de données précises
sur ce point crucial!
Tel que je le comprend, on ajoute un champ nchar ou nvarchar, on fait une
copie de l'ancien champ, on supprime l'ancien, on renomme le nouveau ? Et
après évidemment adaptation des applications clientes (mais je ne connais
pas de langage moderne qui auraient des prb avec ça ?)
Ca ne parait pas insurmontable ? Mais je dois rater des choses à vous
lire...
Maintenant, on retrouve souvent l'argument qu'avec l'utilisation du code
Windows-1252 (qui corrige le problème du symbole de l'Euro présent dans
le code 1251)
Vous semblez faire une confusion : si 1251 est pour Windows-1251, c'est un
codage dédié aux langues d'Europe de l'est (liste caractères contenus sur
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT -
au passage si vous connaissez de tels documents disponibles chez
Microsoft, je suis preneur)
Par example, dans le newsgroup anglais m.p.sqlserver.programming, il y a
ce message posté le 2009/10/06 au sujet d'un problème avec le symbole de
la livre britannique £ et le code page SQL_Latin1_General_CP1_CI_AS.
La livre anglaise (U+0031) est bien inclue dans ISO Latin-1 :
http://www.miakinen.net/vrac/charsets/?hv=h&o6=MacRoman&or=2&pr3
Je ne sais pas quelle était la source de ce prb (je ne suis pas abonné à
ce newsgroup te j'ai la flemme d'aller chercher sur google groups,
auriez-vous au moins un message-id ?) mais il me parait excessif d'accuser
le stockage sur un charset 8 bits.
Comme autre example, voici un extrait d'un courriel reçu d'un client
voilà moins de deux semaines:
« ... Il va rester ? vérifier le menu de Notre -Dame-De-Sion (un m?me
prix pour les repas) comme on avais discuté. ... »
Étrangement, le e avec l'accent aigu apparaît correctement mais les
caractères accentués à et ê (ainsi que les è) ont été remplacé par un
point d'interrogation ? et cela était de même pour le reste du message
également.
Je ne comprend pas ce que vous voulez démontrer ? Que lorsque les choses
sont mal faites et/ou mal maîtrisées on a des prb ? Ce n'ets pas une
découverte...
À cela, vous devez ajouter le problème potentiel d'un utilisateur
utilisant une machine configurée de base pour une autre langue que
l'alphabet latin de base; c'est-à-dire le latin étendu ou pire encore,
non-latin. Sur l'internet, les frontières aujourd'hui ont tendance à
s'abattre, pas à s'élever (sauf exception).
Je ne comprend pas du tout votre propos. "Configuré de base" ne m'évoque
rien de bon, car lorsque l'on envoi un flux de données à une machine on
doit *toujours* préciser la nature de ce que l'on envoie, et le codage
notamment. Ce "configuré de base" me laisse à penser à un envoi sans
charset précisé, ce qui est plus qu'une mauvaise pratique, une faute.
2- En 2009, vous avez simplement l'air complètement ridicule si vous
n'êtes pas encore capable de stocker le nom d'un usager utilisant des
caractères latins accentués non-français. Pas besoin d'aller chercher le
japonais comme example pour ça.
??
Je n'ai jamais dit qu'il ne fait plus utiliser l'ascii mais que si vous
ne connaissez pas la différence entre les deux ou que vous ne savez pas
quoi faire ou que si les besoins sont indéfinies ou que vous ne savez pas
dans quoi vous vous embarquez exactement (genre le client vous jure la
main sur le coeur qu'il n'y aura jamais besoin d'utiliser autre chose que
le code Windows-1252 mais qu'en cas de problème, c'est vous qui allez
êtes le responsable pour corriger le problème à vos frais), l'unicode
doit être le choix par défaut et non pas le contraire.
Vous m'inquiétez énormément en évoquant un choix par défaut si l'on ne
sait pas ce qu'est ascii et unicode. Que dans le monde réel de nombreux
développeurs et administrateurs ne se soucient pas de charset et fassent
au petit bonheur la chance, c'est une réalité. Mais je ne recommanderai
jamais un choix sans expliquer la raison dudit choix ! Et donc, tout le
monde devrait avoir un minimum de culture dans le domaine des charset, et
choisir de manière éclairée.
En ce qui concerne l'inconnu de ce que l'on va stocker à terme, j'en
convient avec vous, il faut en effet souvent privilégier l'ouverture car
il a fort à parier que si l'on ne sait pas aujourd'hui si l'on va s'ouvrir
à un marché asiatique par exemple ça arrivera demain.
Sylvain Lafontaine wrote:En 2009, c'est maintenant rendu plus une question de sécurité et de
prudence envers le présent et le futur qu'une question de performance.
J'avais posé la question des manipulations à effectuer pour transformer
des données stockées en charset 8 bit vers de l'Unicode et je ne me
souviens pas avoir vu de réponse (et en rebalayant rapidement je n'en vois
toujours pas). Ce serait bien d'étayer la discussion de données précises
sur ce point crucial!
Tel que je le comprend, on ajoute un champ nchar ou nvarchar, on fait une
copie de l'ancien champ, on supprime l'ancien, on renomme le nouveau ? Et
après évidemment adaptation des applications clientes (mais je ne connais
pas de langage moderne qui auraient des prb avec ça ?)
Ca ne parait pas insurmontable ? Mais je dois rater des choses à vous
lire...
Maintenant, on retrouve souvent l'argument qu'avec l'utilisation du code
Windows-1252 (qui corrige le problème du symbole de l'Euro présent dans
le code 1251)
Vous semblez faire une confusion : si 1251 est pour Windows-1251, c'est un
codage dédié aux langues d'Europe de l'est (liste caractères contenus sur
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT -
au passage si vous connaissez de tels documents disponibles chez
Microsoft, je suis preneur)
Par example, dans le newsgroup anglais m.p.sqlserver.programming, il y a
ce message posté le 2009/10/06 au sujet d'un problème avec le symbole de
la livre britannique £ et le code page SQL_Latin1_General_CP1_CI_AS.
La livre anglaise (U+0031) est bien inclue dans ISO Latin-1 :
http://www.miakinen.net/vrac/charsets/?hv=h&o6=MacRoman&or=2&pr3
Je ne sais pas quelle était la source de ce prb (je ne suis pas abonné à
ce newsgroup te j'ai la flemme d'aller chercher sur google groups,
auriez-vous au moins un message-id ?) mais il me parait excessif d'accuser
le stockage sur un charset 8 bits.
Comme autre example, voici un extrait d'un courriel reçu d'un client
voilà moins de deux semaines:
« ... Il va rester ? vérifier le menu de Notre -Dame-De-Sion (un m?me
prix pour les repas) comme on avais discuté. ... »
Étrangement, le e avec l'accent aigu apparaît correctement mais les
caractères accentués à et ê (ainsi que les è) ont été remplacé par un
point d'interrogation ? et cela était de même pour le reste du message
également.
Je ne comprend pas ce que vous voulez démontrer ? Que lorsque les choses
sont mal faites et/ou mal maîtrisées on a des prb ? Ce n'ets pas une
découverte...À cela, vous devez ajouter le problème potentiel d'un utilisateur
utilisant une machine configurée de base pour une autre langue que
l'alphabet latin de base; c'est-à-dire le latin étendu ou pire encore,
non-latin. Sur l'internet, les frontières aujourd'hui ont tendance à
s'abattre, pas à s'élever (sauf exception).
Je ne comprend pas du tout votre propos. "Configuré de base" ne m'évoque
rien de bon, car lorsque l'on envoi un flux de données à une machine on
doit *toujours* préciser la nature de ce que l'on envoie, et le codage
notamment. Ce "configuré de base" me laisse à penser à un envoi sans
charset précisé, ce qui est plus qu'une mauvaise pratique, une faute.
2- En 2009, vous avez simplement l'air complètement ridicule si vous
n'êtes pas encore capable de stocker le nom d'un usager utilisant des
caractères latins accentués non-français. Pas besoin d'aller chercher le
japonais comme example pour ça.
??Je n'ai jamais dit qu'il ne fait plus utiliser l'ascii mais que si vous
ne connaissez pas la différence entre les deux ou que vous ne savez pas
quoi faire ou que si les besoins sont indéfinies ou que vous ne savez pas
dans quoi vous vous embarquez exactement (genre le client vous jure la
main sur le coeur qu'il n'y aura jamais besoin d'utiliser autre chose que
le code Windows-1252 mais qu'en cas de problème, c'est vous qui allez
êtes le responsable pour corriger le problème à vos frais), l'unicode
doit être le choix par défaut et non pas le contraire.
Vous m'inquiétez énormément en évoquant un choix par défaut si l'on ne
sait pas ce qu'est ascii et unicode. Que dans le monde réel de nombreux
développeurs et administrateurs ne se soucient pas de charset et fassent
au petit bonheur la chance, c'est une réalité. Mais je ne recommanderai
jamais un choix sans expliquer la raison dudit choix ! Et donc, tout le
monde devrait avoir un minimum de culture dans le domaine des charset, et
choisir de manière éclairée.
En ce qui concerne l'inconnu de ce que l'on va stocker à terme, j'en
convient avec vous, il faut en effet souvent privilégier l'ouverture car
il a fort à parier que si l'on ne sait pas aujourd'hui si l'on va s'ouvrir
à un marché asiatique par exemple ça arrivera demain.
J'avais posé la question des manipulations à effectuer pour transformer
des données stockées en charset 8 bit vers de l'Unicode et je ne me
souviens pas avoir vu de réponse (et en rebalayant rapidement je n'en vois
toujours pas). Ce serait bien d'étayer la discussion de données précises
sur ce point crucial!
Par sûr de vraiment comprendre votre question car cela peut vouloir dire
plusieurs choses différentes et la procédure à suivre dépend de la situation
exacte de ce que vous avez en ce moment.
Tel que je le comprend, on ajoute un champ nchar ou nvarchar, on fait une
copie de l'ancien champ, on supprime l'ancien, on renomme le nouveau ?
Cela n'est pas insurmontable mais cela peut quelque fois (ou souvent) une
charge de travail beaucoup plus lourde que ce que vous prévoyez
actuellement. À titre d'example, pensez simplement aux cas d'entreprises où
chaque modification, aussi petite soit-elle, exige d'être complètement
documentée, justifiée, approuvée et testée avant dêtre finalement déployée.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori il
paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une. Même chose pour les accents français: s'il
n'y a pas d'erreur, tout est correct mais s'il y en a une, plusieurs vont
vous dire qu'ils utilisent déjà Windows-1252 et que par conséquent, cela est
complètement impossible qu'il y ait une erreur. Par conséquent, pour eux,
la seule possibilité qui reste, c'est qu'il y a un bug dans le serveur sql
lui-même. Si vous dites-cela, vous risquez d'avoir à attendre bien
longtemps avoir de recevoir un correctif de MS à ce problème là.
Ici, la configuration de base indique tout simplement les deux choix de code
page pour une machine windows: l'OEM et le Window. Que vous le vouliez ou
non, ces deux choix ont de l'importance lorsque vous utiliser des charsets 8
bit et vous ne pouvez pas commencer à vous amuser à changer ces codes pages
tout le temps.
Vous m'inquiétez énormément en évoquant un choix par défaut si l'on ne
sait pas ce qu'est ascii et unicode. Que dans le monde réel de nombreux
développeurs et administrateurs ne se soucient pas de charset et fassent
au petit bonheur la chance, c'est une réalité. Mais je ne recommanderai
jamais un choix sans expliquer la raison dudit choix ! Et donc, tout le
monde devrait avoir un minimum de culture dans le domaine des charset, et
choisir de manière éclairée.
Peut-être mais vous oubliez qu'avoir un choix éclairé là-dessus demande de
l'étude, du temps, et du travail et que tout cela n'est pas gratuit et coûte
quelque chose. En 1990, cela était justifiable que de demander à un dba
d'étudier les charsets et de consacrer du temps et de l'argent là-dessus.
En 2009, cela n'est plus justifiable dans la majorité des cas: les charsets
sont une culture du passé et comme avec toutes les autres cultures du passé,
c'est à ceux qui veulent continuer à travailler avec qui ont le fardeau de
la preuve. L'unicode est maintenant rendu le standard moderne et
mondialement reconnu. Vous pouvez choisir d'utiliser autre chose que
l'unicode - pour les raisons que vous voulez, bonnes ou mauvaises - mais
vous vous écartez alors du standard et c'est dans ce cas là que vous avez à
expliquer votre choix si on vous le demande. Ce n'est pas ceux qui veulent
suivrent les standards qui ont des comptes à rendre, c'est les autres qui en
ont.
J'avais posé la question des manipulations à effectuer pour transformer
des données stockées en charset 8 bit vers de l'Unicode et je ne me
souviens pas avoir vu de réponse (et en rebalayant rapidement je n'en vois
toujours pas). Ce serait bien d'étayer la discussion de données précises
sur ce point crucial!
Par sûr de vraiment comprendre votre question car cela peut vouloir dire
plusieurs choses différentes et la procédure à suivre dépend de la situation
exacte de ce que vous avez en ce moment.
Tel que je le comprend, on ajoute un champ nchar ou nvarchar, on fait une
copie de l'ancien champ, on supprime l'ancien, on renomme le nouveau ?
Cela n'est pas insurmontable mais cela peut quelque fois (ou souvent) une
charge de travail beaucoup plus lourde que ce que vous prévoyez
actuellement. À titre d'example, pensez simplement aux cas d'entreprises où
chaque modification, aussi petite soit-elle, exige d'être complètement
documentée, justifiée, approuvée et testée avant dêtre finalement déployée.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori il
paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une. Même chose pour les accents français: s'il
n'y a pas d'erreur, tout est correct mais s'il y en a une, plusieurs vont
vous dire qu'ils utilisent déjà Windows-1252 et que par conséquent, cela est
complètement impossible qu'il y ait une erreur. Par conséquent, pour eux,
la seule possibilité qui reste, c'est qu'il y a un bug dans le serveur sql
lui-même. Si vous dites-cela, vous risquez d'avoir à attendre bien
longtemps avoir de recevoir un correctif de MS à ce problème là.
Ici, la configuration de base indique tout simplement les deux choix de code
page pour une machine windows: l'OEM et le Window. Que vous le vouliez ou
non, ces deux choix ont de l'importance lorsque vous utiliser des charsets 8
bit et vous ne pouvez pas commencer à vous amuser à changer ces codes pages
tout le temps.
Vous m'inquiétez énormément en évoquant un choix par défaut si l'on ne
sait pas ce qu'est ascii et unicode. Que dans le monde réel de nombreux
développeurs et administrateurs ne se soucient pas de charset et fassent
au petit bonheur la chance, c'est une réalité. Mais je ne recommanderai
jamais un choix sans expliquer la raison dudit choix ! Et donc, tout le
monde devrait avoir un minimum de culture dans le domaine des charset, et
choisir de manière éclairée.
Peut-être mais vous oubliez qu'avoir un choix éclairé là-dessus demande de
l'étude, du temps, et du travail et que tout cela n'est pas gratuit et coûte
quelque chose. En 1990, cela était justifiable que de demander à un dba
d'étudier les charsets et de consacrer du temps et de l'argent là-dessus.
En 2009, cela n'est plus justifiable dans la majorité des cas: les charsets
sont une culture du passé et comme avec toutes les autres cultures du passé,
c'est à ceux qui veulent continuer à travailler avec qui ont le fardeau de
la preuve. L'unicode est maintenant rendu le standard moderne et
mondialement reconnu. Vous pouvez choisir d'utiliser autre chose que
l'unicode - pour les raisons que vous voulez, bonnes ou mauvaises - mais
vous vous écartez alors du standard et c'est dans ce cas là que vous avez à
expliquer votre choix si on vous le demande. Ce n'est pas ceux qui veulent
suivrent les standards qui ont des comptes à rendre, c'est les autres qui en
ont.
J'avais posé la question des manipulations à effectuer pour transformer
des données stockées en charset 8 bit vers de l'Unicode et je ne me
souviens pas avoir vu de réponse (et en rebalayant rapidement je n'en vois
toujours pas). Ce serait bien d'étayer la discussion de données précises
sur ce point crucial!
Par sûr de vraiment comprendre votre question car cela peut vouloir dire
plusieurs choses différentes et la procédure à suivre dépend de la situation
exacte de ce que vous avez en ce moment.
Tel que je le comprend, on ajoute un champ nchar ou nvarchar, on fait une
copie de l'ancien champ, on supprime l'ancien, on renomme le nouveau ?
Cela n'est pas insurmontable mais cela peut quelque fois (ou souvent) une
charge de travail beaucoup plus lourde que ce que vous prévoyez
actuellement. À titre d'example, pensez simplement aux cas d'entreprises où
chaque modification, aussi petite soit-elle, exige d'être complètement
documentée, justifiée, approuvée et testée avant dêtre finalement déployée.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori il
paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une. Même chose pour les accents français: s'il
n'y a pas d'erreur, tout est correct mais s'il y en a une, plusieurs vont
vous dire qu'ils utilisent déjà Windows-1252 et que par conséquent, cela est
complètement impossible qu'il y ait une erreur. Par conséquent, pour eux,
la seule possibilité qui reste, c'est qu'il y a un bug dans le serveur sql
lui-même. Si vous dites-cela, vous risquez d'avoir à attendre bien
longtemps avoir de recevoir un correctif de MS à ce problème là.
Ici, la configuration de base indique tout simplement les deux choix de code
page pour une machine windows: l'OEM et le Window. Que vous le vouliez ou
non, ces deux choix ont de l'importance lorsque vous utiliser des charsets 8
bit et vous ne pouvez pas commencer à vous amuser à changer ces codes pages
tout le temps.
Vous m'inquiétez énormément en évoquant un choix par défaut si l'on ne
sait pas ce qu'est ascii et unicode. Que dans le monde réel de nombreux
développeurs et administrateurs ne se soucient pas de charset et fassent
au petit bonheur la chance, c'est une réalité. Mais je ne recommanderai
jamais un choix sans expliquer la raison dudit choix ! Et donc, tout le
monde devrait avoir un minimum de culture dans le domaine des charset, et
choisir de manière éclairée.
Peut-être mais vous oubliez qu'avoir un choix éclairé là-dessus demande de
l'étude, du temps, et du travail et que tout cela n'est pas gratuit et coûte
quelque chose. En 1990, cela était justifiable que de demander à un dba
d'étudier les charsets et de consacrer du temps et de l'argent là-dessus.
En 2009, cela n'est plus justifiable dans la majorité des cas: les charsets
sont une culture du passé et comme avec toutes les autres cultures du passé,
c'est à ceux qui veulent continuer à travailler avec qui ont le fardeau de
la preuve. L'unicode est maintenant rendu le standard moderne et
mondialement reconnu. Vous pouvez choisir d'utiliser autre chose que
l'unicode - pour les raisons que vous voulez, bonnes ou mauvaises - mais
vous vous écartez alors du standard et c'est dans ce cas là que vous avez à
expliquer votre choix si on vous le demande. Ce n'est pas ceux qui veulent
suivrent les standards qui ont des comptes à rendre, c'est les autres qui en
ont.
Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le regretter,
car on aura à faire face à des modifications lourdes. Ce sont donc des
éclaircissements sur les modifications auxquelles vous pensiez que
j'attendais ? En vous lisant c'est l'argument principal que j'ai retenu
dans votre argumentation, des éclaircissements me paraissent donc les
bienvenus.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori
il paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une. Même chose pour les accents français:
s'il n'y a pas d'erreur, tout est correct mais s'il y en a une, plusieurs
vont vous dire qu'ils utilisent déjà Windows-1252 et que par conséquent,
cela est complètement impossible qu'il y ait une erreur. Par conséquent,
pour eux, la seule possibilité qui reste, c'est qu'il y a un bug dans le
serveur sql lui-même. Si vous dites-cela, vous risquez d'avoir à
attendre bien longtemps avoir de recevoir un correctif de MS à ce
problème là.
S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage, mais
que quelque part dans la chaîne entre la présentation et la persistance on
n'aura pas utilisé le bon codage. Que vous soyez en stockage Unicode ne
change absolument pas l'absolue nécessité d'être très rigoureux sur un
charset explicite et correct à tout niveau du traitement.
Si je rate quelque chose, éclairez moi!
En 13 ans d'expérience en développement informatique, je n'ai eu à me
soucier des paramétrages de charset OEM et Windows que dans XP pour une
application console mal codée. Et je gère massivement des applications
multilingues (inclus BiDi et CJK) depuis plus de 5 ans maintenant, après
avoir régulièrement été confronté à ces problématiques les années
précédentes. Le tout en utilisant tous types de codages suivant les
besoins et le contexte (et Unicode s'avère bien souvent une fort agréable
solution, oui !).
Donc en conclusion je conviens avec vous que certains métiers pourront ne
pas se poser trop de questions. Mais les charset restent des éléments
indispensables dans les systèmes d'information. Dire que l'on peut les
ignorer en disant que l'on est "toujours en Unicode"... ce serait comme
prétendre que du moment que l'on manipule des données binaires, on n'a pas
à se soucier du content-type ! En tout cas moi, ça m'évoque le "j'ai lu ça
sur un forum, ils disent que ça marche, j'applique", et c'est très loin
d'être une bonne pratique d'appliquer des "recettes miracles" sans ne rien
en comprendre. Mais j'imagine que vous avez écris vos deux interventions
de mauvaise humeur.
Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le regretter,
car on aura à faire face à des modifications lourdes. Ce sont donc des
éclaircissements sur les modifications auxquelles vous pensiez que
j'attendais ? En vous lisant c'est l'argument principal que j'ai retenu
dans votre argumentation, des éclaircissements me paraissent donc les
bienvenus.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori
il paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une. Même chose pour les accents français:
s'il n'y a pas d'erreur, tout est correct mais s'il y en a une, plusieurs
vont vous dire qu'ils utilisent déjà Windows-1252 et que par conséquent,
cela est complètement impossible qu'il y ait une erreur. Par conséquent,
pour eux, la seule possibilité qui reste, c'est qu'il y a un bug dans le
serveur sql lui-même. Si vous dites-cela, vous risquez d'avoir à
attendre bien longtemps avoir de recevoir un correctif de MS à ce
problème là.
S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage, mais
que quelque part dans la chaîne entre la présentation et la persistance on
n'aura pas utilisé le bon codage. Que vous soyez en stockage Unicode ne
change absolument pas l'absolue nécessité d'être très rigoureux sur un
charset explicite et correct à tout niveau du traitement.
Si je rate quelque chose, éclairez moi!
En 13 ans d'expérience en développement informatique, je n'ai eu à me
soucier des paramétrages de charset OEM et Windows que dans XP pour une
application console mal codée. Et je gère massivement des applications
multilingues (inclus BiDi et CJK) depuis plus de 5 ans maintenant, après
avoir régulièrement été confronté à ces problématiques les années
précédentes. Le tout en utilisant tous types de codages suivant les
besoins et le contexte (et Unicode s'avère bien souvent une fort agréable
solution, oui !).
Donc en conclusion je conviens avec vous que certains métiers pourront ne
pas se poser trop de questions. Mais les charset restent des éléments
indispensables dans les systèmes d'information. Dire que l'on peut les
ignorer en disant que l'on est "toujours en Unicode"... ce serait comme
prétendre que du moment que l'on manipule des données binaires, on n'a pas
à se soucier du content-type ! En tout cas moi, ça m'évoque le "j'ai lu ça
sur un forum, ils disent que ça marche, j'applique", et c'est très loin
d'être une bonne pratique d'appliquer des "recettes miracles" sans ne rien
en comprendre. Mais j'imagine que vous avez écris vos deux interventions
de mauvaise humeur.
Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le regretter,
car on aura à faire face à des modifications lourdes. Ce sont donc des
éclaircissements sur les modifications auxquelles vous pensiez que
j'attendais ? En vous lisant c'est l'argument principal que j'ai retenu
dans votre argumentation, des éclaircissements me paraissent donc les
bienvenus.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori
il paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une. Même chose pour les accents français:
s'il n'y a pas d'erreur, tout est correct mais s'il y en a une, plusieurs
vont vous dire qu'ils utilisent déjà Windows-1252 et que par conséquent,
cela est complètement impossible qu'il y ait une erreur. Par conséquent,
pour eux, la seule possibilité qui reste, c'est qu'il y a un bug dans le
serveur sql lui-même. Si vous dites-cela, vous risquez d'avoir à
attendre bien longtemps avoir de recevoir un correctif de MS à ce
problème là.
S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage, mais
que quelque part dans la chaîne entre la présentation et la persistance on
n'aura pas utilisé le bon codage. Que vous soyez en stockage Unicode ne
change absolument pas l'absolue nécessité d'être très rigoureux sur un
charset explicite et correct à tout niveau du traitement.
Si je rate quelque chose, éclairez moi!
En 13 ans d'expérience en développement informatique, je n'ai eu à me
soucier des paramétrages de charset OEM et Windows que dans XP pour une
application console mal codée. Et je gère massivement des applications
multilingues (inclus BiDi et CJK) depuis plus de 5 ans maintenant, après
avoir régulièrement été confronté à ces problématiques les années
précédentes. Le tout en utilisant tous types de codages suivant les
besoins et le contexte (et Unicode s'avère bien souvent une fort agréable
solution, oui !).
Donc en conclusion je conviens avec vous que certains métiers pourront ne
pas se poser trop de questions. Mais les charset restent des éléments
indispensables dans les systèmes d'information. Dire que l'on peut les
ignorer en disant que l'on est "toujours en Unicode"... ce serait comme
prétendre que du moment que l'on manipule des données binaires, on n'a pas
à se soucier du content-type ! En tout cas moi, ça m'évoque le "j'ai lu ça
sur un forum, ils disent que ça marche, j'applique", et c'est très loin
d'être une bonne pratique d'appliquer des "recettes miracles" sans ne rien
en comprendre. Mais j'imagine que vous avez écris vos deux interventions
de mauvaise humeur.
Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le regretter,
car on aura à faire face à des modifications lourdes.
Ce n'est pas nécessairement l'argument principal et d'autres arguments
s'appliquent ou peuvent s'appliquer; selon le cas particulier de chacun
comme je l'ai explicité dans mes messages précédents.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori
il paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une.
S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage, mais
que quelque part dans la chaîne entre la présentation et la persistance on
n'aura pas utilisé le bon codage. Que vous soyez en stockage Unicode ne
change absolument pas l'absolue nécessité d'être très rigoureux sur un
charset explicite et correct à tout niveau du traitement.
Si je rate quelque chose, éclairez moi!
Le quelque chose que vous ratez ici, c'est que l'on n'a pas toujours le
choix ou le contrôle absolue sur tout ou le temps et l'argent de le faire.
Premièrement, le temps que vous consacrez à définir ces séquences de codage,
c'est du temps et de l'argent de perdu que vous ne consacrez pas à autre
chose. Ce n'est pas un lunch gratuit: si vous consacrez une semaine à cela,
c'est une semaine de perdu pour faire autre chose à la place. De plus, si
plus tard vous vous retrouvez avec des problèmes, ces problèmes ne se
résoudront pas tout seul et vous aller devoir rajouter encore du temps et de
l'argent à les résoudre.
Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le regretter,
car on aura à faire face à des modifications lourdes.
Ce n'est pas nécessairement l'argument principal et d'autres arguments
s'appliquent ou peuvent s'appliquer; selon le cas particulier de chacun
comme je l'ai explicité dans mes messages précédents.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori
il paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une.
S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage, mais
que quelque part dans la chaîne entre la présentation et la persistance on
n'aura pas utilisé le bon codage. Que vous soyez en stockage Unicode ne
change absolument pas l'absolue nécessité d'être très rigoureux sur un
charset explicite et correct à tout niveau du traitement.
Si je rate quelque chose, éclairez moi!
Le quelque chose que vous ratez ici, c'est que l'on n'a pas toujours le
choix ou le contrôle absolue sur tout ou le temps et l'argent de le faire.
Premièrement, le temps que vous consacrez à définir ces séquences de codage,
c'est du temps et de l'argent de perdu que vous ne consacrez pas à autre
chose. Ce n'est pas un lunch gratuit: si vous consacrez une semaine à cela,
c'est une semaine de perdu pour faire autre chose à la place. De plus, si
plus tard vous vous retrouvez avec des problèmes, ces problèmes ne se
résoudront pas tout seul et vous aller devoir rajouter encore du temps et de
l'argent à les résoudre.
Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le regretter,
car on aura à faire face à des modifications lourdes.
Ce n'est pas nécessairement l'argument principal et d'autres arguments
s'appliquent ou peuvent s'appliquer; selon le cas particulier de chacun
comme je l'ai explicité dans mes messages précédents.
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à priori
il paraît impossible (à plusieurs) d'avoir une erreur à ce niveau là.
Malheureusement, il y en a une.
S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage, mais
que quelque part dans la chaîne entre la présentation et la persistance on
n'aura pas utilisé le bon codage. Que vous soyez en stockage Unicode ne
change absolument pas l'absolue nécessité d'être très rigoureux sur un
charset explicite et correct à tout niveau du traitement.
Si je rate quelque chose, éclairez moi!
Le quelque chose que vous ratez ici, c'est que l'on n'a pas toujours le
choix ou le contrôle absolue sur tout ou le temps et l'argent de le faire.
Premièrement, le temps que vous consacrez à définir ces séquences de codage,
c'est du temps et de l'argent de perdu que vous ne consacrez pas à autre
chose. Ce n'est pas un lunch gratuit: si vous consacrez une semaine à cela,
c'est une semaine de perdu pour faire autre chose à la place. De plus, si
plus tard vous vous retrouvez avec des problèmes, ces problèmes ne se
résoudront pas tout seul et vous aller devoir rajouter encore du temps et de
l'argent à les résoudre.
Sylvain Lafontaine wrote:Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le
regretter, car on aura à faire face à des modifications lourdes.
Ce n'est pas nécessairement l'argument principal et d'autres arguments
s'appliquent ou peuvent s'appliquer; selon le cas particulier de chacun
comme je l'ai explicité dans mes messages précédents.
Vous êtes arrivé dans ce fil en militant pour une utilisation systématique
de nchar/nvarchar, des arguments précis ont été opposés à cela autant par
Fred que Med, et je vous ai naturellement demandé des précisions, autant
sur les contraintes de ne pas faire ce choix, que de comment on gère cela
au quotidien... Vous éludez la plupart du temps, vos réponses sont
floues... Ce n'est vraiment pas très convaincant !Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à
priori il paraît impossible (à plusieurs) d'avoir une erreur à ce
niveau là. Malheureusement, il y en a une.S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage,
mais que quelque part dans la chaîne entre la présentation et la
persistance on n'aura pas utilisé le bon codage. Que vous soyez en
stockage Unicode ne change absolument pas l'absolue nécessité d'être
très rigoureux sur un charset explicite et correct à tout niveau du
traitement.
Si je rate quelque chose, éclairez moi!
Le quelque chose que vous ratez ici, c'est que l'on n'a pas toujours le
choix ou le contrôle absolue sur tout ou le temps et l'argent de le
faire.
(...)
> Deuxièmement, il y a bien des cas où que vous le vouliez ou non, vous
n'avez
> absolument aucun contrôle sur une bonne partie de l'application.
J'ai l'habitude de répondre la tête froide mais vraiment, cet argument que
vous développez à deux endroits de votre réponse est ahurissant !
Quelque soit le codage choisit, un dérivé 8 bit de ascii ou un des codages
de l'Unicode ou encore autre chose, il est *absolument nécessaire* que
toute la chaine de traitement soit cohérente, éventuellement avec des
transcodages s'il y a lieu. Vous appelez ça une "perte de temps",
j'appelle ça faire mal son travail et je vois mal comment on pourrait me
dire le contraire.
Unicode ce n'est pas une solution magique : que vous stockiez ou non avec
un des codages d'Unicode, ce sera la même problématique qu'avec n'importe
quel autre codage, il faudra que les applications clientes gèrent
correctement les flux de données !Premièrement, le temps que vous consacrez à définir ces séquences de
codage, c'est du temps et de l'argent de perdu que vous ne consacrez pas
à autre chose. Ce n'est pas un lunch gratuit: si vous consacrez une
semaine à cela, c'est une semaine de perdu pour faire autre chose à la
place. De plus, si plus tard vous vous retrouvez avec des problèmes, ces
problèmes ne se résoudront pas tout seul et vous aller devoir rajouter
encore du temps et de l'argent à les résoudre.
(...)
> À quoi cela sert-il de vouloir perpétuer à
> tout prix le fouillis du passé; avec toute les pertes de temps et
d'argent
> que cela entraîne? Ne pensez-vous pas que vous avez vous-même déjà
perdu
> trop de temps avec ces problèmes de code pages? Non seulement vous
voulez
> continuer à perdre du temps avec cela mais vous voudriez que les
autres vous
> suivent également dans cette voie?
Vous ne connaissez absolument rien de mon travail, soyez gentil d'arrêter
ces attaques ad hominem, il aurait été plus utile que vous répondiez à mes
questions et donniez des arguments solides et documentés.
J'arrête la discussion ici car j'ai le sentiment de tourner en rond. Je
suis déçu que quelqu'un se réclamant MVP se comporte ainsi sur un forum
que j'estime de qualité.
Sylvain Lafontaine wrote:
Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le
regretter, car on aura à faire face à des modifications lourdes.
Ce n'est pas nécessairement l'argument principal et d'autres arguments
s'appliquent ou peuvent s'appliquer; selon le cas particulier de chacun
comme je l'ai explicité dans mes messages précédents.
Vous êtes arrivé dans ce fil en militant pour une utilisation systématique
de nchar/nvarchar, des arguments précis ont été opposés à cela autant par
Fred que Med, et je vous ai naturellement demandé des précisions, autant
sur les contraintes de ne pas faire ce choix, que de comment on gère cela
au quotidien... Vous éludez la plupart du temps, vos réponses sont
floues... Ce n'est vraiment pas très convaincant !
Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à
priori il paraît impossible (à plusieurs) d'avoir une erreur à ce
niveau là. Malheureusement, il y en a une.
S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage,
mais que quelque part dans la chaîne entre la présentation et la
persistance on n'aura pas utilisé le bon codage. Que vous soyez en
stockage Unicode ne change absolument pas l'absolue nécessité d'être
très rigoureux sur un charset explicite et correct à tout niveau du
traitement.
Si je rate quelque chose, éclairez moi!
Le quelque chose que vous ratez ici, c'est que l'on n'a pas toujours le
choix ou le contrôle absolue sur tout ou le temps et l'argent de le
faire.
(...)
> Deuxièmement, il y a bien des cas où que vous le vouliez ou non, vous
n'avez
> absolument aucun contrôle sur une bonne partie de l'application.
J'ai l'habitude de répondre la tête froide mais vraiment, cet argument que
vous développez à deux endroits de votre réponse est ahurissant !
Quelque soit le codage choisit, un dérivé 8 bit de ascii ou un des codages
de l'Unicode ou encore autre chose, il est *absolument nécessaire* que
toute la chaine de traitement soit cohérente, éventuellement avec des
transcodages s'il y a lieu. Vous appelez ça une "perte de temps",
j'appelle ça faire mal son travail et je vois mal comment on pourrait me
dire le contraire.
Unicode ce n'est pas une solution magique : que vous stockiez ou non avec
un des codages d'Unicode, ce sera la même problématique qu'avec n'importe
quel autre codage, il faudra que les applications clientes gèrent
correctement les flux de données !
Premièrement, le temps que vous consacrez à définir ces séquences de
codage, c'est du temps et de l'argent de perdu que vous ne consacrez pas
à autre chose. Ce n'est pas un lunch gratuit: si vous consacrez une
semaine à cela, c'est une semaine de perdu pour faire autre chose à la
place. De plus, si plus tard vous vous retrouvez avec des problèmes, ces
problèmes ne se résoudront pas tout seul et vous aller devoir rajouter
encore du temps et de l'argent à les résoudre.
(...)
> À quoi cela sert-il de vouloir perpétuer à
> tout prix le fouillis du passé; avec toute les pertes de temps et
d'argent
> que cela entraîne? Ne pensez-vous pas que vous avez vous-même déjà
perdu
> trop de temps avec ces problèmes de code pages? Non seulement vous
voulez
> continuer à perdre du temps avec cela mais vous voudriez que les
autres vous
> suivent également dans cette voie?
Vous ne connaissez absolument rien de mon travail, soyez gentil d'arrêter
ces attaques ad hominem, il aurait été plus utile que vous répondiez à mes
questions et donniez des arguments solides et documentés.
J'arrête la discussion ici car j'ai le sentiment de tourner en rond. Je
suis déçu que quelqu'un se réclamant MVP se comporte ainsi sur un forum
que j'estime de qualité.
Sylvain Lafontaine wrote:Par contre, vous avez à de nombreuses reprises appuyé vos propos sur
l'argument que si l'on décidait de ne pas utiliser Unicode et que des
années après on avait à changer la chose, on allait beaucoup le
regretter, car on aura à faire face à des modifications lourdes.
Ce n'est pas nécessairement l'argument principal et d'autres arguments
s'appliquent ou peuvent s'appliquer; selon le cas particulier de chacun
comme je l'ai explicité dans mes messages précédents.
Vous êtes arrivé dans ce fil en militant pour une utilisation systématique
de nchar/nvarchar, des arguments précis ont été opposés à cela autant par
Fred que Med, et je vous ai naturellement demandé des précisions, autant
sur les contraintes de ne pas faire ce choix, que de comment on gère cela
au quotidien... Vous éludez la plupart du temps, vos réponses sont
floues... Ce n'est vraiment pas très convaincant !Oui, la livre anglaise est bien incluse dans l'ISO Latin-1; donc à
priori il paraît impossible (à plusieurs) d'avoir une erreur à ce
niveau là. Malheureusement, il y en a une.S'il y a des soucis, c'est qu'ils ne sont pas au niveau du stockage,
mais que quelque part dans la chaîne entre la présentation et la
persistance on n'aura pas utilisé le bon codage. Que vous soyez en
stockage Unicode ne change absolument pas l'absolue nécessité d'être
très rigoureux sur un charset explicite et correct à tout niveau du
traitement.
Si je rate quelque chose, éclairez moi!
Le quelque chose que vous ratez ici, c'est que l'on n'a pas toujours le
choix ou le contrôle absolue sur tout ou le temps et l'argent de le
faire.
(...)
> Deuxièmement, il y a bien des cas où que vous le vouliez ou non, vous
n'avez
> absolument aucun contrôle sur une bonne partie de l'application.
J'ai l'habitude de répondre la tête froide mais vraiment, cet argument que
vous développez à deux endroits de votre réponse est ahurissant !
Quelque soit le codage choisit, un dérivé 8 bit de ascii ou un des codages
de l'Unicode ou encore autre chose, il est *absolument nécessaire* que
toute la chaine de traitement soit cohérente, éventuellement avec des
transcodages s'il y a lieu. Vous appelez ça une "perte de temps",
j'appelle ça faire mal son travail et je vois mal comment on pourrait me
dire le contraire.
Unicode ce n'est pas une solution magique : que vous stockiez ou non avec
un des codages d'Unicode, ce sera la même problématique qu'avec n'importe
quel autre codage, il faudra que les applications clientes gèrent
correctement les flux de données !Premièrement, le temps que vous consacrez à définir ces séquences de
codage, c'est du temps et de l'argent de perdu que vous ne consacrez pas
à autre chose. Ce n'est pas un lunch gratuit: si vous consacrez une
semaine à cela, c'est une semaine de perdu pour faire autre chose à la
place. De plus, si plus tard vous vous retrouvez avec des problèmes, ces
problèmes ne se résoudront pas tout seul et vous aller devoir rajouter
encore du temps et de l'argent à les résoudre.
(...)
> À quoi cela sert-il de vouloir perpétuer à
> tout prix le fouillis du passé; avec toute les pertes de temps et
d'argent
> que cela entraîne? Ne pensez-vous pas que vous avez vous-même déjà
perdu
> trop de temps avec ces problèmes de code pages? Non seulement vous
voulez
> continuer à perdre du temps avec cela mais vous voudriez que les
autres vous
> suivent également dans cette voie?
Vous ne connaissez absolument rien de mon travail, soyez gentil d'arrêter
ces attaques ad hominem, il aurait été plus utile que vous répondiez à mes
questions et donniez des arguments solides et documentés.
J'arrête la discussion ici car j'ai le sentiment de tourner en rond. Je
suis déçu que quelqu'un se réclamant MVP se comporte ainsi sur un forum
que j'estime de qualité.
