인코딩된 문자열은 퍼즐, 출시 티저, 소셜 게시물에 자주 나타납니다. 디코딩은 문자열이 나타내는 바이트를 설정할 수 있습니다. 메시지를 작성한 사람이 누구인지, 스크린샷이 진짜인지, 향후 제품이 어떤 역할을 할지 등은 알 수 없습니다. 단서를 조사할 때 이러한 질문을 별도로 유지하십시오.
정확한 전사로 시작
가능하면 다시 입력하지 말고 소스 문자열을 복사하세요. 대문자, 구두점 및 눈에 보이는 여백을 유지합니다. 소스 URL을 기록하고 디코딩된 출력과 별도로 시간을 캡처합니다. 출처가 이미지인 경우 표기 시 대문자 I, 소문자 l, 숫자 1 등의 문자가 혼동될 수 있다는 점에 유의하세요. 그럴듯한 문장이 표기가 정확하다는 증거는 아닙니다.
리터럴 값 디코딩
예를 들어, 짧은 문자열 NS41 직설적이다 Base64 결과: ASCII 바이트 5.5. 결과는 문자열입니다. 이는 독립적으로 릴리스 번호, 날짜, 벤치마크 점수 또는 특정 조직의 발표에 대한 증거가 아닙니다.
const bytes = Uint8Array.from(atob('NS41'), c => c.charCodeAt(0));
console.log([...bytes]); // [53, 46, 53]
console.log(new TextDecoder('utf-8', { fatal: true }).decode(bytes)); // 5.5
console.log(btoa('5.5')); // NS41역변환을 통해 인코딩 관계가 확인됩니다. 출처를 추가하지 않습니다. 기존 기사 URL에는 티저 검색과 관련된 이름이 포함되어 있습니다. 이 페이지는 해당 조직이 해당 페이지를 게시했거나 제품을 발표했다고 주장하지 않습니다.
작은 증거 테이블을 유지하십시오
리터럴 입력, 결정론적 디코딩 결과, 고려 중인 해석이라는 세 가지 개별 필드를 기록합니다. 주요 출처가 이를 확인하지 않는 한 해석을 가설로 표시하십시오. 제품에 대한 주장을 반복하기 전에 공식 발표를 직접 확인하세요. 재게시물, 스크린샷 캡션 또는 디코딩된 숫자가 자동으로 해당 수표를 대체해서는 안 됩니다.
디코딩이 실패하면 의미 있는 것으로 보일 때까지 많은 변환을 시도하기보다는 정확한 문제를 보고하십시오. 패딩을 추가하면 알려진 형식 누락을 수정할 수 있습니다. 알 수 없는 문자를 삭제하면 증거가 변경됩니다. 출력을 반복적으로 디코딩하는 것은 소스나 형식이 다른 레이어를 나타내는 경우에만 정당화됩니다.
마지막으로, 디코딩된 콘텐츠를 비활성 상태로 유지하세요. 퍼즐 페이로드에는 링크나 실행 가능한 스니펫이 포함될 수 있습니다. 텍스트를 읽으려면 링크를 방문하거나 코드를 실행할 필요가 없습니다. 이 접근 방식은 제품 티저, 게임 단서 및 디버깅 메시지 모두에 적용됩니다. 즉, 되돌릴 수 있는 작업을 수행한 다음 자체 증거에 따라 주장을 평가합니다.