UTF8 ou ISO-8859-1 que choisir ? [Résolu]

[SergioMaster]

Cruel dilemme qui me trotte dans la tête depuis quelques temps déjà j'ai maintenant besoin d'une réponse (qui ne soit pas de normand ) pour une nouvelle base de données pour une nouvelle application .

Si cette application est avant tout française, utilisée par des français pour une clientèle (fichier clients et articles) en majorité française (au pire européenne) je pencherai pour l'ISO
Mais je lis de plus en plus que l'ISO devrait être abandonné au profit de l'UTF8 (mondialisation oblige)
j'y perds mon (caractère) latin que me conseillez vous ?

[Barbibulle]

Bonjour Sergio,

Je dirais qu'en utilisant UFT8 tu es certain de pouvoir gérer tous les cas si jamais ils se présentaient...

Maintenant le choix je le ferai plus par rapport à tes outils de développements.
S'il permettent de développer nativement en UFT8, la question ne se pose même pas, utilise UFT8. Si tes outils ne le permettent pas la question ne se pose pas non plus :=> Go ISO.

Et si comme Delphi7 tu peux utiliser UFT8 mais pas nativement, le développement en UFT 8 va être contraignant et comme ton application est française maximum EU, je m'embêterais pas avec UFT8 et je choisirais ISO.

Réponse Normande :
- Ceci dit (je n'ai pas testé mais je crois que ca fonctionne) tu peux très bien avoir ta base de données en UFT8 et ton application qui se connecte en ISO8859_1. FB se chargeant de faire la conversion à chaque échange. Et le jour ou ton application pourra gérer nativement l'UFT8 la base sera déjà prête.

[e-ric]

bonjour

J'apporte une réponse tardive mais j'espère qu'elle sera intéressante.

J'ai commencé à développer une application avec Lazarus+ZeosLib+Firebird 2.1.3., après des heures de recherches (Internet et tests) la seule façon de transcrire correctement les accentués sous Lazarus avec Fb est d'utiliser uTF8. Manifestement Lazarus ne supporte correctement que ces ensemble de caractères.

Après tout se passait bien. Cela plaide pour l'utilisation de l'UTF8 sans se poser plus de questions.

[SergioMaster]

UTF8 Avec Lazarus + ZEOS , c'est exact , avec Delphi2009 et plus les ZEOS ne sont pas encore au point .

Je fais actuellement sous D2010 des essais avec UIB et le Grizzly pack , essais mitigés :
- la gestion des erreurs avec le Grizzly pack me pose encore des problèmes
- UIB seul , je maitrise mal le dataprovider et donc ma 'productivité s'en ressent fortement'

malgré tout , mon choix se porte sur UTF8 . Cependant pressé par le temps je risque de produire ma première version en ISO

[Barbibulle]

Envoyé par e-ric

Après tout se passait bien. Cela plaide pour l'utilisation de l'UTF8 sans se poser plus de questions.

Dans votre cas oui, mais encore une fois il ne faut pas généraliser...

Les utilisateurs de Delphi 6, Delphi 7 ne peuvent pas utiliser les composants orientés données (d'origine) en natif UFT8, l'utilisation d'UFT8 est possible mais c'est plus lourd (et de toute façon ne permettra pas d'afficher tout le jeux de caractère UFT8, donc mis à part avoir une base UFT8 les programmes ne le seront pas à 100%).

Personnellement je fais au plus simple et ne compte pas me compliquer la vie avec UFT8 tant que je n'aurai pas un environnement de développement qui me permette de l'utiliser en natif. D'autant que ISO8859_1 couvre une grande partie des langues de l'Europe de l'ouest, Amérique, et en partie les pays d'Afrique, d'Océanie et même Asie du sud est.

SergioMaster parle d'abandon de l'ISO, mais le mot est mal choisi, car l'ISO existera encore pendant très longtemps, simplement c'est vrai que plus il y aura d'outils permettant de manipuler l'UFT8 en natif, plus celui ci sera utilisé (à la place de l'ISO).

Cependant l'ISO sera supporté encore pendant très longtemps, par les systèmes d'exploitation, par firebird et les environnements de développement afin de garder une compatibilité avec l'existant.

[TryExceptEnd]

Envoyé par SergioMaster

Je fais actuellement sous D2010 des essais avec UIB et le Grizzly pack , essais mitigés :
- la gestion des erreurs avec le Grizzly pack me pose encore des problèmes
- UIB seul , je maitrise mal le dataprovider et donc ma 'productivité s'en ressent fortement'

Quels problèmes tu as concrètement ?

[alanglet]

Bonsoir,

Le problème devrait être simple, puisqu'avec Firebird on définit un jeu de caractères pour la connexion et un autre (le même ou différent) pour le stockage dans les champs de la base (il peut même être différent selon les champs). Comme le dit Barbibulle le 12/05 Firebird se charge du passage dans le jeu de caractères de la connexion en lecture et réciproquement en écriture. Pour ne pas avoir besoin de faire de transcodage dans le logiciel, il suffit donc de choisir pour la connexion le jeu de caractères utilisé par ce logiciel ou l'outil de développement. Par exemple sous les versions actuelles de Lazarus il est préférable d'utiliser une connexion en UTF8, alors que sous Delphi 7 il faut utiliser le WIN1252 qui est le codage utilisé par nos versions de Windows.
La raison des complications vient de ce que lorsque les jeux de caractères sont identiques, logiquement Firebird ne fait pas de transcodage. De ce fait il ne vérifie plus que les caractères qu'il lit ou enregistre appartiennent bien au jeu de caractères utilisé. Et la bêtise souvent faite a été d'utiliser l'ISO8859_1 pour la connexion et pour le stockage, alors que nous envoyons des caractères en WIN1252 depuis Windows. Çà a permis de stocker dans nos champs ISO8859_1 des caractères propres au jeu WIN1252 comme le œ (o et e collés) pourtant très utilisé en français (sœur, cœur et beaucoup de noms de communes) qu'il ne connait pas et qui auraient normalement dû être rejetés à l'enregistrement.
Dans cette situation, il devient quasiment impossible de se connecter à cette base autrement qu'en ISO8859_1. Dans le cas contraire, Firebird signale une erreur a chaque lecture d'un champ contenant les caractères inconnus de ce jeu. Certains considèrent même que cette base est corrompue.

André

[moyzer]

Simple Constat : A méditer !
Avec Delphi 2006 et une Base de donnée ASCII FireBird 2.5, Default Character Set NONE, ça carburait !

Maintenant avec Delphi 2010 la même DB mais cette fois convertie en Default Caracter Set UTF8....et bien ça met beaucoup plus de temps !!!
(Connexion dbExpress)

Je me pose des questions sur l'UTF8

[SergioMaster]

D2006 n'était pas unicode il me semble ? donc difficile de faire une comparaison 'fiable'
J'ai fait des comparaisons Lazarus,D7,D2006,D2010 composants UIB et/ou ZEOSDBO sur les mêmes BDD FB2.1 et je n'ai pas trouvé de différences notables (sauf bien sur mes problèmes d'accents et les tailles de programmes)