Discussion :

[exaju]

Bonjour à tous,

Je débute des cours en Java et j'ai un exercice qui me prends bien la tête... Je dois convertir les 255 premiers caractères Unicode vers UTF-8. De ce que je comprends Java fait de base de l'Unicode dans cette forme: (char)car = '\uxxxx' ou String str = "\\uxxxx".

Donc dans mon idée je fais un for (int i = 0; i<255; i++), j'incrémente un String et je le traduit en UTF-8 via la méthode "getBytes("UTF-8")" et de la possibilité de forcer le format lors de la création de l'objet String.

Donc j'ai pondu ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
String symbol = "\\u0000";
for (int i = 0; i<255; i++){
 
String hex = Integer.toHexString(i);
 
			  if(i< 9){
				  symbol = "\\u000"+hex;
			  }else if (i >10 && i <100){
				  symbol = "\\u00"+hex;
			  }else{
				  symbol = "\\u0"+hex; 
			  }
 
char carResult = (char) Integer.parseInt(symbol.substring(2), 16 );
System.out.println("carResult: "+ carResult);
 
String string2convert =  Character.toString((char) carResult);
 
byte[] convertUnicodeBytes = string2convert.getBytes();
byte[] convertUTF8Bytes2 = string2convert.getBytes("UTF-8");
 
String stringUTF8= new String(convertUTF8Bytes2, "UTF-8");
String stringUnicode = new String(convertUnicodeBytes, "UTF-8");
 System.out.println("stringUTF8: "+ stringUTF8 +" stringUnicode: "+ stringUnicode);
}

Outre le problème de l'addition des hexadécimaux qui ne fonctionne pas (des idées ?) est-ce la bonne manière de faire ? Et existe-t-il un moyen (ou pas) de faire ça en ayant juste des char et pas des String (avec du pur algo) ?

Merci de m'avoir lu :-), toute aide est la bienvenue (même en pseudo code... surtout si mon prof passe par là :-))

[thelvin]

Hello,

Java fait de base de l'Unicode, tout court. Pas besoin de chercher une notation.
La notation \uXXXX ne peut pas t'aider, parce qu'elle ne concerne que les littéraux String et char. Uniquement ce que tu mets entre " et " ou bien entre ' et '. On ne peut pas "construire" cette notation à l'intérieur d'un programme, on peut seulement l'écrire dans le code source. Et c'est à ça qu'elle sert, il serait inutile et inadapté qu'elle fasse autre chose.


Quand je dis que Java fait de l'Unicode tout court, je veux dire que les char Java, c'est de l'Unicode et pas autre chose. Pas besoin de chercher plus.

Prenons le code Unicode décimal 65, qui correspond à la lettre A. Et faisons ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
char ch = 65;
System.out.println(ch);

Ça affiche A. C'est pas plus compliqué que ça. Pour avoir dans un char un caractère Unicode précis, tu lui assignes sa valeur. Parce qu'un char c'est de l'Unicode.


Pour ce qui est de convertir en UTF-8 ensuite, tu vas devoir forcément passer par des String. Un char ne suffit pas, il faut en faire une String. L'encodage de charset se fait sur l'ensemble d'un texte, par sur ses caractères séparés.

Une question que je me pose, c'est : que vas-tu en faire après avoir converti ces caractères en UTF-8 ? Des caractères encodés, ce sont des octets. Les octets ce n'est pas quelque chose d'intéressant à montrer, normalement on montre plutôt du texte. Les octets on les met plutôt dans un fichier ou dans une communication réseau. Alors que vas-tu en faire ?

[exaju]

Salut Thelvin, et merci pour ce retour :-) tu es la lumière au bout du tunnel...

Je comprends mieux comment faire maintenant, je vais partir sur l'incrémentation des char de 0 à 255 tout simplement et repartir sur un String en forçant le format à UTF-8 pour l'afficher.

Voilà le résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
import java.io.UnsupportedEncodingException;
import java.nio.charset.StandardCharsets;
 
//The character encoding describes how to map a byte array (byte[]) to a char array (char[]), and vice versa
public class UnicodeVersUtf8 {
 
	public static void transform(){
 
		try {
			for (int i =0 ; i<255; i++){
 
				char ch = (char) i;
				byte[] bytesDeChar = Character.toString(ch).getBytes(StandardCharsets.UTF_8);
				String stringUTF8 = new String(bytesDeChar, "UTF-8");
				System.out.println("UTF8: "+stringUTF8+" == char: "+ch);
			}
 
		} catch (UnsupportedEncodingException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
	public static void main(String[] args) {
		// TODO Auto-generated method stub
		transform();
	}
 
}

Pour ce qui est de ce que je veux en faire, ben l'afficher ? J'imaginais (à tort) qu'il y aurait des disparités entre un char unicode (ex char(65)=A) et sa représentation en String UTF-8 mais peux être que le but de l'exercice est de nous faire comprendre que jusqu'à 255 il y a pas de différence...

Bref, c'est le début des cours et on étudie les primitives, je pense que le but est de nous faire comprendre que selon la primitive (et du charset !!) ce n'est pas codé sur le même nombre de bits sans plus mais cette réponse me paraît presque trop simple... Ou alors il faut comparer les tableau de bytes pour déterminer une différence, ce serait plus intéressant au niveau de la démonstration non (EDIT: ils sont similaires...) ? Donc je sais pas trop quelle est le but de cet exercice...

Sinon petite question: pourquoi je suis obligé de faire un cast sur l'int pour la création du char (pour un erreur si char > 65535)?

Mais merci encore pour ton retour ! Je sens que tu es un utilisateur Java éclairé ;-) toutes indication supplémentaire est la bienvenue !!

[tchize_]

repartir sur un String en forçant le format à UTF-8 pour l'afficher.

Ce que tu dis là ne veux rien dire. Pour 'afficher', on utilise l'encodage de la console, pas autre chose. Ce que fait par défaut System.out.printXXX
Une String n'a pas d'encodage donc on ne peux donc pas "forcer" un encodage. La seule chose qui a un encodage c'est du binaire, un fichier donc. Parce que un "encodage", c'est une règle pour transformer des byte en du texte et vice versa.

Ce code si est complètement neutre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
				byte[] bytesDeChar = Character.toString(ch).getBytes(StandardCharsets.UTF_8);
				String stringUTF8 = new String(bytesDeChar, "UTF-8");

car tu transforme en byte[] via utf-8 puis tu retransforme en String via utf-8. Tu as donc exactement la même string qu'au départ.
Ton code est donc strictement le même que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
				char ch = (char) i;
				System.out.println("UTF8: "+ch+" == char: "+ch);

mais en plus compliqué à lire et à exécuter :/ En tant que débutant, tu devrais tout simplement oublie que String a des constructeurs qui prennent des byte[], ceux-ci ne servent que dans de très très rares cas. Si on te demande de les représenter en UTF 8 pour ton exercice, ça veux surement simplement dire qu'on te demande de les écrire dans un fichier texte en utilisant l'encodage utf8, donc en ouvrant un writer avec cet encodage. Sans avoir l'énoncé, difficile de savoir.

Sinon petite question: pourquoi je suis obligé de faire un cast sur l'int pour la création du char (pour un erreur si char > 65535)?

Que veux tu dire? Un char ne peut pas aller au delà de 65535, puisque les char en java font 16bits

[thelvin]

Merci tchize_ pour les précisions concernant "l'affichage d'un encodage".

Sinon petite question: pourquoi je suis obligé de faire un cast sur l'int pour la création du char (pour un erreur si char > 65535)?

D'abord parce qu'un int peut être négatif et un char, non. Du coup en essayant d'assigner un int à un char il y a risque d'erreur, et le compilateur te le fait savoir.
Si tu fais un cast, tu assumes la compréhension de ce risque d'erreur, et considère probablement que tu as pris des mesures adéquates pour que ce ne soit pas un problème.
Ici, ta variable i ne prend des valeurs que de 0 à 255, aucune négative, donc tu as bien pris les mesures qui conviennent. Mais c'est toi qui le sais, pas le compilateur. Le cast est donc nécessaire.

Tu aurais pu faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
for(char ch = 0; ch < 256; ch++) {
 
}

Et le cast aurait été inutile.


Ensuite, et même chose, un int peut avoir des valeurs jusqu'à 2.147.483.647 et ce n'est évidemment pas le cas d'un char, d'où risque d'erreur.


Enfin, reste le cas compliqué des valeurs entre U+FFFF et U+10FFFF. C'est à dire de 65.535 à 1.114.111
J'ai un peu simplifié en disant que les char, c'est de l'Unicode. C'est vrai tant qu'on reste entre U+0000 et U+FFFF, et donc bien sûr pour les 255 premiers. Mais au-delà, c'est plus compliqué.
Les char Java tiennent sur deux octets, ils ne peuvent donc représenter les caractères que de U+0000 à U+FFFF. Au-delà, ça ne rentre pas.
Java gère quand même les caractères qui vont au-delà, mais il faut alors deux char consécutifs, un seul ne suffit pas. Le mécanisme est le même qu'en UTF-16.

Et donc, si tu essaies de rentrer dans un char une valeur supérieure à 65.535, ça ne rentre pas. Par exemple, dans le cas de U+12345, ça ne rentre pas, et le cast va tronquer cette valeur en enlevant le début et en ne gardant que U+2345. D'où résultat inattendu.

[exaju]

Ok. ça avance un peu (du côté de la compréhension) mais pas de l'exercice... Pour info voici l'intitulé exacte de la question: " coder en UTF-8 les 256 premières valeur du code UC16 " ni plus, ni moins. J'en ai déduit UC16=Unicode sur 16 bits et qu'il fallait être indépendant pour la résolution de cet exercice mais peux être que je me trompe ? Donc pas plus d'indications...

Je vais essayer de comprendre le fond de ta démonstration, j'ai compris que tant que j'affiche des String en console je verrais pas de différence.

Donc pour démontrer une différence entre les encodages (table de correspondance byte <>caractère différente) je peux les transformer en binaire et les comparer non ? Ou utiliser la classe Writer() pour pousser le tout dans un fichier ?

Le truc c'est que dans mon code les bytes en UTF-8 ou en Unicode sont similaires...

Mais tu me dit aussi " L'encodage de charset se fait sur l'ensemble d'un texte, par sur ses caractères séparés" donc avec l'intitulé de l'exercice qui ne parle que des 255 premiers caractères il n'y aura aucune démonstration de différence non ?

En tout cas merci encore de ta patience... J'avoue que je suis comme une poule qui à trouvé un couteau... ça fait mal parfois :-)

[exaju]

Merci tchize_ pour les précisions concernant "l'affichage d'un encodage".Enfin, reste le cas compliqué des valeurs entre U+FFFF et U+10FFFF. C'est à dire de 65.535 à 1.114.111J'ai un peu simplifié en disant que les char, c'est de l'Unicode. C'est vrai tant qu'on reste entre U+0000 et U+FFFF, et donc bien sûr pour les 255 premiers. Mais au-delà, c'est plus compliqué.Les char Java tiennent sur deux octets, ils ne peuvent donc représenter les caractères que de U+0000 à U+FFFF. Au-delà, ça ne rentre pas.Java gère quand même les caractères qui vont au-delà, mais il faut alors deux char consécutifs, un seul ne suffit pas. Le mécanisme est le même qu'en UTF-16.

Merci pour l'explication c'est tout de suite plus clair (le cast vers une primitive/objet codé sur un nombre de bits inférieur = perte) et je vais, avant de voir comment ça peux être sérialisé (c'est le bon terme ?) en plusieurs char si le char est > 65535 (2^16), essayer d'assimiler la base :-)

[exaju]

Salut à toi tchize_ j'ai oublié toute politesse car je n'avais pas vu que c'était une réponse d'une autre personne... et donc merci pour ton explication et d'avoir pris un peu de ton temps pour me répondre

Sinon je continue ma quête du graal de l'encodage

Je viens de lire la fiche Wikipedia sur UTF8: https://fr.wikipedia.org/wiki/UTF-8 et un exemple de conversion de Oracle: https://docs.oracle.com/javase/tutor...xt/stream.html et je suis partit sur cette démonstration avec un fichier écrit en UTF-8 puis lu et affiché dans une fenêtre...

Mais le rendu est identique, et si je comprends bien c'est normal, car UTF-8 est codé sur 8 bits (1 octets) mais est "variable" et peux être encodé jusqu'a 32 bits (4 octets) si besoin, donc tous les caractères unicode (sauf les demi-codets kesako ?) sont compatibles.

Mais si je comprends bien UTF-8 est un sous ensemble d'Unicode et donc tout caractère UTF-8 est valide en Unicode, donc il ne peux y avoir de différence ? ça avance mais je sens que je ne saisi pas encore tout...

[thelvin]

UTF-8 est un moyen d'encoder Unicode.
Unicode étant une définition mathématique des caractères associés à des nombres entier de U+0 à U+10FFFF, c'est très bien et tout, mais il arrive un moment où il faut se rappeler qu'on fait ça pour des ordinateurs, et qu'il faut donc trouver un moyen de mettre ces entiers dans un ordinateur.
Autrement dit il faut définir un encodage d'Unicode, et UTF-8 est un tel encodage. Il y a aussi les UTF-16 et les UTF-32, par exemple. Dans la même veine, Java en interne a son propre encodage, qui au départ disait un caractère <-> un char, mais qui est devenu plus compliqué quand Unicode a passé le cap de U+FFFF.


Quant à ce que tu peux faire pour "voir" de l'UTF-8, eh ben, c'est moi qui t'ai posé cette question le premier .
Je suis désolé mais dans le monde réel, on ne fait pas de l'UTF-8 pour le plaisir de dire qu'on fait de l'UTF-8. On fait de l'UTF-8 parce que si on faisait autre chose ça marcherait pas. Et donc on voit qu'on en fait, parce que ça marche.
Toi tu te mets dans des situations qui marchent de toute façon dès le départ, donc UTF-8 ne te concerne pas et il n'y a rien à regarder.


À la rigueur ce que tu peux faire, c'est regarder les tableaux de byte obtenus. Constater leur longueur et la valeur de chaque byte, par exemple.
Ça te montrera notamment que tous les caractères avant 128 tiennent sur 1 seul octet, et que leur valeur va de 0x00 à 0x79. À l'inverse ceux que tu vois après tiennent sur deux octets, et leurs valeurs sont toujours au-dessus de 0x80. Autrement dit les valeurs d'avant et d'après ne se recoupent pas.
C'est intéressant à voir.

[tchize_]

Pour info voici l'intitulé exacte de la question: " coder en UTF-8 les 256 premières valeur du code UC16 " ni plus, ni moins. J'en ai déduit UC16=Unicode sur 16 bits et qu'il fallait être indépendant pour la résolution de cet exercice mais peux être que je me trompe ? Donc pas plus d'indications...

Donc faut voir ton cours / prof pour savoir ce qu'il appelle uc16. Car le seul uc16 que je trouve sur internet, c'est ça:

[exaju]

Salut à vous deux; tchize_ et thelvin et merci pour votre engagement.

@tchize_
J'ai fait la même chose que toi et j'ai trouvé la même chose donc dans le doute je suis partit sur Unicode sur 16 bits, ce qui se rapproche le plus de l'énoncé (UC16) mais demain j'ai le cours et je demanderai des informations complémentaire en effet !

@Thelvin

Quant à ce que tu peux faire pour "voir" de l'UTF-8, eh ben, c'est moi qui t'ai posé cette question le premier .

Je te laisse la paternité de cette idée, dans mon cerveau embrouillé j'ai sûrement cru à un moment que c'était moi qui avais eût cette idée mais comme tu me l'a gentiment rappelé elle m'a été soufflée...

Bref, j'ai encore le cerveau qui fume avec cette UE et je vais essayer de débroussailler l'exercice avec des questions au prof demain... Je posterai demain soir ou mercredi des nouvelles, voir le code pour répondre à cet exercice.

En tout cas merci encore à vous deux, je me sens moins seul avec ma peine et mon mal de tête !!!

Bonne soirée à vous deux

[exaju]

Salut à vous deux; tchize_ et thelvin !

Alors j'ai vu avec mon prof qui a débroussaillé un peu tout ça... UC16 = UCS16 soit unicode sur 16 bits.

Après le but de l'exercice est de prendre les 255 premiers codes Unicode sur 16Bits et les transformer en UTF8 le tout en sortie en hexa dans un tableau comme celui-ci: [Représentation Unicode Hexa | Représentation UTF8 Hexa | Caractère]

Pour nous aider ils nous à donné ce schéma:
Ainsi l'octet: " [1x xxxxxx]" (découpé en 2) en unicode deviens: [110xxxxx 10xxxxxx] en UTF-8 (au dessus de 127...)

Ainsi l'octet: [1x xxxxxx] en unicode deviens: [0xxxxxxx] en UTF-8 (au dessous de 127...)

Donc on utilise l'opérateur >> pour décaler les bits et on fait un & sur le masque et un OU logique ensuite pour ajouter l'extension "110" pour le deuxième octet et "10" pour le premier. Ce qui donne pour > 127

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Avec I un short incrémenté:
short codePoint = (short) (i >> 6);
byte curByte1 = (byte)((i & 0x3F) | 0x80);
byte curByte2 = (byte)(codePoint | 0xC0);
String hex = String.format("%02x%02x | %2c "curByte2,curByte1,i);

System.out.println(hex);

J'avoue que je l'ai codé et que ça marche (même valeurs attendues que les références sur internet) mais pour le 1/3 je l'ai fais en reverse engineering et donc il y a des choses que je comprends pas bien. Ce que je comprends mal c'est qu'en dessous de 127 je fais 0 conversion et c'est correct en hexa...

Je posterai bien le résultat mais je risque de me faire engueler si je fourni la réponse complète à un exercice noté sur internet...

Sinon ça vous parle ce genre de code et de manipulation ? D'ailleurs je vous solliciterai sûrement encore car la suite est aussi coton; faire une fonction qui encode et une autre qui décode du Base64 !! ARGHHHH !!!

En tout cas merci à vous deux pour votre patience, si vous avez des remarques n'hésitez pas !!!

[Gugelhupf]

Vous m'excuserez je n'ai pas suivi toute la conversation, mais je vois qu'il y a un besoin de manipuler les 255 premiers caractères unicode, et je vois que le type byte est utilisé, mais sa plage va de -128 à 127.

[thelvin]

En lisant la discussion, tu constateras que ce n'est pas grave.
Seuls des char, short et int ont été utilisés avec valeur de 0 à 255.
Les bytes ne sont là que pour l'encodage, après donc, qu'on ait choisi les 256 premiers caractères à encoder.