为什么在记事本中复制粘贴字符并转换生成的图片损坏？

Question

这个问题本质上是在编写更大的程序时出现问题。我已将问题的原因缩小到这个小得多的问题；

简单地说，我们遵循以下程序；

1. 制作图片，例如位图，使用 Paint
2. 通过重命名将此图片转换为 .txt 文件
3. 复制文本文件中的所有字符，使用记事本访问
4. 将其粘贴到新的 .txt 文件中
5. 将此转换为原始图片文件类型，例如位图

我们为此获取的图片将无法打开，因为它显然已损坏。为什么会这样？

在进行此操作时，我假设所有数据都包含在编码中的图片中，这是不正确的吗？是否创建了一些“隐形签名”以防止在没有适当软件的情况下创建新的图片文件？如果是这样，我可以使用 Python 2.7.5 中的 pygame 支持的其他文件类型吗？

计算机存储文件的方式是否类似于游戏安装存储与安装相关的文件的方式，因此它们不允许应用程序在未合法安装的情况下执行？如果是这样，我可以使用不这样做的文件类型吗？

总的来说，主要是想弄清楚为什么这不起作用。感谢您的任何回复，非常感谢

Answer 1

记事本可能正在将换行符 (0x0a) 字符转换为 DOS 换行符 (0x0d0a)。几乎所有 Windows 文本编辑器都会自动执行此操作。

毫不奇怪，这会破坏图像文件。更一般地说，这就是为什么您永远不应该尝试使用文本编辑器编辑二进制文件的原因。

你到底为什么要这样做呢？为什么不直接复制文件？

Answer 2

这归结为图像与文本编码的本质。以下是发生的事情，以及如何解决它：

1) 正如您所料，将文件重命名为 .txt 对基础数据没有任何影响，基础数据保持不变。

2) 在记事本中打开它。记事本会看到一堆字节 (0-256) 并尝试将它们解释为 ASCII 或其他编码。

• 介于 32 和 128 之间的字节以及低于 32 的几个字节将被解释为 ASCII 字母（a-z、A-Z、0-9 等）。
• 大多数低于 32 的字节和许多高于 128 的字节将被解释为非打印字符，并被忽略或打印为它们的 UTF 描述性符号。这会导致它们丢失或更改。
• 超过 128 的某些字节将被解释为有效的多字节编码字符，并按原样显示（例如 UTF 或其他自动错误检测的编码。）

3) 复制字符将这些损坏的字符复制到剪贴板，然后返回到 python。

4) Python 可能会将新字符串存储为 UTF 字符串或字节字符串，无论哪种方式，如果此转换与记事本的错误检测编码不匹配，则此转换可能会创建一组额外的情况，如 #2 中的情况。

5) 转换回二进制字节会得到不同的结果，因为基础数据已被 2-4 损坏。

现在，如何解决它：

使用有效的 ASCII（或 UTF-7）编码算法。我建议使用类似于 MIME 中使用的 base-64。这是一个使用 Python 的 base64 模块的示例：

import base64, binascii
# Here, we write the content of source.png to a text file store.txt
with open('source.png', 'rb') as src_file, open('store.txt', 'w') as store_file:
    store_file.write(binascii.b2a_base64(src_file.read()))
# Now, read the store.txt file and convert back to binary.
with open('store.txt', 'r') as store_file:
    data = binascii.a2b_base64(store_file.read())
# Finally, if desired, write out the recreated png file to make sure it worked.
with open('destination.png', 'wb') as dest_file:
    dest_file.write(data)

PS：对于那些想知道的人来说，这就是电子邮件中附件的发送方式，因此，如果您在电子邮件中收到了图像（我相信您已经收到），那么您的计算机很可能会收到使用编码的base-64 编码如上。 （确保 MIME 兼容性需要一些细微的差别。）