主页 / unix / 问题 / 720100
Accepted
Vlastimil Burián
Asked: 2022-10-07 20:54:08 +0800 CST

我的文字是否已无法修复？

  • 772

我损坏的捷克文本：

NOTE ON CZECH BIRTH NUMBER VALIDATION IN CZECH LANGUAGE;
in Czechia birth number = personal identification number
========================================================
Do roku 1985 bylo pé?idá?leno cca 1000 rodnű§ch á?űŮsel, kterűŔ nejsou dá?litelnűŔ 11.
NenűŮ vylouá?eno, éƒe se v miniműŔlnűŮm poá?tu vyskytly i po tomto roce.
KorektnűŮ algoritmus je nűŔsledujűŮcűŮ:
spoá?ti zbytek po dá?lenűŮ prvnűŮch devűŮti á?űŮslic a á?űŮsla 11; je-li zbytek 10, musűŮ bű§t poslednűŮ á?űŮslice 0; jinak poslednűŮ á?űŮslice musűŮ bű§t rovna zbytku; Tedy 780123/3540 je korektnűŮ rodnű? á?űŮslo, aá?koliv nenűŮ dá?litelnű? jedenűŔcti.

最后两个单词拼写正确：dá?litelnű? jedenűŔcti = dělitelné jedenácti .

我找到了一个 FTFY 工具https://ftfy.readthedocs.io/en/latest/但即使使用它我也无法修复文本。

它应该是带有 BOM 的 UTF-8，我尝试使用 VI 删除 BOM；使用 Sublime Text 将我的文本重新加载到每种可能的编码中。

所以我的想法是，这个文本可能丢失了一些信息，现在无法修复？

这将是一个遗憾，因为我有更多的文字。

笔记：

  • 不，我没有任何以前未损坏的文本，也不知道它是如何发生的。

  • set | grep -E '^LC_|^LANG'：

LANG=en_US.UTF-8
LANGUAGE=en_US
LC_ADDRESS=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_TIME=en_US.UTF-8

应该有什么地方cs_CZ吗？只是吐槽...

  • file MainWindow.xaml.cs：
MainWindow.xaml.cs: C++ source, Unicode text, UTF-8 text

  • od -t ax1 MainWindow.xaml.cs: 输出量很大，一丧葬回来就缩水了。

  • LC_ALL=cs_CZ.UTF-8 head -50 '/mnt/windows/Users/vlastimil/Downloads/_DISK_D/csharp/Rodné číslo a IČ/Rodné číslo a IČ/MainWindow.xaml.cs' | grep jeden

Tedy 780123/3540 je korektnűŮ rodnű? á?űŮslo, aá?koliv nenűŮ dá?litelnű? jedenűŔcti.

LC_ALL=cs_CZ.UTF-8 head -50 '/mnt/windows/Users/vlastimil/Downloads/_DISK_D/csharp/Rodné číslo a IČ/Rodné číslo a IČ/MainWindow.xaml.cs' | grep jeden | od -t ax1

0000000   T   e   d   y  sp   7   8   0   1   2   3   /   3   5   4   0
         54  65  64  79  20  37  38  30  31  32  33  2f  33  35  34  30
0000020  sp   j   e  sp   k   o   r   e   k   t   n   E   1   E   .  sp
         20  6a  65  20  6b  6f  72  65  6b  74  6e  c5  b1  c5  ae  20
0000040   r   o   d   n   E   1   ?  sp   C   !   ?   E   1   E   .   s
         72  6f  64  6e  c5  b1  3f  20  c3  a1  3f  c5  b1  c5  ae  73
0000060   l   o   ,  sp   a   C   !   ?   k   o   l   i   v  sp   n   e
         6c  6f  2c  20  61  c3  a1  3f  6b  6f  6c  69  76  20  6e  65
0000100   n   E   1   E   .  sp   d   C   !   ?   l   i   t   e   l   n
         6e  c5  b1  c5  ae  20  64  c3  a1  3f  6c  69  74  65  6c  6e
0000120   E   1   ?  sp   j   e   d   e   n   E   1   E dc4   c   t   i
         c5  b1  3f  20  6a  65  64  65  6e  c5  b1  c5  94  63  74  69
0000140   .  nl
         2e  0a
0000142

不知道以上是什么意思，抱歉耽搁了。

text-processing unicode

1 个回答

  1. Best Answer

    部分答案，解释过程：

    从 hexdump 中，可以在“korektnűŮ rodnű?”中看到这一点。部分，字节“c5 b1 c5 ae”是“korektnűŮ”的结尾，字节“c5 b1 3f”是“rodnű？”的结尾。并且?真的是一个?.

    如果你？” 在“rodnű”中 真的应该是“é”，如“dá?litelnű？” -> “dělitelné”，那么我们现在知道“é”以某种方式结束为“c5 b1 3f”。但我不懂捷克语，所以我不知道这是否正确。

    那么现在我们可以开始猜测发生了什么。“c5 b1”看起来像一个双字节字符编码，所以我猜这个文本由于某种原因被转换了两次 - 第一步将“é”编码为两个字节（以任何编码），然后第二步编码第一个字节为“c5 b1”，而第二个字节是不可打印的，它最终以?.

    这是不幸的，因为如果这是真的，那么我们就会丢失有关不可打印字节的信息。尽管如此，如果没有太多以“c5 b1 3f”结尾的字母，则可能有足够的信息来重建文本。

    但在此之前的步骤是要知道收集足够的数据——我们需要足够多的“字母 é 被转换为 c5 b1 3f”的例子来处理不同的重音字母，以猜测文本是通过哪两种编码被破坏的。

    或者，如果我们无法猜测，也许您已经可以检测到足够多的对，我们可以用正确的字母替换错位的字节序列，而无需重新构建错位过程。

    但是我们需要您作为捷克语使用者来做到这一点，因为您拥有完整的文本，并且您可以猜出正确的字母。

    • 2

相关问题