Comment compiler un fichier source java codé "UTF-8"?
j'ai sauvegardé mon fichier source Java en spécifiant son type d'encodage comme UTF-8 (en utilisant Notepad, par défaut le type d'encodage de Notepad est ANSI) et ensuite j'ai essayé de le compiler en utilisant:
javac -encoding "UTF-8" One.java
mais il a donné un message d'erreur"
One.java:1: illegal character: 279
?public class One {
^
1 error
Est-il un autre moyen, je peux le compiler?
Voici la source:
public class One {
public static void main( String[] args ){
System.out.println("HI");
}
}
10 réponses
Votre fichier étant lu comme UTF-8, sinon un caractère avec la valeur "65279" ne pourrait jamais apparaître. javac s'attend à ce que votre code source soit dans l'encodage par défaut de la plate-forme, selon javac documentation:
Si codage n'est pas spécifié, le convertisseur par défaut de la plate-forme est utilisé.
Décimal 65279 est hex FEFF, qui est l' Unicode Marque d'Ordre des Octets (BOM). C'est inutile dans UTF-8, parce que UTF-8 est toujours encodé comme un flux d'octet et n'a pas de problèmes d'endianité.
Notepad aime coller dans les BOMs même quand ils ne sont pas nécessaires, mais certains programmes n'aiment pas les trouver. Comme D'autres l'ont souligné, Notepad n'est pas un très bon éditeur de texte. Passer à un autre éditeur de texte résoudra presque certainement votre problème.
ouvrir le fichier dans le bloc-notes++ et sélectionner Encoding - > convertir en UTF-8 sans BOM.
javac -encoding UTF8 One.java
sans les citations et C'est UTF8, pas de tiret.
Ce n'est pas un problème avec votre éditeur de texte, c'est un problème avec javac ! La spécification Unicode dit que BOM est optionnel en UTF-8, ça ne dit pas que c'est interdit ! Si un BOM peut être là, alors javac doit s'en occuper, mais ce n'est pas le cas. En fait, l'utilisation du BOM dans les fichiers UTF-8 est utile pour distinguer un fichier codé ANSI d'un fichier codé Unicode.
la solution proposée de supprimer le BOM n'est qu'une solution de contournement et non la bonne solution.
Ce rapport de bug indique que ce "problème" ne sera jamais corrigé : http://bugs.java.com/view_bug.do?bug_id=4508058
puisque ce fil est dans le top 2 des résultats google pour la recherche" javac BOM", je laisse ceci ici pour les futurs lecteurs.
je sais que c'est un fil très ancien, mais je rencontrais un problème similaire avec PHP au lieu de Java et Google m'a pris ici. J'écrivais PHP sur le Notepad++ (pas un simple Notepad) et j'ai remarqué qu'une ligne blanche supplémentaire apparaissait chaque fois que j'appelais un fichier include. Firebug a montré qu'il y avait un 65279 caractère dans ces lignes supplémentaires.
en fait, le fichier PHP principal et les fichiers inclus étaient encodés en UTF-8. Cependant, Notepad++ a aussi une option pour encoder comme " UTF-8 sans BOM". Cela a résolu mon problème.
en bref: L'encodage UTF-8 insère çà et là ce caractère bom supplémentaire à moins que vous ne demandiez à votre éditeur D'utiliser L'encodage UTF8 sans BOM.
Voir Ci-Dessous Par exemple, nous pouvons discuter avec un programme (mots Telugu)
Programme (UnicodeEx.java)
class UnicodeEx {
public static void main(String[] args) {
double ఎత్తు = 10;
double వెడల్పు = 25;
double దీర్ఘ_చతురస్ర_వైశాల్యం;
System.out.println("The Value of Height = "+ఎత్తు+" and Width = "+వెడల్పు+"\n");
దీర్ఘ_చతురస్ర_వైశాల్యం = ఎత్తు * వెడల్పు;
System.out.println("Area of Rectangle = "+దీర్ఘ_చతురస్ర_వైశాల్యం);
}
}
Ceci est le programme tout en sauvegardant sous "UnicodeEx.java "et changer L'encodage en "unicode"
**Comment Compiler**
javac-encoding" unicode " UnicodeEx.java
Comment Exécuter
java UnicodeEx
La valeur de hauteur = 10.0 et largeur = 25.0
surface du Rectangle = 250.0
fonctionne bien ici, même édité dans Bloc-notes. La morale de l'histoire, ne pas utiliser de bloc-notes. Il y a probablement un personnage inimitable là-dedans que le bloc-notes insère ou se cache heureusement de vous.
j'ai eu le même problème. Pour la résoudre, ouvert le fichier dans un éditeur hexadécimal et trouvé trois "invisible" octets au début du fichier. Je les ai enlevées, et la compilation a fonctionné.
ouvrez votre fichier avec WordPad ou tout autre éditeur à l'exception de Notepad.
Sélectionnez Enregistrer sous le format Texte-Format MS-DOS
Rouvrir le Projet
Pour prolonger l'existant des réponses avec une solution pour les utilisateurs de Linux:
Pour supprimer la NOMENCLATURE sur tous les .java fichiers à la fois, allez dans votre répertoire source et l'exécution
find -iregex '.*\.java' -type f -print0 | xargs -0 dos2unix
il faut find, xargs et dos2unix à installer, qui devrait être inclus dans la plupart des distributions. La première déclaration trouve tout .java fichiers dans le répertoire courant de façon récursive, le second convertit chacun d'eux avec le dos2unix outil, qui est destiné à convertir les fins de ligne, mais supprime également la NOMENCLATURE.
la conversion des fins de ligne ne devrait pas avoir d'effet car elle devrait déjà être sous Linux \n formater sur Linux si vous configurez correctement votre contrôle de version mais soyez averti qu'il le fait aussi dans le cas où vous avez un de ces rares cas où ce n'est pas prévu.