在我的 Java 应用程序中，我将 TIBCO RV 消息作为字节归档到文件中。
我正在编写一个可以回放消息的小型实用程序。这样我就可以从字节中创建一个 TibrvMsg 对象，而无需解析文件并手动构造对象。
我遇到的问题是我正在读取在 Linux 机器上创建的文件，并尝试在 Windows 机器上运行我的应用程序。由于文件写入的字符集不同，我收到错误消息。
所以现在，我想要做的是将每条消息记录在一个特定的字符集（UTF-8）中，这样我就不关心我在哪个平台上运行我的播放应用程序了。该应用程序应该只在事先知道的文件中读取写入文件的字符集。我计划为此使用 java.nio 包，将字节从一个字符集转换为另一个字符集。
我是否需要知道 TIBRV 消息字节编码的字符集以进行转换？如果是这样，我怎样才能找到这个？
您正在获取不透明的数据，并且看起来，它试图将其作为文本数据写入文件而不转义它的非文本部分（或者您将其作为原始字节写入，然后尝试读取它，就好像它是基于字符的这是相同的问题）。这从一开始就是有缺陷的。
不透明的数据应该被视为无意义的，无需修改即可简单地存储，以返回给知道如何处理它的 API。如果数据必须以文本形式存储，则必须无损地将字节转换为文本。适当的编码是 base64 之类的东西。如果将其应用于原始二进制数据，则字符集编码意义上的编码不是无损的。
只需将字节作为字节（而不是字符）存储在文件中，以及指示消息长度和发送主题的固定长度前缀就足以通过系统重播 RV 消息。
关于消息中任何基于文本的字段，如果编码很重要（我强烈建议在设计应用程序时通常避免这个问题），那么您在重播时会遇到与原始接收时间相同的问题，即转换从源编码到所需的编码（希望使用完全相同的代码），所以这对于重放应该不是问题。
正如这个（诚然相当陈旧的）邮件列表消息所表明的那样，对该网络协议的内部结构知之甚少。这可能会给你所追求的事情带来很大的挑战。
也就是说，如果消息只是二进制数据块（从网络捕获），它们甚至不应该有字符集。Charsets 用于文本数据，它很重要，因为单个字符可以以多种不同的方式编码。二进制数据不是由字符组成的，因此在这种意义上不可能存在编码。
这可能与 Java 字符串编码有关，而不是 TIBRV。虽然文档中有这个：
字符串和字符编码 -------------------------------------------------- ------------------------------ Rendezvous 软件在几个角色中使用字符串： * 消息字段内的字符串数据 * 字段名称 * 主题名称（以及其他相关的字符串不是 严格在消息内） * 经认证的交货通讯员姓名 * 组名（容错） 所有这些字符串（C 和有线格式）都使用字符 适合发件人的 ISO 区域设置的编码。例如， 美国是语言环境 en_US，并使用 Latin-1 字符 编码（也称为 ISO 8859-1）；日本是语言环境 ja_JP，并使用 Shift-JIS 字符编码。 当两个程序在同一语言环境中交换消息时，字符串 总是正确的。但是，当消息发送方和接收方使用 不同的字符编码，接收程序必须转换 根据需要在编码之间。集合点软件不转换 自动地。 EBCDIC 有关 EBCDIC 环境中的字符串编码的信息， 见 tibrv_SetCodePages() 。
因此，您可能想查看机器的语言环境。
我是否需要知道 TIBRV 消息字节编码的字符集以进行转换？
是的。字符集是一种将文本转换为字节流的方法，反之亦然。您的网络数据是一个字节流，因此当您将其部分解释为文本时，您是（隐式或显式）使用字符集 - 问题是它是否正确。
将字节从一个字符集转换为另一个基本上意味着使用一个字符集将它们转换为文本，然后使用另一个字符集转换回字节。请注意，这可能会导致数据长度发生变化，因为许多字符集对某些字符使用超过 1 个字节。在网络消息的上下文中，当它使长度字段无效或导致文本字段溢出时，这可能会出现问题。最好不要进行任何转换，而是教阅读应用程序学习如何处理不同的字符集。
如果是这样，我怎样才能找到这个？
查看协议规范。
从 inputStream 中读取字节 [] 中的所有内容，将字节 [] 写入到 FileOutputStream。
不应该涉及读者或作家，他们会进行字符转换，这是错误的。
在您了解 java.io 之前，请远离 java.nio。