という先日バグってなったのか何かしらの標的型攻撃なのかははっきりしないが、突如特定のフォルダ内の.txt拡張子がついたテキストファイルのみ文字化けして、さらには元に戻そうとバックアップしていたUSBメモリに入った.txtファイルまでPCに接続して数秒後一部文字化けしたファイルに変わってしまった。
PCのバグであるなら特定のフォルダ内のみではなく全体がなるはずではあるが、ブログ用に作っておいた.txtで何かちゃんと選んで文字化けさせたかの印象を持ったので何かしらどこぞの気に入らないと思ってる人物でもいて消してやろうと思ったのかもしれない。と、これはただの予想なので全然的外れなことかもしれないから保留。
とりあえずマルウウェアなのかスクリプトを動かしたのか１回しか実行されなかった。（気持ちは標的型攻撃を受けている、という前提で考える）
発生した文字化けは直す試みをしてみる。が２種類に分けて変換されていて1個はただエンコーディングをラテンなんとかに変えただけの芸のないもの。
もう一個はどの文字エンコードに切り替えても全て当てはまらず、結局一晩探して戻し方がわからずしばらく様子を見ることにした。
結果として、この文字コードはどのツールにかけても元に戻らない、が仕組みを少し理解して完全再現とまでは行かないでも似たような仕掛けがわかったのでやり方を書いてみる。
最初にUTF-8で適当に日本語で文字を打った.txtを用意しておく。
それをMac OSならHex Fiendというバイナリエディタ（APP STOREで入手）で開いてバイナリで編集できる状態にする。
適当な日本語を打って、１回目のnkf -w8 4.txt で正常表示。２回目のnkf -w8 4.txtではHex Fiendで文字化けが発生するように最初の文字の値を変えてから実行しています。
バイナリの最初の４バイトはファイル形式で、FF FE DF だとUTF-8形式で開くようにするコード、Shift_JIS形式やEUCだとこの最初のコードが変わってくる。
元に戻せないようにする方法は、このコード以降の最初の部分 44 を適当に文字コードが割り振られてないとかデタラメな数値を入れる、すると以降の文字全体が文字化けしたかのような表示に変わる。しかしnkfコマンドなどでいくら文字コードのエンコーディングをShift_JISやUTF-8などに変えても当てはまらず直すことは不可能のように見える。
これを他人にやるとしたら、簡単なスクリプトで先頭文字だけを適当な値に書き換えるようにすると不思議な、どのエンコーディングにも当てはまらない困った.txtファイルになってしまうという仕様です。バイナリエディタを使わない人になら.txtに限らず正常に開けないようになるのではないでしょうか。