☰

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

tag-icon • tag-icon text-processing unicode character-encoding
我的文字是否已损坏且无法修复？

我损坏的捷克语文本：

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

不过，我不知道上述内容是什么意思，对于延迟，我们深表歉意。

答案1

部分答案，解释一下过程：

从十六进制转储中，我们可以在“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”示例，用于不同的重音字母，以猜测文本通过哪两种编码被破坏。

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

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

相关内容