cause profonde:

par défaut l'encodage des caractères ISO 8859-1 est utilisé pour le fichier de propriétés Eclipse (lire ici ), donc si le fichier contient un caractère au-delà de L'ISO 8859-1, il ne sera pas traité comme prévu.

Solution 1

si vous utilisez Eclipse, vous remarquerez qu'il convertit implicitement le caractère spécial en \Uxxxx équivalent. Essayez de copier

会意字 / 會意字

dans un fichier de propriétés ouvert dans Eclipse.

EDIT: Comme par le commentaire de l'OP

mettez à jour l'encodage de votre éclipse comme indiqué ci-dessous. Si vous définissez l'encodage comme UTF-32, alors vous pouvez même voir le caractère chinois, que vous ne pouvez pas voir généralement.

Comment changer l'Encodage du fichier de propriétés dans Eclipse: Voir ce Eclipse bug Bugzilla pour plus de détails, qui parle de plusieurs autres possibilités et à la fin de suggérer ce que j'ai mis en évidence ci-dessous.

les caractères chinois peuvent être vus dans Eclipse après que le codage est réglé correctement:

Solution 2

Si ci-dessus ne fonctionne pas systématiquement pour vous ( il ne fonctionne pour moi et je ne vois jamais de problèmes d'encodage ) puis essayer cela en utilisant certains plugin Eclipse qui gère l'encodage des propriétés ou d'autres fichiers. Par exemple Eclipse ResourceBundle Éditeur ou extension de la Resource-Bundle éditeur

je recommande D'utiliser Eclipse ResourceBundle Editor.

Solution 3

un autre possibilité de changer l'encodage du fichier en utilisant l'option Edit --> Set Encoding . Cela importe vraiment parce qu'il change le jeu de caractères par défaut et l'encodage du fichier. Jouez avec en changeant l'encodage en utilisant l'option Edit --> Set Encoding et en suivant Java sysout System.out.println("Default Charset=" + Charset.defaultCharset()); et System.out.println(System.getProperty("file.encoding"));

---

de côté: 1

traiter le fichier de propriétés pour avoir le contenu avec l'encodage de caractères ISO 8859-1 en utilisant native2ascii-natif-au-convertisseur ASCII

Ce native2ascii : Il convertit tous les non-ISO 8859-1 caractère dans leur équivalent \uXXXX. C'est un bon outil car vous n'avez pas besoin de rechercher l'équivalent \uXXXX du caractère spécial.

utilisation pour UTF-8: native2ascii -encoding utf8 e:\a.txt e:\b.txt

---

comme une mise de côté: 2

tout programme d'ordinateur QU'il s'agisse d'un IDE, d'un serveur d'application, d'un serveur web, d'un navigateur, etc. comprend seulement les bits, de sorte qu'il faut savoir interpréter les bits anticipée de sens, car en fonction de l'encodage utilisé, même bits peut représenter des caractères différents. et C'est là que" Encoding " entre en jeu image en donnant un identifiant unique pour représenter un caractère de sorte que tous les programmes informatiques, OS divers, etc. sait exact de la bonne façon de l'interpréter.

ainsi, si vous avez écrit dans un fichier en utilisant un schéma d'encodage, disons UTF-8, et puis la lecture en utilisant n'importe quel éditeur mais en exécutant avec Schéma d'encodage comme UTF-8 alors vous pouvez vous attendre à obtenir l'affichage correct.

s'il vous Plaît lire mes cette réponse pour obtenir plus de détails, mais du point de vue du navigateur-serveur.

Fichiers de Propriétés devraient être ISO-8859-1 (Latin-1) codé. Probablement, ce que l'éclipse a été défini sur par défaut.

vous devez vous assurer que chaque outil qui est exécuté dans la construction ou quoi que ce soit ne tient pas compte de la spécification et utilise UTF-8 à la place.

ajouter les arguments suivants à votre fichier eclipse.ini .

-Dclient.encoding.override=UTF-8
-Dfile.encoding=UTF-8

par défaut Eclipse utilise le format d'encodage récupéré par la machine virtuelle Java (JVM). De plus, vous pouvez définir le codage du fichier à utf-8 .

cela ressemble à un mélange D'Eclipse et de Git encoding ou plutôt pas-encoding.

Git utilise des octets bruts et ne se soucie pas de l'encodage. En utilisant git diff vous pourriez obtenir des caractères comme montré ici . Un exemple est R<C3><BC>ckg<C3><A4>ngig # should be "Rückgängig" .

comme vous pouvez le voir, il y a deux drôles de brackets par umlaut. Et dans votre éditeur, il y a toujours deux \uFFFD pour chaque umlaut dans les lignes commençant par + .

donc je suppose que votre éditeur UTF-8 essaie d'interpréter la notation git et échoue. Cela conduit à son tour à la représentation \uFFFD , qui signifie essentiellement qu'il s'agit d'un caractère dont la valeur est inconnue ou non brevetable ( voir ici ).

comme suggéré dans le premier lien, vous pouvez essayer de définir LESSCHARSET=UTF-8 dans votre variable d'environnement (Windows). Hmm, sous Linux, ça devrait être dans etc/profile ?

voir: un marqueur tel que FFFD (caractère de remplacement) dans http://unicode.org/faq/utf_bom.html

et voir native2ascii -- help

   -encoding encoding_name
          Specifies the name of the character encoding to be used by the conversion procedure. If this option is not present, then the
          default character encoding (as determined by the java.nio.charset.Charset.defaultCharset method) is used. The encoding_name
          string must be the name of a character encoding that is supported by the JRE. See Supported Encodings at
          http://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html

un cas

$ file yourfile.properties
yourfile.properties : ISO-8859 text, with very long lines
$ native2ascii -encoding ISO-8859-1 yourfile.properties yourfile.properties