在这里您可以对计算机内存和文件中的字符编码问题进行非常有用的介绍。此外，本文还讨论了 RP Photonics 的软件如何实现现代化，从而可以在几乎所有情况下避免编码问题。

大概每一个计算机用户遇到有关字符编码问题-例如，特殊字符（例如：μ 2，°）从文本文件中读取数据时被损坏。如果您正确地理解了这个问题，那么这些问题至少会减少一些麻烦，但是很少有人这样做。事情可能会很复杂。

在本文中，我们为您提供两件事：希望有用的，对技术背景有所简化的介绍，以及有关在我们的软件中实现的字符编码处理的深刻改进的说明。

许多用户可能只是不使用任何特殊字符，从而避免了任何编码问题。但是，您可能会得到一些特殊的输出，尤其是希腊语 μ 用作格式化数字输出中的微符号。在某些国家/地区，您甚至可能想要使用更多的东西，特别是在创建自定义表格时，例如包含中文或日语的说明或一些箱形图符号。

字符编码的一般说明

计算机内存和文件不存储数字或字符本身，而仅存储位序列。根据某些编码，这些字符通常被解释为数字或字符。无论是数字还是字符，目前都存在非常不同种类的编码。

编码与字体

人们不应混淆字符编码和字体的问题; 如今，这些方面通常是单独处理的。编码确定哪种字符（例如，某个字母）与某个位序列相关联，而字体则确定该字符在屏幕上显示或打印时的外观。通过使用不同的字体，例如，一个字母“ A”可以具有不同的图形外观。

ASCI编码

对于字符，早期使用 ASCII 编码，仅提供128个可用的不同字符，以单个字节（一组8位）表示，其中仅使用低7位。当然，这仅对于最简单的目的就足够了。

ANSI代码页

由于需要更多不同的字符，因此人们很快开始使用扩展的字符范围，其中使用了可以用8位编码的完整256个字符。但是，已经使用了（但仍在使用）这种 ANSI 字符集的许多不同版本。其中一些主要包含重音字母（例如法语）之类的内容，而其他一些包含其他语言的字母或更多特定类型的符号（例如，箱形图符号）。基本上，问题是这个世界上的整个人需要远远超过256个不同的字符。在 Windows 中，不同的 ANSI 字符集以所谓的 代码页为特征（最初由 IBM 引入）。例如，在欧洲部分地区，Windows系统通常使用代码页1252“西欧”。请注意，对于像日本这样需要256个以上字符的国家，8位不足以表示一个字符。

尽管使用不同的 ANSI 代码页可以使用各种各样的字符，但是这种方法存在严重的局限性。特别地，例如以这种编码显示文本文件的内容时，这仅在相应的代码页是已知的并且被正确考虑时才正确地起作用。不幸的是，纯文本文件通常在使用的代码页上不包含任何信息，因此通常需要其他信息（例如，由用户手动发送）才能正确显示此类文件；如果有此类信息，则可能正确也可能不正确。另外，除非文件只包含在两个代码页中都出现的字符，否则当然不能将文件从一个代码页转换为另一代码页而不会造成信息丢失。

Unicode作为通用解决方案

为了解决这些问题，已经开发了Unicode系统（即，与各种编码系统结合的Unicode字符定义）。在这里，可以对大量不同的字符（每个字符用一个所谓的代码点表示）进行编码-实际上是通常需要的任何字符。

当然，一个字节（8位）不足以编码任意 Unicode 字符。现在，有两种不同的编码方案可用于处理计算机内存或文件中的 Unicode 字符。一种通用的方案是UTF-16，其中最常见的字符是用一个字节（8位）编码的，其他大多数字符则需要两个字节，有些甚至需要三个或四个字节。

例如，只有在已知使用的编码（例如 ANSI 或 Unicode，以及哪种特定方案）的情况下，才能正确处理计算机文件的内容。不幸的是，该信息经常由于错误的编码假设而丢失或损坏。通过在文件的开头写入一个由几个字节组成的所谓的字节序标记（BOM），已解决了许多 Unicode 文件的问题。在文本文件中找到这样的 BOM 的程序可以使用它来确定（a）它是 Unicode 文件，以及（b）确切使用了哪种UTF编码。但是，例如对于使用Unicode而不使用 Unicode 的网页，这很常见。BOM；使用的编码在其他地方（在页面内容之前发送的HTTP标头中）指示。这样，软件通常很难或不可能确定某个文件使用了哪种编码。向用户询问可能是不切实际的，或者是行不通的，因为用户也不知道。

当然，对于一个字符不使用固定数目的字节的编码意味着一些技术上的困难。例如，为了找到这样一个字节序列中的第23个字符，必须从头开始对其进行扫描，以便正确考虑每个先前字符的字节数。由于这些困难，修改旧软件以使其能够处理 Unicode 数据通常并不容易。原则上可以通过使用 UTF-32 编码解决此问题，其中每个字符都由32位（4字节）表示，但是很少使用，因为它不提供用于存储文本的内存有效方式。

我们软件中的编码处理

在 RP Photonics 的软件的早期版本（2017年之前）中，整个内部都使用UTF-16形式的Unicode，但是文本文件（例如脚本）是根据 Windows 系统的标准代码页以ANSI编码编写的。这种方法很普遍，但是却给日本用户带来了麻烦。另外，还存在（罕见）问题，例如希腊语的 μ（微）字符丢失或在某些代码页中的编码方式不同。因此，现在工作已进行了深刻的现代化，得出以下规则：

内部使用 UTF-16，几乎可以处理所有字符。只是它并不关心某些位置的代理对。可能会导致问题，但是我们软件的几乎所有用户都不会处理这样的字符，即使那样，它也经常可以工作。

现在，当软件编写纯文本文件时（例如，当用户保存脚本或交互式表单的设置时），它内部使用 UTF-16始终将 BOM 表使用 UTF-8 编码（请参见上文）。这意味着（a）现在几乎所有字符都可以存储在文件中，并且（b）毫无疑问可以自动确定对该文件使用了哪种编码。

该软件提供了将信息保存在文本文件中的各种功能; 例如，请参见描述函数open_file（）的页面。默认情况下，它现在也对此类文件使用 UTF-8，但是上述功能提供了一项新功能，即可以更改用于写入或在读取文本文件时使用的文件编码。因此，现在可以轻松编写或读取具有任何编码的文本文件不管是带或不带BOM 的 Unicode。

现在，所有演示脚本和相关文件都使用 UTF-8（带有BOM）进行编码。

当读取不带 BOM 的纯文本文件，并且未明确告知软件编码是什么时，它将采用带有特定代码页的 ANSI 编码。默认情况下，该代码页为1252（西欧），这会导致正确的结果，例如，加载旧版本的演示脚本时。但是，如果在 Windows 系统中具有不同代码页的用户使用较旧版本的软件保存了文件，则此假设可能会导致问题。因此，可以在常规设置中更改假定的代码页（请参阅“选项” |“选项”）；在打开这样的文件之前，需要在此处设置正确的代码页。此后，可以保存文件以便以 UTF-8 编码获取文件。因此，即使在这种罕见的情况下，您也不需要额外的软件使用程序来转换旧文件。

剩下的问题是如何在软件中输入特殊字符。在主菜单中，可以使用“编辑” |“输入”来获得一个新的字符映射表。角色图。例如，您可以在此处选择某个字符块并单击任何显示的字符，以收集它们并将其粘贴到脚本中。无论如何，您可以将任何文本粘贴到脚本编辑器中，因此您可以使用一些外部使用程序来输入特殊字符。

也可以一次打开大量文本文件，即使用单个 File | File。公开行动。这对于转换一堆文件很有用：只需打开所有文件，然后使用 Ctrl-S 保存每个文件即可。