私のテキストが回復できないほど破損していますか?

私のテキストが回復できないほど破損していますか?

私の破損したチェコ語のテキスト:

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.

最後の2つの単語のスペルは正しいです。すべて?少し? jedenűŔcti=delitelné 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

部分的な答え、プロセスの説明:

16進ダンプで「korektnűŮrodnű?」でこれを見ることができます。部分では、バイト「c5 b1 c5 ae」は「korektnűŮ」の終わり、バイト「c5 b1 3f」は「rodnű?」の終わりです。これは?実際に一つです?

もしあなたなら? 「rodnű」で「é」になるべきですか? 「dá?litelnű?」 -> 「delitel」のように、「é」が「c5 b1 3f」で終わっていることがわかります。チェコ語を理解しているので、これが正しいかどうかわかりません。

今、私たちは何が起こったのかを推測することができます。 「c5 b1」は、2バイト文字エンコーディングのように見えます。推測する何らかの理由でテキストが2回変換されることです。最初のステップでは「é」を2バイト(すべてのエンコードで)にエンコードし、2番目のステップでは最初のバイトを「c5 b1」にエンコードし、2番目の2バイトは印刷できません。そしてそれは最終的に?

これは不幸なことです。なぜなら、これが真であれば、印刷できないバイトに関する情報を失うことになるからです。ただし、「c5 b1 3f」で終わる文字が多すぎない場合は、テキストを再構成するのに十分な情報がある可能性があります。

しかし、その前のステップは、十分なデータを収集する方法を知ることです。テキストがどの2つのエンコーディングによって区切られるかを推測するには、他のアクセント文字に十分な「文字éをc5 b1 3fに変換する」例が必要です。

あるいは、推測できない場合は、破損プロセスを再構築しなくても、破損したバイトシーケンスを正しい文字に置き換えるのに十分なペアをすでに検出できます。

ただし、これを行うには、チェコ語のユーザーとして完全なテキストがあり、正しい文字を推測できるため必要です。

おすすめ記事