Mornagest a écrit :Oui, obtenir le Œ et le œ est simple avec la disposition de clavier que j'ai, mais c'est effectivement plutôt un problème d'encodage, je pense. C'est un problème que je n'ai jamais compris ni réussi à résoudre, d'ailleurs
C'est une simple absurdité historique.
Autrefois, pour enregistrer du texte dans l'ordinateur, on utilisait essentiellement l'ASCII étendu, c'est-à-dire la
table ASCII de base plus un certain nombre de caractères régionaux (lettres accentuées, signes de ponctuations spécifiques, etc.). Sauf que, le nombre de caractères pouvant être représenté de cette manière étant assez limité, il y avait plusieurs tables étendues, une par région.
Le souci, c'est qu'au moment de faire la table étendue pour les caractères européens (iso-8859-1, ou iso-latin-1), le français de service a qui on a demandé quels étaient les caractères utiles à encoder là-dedans a répondu que c'est bon, le « œ » ne servait à rien, il n'y avait pas besoin de l'inclure (j'imagine qu'il n'avait pas de sœur, entre autres). Et donc, le caractère n'ayant pas été intégré à la table, il était impossible de l'utiliser chaque fois qu'on n'avait que cet encodage-là à disposition.
Ça a fait assez mal, parce que c'est l'époque où on a défini un certain nombre de normes et que l'iso-8859-1 a donc été gravé dans le marbre assez rapidement (par exemple, selon la norme HTTP, si l'encodage de la page que vous voulez afficher n'est pas précisé, votre navigateur est censé supposer que c'est celui-ci qui est utilisé).
Le problème est résolu par le passage à l'Unicode (qui est la norme abstraite, pouvant en pratique être encodée de diverses façons, dont l'UTF-8 et l'UTF-16), dans lequel on tente de faire une seule table pour l'ensemble des caractères représentables plutôt qu'une table par jeu de caractères (ce qui donne des trucs assez funs, lire par exemple
l'infobulle de cette image) ; mais il faut que le logiciel soit compatible, ce qui n'était pas le cas du moteur d'origine de BG.
Isaya a écrit :Sous Windows, tu peux utiliser l'application Tables des caractères (menu Démarrer, Accessoires) pour afficher les caractères et leur code ; l'application affiche aussi la combinaison Alt + séquence de chiffres qui permet de le saisir dans un texte quelconque.
Pour Œ : Alt + 0140
Pour œ : Alt + 0156
J'ignore si Linux utilise ce système pour insérer des caractères spéciaux.
Sous Windows, il faut impérativement taper les chiffres avec le pavé numérique, si je ne m'abuse.
Sous GNU/Linux, les applications en GTK ont un système analogue en utilisant ctrl+shift+u suivi (en lâchant u mais en gardant ctrl et shift enfoncés) du numéro du caractère désiré dans la table unicode (ce qui, au moins, est plus facile à retrouver que les numéros utilisés par Windows, il suffit de consulter
une table).
Mais pour des caractères courants comme celui-ci, inutile de passer par ce genre de système : avec une disposition clavier un minimum pratique, altgr+o donne œ et altgr+O (avec le caps lock actif ou en maintenant shift) donne Œ. S'il y a une touche compose sur le clavier, on peut aussi y arriver avec compose+o+e.
J'ai fait un pavé pour expliquer un certain nombre de choses à ce sujet
par là.
Mornagest a écrit :sinon je passerai par Notepad++ qui semble bien complet !
Pour info, Notepad++ est basé sur le widget d'édition de texte Scintilla, qui est également utilisé par l'éditeur de texte SciTE (Scintilla Text Editor, ils ne se sont pas foulés pour le nom), qui est natif sous GNU/Linux. Normalement, les deux sont donc très proches à l'utilisation (après, le reste de l'interface (barres d'outils, menus…) doit changer, mais ça devrait gérer les encodages grosso-modo de la même façon).
Isaya a écrit :Le principal souci est de ne pas avoir mélangé deux encodages dans le même fichier, ce qui est un vrai risque en agglomérant des données fournies par plusieurs personnes. Parce que, dans ce cas, aucun outil ne fera de miracle.
Pour GEdit et la plupart des autres éditeurs de texte en GTK, on passe par le widget GtkSourceView, que je connais un peu mieux. Dans ce cas, sauf erreur de ma part, le texte est automatiquement converti en UTF-8 pour l'utilisation interne, que ce soit en ouvrant un fichier ou en collant depuis le presse-papier, et c'est ensuite en enregistrant le fichier que l'ensemble peut éventuellement être converti dans un encodage donné. Donc, aucun risque de fichier mélangeant plusieurs encodages.