エンコードされた文字列は、パズル、リリースのティーザー、ソーシャル投稿によく登場します。デコードすると、文字列がどのバイトを表しているかを確認できます。誰がメッセージを書いたか、スクリーンショットが本物かどうか、将来の製品でどうなるかなどを特定することはできない。手がかりを調査するときは、これらの質問を分けてください。
正確な文字起こしから始める
可能であれば、再入力せずにソース文字列をコピーします。大文字、句読点、および目に見えるパディングを保持します。ソース 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 には、ティーザーの検索に関連付けられた名前が含まれています。このページは、指定された組織がそれを発行したり、製品を発表したりすることを主張するものではありません。
小さな証拠テーブルを用意しておく
リテラル入力、決定論的なデコード結果、検討中の解釈の 3 つのフィールドを別々に書き留めます。一次情報源が確認しない限り、その解釈を仮説としてマークしてください。製品の主張を繰り返す前に、公式発表を直接確認してください。再投稿、スクリーンショットのキャプション、またはデコードされた番号がそのチェックを黙って置き換えるべきではありません。
デコードが失敗した場合は、意味があると思われるまで何度も変換を試みるのではなく、正確な問題を報告してください。パディングを追加すると、既知の書式設定の欠落を修正できます。不明な文字を削除すると証拠が変わります。出力を繰り返しデコードすることは、ソースまたは形式が別のレイヤーを示している場合にのみ正当化されます。
最後に、デコードされたコンテンツを不活性に保ちます。パズルのペイロードには、リンクまたは実行可能スニペットが含まれる場合があります。テキストを読むために、リンクにアクセスしたり、コードを実行したりする必要はありません。このアプローチは、製品ティーザー、ゲームの手掛かり、デバッグ メッセージにも同様に機能します。つまり、可逆操作を実行し、独自の証拠に基づいて主張を評価します。