问题描述
我有一个遗留程序，我假设它是用 BASIC 编写的（一个以 .bas 结尾的文件）。不过好像已经编译好了！ 当在十六进制编辑器中打开时，字符串和注释是可读的，而进行计算的部分则不是。 AFAIK，BASIC 是/是一种解释性语言。
问题：
解决方法
对于老式的 BASIC 程序，编译和标记化之间存在差异。编译将 BASIC 代码转换为机器代码，并且通常会以文件扩展名存储，表明代码应该直接运行而不是解释；通常，这个扩展名是“.BIN”的一些变体。至少在个人电脑上，编译通常需要第三方软件将 BASIC 语句转换为机器码。
虽然 BASIC 程序通常可以保存为直接的 ASCII，BASIC 语句完全由它们的文本表示，但大多数 BASIC 默认情况下标记保存的程序。标记化文件通常以 .BAS 文件扩展名的一些变体保存。
标记化通常是将 BASIC 语句/函数一对一转换为该语句或函数的一字节或两字节代码。这节省了系统空间；较旧的个人计算机上的磁盘空间和 RAM 都受到限制。但它也让系统更轻松地动态运行代码（解释它），并使解释速度更快。
如果没有标记化，例如 Radio Shack Color Computer 的 Extended Color BASIC 中的 RESET 和 RESTORE 之间的差异，直到比较第四个字符时才会显示出来。通过标记化，比较第一个字符时会出现差异 - 9D 与 8F。
例如，this archiveteam.org page lists the tokenization numbers for GW-BASIC。
去标记化，或从标记到语句的文本表示的转换，只是颠倒了这个过程。每次用户列出该程序时，都会执行这种反转。在现代计算机上，应该能够使用几乎任何现代脚本语言轻松编写去令牌化程序。只要您知道格式，去标记化就是逐字节浏览标记化文件并将标记转换回其等效的 BASIC 语句或函数的问题。
例如，bascat 声称对 GW-BASIC 进行去令牌化。
这是一个标记化的例子；我使用 TRS-80 彩色计算机的 Extended Color BASIC 是因为我有 the tools easily available 来标记它，但对于大多数老式 BASIC 来说，基本思想是相同的。
（有点荒谬的）BASIC 程序：
10 RESET(14,15)
20 RESTORE
标记化文件的十六进制转储：
00000000 26 0b 00 0a 9d 28 31 34 2c 31 35 29 00 26 11 00
00000010 14 8f 00 00 00
00000015
前两个字符是下一行的地址；从文件中去标记化时，如果您的特定语言使用这些地址，您可能会忽略这些地址。 （它们主要用于运行代码：例如，如果您在一行中有一个 GOTO 60，解释器可以找到第 60 行，而无需解释标记即可到达那里。）
后两个字符是行号：000A 是 10。下一个字符 9D 是 RESET 的标记化。那么，28是左括号的ASCII值，31是“1”，34是“4”（即14作为RESET的第一个参数；2C是逗号，31和35是1和 RESET 的第二个参数的 5，29 是右括号，00 是行尾。
接下来的两个字符是下一行的地址，0014是第二行的行号：14是20的十六进制。最后，8F是RESTORE的标记化，00结束该行，最后两个零结束程序。