-4

我有一个程序必须解码一个 base 64 字符串，然后再次将其解码为 UTF-8。该程序从 .doc 中提取文本，然后从 Dropbox 本地下载（使用 Temboo）。文档前后还是有奇怪的字符。这是页面的一部分在 Microsoft Word 2011 for Mac 中的样子：

人物形象

我试图将文本放入在线文本解码器中，但似乎无法找到上面的文本块是什么编码。这就是我目前解码文本的方式：

encoded = encoded.replaceAll("\r\n", "");
encoded = encoded.replaceAll("\n", "");
encoded = encoded.replaceAll("\r", "");

// decoding the response
decoded = StringUtils.newStringUtf8(Base64.decodeBase64(encoded));

在 TextEdit.app 中它看起来像这样：

文本编辑

有谁知道这是什么编码以及如何解码这些字符？

4

2 回答 2

3

您的示例中没有 base64。我建议您使用 Office 格式库（如 POI）从 Office 文档中提取文本/数据。

于 2014-07-31T23:10:06.650 回答
2

这是 Word .docx 文件的第一部分，以十六进制表示：

50 4b 03 04 14 00 06 00 08 00 00 00 21 00 e1 0f
8e bf 8d 01 00 00 29 06 00 00 13 00 08 02 5b 43
6f 6e 74 65 6e 74 5f 54 79 70 65 73 5d 2e 78 6d
6c 20 a2 04 02 28 a0 00 02 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

请注意，上面的每个 2 位值都是一个字符。前两个值——50 和 4b——是 ASCII 字符 P 和 K。（谷歌“ASCII 表”，你会明白我的意思。）

这是您可以看到的所有字符数据：

PK[Content_Types].xml

如果您查看十六进制值，任何大于 0x7F 的值都不是有效的 ASCII/UTF8 字符。当此类数据通过某些协议通过 Internet 传输时，数据很容易出现乱码（因为协议需要 ASCII 字符），除非它以某种方式编码为 ASCII。这就是“Base-64”的目的。

Base-64 将上述数据编码为：

UEsDBBQABgAIAAAAIQDhD46/jQEAACkGAAATAAgCW0NvbnRlbn
RfVHlwZXNdLnhtbCCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

这可以安全地传输，因为所有值都是常规 ASCII 字符（它们的数值低于 0x7f）。

当您解码 Base-64 时，您可能会得到与开始时相同的数据，因此如果您将该数据写入文件，您将“重构”原始 .docx 文件。

另一方面，如果您将解码数据（或从未编码的数据）输入字节到字符串转换器（例如newStringUtf8），则大于 0x7f 的字符将被解释为 UTF8 序列并转换为相应的 UTF16 或 UTF32 字符。但是“二进制”数据（例如 .doc 或 .docx 文件中的标题数据）只是数字——它不是字符数据。将这些二进制值转换为 UTF 字符不会产生任何意义。此外，某些值无法在转换后保留下来，也不会正确转换回来。

处理此文件的方法是将 .doc 文件从 Base-64 格式“重构”为“二进制”，将该数据写入“二进制”文件。然后使用了解如何读取其标题并明智地将其拆开的软件。这可能是 Word 本身，也可能是一些专门为访问 Word 文件内部而编写的 API。

于 2014-08-01T00:52:14.890 回答