Je ne connais pas la réponse à la question parce qu'il s'agit de détails d'implémentation, mais il y a trois solutions, ou familles de solution, plus ou moins couteuses:
* On ne fait rien, et une couche supplémentaire vient faire le travail. C'est ce qui est fait par exemple en XML/HTML: une entité permet de représenté un caractère unicode quelconque alors que le document est dans un codage qui ne permet pas de le représenter directement.
* On change tout pour augmenter la taille allouée à un caractère, en espérant que cette fois ci, on aura suffisement de place.
* On bricole pour rester compatible. UTF-8 est de ce coté un mécanisme très bien conçu: les programmes qui pensent qu'un caractère est un octet doivent continuer à fonctionner, mais un mécanisme doit permettre aux programme "aware" de placer des caractères supplémentaires. Au passage, il ne faut pas qu'un caractère codé sur plusieurs octets génère des octets qui seraient interprété comme un caractère de controle par un programme d'ancienne génération.
Pour le problème de Windows et de Java, on peut faire exactement la même extension, mais sur 16 bits. Ca s'appelle UTF-16. Un programme qui est purement UCS-2 verra des caractères, plusieurs caractères étrange à la place de ceux qui dépassent U+0FFFF, mais cela ne lui posera pas de problème. Un programme travaillant en UTF-16 sera capable de reconnaitre certaines séquences de caractères de 16 bits et de produire le caractère étendu correspondant.
[^] # Re: Codage des caractères ?
Posté par Sébastien Koechlin . En réponse à la dépêche Appel à commentaires sur le référentiel général d'interopérabilité. Évalué à 4.
* On ne fait rien, et une couche supplémentaire vient faire le travail. C'est ce qui est fait par exemple en XML/HTML: une entité permet de représenté un caractère unicode quelconque alors que le document est dans un codage qui ne permet pas de le représenter directement.
* On change tout pour augmenter la taille allouée à un caractère, en espérant que cette fois ci, on aura suffisement de place.
* On bricole pour rester compatible. UTF-8 est de ce coté un mécanisme très bien conçu: les programmes qui pensent qu'un caractère est un octet doivent continuer à fonctionner, mais un mécanisme doit permettre aux programme "aware" de placer des caractères supplémentaires. Au passage, il ne faut pas qu'un caractère codé sur plusieurs octets génère des octets qui seraient interprété comme un caractère de controle par un programme d'ancienne génération.
Pour le problème de Windows et de Java, on peut faire exactement la même extension, mais sur 16 bits. Ca s'appelle UTF-16. Un programme qui est purement UCS-2 verra des caractères, plusieurs caractères étrange à la place de ceux qui dépassent U+0FFFF, mais cela ne lui posera pas de problème. Un programme travaillant en UTF-16 sera capable de reconnaitre certaines séquences de caractères de 16 bits et de produire le caractère étendu correspondant.