Comment puis-je trouver le codage d'octet d'un message TIBCO Rendezvous?

Question

Dans mon application Java, je suis l'archivage des messages TIBCO RV à un fichier en octets.

Je suis en train d'écrire une petite application utilitaire qui va jouer les messages en arrière. De cette façon, je peux créer un objet TibrvMsg des octets sans avoir à analyser le fichier et construire l'objet manuellement.

Le problème que j'ai est que je suis en train de lire un fichier qui a été créé sur une boîte Linux, et de tenter d'exécuter mon application sur une machine Windows. Je reçois une erreur en raison du jeu de caractères différent du fichier a été écrit dans.

Alors maintenant, ce que je veux faire est Consigner chaque message dans un jeu de caractères spécifique (UTF-8), de sorte que je ne me soucie pas ce que la plate-forme je lance mon application de lecture. L'application devrait simplement lire dans le fichier savoir avant la main le jeu de caractères du fichier est écrit. Je suis planification sur l'utilisation des paquets de java.nio pour cela, pour transformer les octets d'un charset à l'autre.

Ai-je besoin de savoir ce que charset les octets de messages TIBRV sont codés pour faire la transformation? Si oui, comment puis-je trouver cela?

Answer 1

Vous prenez des données opaques et, il semblerait, en essayant d'écrire dans un fichier sous forme de données textuelles sans échapper aux parties non textuelles de celui-ci (sinon, vous écrivez comme octets bruts, puis essayer de le lire comme si elle ont été le caractère à base qui est bien le même problème). Ceci est viciée dès le début.

Les données Opaque doivent être traités comme vide de sens et simplement stockés sans modification de redonner à une API qui ne sait comment faire face. Si les données doivent être stockées sous une forme textuelle, vous devez losslessly convertir les octets en texte. encodages appropriés sont des choses comme base64. L'encodage dans le sens du jeu de caractères encodage est sans perte pas si vous l'appliquez aux données binaires brutes.

simplement stocker les octets dans un fichier sous la forme octets (pas de caractères) ainsi que d'un préfixe de longueur fixe indiquant la longueur du message et le sujet a été envoyé sur est suffisante pour relire les messages de VR par la système.

En ce qui concerne les champs de texte à l'intérieur du message si les questions de codage (je vous suggère fortement d'éviter ce mattering en général lors de la conception de l'application), vous avez le même problème sur la relecture que vous auriez eu au moment de la réception originale qui est de convertir le codage de source pour le codage désiré (espérons en utilisant exactement le même code) ce qui devrait être un problème non par rapport à la relecture.

Answer 2

Comme cela (certes un peu vieux) message liste de diffusion indique, on sait peu sur la structure interne de ce protocole de réseau. Cela pourrait en faire un défi de faire ce que vous êtes après.

Cela dit, si les messages ne sont que des blocs de données binaires (comme capturées à partir du réseau), ils ne devraient même pas avoir un charset. Charsets est pour les données textuelles, où il importe depuis un seul caractère peut être codé de plusieurs façons différentes. Les données binaires ne se compose pas de caractères, donc il ne peut pas être un codage en ce sens.

Answer 3

Ceci est probablement lié à l'encodage de chaîne Java, pas TIBRV. Bien qu'il y ait cela dans la documentation:

Strings and Character Encodings 

--------------------------------------------------------------------------------

Rendezvous software uses strings in several roles: 

* String data inside message fields
* Field names
* Subject names (and other associated strings that are not
  strictly inside the message)
* Certified delivery correspondent names
* Group names (fault tolerance)

All these strings (both in C and in wire format) use the character
encoding appropriate to the ISO locale of the sender. For example,
the United States is locale en_US, and uses the Latin-1 character
encoding (also called ISO 8859-1); Japan is locale ja_JP, and uses
the Shift-JIS character encoding. 

When two programs exchange messages within the same locale, strings
are always correct. However, when a message sender and receiver use
different character encodings, the receiving program must convert
between encodings as needed. Rendezvous software does not convert
automatically. 

EBCDIC 
For information about string encoding in EBCDIC environments,
see tibrv_SetCodePages() . 

Vous pouvez regarder les paramètres régionaux des machines.

Answer 4

  

Ai-je besoin de savoir ce que charset la   octets de message TIBRV sont codés pour   faire la transformation?

Oui. Un jeu de caractères est une méthode de transformation de texte en un flux d'octets, et vice versa. Vos données de réseau est un flux d'octets, donc quand vous interprétez des parties de celui-ci sous forme de texte, que vous (implicitement ou explicitement) à l'aide d'un jeu de caractères -. La question est de savoir s'il est le bon

Transformer octets d'un charset à un autre signifie essentiellement les convering en texte en utilisant un charset et puis de nouveau à octets en utilisant un autre. Notez que cela peut entraîner la longueur du changement de données, car de nombreux jeux de caractères utilisent plus de 1 octet pour certains caractères. Dans le contexte des messages du réseau, cela pourrait être problématique quand il invalident les champs de longueur ou provoque des champs de texte à déborder. Il est sans doute préférable de ne pas faire toute transformation et au lieu enseigner l'application de lecture pour apprendre comment faire face à différents jeux de caractères.

  

Si oui, comment puis-je trouver cela?

Regardez la spécification du protocole.

Answer 5

Lire tout inte un octet [] à partir d'un INPUTSTREAM écrire l'octet [] à un FileOutputStream.

NO Reader ou Writer doivent être impliqués, ils le font la conversion des caractères et qui ne va pas.

Rester loin de java.nio jusqu'à ce que vous comprenez java.io.