Dev Faq
12
votes

Java: lecteurs et codages

Le codage par défaut de Java est ASCII code>. Oui? (Voir mon édition ci-dessous)

Lorsqu'un fichier texte est codé dans utf-8 code>? Comment un lecteur sache-t-il qu'il doit utiliser utf-8 code>? P>

Les lecteurs dont je parle sont: p>

  • FileReader Code> S LI>
  • bufferedreader code> s de socket code> s li>
  • A scanner code> à partir de système.in code> li>
  • ... li> ul>

    edit h1>

    Il tourne que notre codage dépend du système d'exploitation, ce qui signifie que ce qui suit n'est pas vrai sur chaque système d'exploitation: P> 

    'a'== 97

2 commentaires

J'ai trouvé cette question (et les réponses) très éducatives, merci!

La conclusion dans votre édition est pas correcte. 'A' == 97 est vrai sur tous les systèmes d'exploitation en Java, car à l'interne (pour char / chaîne) Java utilise UTF-16 partout. Seulement lorsque vous utilisez en quelque sorte l'encodage par défaut de la plate-forme (c'est-à-dire la conversion de Char / String en octets / octets [] sans spécification de codage explicitement) le résultat dépend de l'OS / Paramètres / ...

5 Réponses :

10
votes

Le codage par défaut de Java dépend de votre système d'exploitation. Pour Windows, c'est normalement "Windows-1252", pour UNIX, il est typiquement "ISO-8859-1" ou "UTF-8".

Un lecteur connaît le codage correct car vous le dites le bon codage. Malheureusement, tous les lecteurs ne vous laissent pas faire cela (par exemple, fileReader ne) pas), vous devez donc utiliser un INPUTStreamReader . .

6 commentaires

FYI: Le codage sur Windows dépend de la langue du système d'exploitation. MSDN.MicRosoft.com/en-us/Library/ DD317756% 28vs.85% 29.aspx Mais essentiellement, vous êtes correct - le codage par défaut est le codage du système - utilisez-le à votre péril.

La propriété système pour l'encodage par défaut est fichier.exoding et cela dépend normalement de vos paramètres locaux (langue de victoire, comme indiqué ci-dessus, ainsi que les variables LC _ * sur * Nix ).

@gustafc - merci pour l'information; J'ai regardé System.GetProperties () et je ne l'ai pas vu figurant parmi les propriétés standard, ainsi éditées de ma réponse. Je pense toujours que c'est une mauvaise idée de compter sur la valeur par défaut correctement définie.

Malheureusement, FilerAder est une classe de commodité pour lire des caractères dans le codage par défaut d'un fichier et rien de plus. Vous penseriez que cela vous permettrait de sélectionner également le jeu de caractères, mais ce n'est pas le cas. En fait, vous remarquerez que les signatures de constructeur sont identiques à des signatures constructrices Signature de fichier .

@kdgregory - Vous êtes correct sur fichier.excoding ne pas être une propriété standard; Il s'agit d'un détail de mise en œuvre que les développeurs ne doivent pas définir ou lire directement: Bugs.sun.com/ View_bug.doo?bug_id=4163515

Merci pour la réponse très claire et pour mentionner que fileReader ne le fait pas.

0
votes

Vous pouvez commencer à obtenir l'idée ici Java Charset API

Notez que, selon le doc,

le codage du personnage natif du Le langage de programmation Java est UTF-16

EDIT:

Désolé, j'ai été appelé avant que je puisse finir cela, je n'aurais peut-être pas dû poster la réponse partielle telle qu'elle était. Quoi qu'il en soit, les autres réponses expliquent les détails, le point étant que le fichier natif Charset de chaque plate-forme ainsi que des charages de remplacement commun seront lus correctement par Java.

1 commentaires

Bien que techniquement correct, ceci est sans importance ... L'encodage natif est uniquement utilisé dans Java . Lorsque les fichiers E / S sont terminés, les classes de lecteur utilisent l'encodage par défaut de la plate-forme, sauf si vous spécifiez une à l'aide des constructeurs pour un entréeStreamReader, qui prennent en charge les arguments de codage / charset.

5
votes

Pour la plupart des lecteurs, Java utilise tout ce que le codage et le caractère définissez votre plate-forme - ceci peut être une certaine arôme d'ASCII ou UTF-8, ou quelque chose de plus exotique comme JIS (au Japon). Les caractères de cet ensemble sont ensuite convertis en UTF-16 que Java utilise en interne.

Il y a un travail de travail si le codage de la plate-forme est différent d'un codage de fichier (mes fichiers UTF-8 sont standard, mais ma plate-forme utilise le codage Windows-1252). Créez une instance InputStreamReader qui utilise le constructeur spécifiant le codage. P>

EDIT: Faites-le comme: H2> 
InputStreamReader myReader = new InputStreamReader(new FileInputStream(myFile),"UTF-8");
//read data
myReader.close();

5 commentaires

Non, je ne suis pas français. Je suis néerlandais. Je parle flamande.

Hah, je suis en fait à moitié néerlandais moi-même. J'ai oublié de tes gars folles folles.

Bien sûr, vous êtes néerlandais. Ce serait "Martin" en français, pas "Martijn" :)

Flamand? Tu veux dire flamand :)

Je refuse de faire référence à un peuple par un nom qui ressemble à quelque chose appartenant à un tissu. Flamand, je dis! :)

26
votes

Comment un lecteur sache-t-il qu'il doit utiliser UTF-8? em> p>

Vous spécifiez normalement que vous-même fort> dans un INPUTStreamReader code> . Il a un constructeur qui prend le codage du personnage. Par exemple p> xxx pré>

Tous les autres lecteurs (autant que je sache) utilise le codage de caractères par défaut de la plate-forme, ce qui peut en effet ne pas être le codage correct (tel que -cough - em> cp-1252 code>). p>

Vous pouvez en théorie détecter également le codage du personnage automatique basé sur le Byte Commande Mark . Cela distingue les nombreux codages Unicode d'autres codages. Java SE n'a malheureusement pas d'API pour cela, mais vous pouvez accomplir homebrew one qui peut être utilisé pour remplacer InputStreamreader code> comme dans l'exemple ci-dessus: p> xxx pré>

Modifier STRT> comme réponse sur votre édition: p>

afin que le codage dépend du système d'exploitation. Cela signifie donc que non sur chaque système d'exploitation, cela est vrai: em> p> 

'a'== 97

4 commentaires

Vous oubliez d'Ebcdic ... à Ebcdic, 'A'! = 97.

Haha, tu as raison. EBCDIC est en effet un codage exclusif (IBM) qui existait Suivant à ASCII dans les temps hérités, mais à la fin ASCII a obtenu la domination du monde. De nos jours, vous verrez EBCDIC dans Old "Mainframes" uniquement (S / 390, VM et des consomptes) qui sont à son tour cependant configurable pour utiliser un fichier ASCII .

C'est une affichage très approfondie et le code est bon. J'aurais pu juré que certaines des API détectent automatiquement les codages courants, mais cela aurait pu être destiné à des trucs de réseau uniquement (spécifiquement http).

En outre, le fait que 'a' == 97 est toujours vrai en Java ne doit pas nécessairement avoir à voir avec ASCII directement, mais est un effet de Java à l'aide de UTF-16 en interne.

6
votes

J'aimerais aborder cette partie d'abord:

Le codage par défaut de Java est ASCII. Oui?

Il y a au moins 4 choses différentes dans l'environnement Java qui peut être qualifiée de "codage par défaut":

  1. La "briet par défaut" est ce que Java utilise pour convertir des octets en caractères (et octet [] sur string ) au moment de l'exécution, lorsque rien d'autre n'est spécifié. Celui-ci dépend de la plate-forme, des paramètres, des arguments de ligne de commande, ... et est généralement simplement le codage par défaut de la plate-forme.
  2. Le caractère interne codant pour que Java utilise dans Char valeurs et chaîne objets. Celui-ci est toujours utf-16 ! Il n'y a aucun moyen de le changer, c'est juste utf-16! Cela signifie qu'un char représentant a a la valeur numérique 97 et un caractère représentant π a toujours le numérique Valeur 960.
  3. Le personnage codant pour que Java utilise pour stocker des constantes de chaîne dans les fichiers .Class . Celui-ci est toujours utf-8. Il n'y a aucun moyen de le changer.
  4. Le charert utilise le compilateur Java pour interpréter le code source Java dans .java fichiers. Celui-ci est par défaut à la branlette par défaut, mais peut être configuré à l'heure de la compilation.

    Comment un lecteur sache-t-il qu'il doit utiliser UTF-8?

    Ce n'est pas le cas. Si vous avez un fichier texte clair, vous devez DO connaître le codage pour le lire correctement. Si vous avez de la chance, vous pouvez deviner (par exemple, vous pouvez essayer le codage par défaut de la plate-forme), mais c'est un processus d'erreur d'erreur et, dans de nombreux cas, vous n'auriez même pas un moyen de réaliser que vous avez mal deviné. Ceci est pas spécifique à Java. C'est vrai pour tous les systèmes.

    Certains formats tels que XML et tous les formats à base de XML ont été conçus avec cette restriction à l'esprit et incluent un moyen de spécifier le codage dans les données, de sorte que la devinette n'est plus nécessaire.

    Lire Le minimum absolu Tous les développeurs de logiciels absolument doivent connaître de manière positive à propos de Unicode et des ensembles de caractères (aucune excuse !) pour les détails.

0 commentaires

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject