다음 두 명령을 비교해 보세요.
mysqldump database_name --hex-blob -uuser_name -p | tee database_name_tee.sql
mysqldump database_name --hex-blob -uuser_name -p > database_name_out.sql
첫 번째 실행을 실행하면 완료되면 터미널에 다음이 표시됩니다.
$ 62;c62;c62;c62;c
이것은 어디에서 왔습니까? 이는 도중에 문제가 발생했음을 의미합니까? 어떤 이유로 이러한 제어 문자가 출력되고 있습니까?
U+0C62Telugu Vowel Sign Vocalic L입니다. 내 데이터의 일부가 아니라고 확신하므로 유니코드는 아닌 것 같습니다. 아무튼 순서는 아닌 것 c62
같지만 62;c
. 이것은 아마도 일종의 제어 문자일 것입니다. 원인이 무엇이든 출력 파일에 포함됩니다. 나중에 하게 된다면 , cat
아니면 database_name_tee.sql
다 하고 나면 database_name_out.sql
이 순서를 다시 보게 될 것입니다.cat
tail database.sql -n200
이 출력은 생성되지 않고 -n300
생성 $ 62;c62;c
됩니다 -n400
. $ 62;c62;c62;c62;c
따라서 원인이 무엇이든 파일 전체에 배포됩니다.
좀 더 자세히 살펴보면 head
, tail
범인 중 하나를 발견했습니다. 별도의 파일에 저장하고 를 사용하여 인쇄할 때 cat
생성되는 줄입니다 $ 62;c62;c
. 내 문제는 이 줄에 1043108바이트가 있다는 것입니다.
(생성된 SQL 파일은 정상이고 오류 없이 실행됩니다. MySQL 자체와는 관련이 없는 것 같습니다.)
저는 CentOS 서버에서 초기 빌드를 실행하고 mysqldump
있으며 서버 자체와 Ubuntu 데스크탑에서 동일한 효과를 확인하므로 cat
이는 일반적인 Bash인 것 같습니다.
od -c problem_line
생산하다65174 라인의 출력그래서 나는 그것을 다음과 같이 줄였습니다.동일한 출력의 더 작은 부분을 보여줍니다.(다음으로도 사용 가능일반 16진수 덤프).
답변1
8진수 덤프에는 이스케이프 문자가 없습니다 033
.
일부 8비트 제어 코드가 있습니다(보통 xterm을 제외한 대부분의 터미널에서는 구현되지 않음). 8진수 232
는 16진수 0x9a이고, (참조XTerm 제어 순서):
ESC Z
Return Terminal ID (DECID is 0x9a). Obsolete form of CSI c (DA).
...
CSI Ps c Send Device Attributes (Primary DA).
Ps = 0 or omitted -> request attributes from terminal. The
response depends on the decTerminalID resource setting.
...
-> CSI ? 6 c ("VT102")
이러한 문자는 제어 문자에 대한 터미널 DECID
의 응답에서 나옵니다. 응답의 세부 사항은 터미널 에뮬레이터에 따라 다릅니다(질문에 언급되지 않음).