我从我开发的应用程序创建了一个文本文件。
当我将文本文件发送到系统验证，他们（第三方系统）说文件无效并且文件开头包含三个字符不允许的文件特殊字符不正确。
他们还说我需要使用ISO 8859-1或者PC850。
嗯，我正在使用记事本++，我根本看不到！对于这类问题，最好的文本文件阅读器是什么？
我也有 Mac，只是记得打开文本伴侣...哇！现在我知道他们在说什么了！
我怎样才能在 Windows 中实现同样的效果？
答案1
好吧，我正在使用 NotePad++，但我根本看不到！对于此类问题，最好的文本文件阅读器是什么？
问题是，一个“好的”文本编辑器应该能够透明地加载所有文本编码——即使是像 UTF-8-plus-BOM 这样愚蠢的破烂编码——这会阻止你看到问题。当然，一个好的文本编辑器应该保存没有虚假 BOM 的 UTF-8，或者至少让你可以选择这样做，但如果你没有看到那里的虚假 BOM，你就不会知道重新保存它。
在 TextMate 中，文件开头看到三个高字节的原因实际上是因为TextMate 弄错了并猜测编码是 Latin-1 而不是 UTF-8。这可能重现了您发送消息到的不了解 Unicode 的服务的行为，但这本身并不是一个理想的功能。这也是为什么 sæ和øs 还没有出现的原因。
如果你想明确地看到文件中的每个字节，你需要的不是文本编辑器，而是十六进制编辑器。有很多可供选择，例如：xvi32在 Windows 上。
然后修复您的应用程序，使其不产生虚假的 BOM；无论如何，它们在 UTF-8 文件中没有位置，更不用说它给非 Unicode 应用程序造成的问题了。[我不知道应用程序是用什么编写的，但产生不需要的 BOM 的一个常见原因是使用 .NET 的Encoding.UTF8编码。new UTF8Encoding(false)最好是 A。]
无论如何，您发送的服务是否需要 UTF-8 或其他编码，您都必须询问该服务的运营商。如果他们已经将æ文件中 et al 的高字节描述为固有“无效”，那么您可能面临他们根本不支持任何非 ASCII 字符的情况，在这种情况下，您必须考虑根据目标语言适当地音译字符，例如æ-> ae。
答案2
在 Windows 中查看此类内容的简单方法是使用“type”命令。
我会做这样的事情：
type filename.txt | more
答案3
弗雷德我突然想到...这是一个非常好的工具。正如 Arjan 指出的那样，您正在将文件保存为 UTF-8 编码文档。