新たに作ったライブラリー2022の表示を工夫するときに、<a href="..." > の行先に *.js のファイルを直接指定して飛ぶようにしたところ、文字化けが起こりました。 同じファイルでも、<iframe src="..." > で参照すれば化けなかったので、php でリーダーのページを作り、ファイル名を引数渡しするように最終的にはしました。
然しながら、 <a href="..." > で文字化けすることはやはり気になり、原因を調べたところ、UTF-8 のファイル形式に問題がありました。 UTF-8 には、先頭に BOM と呼ばれる定型コードが付いている場合と付いていない場合があるのですが、BOM がない場合に化けることがわかりました。 通常使っている Microsoft によるテキストエディター（Visual Studio Code）の出力にはデフォールトで BOM は付きません。 これは「メモ帳」も同じですが、どちらにしても常にそうというわけではなく、UTF-8 として開いたときのコードが BOM 付きであれば出力も BOM 付きという、わかりにくい動作をするようです。 これらの場合は、BOM 付きの UTF-8 ファイルを一つ持っておいて、これの編集という形で出力すれば、BOM 付きが得られることになります。 C# などを開発している VisualStudio の場合は、ANSI がデフォのようですが、これでも初めから UTF-8 などで書かれたファイルは開けるし、編集して保存する時は、元の形式が維持されるようです。
しかし、BOM の有無ってどうしてわかるの？　という疑問が生じるかも知れません。 普通のやり方というのは不明ですが、私は自作の Bytespy というツールを使っています。ソースコードをご紹介しておきます。 これで開いて、先頭が "EF BB BF" となっていれば BOM 付きです。
一応、編集もできるので、BOM の付け外しもできる、はずです。
さらに多様なテキストファイルに対応した SuperTextEditor も公開します。 テキストファイルのエンコーディングは、BOM のようなコードによって形式を特定できることもありますが、完全ではありません。 文字化けしていることが、普通の例えば日本人が見れば明らかな場合でも、入力時のエンコーディング指定はできないものが多いと思います。 このエディターでは、入力ファイルのエンコーディングを指定でき、しかも、入力したバイナリーはバッファに保持するので、再読み込みすることなく、エンコーディングの再設定（再デコード）が可能です。 読める形のデータになったら、「テキスト固定」をチェックします。または、何らかの編集を加えれば、再デコードはなくなります。 出力のエンコード形式は別途選べますが、これは「メモ帳」でもできることです。


【各種エンコーディングによるバイナリーの違い】

一例として、「山のあなたの空遠く」という短文を用意しました。各エンコーディングによるバイナリーは次のようです。

ANSI: 8E 52 82 CC 82 A0 82 C8 82 BD 82 CC 8B F3 89 93 82 AD
UTF-7: 2B 58 48 45 77 62 6A 42 43 4D 47 6F 77 58 7A 42 75 65 6E 71 51 59 44 42 50 2D
UTF-8(BOM無): E5 B1 B1 E3 81 AE E3 81 82 E3 81 AA E3 81 9F E3 81 AE E7 A9 BA E9 81 A0 E3 81 8F
UTF-8(BOM付): EF BB BF E5 B1 B1 E3 81 AE E3 81 82 E3 81 AA E3 81 9F E3 81 AE E7 A9 BA E9 81 A0 E3 81 8F
UTF-16(LE): FF FE 71 5C 6E 30 42 30 6A 30 5F 30 6E 30 7A 7A 60 90 4F 30
UTF-16(BE): FE FF 5C 71 30 6E 30 42 30 6A 30 5F 30 6E 7A 7A 90 60 30 4F
UTF-32: 71 5C 00 00 6E 30 00 00 42 30 00 00 6A 30 00 00 5F 30 00 00 6E 30 00 00 7A 7A 00 00 60 90 00 00 4F 30 00 00


Bytespy（C#）:


SuperTextEditor（C#）: