내 텍스트가 복구할 수 없을 정도로 손상되었나요?

내 텍스트가 복구할 수 없을 정도로 손상되었나요?

내 손상된 체코어 텍스트:

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.

마지막 두 단어의 철자가 정확합니다.다? 조금? 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

부분 답변, 프로세스 설명:

16진수 덤프에서 "korektnűŮrodnű?"에서 이를 볼 수 있습니다. 부분에서 바이트 "c5 b1 c5 ae"는 "korektnűŮ"의 끝이고 바이트 "c5 b1 3f"는 "rodnű?"의 끝입니다. 이것은 ?실제로 하나입니다 ?.

만약 너라면? "rodnű"에서 "é"가 되어야 합니까? "dá?litelnű?" -> "dělitelné"에서와 같이 "é"가 "c5 b1 3f"로 끝나는 것을 알 수 있습니다. 체코어를 이해하므로 이것이 맞는지 모르겠습니다.

이제 우리는 무슨 일이 일어났는지 추측할 수 있습니다. "c5 b1"은 2바이트 문자 인코딩처럼 보입니다.추측하다어떤 이유로 텍스트가 두 번 변환된다는 것입니다. 첫 번째 단계에서는 "é"를 2바이트(모든 인코딩에서)로 인코딩하고, 두 번째 단계에서는 첫 번째 바이트를 "c5 b1"로 인코딩하고, 두 번째 2바이트는 인쇄할 수 없습니다. 그리고 그것은 결국 ?.

이는 불행한 일입니다. 왜냐하면 이것이 사실이라면 인쇄할 수 없는 바이트에 대한 정보를 잃게 되기 때문입니다. 그러나 "c5 b1 3f"로 끝나는 문자가 너무 많지 않다면 텍스트를 재구성하기에 충분한 정보가 있을 수 있습니다.

그러나 그 이전 단계는 충분한 데이터를 수집하는 방법을 아는 것입니다. 텍스트가 어떤 두 인코딩에 의해 구분되는지 추측하려면 다른 악센트 문자에 대해 충분한 "문자 é를 c5 b1 3f로 변환"하는 예제가 필요합니다.

또는 추측할 수 없다면 손상 프로세스를 다시 구축하지 않고도 손상된 바이트 시퀀스를 올바른 문자로 바꿀 수 있을 만큼 충분한 쌍을 이미 감지할 수 있을 것입니다.

하지만 이 작업을 수행하려면 체코어 사용자로서 완전한 텍스트가 있고 올바른 문자를 추측할 수 있기 때문에 필요합니다.

관련 정보