Je travaille sur un serveur proxy. Je reçois des données dans Donc, principalement c'est comme si je dois savoir correctement convertir un J'ai essayé de convertir le donc c'est comme: p> n'est pas équivalent à p> mon proxy fonctionne bien lorsque je viens d'envoyer le peut-il vous aider? =] p> p> octet [] code> que je convertis en une chaîne
code> pour effectuer certaines opérations. Maintenant, lorsque je convertissez cette nouvelle chaîne code> de la chaîne de code> dans un octet
[] code> Il provoque des problèmes inconnus.
octet [] code> dans une chaîne code> retour> puis dans un octet
[] code> à nouveau. p>
octet [] code> à
string code> puis retour à
octet [] code> à nouveau (pour vous assurer que ce n'est pas mes opérations qui ne causent pas de problèmes). p>
octet [] code> sans aucune conversion, mais lorsque je le convertit de
octet [] code> à une chaîne code> et ensuite retour à un octet
[] code> ses problèmes. P>
4 Réponses :
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: 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. P> p>
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.
Le meilleur moyen de convertir un octet Si vous devez, vous devez connaître le codage utilisé pour produire le Quant à la manière de savoir le codage, cela dépend: P>
S'il n'y a aucun moyen de trouver le codage vous avez des ordures aléatoires, pas des données texte em>. p>. [] code> à
et de retour dans un octet
[] code> ne doit pas le faire du tout. p>
octet [] code>, 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. P>
en-tête li>
ul>
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! :)
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); }
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); }}
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.