Existe-t-il un moyen simple de faire cela ?

ben tu consideres tout comme de l'unicode et basta

euh... et tu lis deux octets par deux, et tu loupes la moitié  

ben non
en unicode les caracteres ascii sont pas encodés
les autres sont précédés de \u  
je raconte n'importe quoi?

--greg-- a écrit a écrit : ben non en unicode les caracteres ascii sont pas encodés les autres sont précédés de \u   je raconte n'importe quoi?

je pense, vu que pour une dll a la con windows a laquelle je devais m'interfacer et qui me permettait de recupérer les mots de passes, je lisais qu'un octet sur 2 (car cette merde d'api te file de l'unicode...)

ben en fait ça depend ss doute de quel type d'encodage on parle, mais (hop hop je reviens sur mes paroles discretement) il me semble que c'est genre: tu lis 1 octet: si < telle valeur ==> c de l'ascii, sinon tu prend le(s) suivant(s) en compte pour récupérer le caractere unicode
bon en meme temps si dans ton fichier ascii t'as de l'ascii étendu tu es pê de la baise. j'en sais trop rien en fait.
 
mais chuis persuadé qu'il y a moyen de lire les 2 sans devoir savoir à priori si c ascii pur ou unicode

Un premier test a faire, c'est déja voir si file est capable de faire a différence...

avec un Reader derrière, je pense que oui

--greg-- a écrit a écrit : avec un Reader derrière, je pense que oui

  je parlais de la commande unix

--greg-- a écrit a écrit : avec un Reader derrière, je pense que oui

j'avais même pas vu qu'on est dans un topic java
dans ce cas oui, tu prends un FileReader et il se démerde...

Par définition, du texte brut est... brut !Donc, aucune information annexe ne l'accompagne.
 
Maintenant, si tu cherches une astuce, tu peux essayer de compter le nombre d'octets à zéro, un ou deux dans, disons, les 4000 premiers caractères. Si leur proportion est proche de 50%, il y a de fortes chances que ton fichier soit en Unicode et qu'il ne contienne que des caractères européens.
 
Mais pour faire la différence entre un fichier Unicode rempli de caractères chinois et un fichier ASCII étendu... En tout cas, moi, je ne connais pas de méthode.

j'en connais bien une: le REGEDIT de Windows 2000 exporte sa registry sous forme de fichier unicode.  Si tu édites ce fichier en hexadécimal, tu vas voir que la chose commence par deux bytes précis: 255, 254 (soit en hexa FF FE).  Si ton fichier commence par ces deux bytes, c'est un fichier texte unicode, sinon, c'est de l'ascii.
 
J'ai eu le problème également en VB où j'essayais de charger une ressource texte mais ça marchait pas bien parce que VB travaille uniquement en unicode.

Pareil que Biface.
Je me suis frotté récemment à des fichiers en Japonais à encoder façon URLEncoder. Bin soit t'as une ligne au tout début de ton fichier qui te précise le charset, soit t'en sais rien. Donc bonne chance.
Par contre, je ne crois pas que FileReader marche. Comme le dit la doc, cette classe utilise le charset par défaut donc niveau portabilité du prog c'est moyen. Par contre, DataInputStream fait ça très bien, cf la javadoc de cette classe.
 
En attendant, bon courage passke c'est bien galère.

 
Moui euh bin perso j'peux te garantir que quand un Japonais sauvegarde un fichier texte de base sous Windows ou sous Unix, y a pas ces deux fameux caractères. Et pis toujours pour la portabilité, ça reste plus que moyen

Pour les readers il me semble que tu peux specifier un encodage hein...

 
Bin y a bien un getEncoding() mais pas de set, ou alors j'ai raté un truc. Comme dit la doc :

Ha ben voila, ce sont bien des Reader ça