【问题标题】:Strange Notepad++ HEX-editor plugin奇怪的 Notepad++ HEX 编辑器插件
【发布时间】:2016-06-23 05:16:17
【问题描述】:

目标是将字节数组写入文件。 我有字节数组 fit[] 和一些字节,然后:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;

namespace _32_to_16
{
    class Program
    {
        static void Main(string[] args)
        {
            byte[] fits = File.ReadAllBytes("1.myf");
            byte[] img = new byte[fits.Length / 2];
            for (int i = 0; i < fits.Length; i += 4) //Drops 2 high bytes
            {
                img[i/2] = fits[i + 2];
                img[i/2 + 1] = fits[i + 3];
            }
            File.WriteAllBytes("new.myf", img);
        }
    }
}

在写入文件之前 img[] 具有相同的值:

  • img[0]=0x31
  • img[1]=0x27
  • img[2]=0x31
  • img[3]=0xe2
  • 等等……

写入文件后,在十六进制编辑器中我看到了

  • 00000000: 31 27 31 3f 和其他错误值。

有时,使用其他 fit[] 值,img[] 数组会正确写入文件。我做错了什么?
用于测试 1.myf 的文件(产生错误结果)https://www.dropbox.com/s/6xyf761oqm8j7y1/1.myf?dl=0 用于测试 2.myf 的文件(正确写入文件)https://www.dropbox.com/s/zrglpx7kmpydurz/2.myf?dl=0

我简化了代码:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;

namespace _32_to_16
{
    class Program
    {
        static void Main(string[] args)
        {
            byte[] img_correct = new byte[8] { 0xbd, 0x19, 0xbd, 0x72, 0xbd, 0x93, 0xbd, 0xf7 };
            File.WriteAllBytes("img_correct.myf", img_correct);

            byte[] img_strange = new byte[8] { 0x33, 0x08, 0x33, 0xac, 0x33, 0xe3, 0x33, 0x94 };
            File.WriteAllBytes("img_strange.myf", img_strange);
        }
    }
}

在十六进制编辑器 img_correct.myf 中看起来像这样: bd 19 bd 72 bd 93 bd f7

在十六进制编辑器 img_strange.myf 中看起来像这样: 33 08 33 3f 3f 3f

【问题讨论】:

  • 你没有吞下异常,是吗?也许文件被锁定并且实际上没有被(覆盖)写入?
  • 没有任何例外。没有锁定文件(创建新文件)。我尝试使用 BinaryWriter — 结果相同。 dropbox.com/s/k4zctcy9v2744ke/bw.JPG?dl=0dropbox.com/s/xex5m5gzm2aswnu/notepad%2B%2B.JPG?dl=0
  • 嗯,这很奇怪。您可以尝试创建一个minimal reproducible example 以便我们试用吗?
  • 我删除了所有额外的代码,只留下了重要的部分。编辑了启动消息。我不知道该去哪里了。
  • 调用WriteAllBytes后,尝试将new.myf文件读入另一个字节数组,然后逐字节比较img与新数组。它们应该是一样的。

标签: c# .net unicode hex-editors


【解决方案1】:

您正在使用 Notepad++ 的 HEX-Editor 插件,它似乎有一个 problem reading binary files

尝试使用另一个十六进制编辑器,它应该会显示正确的值。

这是HxD 和 HEX-Editor 显示相同文件的屏幕截图

【讨论】:

  • 是的,没错,我正在使用 Notepad++ 插件。在 HxD 中,一切看起来都是正确的!但是这个问题不仅出现在 N++ 中,而且出现在一些不同的程序中。我将 32 位天文图像转换为 16 位,第三方软件在转换后的可视化图像中存在相同的问题。我将尝试不同的方式将 32 位转换为 16 位。这种方式看起来很快,但并不成功。感谢您的回答!
  • 天哪!!!这阻碍了我们的项目,因为我们认为我们的数据记录被破坏了。我绝望地搜索了“writeallbytes 3f”并找到了这个。非常感谢!
【解决方案2】:

对于全角冒号“:” 正确的 Unicode 格式是:U+EF1A

但在 NotePad ++ 中,十六进制编辑器中的“:”显示“EFBC9A”而不是“EF1A”。

因为这是 UTF8 编码,而且不是 Unicode 格式。

如果我将“EFBC9A”放在另一个编辑器中,它会显示韩文字符“벚”。

当您直接在 Hex Editor 中输入时,请确保使用 UTF8 编码,但当您不在 Hex Editor 中时,请确保使用 Unicode 格式而不是 UTF8 编码。

所以人们对 UTF8 编码和 Unicode 格式感到困惑。

顺便说一下:U+EF1A --> ":"可以放在Windows系统的文件夹名里。

【讨论】:

    【解决方案3】:

    您的源文件大小可以被 4 整除吗?如果不是,则在操作结束时将忽略任何剩余字节。 i += 4 将跳过它们。如果源(适合)文件不能完全被 4 整除,您需要在最后处理这些问题,在您的 for 循环之后。

    【讨论】:

    • 答案保持不变。您可能会通过跳过它们来丢弃额外的字节。就目前而言,代码旨在跳转这些字节,因为它从每组四个字节中获取前两个字节并将它们复制到较小的字节数组中。我建议从 img 的角度而不是从 fit 的角度来做一些不同的编号逻辑。你让你的索引变得不必要地复杂。将 for 循环的每次传递和所有字节输出到控制台,看看发生了什么。
    • 我简化了代码并更正了启动消息。
    • 我明白了。根本没有真正的问题,只是十六进制编辑器。您可以尝试再次读取新写入的文件并在 Visual Studio 或控制台输出中检查字节值。您甚至不需要十六进制编辑器。谢谢:)
    猜你喜欢
    • 2020-06-23
    • 1970-01-01
    • 1970-01-01
    • 2013-01-15
    • 1970-01-01
    • 2015-08-04
    • 1970-01-01
    • 2019-08-17
    • 1970-01-01
    相关资源
    最近更新 更多