8
votes

Conversion de l'octet [] dans une chaîne puis de retour à un octet []

Je travaille sur un serveur proxy. Je reçois des données dans octet [] que je convertis en une chaîne pour effectuer certaines opérations. Maintenant, lorsque je convertissez cette nouvelle chaîne de la chaîne dans un octet [] Il provoque des problèmes inconnus.

Donc, principalement c'est comme si je dois savoir correctement convertir un octet [] dans une chaîne puis dans un octet [] à nouveau.

J'ai essayé de convertir le octet [] à string puis retour à octet [] à nouveau (pour vous assurer que ce n'est pas mes opérations qui ne causent pas de problèmes).

donc c'est comme: xxx

n'est pas équivalent à xxx


mon proxy fonctionne bien lorsque je viens d'envoyer le octet [] sans aucune conversion, mais lorsque je le convertit de octet [] à une chaîne et ensuite retour à un octet [] ses problèmes.

peut-il vous aider? =]


2 commentaires

Eh bien, le codage est un peu Ramdom ... jusqu'à présent, je n'ai vu que "gzip, dégonfler" car je travaille avec un proxy Web qui transmettait les données entre un navigateur Web et un serveur Web.


Si c'est des données binaires, vous ne devriez pas la convertir à la définition moderne d'une "chaîne" du tout.


4 Réponses :


4
votes

Vous devrez connaître le codage de caractères utilisé, décoder les octets à l'aide de cela et re-encoder à l'aide du même codage de caractères. Par exemple: xxx

Si non spécifié, Java à l'aide d'un codage de caractères par défaut, typiquement utf-8 (il peut même être mandaté comme tel) mais HTML sera souvent autre chose. Je soupçonne que c'est ton problème.


2 commentaires

Le codage de caractères par défaut n'est pas typiquement UTF-8, au moins pas sur Windows.


La plupart des distributions Linux modernes par défaut à UTF-8, cependant.



9
votes

Le meilleur moyen de convertir un octet [] à et de retour dans un octet [] ne doit pas le faire du tout.

Si vous devez, vous devez connaître le codage utilisé pour produire le octet [] , sinon l'opération utilise le codage par défaut de la plate-forme, ce qui peut corrompre les données car tous les codages peuvent ne pas encoder Toutes les chaînes possibles, et toutes les séquences d'octets possibles ne sont pas légales dans tous les codages. C'est ce qui se passe dans votre cas.

Quant à la manière de savoir le codage, cela dépend:

  • Si vous utilisez http, consultez le Header de type contenu
  • Si vos données sont XML, vous devez utiliser un analyseur XML, qui gérera le codage pour vous
  • Si vos données sont des pages HTML, il peut également y avoir un en-tête

    S'il n'y a aucun moyen de trouver le codage vous avez des ordures aléatoires, pas des données texte . .


2 commentaires

AHA ... Merci pour la réponse détaillée ... Je suppose que je ferais mieux de commencer à travailler sur une nouvelle approche vers le proxy maintenant.


C'est une réponse merveilleusement stackoverflow-esque à sa question! :)



0
votes

J'ai un problème similaire lors de la lecture d'une prise et d'envoyer à un autre, mais mon problème était que j'écris la sortie avec une bufferedOutputStream, lorsque je change ceci en flux de sortie, cela fonctionne. Je pense qu'il y a un problème avec le flux de tampon de la buffer.

String mensaje ="what I want to send";
String ip = "192.168.161.165";
int port =  2042;
tpSocket = new Socket(ip, port);
os = tpSocket.getOutputStream();
byte[] myBytes= mensaje.getBytes();
ByteArrayInputStream byarris = new ByteArrayInputStream(myBytes);
int resulta =0;
byte[] bufferOutput= new byte[1];
while((resulta = byarris.read(bufferOutput))!= -1) {
    os.write(bufferOutput);
}


0 commentaires

4
votes

Si sa matrice d'octet signée, la solution la plus simple que j'ai trouvée a été coder le tableau d'octets avec base64encoderstream qui le convertira en octets non signés. Ensuite, vous devrez utiliser Base64Decoderstream pour décoder les octets pour récupérer le tableau d'octets signé original.

dépendance POM pour base64: com.sun.mail javax.mail 1.4.4 p>

public class EncryptionUtils {

private static String ALGO = "AES";
private static  Cipher cipher;




public static String encrypt(String message, String keyString) {
    cipher = Cipher.getInstance(ALGO);
        Key key = generateKey(keyString);
        cipher.init(Cipher.ENCRYPT_MODE, key);
        return new String(BASE64EncoderStream.encode(cipher.doFinal( message.getBytes())));
}

public static String decrypt(String message, String keyString)  {

       cipher = Cipher.getInstance(ALGO);
        Key key = generateKey(keyString);
        cipher.init(Cipher.DECRYPT_MODE, key);
        return new String(cipher.doFinal(BASE64DecoderStream.decode(message.getBytes()))); 

}

private static Key generateKey(String keyString) throws NoSuchAlgorithmException {
    byte[] keyBytes = BASE64DecoderStream.decode(keyString.getBytes());
    Key key = new SecretKeySpec(keyBytes, ALGO);
    return key;
}

public static void main(String args[]) {
    byte[] keyValue = new byte[16];
    new SecureRandom().nextBytes(keyValue);
    String key = new String(BASE64EncoderStream.encode(keyValue));
    String message = "test message";
    String enc = encrypt(message, key);
    String dec = decrypt(enc, key);
    System.out.println(dec);
}}


0 commentaires