2份autorun.inf的精确副本，其中一份有效，一份不起作用[重复]

我有两个Autorun.inf文件，其中的代码完全相同。但只有1个有效，其他一个无效。

从DVD复制工作的文件，然后我对其进行了编辑。通过重命名文本文件（我正确地重命名了它），在我的桌面上创建了一个无效的文件。

这个作品

这个不起作用

如果需要文件：

有谁知道我在桌面上创建的那个为什么不起作用？以及如何使它正常工作？那两个文件有什么区别？

谢谢。

windows usb windows-10 filesystems autorun

— 用户名
source

我用十六进制编辑器打开了两者，当查看十六进制值时它们有很大的不同。它很容易制作一个新的。制作一个自动运行的文本文件并输入数据，保存文件并将扩展名从txt更改为inf。

— 摩押

@Moab这就是我所做的，但是我将其保存为“带有UTF-8 BOM的UTF-8”-（dxiv），这就是问题所在。感谢您的答复：）

— user4335407 '16

我不同意他们的确切副本。如果确实如此，这简直是不可能的。

— Zaibis

第一个文件说“ usb”。第二个文件说“ usbk”。看最后几行。好像是一个简单的错字。

— ApproachingDarknessFish

Answers:

第二.inf，这是不行的，似乎已被保存为UTF-8 有一个UTF-8 BOM。

UTF-8 BOM表示文件以二进制序列EF BB BF（以十六进制表示）开头。但是Windows希望autorun.inf文件是纯文本格式，因此它不会这样识别。

我的建议是在保存.inf文件或类似文件时在文本编辑器中选择纯文本选项。

— dxiv
source

这就是为什么您不使用记事本编辑程序文件的原因。

— 托尔比约恩Ravn的安徒生

@ThorbjørnRavnAndersen我不认为记事本会增加BOM。

— Sharky

它不会，但是也不会告诉您BOM，它会以与原始文件相同的编码将其保存回去。

— 尼尔森

UTF8 是纯文本。我假设您正在谈论ASCII。

— fNek '16

问题甚至不是可变长度编码。这是因为在编辑器中看不到“ BOM”（它根本不是BOM表，因为BOM表仅用于区分Little-endian编码与16位或更大Unicode的big-endian编码）。而“ BOM”的隐形性使它不再是纯文本。

— 蒙蒂·哈德

正如dxiv所说，这是由UTF-8 BOM引起的。

您正在使用的文件编辑器Notepad ++可以告诉您文件的编码。

UTF-8 BOM向文件中添加标头字节，破坏了它们与标准ASCII文件的兼容性，而没有BOM（或仅普通UTF-8）文件的UTF-8与标准ASCII文件完全反向兼容，前提是您不使用任何UTF。 -8个字符。

Notepad ++也有一个HEX编辑器插件，您将可以看到这些额外的字节：

— 纳尔逊
source