-
Bienvenue sur le forum de généalogie avec Généatique,
Si vous avez du mal à vous connecter, faites une demande de réinitialisation de mot de passe : Réinitialiser mon mot de passe
Caractères spéciaux dans les villes
- Auteur de la discussion letello2
- Date de début
Pareil j'ai testé čČćĆçÇ en saisie et ça fonctionne.
Il faudrait faire un copier/coller du caractère ici ou donner son n° UNICODE
Thierry
Il faudrait faire un copier/coller du caractère ici ou donner son n° UNICODE
Thierry
Dernière édition:
Rectificatif : Bug export gedcom
les čČćĆ sont transformés en cCcC
Cordialement
Thierry
les čČćĆ sont transformés en cCcC
Cordialement
Thierry
Bonjour,
Dans mon cas je suis confronté à ces caractères pour certains ancêtres Tchèque pour saisir ce type de caractères dans les noms des villes et de façon générale lorsque c'est nécessaire j'ai installé le clavier Tchèque sous Windows et pour saisir les caractères j'utilise le clavier visuel de Windows en ayant au préalable sélectionné le clavier adéquat dans la barre de tâche.
Cordialement.
Dernière édition:
J'utilise un driver FR-OSS pour tous les caractères en saisie direct sur clavier Français
( produit avec MSKLC; ce qui évite d'avoir à swapper de clavier (*) )
Cela utilise les tables Unicode "Latin étendu – A" (U-0100, ...)
Table des caractères Unicode/U0100 — Wikipédia
Vous pouvez me mettre ici une copie texte de votre exemple en Tchéquie ?
Visiblement le problème n'est que pour l'export des lieux et lieux-dits (OK pour les noms et surnoms, les sources, notes, etc...)
Cordialement
Thierry
(*) : par exemple pour oe c'est Alt-Gr+O => œ
etc... c'est très rapide une fois que l'on a mémorisé les touches mortes (diacritiques) pour les caractères accentués.
Dernière édition:
Bonjour et suite :
J'ai compris le problème.
- pas de problème dans la base et la saisie de caractères unicode.
- pas de problème à l'import gedcom
- mais pour l'export gedcom, pour les champs lieux et lieux-dits seulement, les caractères UNICODE composés avec diacritiques sont exportés avec leur équivalent sans diacritique.
Un caractère UNICODE décomposé (*) ne pose pas de problème
Par exemple : Ć représenté U+0043 suivi de U+0301 ne pose pas de problème à l'export alors que Ć représenté U+0106 est transformé en C. Donc tout dépend du clavier (ou copier/coller) utilisé pour renseigner le caractère.
Je vais signaler le problème au CDIP.
Il n'y a pas de problèmes pour les autres champs (noms, surnoms, sources, notes, etc...) seulement dans le cas d'un lieu ou lieu-dit avec un caractère Unicode composé (intégrant un diacritique cf tables à partir de U+0100 )
Cordialement
Thierry
(*) en représentation Unicode il est possible d'encoder de plusieurs manières les caractères avec accentuation (signes diacritiques). Soit sous forme d'un caractère Unicode accentué, soit sous forme d'un caractère unicode non accentué suivi des caractères d'accentuation (symbole composé)
Par exemple pour Ć :
fr.wikipedia.org
J'ai compris le problème.
- pas de problème dans la base et la saisie de caractères unicode.
- pas de problème à l'import gedcom
- mais pour l'export gedcom, pour les champs lieux et lieux-dits seulement, les caractères UNICODE composés avec diacritiques sont exportés avec leur équivalent sans diacritique.
Un caractère UNICODE décomposé (*) ne pose pas de problème
Par exemple : Ć représenté U+0043 suivi de U+0301 ne pose pas de problème à l'export alors que Ć représenté U+0106 est transformé en C. Donc tout dépend du clavier (ou copier/coller) utilisé pour renseigner le caractère.
Je vais signaler le problème au CDIP.
Il n'y a pas de problèmes pour les autres champs (noms, surnoms, sources, notes, etc...) seulement dans le cas d'un lieu ou lieu-dit avec un caractère Unicode composé (intégrant un diacritique cf tables à partir de U+0100 )
Cordialement
Thierry
(*) en représentation Unicode il est possible d'encoder de plusieurs manières les caractères avec accentuation (signes diacritiques). Soit sous forme d'un caractère Unicode accentué, soit sous forme d'un caractère unicode non accentué suivi des caractères d'accentuation (symbole composé)
Par exemple pour Ć :
Ć — Wikipédia
Dernière édition:
U+0043 suivi de U+0301 est le code unicode du caractère
U+0106 n'en est pas le code unicode. Le code unicode d'un caractère est unique et ne change jamais au cours des versions successives de l'unicode
Seulement les lettres non accentuées (et quelques caractères spéciaux, en fait les 128 premiers caractères) sont codés en Unicode sur un octet. Tous les autres sont codés sur deux octets. Du moins dans UTF8 qui est l'implémentaion unicode couramment utilisée, mais il y en a d'autres.
Donc, soit le caractère est saisi avec un code erroné et ce comportement est prévisible. Il n'y a pas d'anomalie généatique.
Soit le caractère est saisi avec le bon code et l'export transforme le codage du caractère.
D'après ce que vous dites, on semble plutôt être dans le premier cas.
Bonjour,
Il y a bien anomalie Geneatique à l'export gedcom des lieux.
Je ne perdrai pas de temps à commenter votre message erroné.
Cordialement
Thierry
Dernière édition:
C'est effectivement un peu plus compliqué que ça :
U+0106 est le code unicode en hexa, soit 262 en décimal
Mais ce n'est jamais ce code qui est utilisé. Il faut regarder le code dans l'implémentation unicode qui en est faite, en l'occurence, en utf8
En utf8 le code est sur 3 octets : 43 CC 81, en hexa
Pour vérifier le code d'un caractère, il faut faire un copier-coller du caractère dans un éditeur hexa, par exemple notepad++ avec l'extension hex-editor, et on peut voir le code.
Ce que l'on voit peut être trompeur.
Par exemple :
A est le "a" latin majuscule unicode numéro 41 hexa
Α est le alpha majuscule grec unicode numéro 391 hexa, ce 91 en utf8
А est le "a" cyrillique majuscule unicode numéro 410 hexa, d0 90 en utf8
L'affichage est le même mais le code est différent et pour un correcteur orthographique ça change tout.
U+0106 est le code unicode en hexa, soit 262 en décimal
Mais ce n'est jamais ce code qui est utilisé. Il faut regarder le code dans l'implémentation unicode qui en est faite, en l'occurence, en utf8
En utf8 le code est sur 3 octets : 43 CC 81, en hexa
Pour vérifier le code d'un caractère, il faut faire un copier-coller du caractère dans un éditeur hexa, par exemple notepad++ avec l'extension hex-editor, et on peut voir le code.
Ce que l'on voit peut être trompeur.
Par exemple :
A est le "a" latin majuscule unicode numéro 41 hexa
Α est le alpha majuscule grec unicode numéro 391 hexa, ce 91 en utf8
А est le "a" cyrillique majuscule unicode numéro 410 hexa, d0 90 en utf8
L'affichage est le même mais le code est différent et pour un correcteur orthographique ça change tout.
Merci GD,
Quand tu exportes tu confirmes que tu n'a pas le problème pour le lieu ?
(à l'import de Heredis les caractères sont bien lus)
Cordialement
Thierry
Mon précédent post avec les copies d'écran des export GEDCOM le confirme.
Voici un copie/collé d'un export GEDCOM de Généatique 2026 d'hier :
1 BIRT
2 DATE 18 JUN 1833
2 PLAC Sádek, , , Střední Čechy, TCHÉQUIE,
3 MAP
4 LATI N49.733077
4 LONG E13.982707
Cordialement.
Gaston
Merci GD,
Exact, je confirme aussi, c'est corrigé en édition 2026, le problème est donc spécifique à la version G2025 que j'ai utilisé
> A confirmer par l'initiateur du fil qu'il est bien en édition 2025 comme j'avais supposé (peut être à tord)
Cordialement
Thierry
Dernière édition:
Bonjour,
Pouvez vous préciser / confirmer :
- l'édition de Généatique utilisée (2025 ?)
- si le problème est dans l'affichage de généatique ou suite à un export gedcom ?
Cordialement
Thierry
Messages similaires
- Question
- Question
- Question
