Unicode Buddy
Unicode Buddy 是一款用于检查 Unicode 文件的工具。它可以检测孤立的代理对和无效的 utf-8 序列。它能够显示特定码点的编码/解码。它不是一个编辑器，而是一个查看器。
引言
当比特（bit）被发明出来后，很快就有了半字节（nibble）和字节（octet/byte）。现在一个字节可以是一个处理器指令、一个参数、一个数字或者一个 ASCII 码。因为人们需要查看字符和字符串，例如文本，所以 ASCII 被发明出来，它实现了字节和字符之间的一对一关系。然而，最高位被保留用于特殊用途，因此覆盖特殊语言/国家字符的语言/国家特定代码页被赋予了 128-255 范围内的数字。
所以对于 ASCII 来说，127 个字符（包括不可打印字符）足以生成、存储、打印文本。a-z、A-Z、@、<、>、{}、[]、()、/\;、: 等字符如今仍在世界各地使用。然而，其他国家声称他们的字母表和/或字符无法与 ASCII 一起使用，ASCII 只包含拉丁字母。
于是人们发明了 UNICODE。首先，我们可能会认为这只是一个从字节到字（word）的改变，即 8 位到 16 位，但事实并非如此，实际上人们为字符赋予了高达 0x10FFFF 的数字。其中一些数字被保留用于特殊用途（代理对）。然而，ASCII 标准没有改变，所以 ASCII 字符的数字仍然是从 0 到 127，但从 128 到 0x10FFFF 的每个数字（代理对除外）都被定义为表示一个特殊字符或符号。最棒的是，UNICODE 字符可以混合在同一个文件或文档中。
当然，大于 255 的字符无法存储在一个字节中，所以我们可能需要使用一个字（word）来存储这些 Unicode 字符。这就是实际存储 Unicode 的方式，尤其是在内存中，字符串通常是字节数组，所以如今大多使用字数组。你也可以称之为
char-array，如今我们使用 wchar-array。然而，这并不是说字符是“宽”（wide）的，仅仅是 Unicode 码点（codepoint）的数字可能远大于 255，所以它无法存储在单个字节中。请注意，大于 0xFFFF 的字符也无法存储在字或 wchar 数据类型中！因此，代理对（surrogates）
被发明了出来。我们稍后会讨论这一点。
现在，因为 Unicode 有 0x10FFFF 个可能的数字需要存储，人们可能会认为最好使用 dwchar-array，或者说一个 32 位的 dword，这样我们就拥有了与 ASCII 时代相同的 1:1 关系，但如今使用的是 Unicode。一个 DWORD 中的每个值将仅仅是字符的数字。但是，大多数只使用 ASCII 字符的人会为每个 ASCII 字符浪费 3 个字节，所以又有人发明了所谓的 Unicode 转换格式（Unicode Transformation Formats），例如 UTF-32、UTF-16 和 UTF-8。这三种转换格式都允许存储整个 Unicode 范围，但使用不同的编码/解码算法来存储 Unicode 字符的数字。为了找出文件实际的编码，BOM（字节顺序标记）被发明了出来。它是文件顶部的 3 字节、2 字节或 4 字节签名，作为文件的“头部”，强烈建议将这样的 BOM 放入 UNICODE 文件中。
为了揭示具有不同编码的文本文件的信息，人们通常使用十六进制编辑器来查看文件内容，因为每个字节都会以其十六进制数字（从 0x00 到 0xFF）显示。例如，很容易检测到文件开头的 UTF-8 3 字节 BOM。
背景
许多十六进制编辑器仍然显示字节和字符之间的 1:1 关系，即使文件的编码已通过检查 BOM 成功检测到。但是，如果文件的编码是 utf-8，字节和字符之间就不再是 1:1 的关系了。utf-8 为小于等于 127 的字符保留单个字节，但大于 127 的所有内容都存储为 2 字节、3 字节或 4 字节序列。这样的序列中的字节不再与 Unicode 字符有 1:1 的关系，而是必须进行解码。如果我们看 utf-16，字节和字符之间不再有 1:1 的关系，取而代之的是字（word）和字符之间有 1:1 的关系，但这只对 BMP（基本多文种平面）中的 Unicode 字符（即小于 0xFFFF 的字符）成立。BMP 之外的字符使用代理对进行编码。最后，utf-32 提供了 DWORD 和 Unicode 码点之间的 1:1 关系。对于所有这些编码，十六进制编辑器不应在左侧显示与打开文件字节 1:1 相关的字符，而应仅显示底层编码的字符。这正是 MadEdit 所做的，所以它极大地启发了我，让我创建了类似 MadEdit 但最终不是十六进制编辑器，而是我从一开始就称之为 Unicode Buddy 的工具。Unicode Buddy 不允许编辑文件的字节，
它只是一个查看器应用程序。然而，它详细展示了字符是如何编码的。
关注点
有时，开发人员和用户在显示文件的正确字符时遇到问题，通常是文件编码和可视化单元的解码不匹配。有时仅仅是因为字体不包含相应 Unicode 字符的字形，因此会显示默认字形（空矩形或问号等）。开发人员通常需要查看 BOM 来找出文件的正确编码，即使有 BOM，文件也可能仍然损坏。例如，一个 ANSI 文件被解释为 utf-8 时，第一个大于 127 的字节通常会引起问题，因为 utf-8 将其检测为起始字节或后续字节，而不是单个字符。UTF-8 和 UTF-32 中不允许使用代理对，因为在那里使用它们没有意义。Unicode Buddy 可以揭示此类信息，它可以揭示代理对、孤立的代理对，它可以检测无效的 UTF-8 序列，并且它内置了过滤功能，以便仅查看序列、仅查看代理对等。还有一个小型统计面板，有助于获取关于文件内容的信息。请注意，由于 Unicode Buddy 使用 Windows ListView 控件，该控件的显示行数有限，因此目前它仅限于处理一定大小的文件。尽管如此，Unicode Buddy 仍然可以帮助揭示编码的 Unicode 字符的信息，并有助于学习某些编码/解码是如何工作的。为了查看需要特殊字体的字符，Unicode Buddy 可以进行配置，以便为特定的 Unicode 块定义特殊字体。
历史
第一个版本具有给定的功能。未来可能还会有更多更新。