让我一步步帮你理清这些问题，解决你跨VB6和VB.NET读写加密二进制文件的编码困扰：

VB6 的字符串内部存储是Unicode（UTF-16），但涉及文件读写或字节交互时，默认会使用系统ANSI编码（也就是Windows代码页，比如中文系统是GB2312/CP936，英文系统是CP1252）。

举个例子：当你用Open "file.txt" For Output As #1写入字符串时，VB6会自动把内部的Unicode字符串转换成系统ANSI编码的字节写入文件；反过来读取时，又会把ANSI字节转成Unicode字符串。

而你提到的ISO-8859-1（Latin-1）是单字节编码，它和Windows的CP1252非常接近，但CP1252包含了一些ISO-8859-1没有的特殊字符（比如智能引号、欧元符号）。如果你的二进制文件是严格按ISO-8859-1存储的，直接用VB6默认的ANSI编码读写就会出问题——因为系统代码页可能和ISO-8859-1不匹配。

这两个函数都是生成字符，但编码逻辑完全不同：

• Chr(number)：基于当前系统的ANSI编码工作。你传入0-255的数值，它会返回对应系统ANSI代码页的字符。如果数值超过255会直接报错。比如在中文系统中，Chr(160)返回的是全角空格，但在英文系统中可能是不间断空格（NBSP）——完全依赖系统环境。
• ChrW(number)：直接基于Unicode（UTF-16）工作。你传入0-65535的数值，它会直接返回对应Unicode码点的字符，完全不依赖系统编码。比如ChrW(160)不管在什么系统，返回的都是Unicode中的不间断空格（U+00A0），这正好和ISO-8859-1中字节0xA0对应的字符一致。

另外要注意：VB6中使用ChrW生成的字符串，内部还是UTF-16格式（每个字符占2字节），但如果你的目标是生成对应ISO-8859-1的单字节，ChrW可以帮你绕过系统ANSI的干扰，直接拿到对应码点的字符。

原因很简单：ISO-8859-1的每个字节值（0-255），正好对应Unicode的前256个码点（U+0000到U+00FF）。

当你在VB6中需要生成严格符合ISO-8859-1的字节时，如果用Chr(n)，会被系统ANSI编码转换——比如在中文系统中，Chr(128)会被转成GB2312的某个字符，而不是ISO-8859-1中字节0x88对应的字符。但用ChrW(n)的话，你可以直接生成对应Unicode码点的字符，之后把这个字符串转成字节数组时，只要取每个字符的低字节（因为U+0000到U+00FF的UTF-16编码是高字节为0，低字节就是数值本身），就能得到严格的ISO-8859-1字节。

举个实用的例子：在VB6中把字符串转成ISO-8859-1字节数组，可以这么写：

Function StrToISO88591Bytes(ByVal str As String) As Byte()
    Dim bytes() As Byte
    bytes = StrConv(str, vbFromUnicode, 28591) ' 28591是ISO-8859-1的代码页编号
    StrToISO88591Bytes = bytes
End Function

或者如果是单个字符转字节，用ChrW(n)然后取字节数组的对应位置，也能得到正确的ISO-8859-1字节。

回到你的跨平台问题：之前用ISO-8859-1编码仍有错误，大概率是VB6端用了Chr()而不是ChrW()（或指定正确代码页的StrConv），导致系统ANSI编码修改了部分字节，而VB.NET端用ISO-8859-1解码时就出现了不匹配。

内容的提问来源于stack exchange，提问作者Dure Sameen