Dont l'encodage n'Processus.getInputStream() utiliser?

Dans un programme Java, je frayer un nouveau Process via ProcessBuilder.

args[0] = directory.getAbsolutePath() + File.separator + program;
ProcessBuilder pb = new ProcessBuilder(args);
pb.directory(directory);
final Process process = pb.start();

Puis, j'ai lu le processus de sortie standard avec un nouveau Thread

new Thread() {
    public void run() {
        BufferedReader reader = new BufferedReader(
            new InputStreamReader(process.getInputStream()));
        String line = "";
        while ((line = reader.readLine()) != null) {
            System.out.println(line);
    }
}.start();

Toutefois, lorsque le processus de sorties de caractères non-ASCII (comme 'é'), le line a du caractère '\uFFFD' à la place.

Qu'est-ce que l'encodage dans le InputStream retourné par getInputStream (ma plateforme Windows en Europe)?

Comment puis-je changer les choses pour que line contient les données attendues (c'est à dire '\u00E9' pour 'é')?

Edit: j'ai essayé new InputStreamReader(...,"UTF-8"):
é devient \uFFFD

  • BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream(), "UTF-8"));
  • s'il vous plaît écrire une réponse plutôt qu'un commentaire, si vous voulez répondre
InformationsquelleAutor rds | 2011-12-06
  1. 3

    Que je comprends, un système d'exploitation, les flux sont des octets de flux, il n'y a pas de caractères ici. Le InputStreamReader constructeur utilise jvm jeu de caractères par défaut java.nio.charset.Charset#defaultCharset(), vous pouvez utiliser un autre constructeur de spécifier un jeu de caractères.

    • Oui, j'ai eu à new InputStreamReader(...,"ISO-8859-1")
    InformationsquelleAutor kan
  2. 9

    Un InputStream est un flux binaire, donc il n'y a pas de codage. Lorsque vous créez le Lecteur, vous devez savoir ce codage des caractères à utiliser, et cela dépendra de ce que le programme que vous avez appelé produit (Java ne sera pas le convertir en quelque sorte).

    Si vous ne spécifiez rien pour InputStreamReader, il va utiliser la plate-forme de codage par défaut, ce qui peut ne pas être approprié. Il est un autre constructeur qui vous permet de spécifier l'encodage.

    Si vous savez ce que le codage à utiliser (et vous avez vraiment à le savoir):

    new InputStreamReader(process.getInputStream(), "UTF-8") //for example
    • Et comme @AlexR points, le même raisonnement s'applique à l'écriture de données, trop.
    • UTF-8 est l'encodage par défaut en Java, donc "UTF-8" ne peut pas aider. La solution est proche, il a juste besoin de "Cp1252" ou "ISO-8859-1" (en fonction de ce que getInputStream() retours)
    • UTF-8 est pas l'encodage par défaut en Java. Il n'y a pas de valeur par défaut, il utilise toujours quelque chose dépendants de la plateforme (qui peut être contrôlée par des variables d'environnement et les propriétés du système). Pas quelque chose d'un développeur d'applications doit généralement s'appuyer sur. Mieux vaut toujours être explicite dans l'encodage que vous voulez.
    • UTF-16 est de java standard interne de la représentation des personnages. D'où la non signé de 16 bits 'char' primitive. Le InputStreamReader TOUJOURS convertir en UTF-16. Bien que l'InputStream est un flux binaire, s'il représente les personnages les octets de suivre ce que le codage a été utilisé pour créer la ressource. Le InputStreamReader constructeur mentionné par Thilo inclut un argument pour spécifier l'encodage de la ressource - comment le flux doit être traitée.
    InformationsquelleAutor Thilo
  3. 5

    Fait intéressant à noter, lors de l'exécution sur Windows:

    ProcessBuilder pb = new ProcessBuilder("cmd", "/c dir");
Process process = pb.start();

    Puis CP437 page de code fonctionne très bien pour

    new InputStreamReader(process.getInputStream(), "CP437");
    • Comme d'autres isc de l'InputStream contient des caractères dans la plate-forme d'encodage. Depuis que j'ai un système d'exploitation moderne, j'ai UTF-8; puisque vous avez Windows, vous avez CP437.
    • Êtes-vous sûr? Vous spécifiquement dire dans la question: mon programme est Windows...
    • Merci, CP437 était le seul jeu de caractères nom qui a fonctionné pour moi (Windows + espagnol caractères)
    • En fait, de nos jours, qui devrait être CP850. La chose étrange est qu'il semble que le système windows est windows-1252/cp1252 (au moins en europe de l'ouest), mais la console utilise CP850 spécifiquement à la place. CP437 est l'ancêtre de CP850. L'ouverture de l'invite de commande et exécutez "chcp" devrait vous dire exactement ce qui l'encodage à l'aide d'imprimer des données de type char.
    • Aussi, l'encodage à utiliser pour l'analyse de l'InputStream dépend de ce programme, l'ProcessBuilder est construit autour de. Disons par exemple : CP850 pour cmd, windows-1252 pour certains autres outils windows vous pouvez appeler directement (sans les emballer dans cmd), et, éventuellement, de l'UTF-8 si le programme que vous appelez sorties UTF-8. Ce programme est spécifique et doit être regardé dans la documentation du programme.
    • Nice! J'ai vérifié certains windows 10 paramètres. Pour diverses européenne paramètres, il est CP850, mais pour defaultians (US paramètres), il reste CP437.

    InformationsquelleAutor jan.supol
  4. 2

    Selon http://www.fileformat.info/info/unicode/char/e9/index.htm '\uFFFD' est un code unicode du caractère 'é'. Cela signifie en fait que vous êtes la lecture du flux correctement. Votre problème est dans l'écriture.

    Console Windows ne prend pas en charge unicode par défaut. Donc, si vous voulez tester votre code d'ouvrir le fichier et écrire votre flux de là. Mais n'oubliez pas de régler l'encodage UTF-8.

    • Correct. new PrintWriter(OutputStreamWriter(..., "Cp1252")) où Cp1252 est le Latin-1 avec extension de Windows, employé dans une petite partie de l'Europe de l'ouest (la France, l'Allemagne et quelques).
    • Pourquoi avez-vous point le caractère (0xE9 que je veux) quand j'ai le caractère 0xFFFD aka de REMPLACEMENT par le CARACTÈRE' fileformat.info/info/unicode/char/fffd/index.htm
    InformationsquelleAutor AlexR
  5. 1

    Scientifique

    Sur Windows cela fonctionne parfaitement:

    private static final Charset CONSOLE_ENCODING;
static {
    Charset enc = Charset.defaultCharset();
    try {
        String example = "äöüßДŹす";
        String command = File.separatorChar == '/' ? "echo " + example : "cmd.exe /c echo " + example;
        Process exec = Runtime.getRuntime().exec(command);
        InputStream inputStream = exec.getInputStream();
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        while (exec.isAlive()) {
            Thread.sleep(100);
        }
        byte[] buff = new byte[inputStream.available()];
        if (buff.length > 0) {
            int count = inputStream.read(buff);
            baos.write(buff, 0, count);
        }

        byte[] array = baos.toByteArray();
        for (Charset charset : Charset.availableCharsets().values()) {
            String s = new String(array, charset);
            if (s.equals(example)) {
                enc = charset;
                break;
            }
        }
    } catch (InterruptedException e) {
        throw new Error("Could not determine console charset.", e);
    } catch (IOException e) {
        throw new Error("Could not determine console charset.", e);
    }
    CONSOLE_ENCODING = enc;
}

    Conformément au cahier des charges: il n'y a pas d'astuce pour l'exécution de codage de changement de la jvm. Nous ne peut pas assurez-vous que le codage ne change PAS lors de l'exécution et le jeu de caractères toujours correct après un tel changement.

    • Hmmm... bonne idée, mais en fait il ne fonctionne pas sur mon système (Windows 7 SP1 64 bits, Java 8 construire 71) -- aucun des codages produit de la chaîne d'origine. Le problème semble être que l'exemple donné de la chaîne n'est même pas correctement transférées au système, de la production de "?" caractères à la place. En dehors de cela, j'ai aussi d'obtenir un supplément de "\r\n" à la fin de la sortie.
    InformationsquelleAutor Peter Rader
  6. 1

    Si vous, comme moi, de savoir dans quel encodage que vous souhaitez utiliser pour toutes les entrées/sorties, vous pouvez l'encoder dans l'API Java appels à certains (pas tous) CreateReader méthodes, dont certaines autres réponses ont souligné.

    Mais ce sera dur de code dans la source, ce qui pourrait ou ne pourrait pas, être ok.

    J'ai trouvé une meilleure façon après la lecture de cette réponse qui révèle que vous pouvez définir l'encodage avant de la machine démarre jusqu'à ce que vous avez besoin.

    java -Dfile.encoding=ISO-8859-1 ...
    InformationsquelleAutor thoni56
  7. 0

    J'ai mis ça comme commentaire, mais je vois qu'il y avait une réponse ,alors il pourrait être redondant maintenant 🙂

    BufferedReader br = new BufferedReader(
    new InputStreamReader(conn.getInputStream(), "UTF-8"));
    • UTF-8 est le codage par défaut. Donc, cela n'aide pas.
    InformationsquelleAutor Cris
  8. 0

    utilisation commons-lang fichier jar dans cette utilisation, - StringEscapeUtils.escapeHtml 

    BufferedReader br = new BufferedReader(
    new InputStreamReader(StringEscapeUtils.escapeHtml(conn.getInputStream()));
    InformationsquelleAutor Vikas Nagargoje viki