Le type de caractère Java est-il garanti d’être stocké dans un codage particulier?
Edit: J’ai mal formulé cette question. Ce que je voulais dire, c’est que les littéraux de caractères sont garantis pour utiliser un encodage particulier?
“Stocké” où? Toutes les chaînes en Java sont représentées en UTF-16 . Lorsqu’il est écrit dans un fichier, envoyé sur un réseau ou autre, il est envoyé en utilisant le codage de caractères que vous spécifiez.
Éditer: Pour le type de caractère en particulier, voir la documentation sur les personnages . Plus précisément: “Les types de données char … sont basés sur la spécification Unicode d’origine, qui définissait les caractères en tant qu’entités 16 bits à largeur fixe.” Par conséquent, la conversion de char
en int
vous donnera toujours une valeur UTF-16 si le caractère contient réellement un caractère de ce jeu de caractères. Si vous insérez simplement une valeur aléatoire dans le caractère, ce ne sera évidemment pas nécessairement un caractère UTF-16 valide, pas plus que si vous lisez le caractère en utilisant un mauvais codage. La documentation explique ensuite que les caractères UTF-16 supplémentaires ne peuvent être représentés que par un int
, car char
n’a pas assez d’espace pour les contenir, et si vous travaillez à ce niveau, il peut être important de vous familiariser avec avec ces sémantiques.
Un caractère Java est classiquement utilisé pour contenir une unité de code Unicode ; c’est-à-dire une unité de 16 bits qui fait partie d’une séquence UTF-16 valide. Cependant, rien n’empêche une application de mettre une valeur non signée de 16 bits dans un caractère, quelle que soit sa signification réelle.
On pourrait donc dire qu’une unité de code Unicode peut être représentée par un caractère et qu’un caractère peut représenter une unité de code Unicode … mais aucune de celles-ci n’est nécessairement vraie, dans le cas général.
Vous ne pouvez pas répondre à votre question sur la manière dont un caractère Java est stocké En termes simples, cela dépend de ce que vous entendez par “stocké”:
Si vous voulez dire “représenté dans un programme en cours d’exécution”, la réponse est spécifique à l’implémentation de la JVM. (Le type de données char
est généralement représenté sous la forme d’un entier de 16 bits, bien qu’il soit ou non aligné sur le mot machine, selon le contexte.)
Si vous voulez dire “stocké dans un fichier” ou quelque chose du genre, la réponse dépend entièrement de la manière dont l’application choisit de le stocker.
Le type de caractère Java est-il garanti d’être stocké dans un codage particulier?
À la lumière de ce que j’ai dit ci-dessus, la réponse est “Non”. Dans une application en cours d’exécution, il appartient à l’application de décider de ce qu’un caractère signifie / contient. Lorsqu’un caractère est stocké dans un fichier, l’application décide comment elle souhaite le stocker et quelle représentation elle utilisera sur le disque.
SUIVRE
Qu’en est-il des littéraux de l’omble? Par exemple, “c” doit avoir une valeur définie par le langage.
Cela dépend de la forme littérale du caractère et de sa nature. Par exemple, “c” aura la valeur des 16 bits du bas du sharepoint code Unicode pour les minuscules “c”. Mais un littéral exprimé par “\ uxxxx” ne peut pas représenter un sharepoint code Unicode valide. Ou (selon le moyen utilisé), il peut ne pas représenter un caractère du tout.
Ceci est également (potentiellement) compliqué par le codage du fichier de code source. Il est théoriquement possible de représenter votre code source dans un codage de caractères personnalisé dans lequel (pour des raisons d’argument) les lettres majuscules sont codées en minuscules, et inversement. Si vous avez fait cela et que vous avez pu enregistrer le codeur et le décodeur Charset correspondants avant de lancer le compilateur, un littéral ressemblant à 'c'
(affichage de l’entrée au format ASCII ou UTF-8) aurait en réalité la valeur 67
dans le 67
programme de compilation plutôt que 99
.
À l’origine, Java utilisait UCS-2 en interne; maintenant, il utilise UTF-16. Les deux sont pratiquement identiques, à l’exception de D800 – DFFF, qui sont utilisés dans le format UTF-16 dans le cadre de la représentation étendue des caractères plus grands.