SHA가 일치하지 않는 이유는 무엇입니까?

SHA가 일치하지 않는 이유는 무엇입니까?

날짜의 SHA를 사용하는 스크립트를 작성하려고 하는데 두 가지 다른 결과가 나오고 평생 동안 그 이유를 알 수 없습니다.

echo -n 03112016 | cut -d'.' -f4 | sha256sum | cut -d' ' -f 1
482c00f7db8419d9f9a151d54de301d73c8f688b2e3e91c485f369596543612e

date "+%m%d%Y" | tr -d '\n' | sha256sum | cut -d' ' -f 1
d373ab72ec7d92ee06ebba4748f78829cd62ce68f1ac600ae1767a272869b664

나는 이것이 내가하는 어리석은 일이라는 것을 알고 있지만 도움을 주시면 정말 감사하겠습니다.

답변1

cat텍스트(예 : , cut, sort, 등) 를 조작하도록 설계된 쉘 유틸리티에서는 tail입력이 텍스트 파일이어야 합니다. Unix 용어로 표현된 텍스트 파일:

  • LC_CTYPE널 바이트를 제외하고 환경의 로케일(로케일)에서 유효한 문자만 포함합니다 .
  • 일련의 줄로 구성되며 각 줄은 \n개행 문자(개행 문자라고도 함)로 끝납니다.

두 번째 점은 비어 있지 않은 파일이 개행 문자로 끝나는 것을 의미합니다.

입력이 텍스트 파일이 아닌 경우 어떻게 됩니까? 유틸리티에 따라 다릅니다. 이전 Unix 시스템은 널 바이트 다음 줄의 텍스트를 무시하고 마지막 불완전 줄(마지막 개행 문자 뒤의 텍스트) 전체 또는 일부를 무시하는 경향이 있었습니다. GNU 버전은 항상 널 바이트를 일반 문자로 처리하고 대부분의 경우 잘못된 바이트 시퀀스를 전달합니다. GNU 버전은 마지막 개행 문자가 손실되더라도 항상 전체 입력을 처리하지만 출력에 후행 개행 문자를 추가하는지 여부가 다릅니다. 예를 들어, GNU는 cat항상 입력을 변경하지 않고 전달하지만 다른 많은 경우(포함)는 cut항상 모든 출력 줄(마지막 줄 포함) 끝에 개행 문자를 인쇄합니다.

따라서 참조 입력을 생성할 때 마지막 순간에 후행 줄 바꿈을 억제해야 합니다.

echo 03112016 | cut -d'.' -f4 | tr -d '\n' | sha256sum

그렇지 않으면

echo -n 03112016 | sha256sum

관련 정보