Cp1252からUTF-8に直接マッピングされない文字は何ですか？
私はいくつかのスタックオーバーフローの回答を読みましたが、Cp1252（Windows-1252とも呼ばれます。同じですが）からUTF-8に変換するときに、一部の文字が直接マップされません（または「マップ不可」ですらあります）。例えばここ： https://stackoverflow.com/a/23399926/2018047
誰かがこれについてもう少し光を当てることができますか？これは、ソースコードをcp1252からutf-8に一括変換または大量変換すると、文字化けしてしまい、最終的にはガベージになるということですか。
これはWindows 1252コードページがどのように見えるかです。
ご覧のとおり、バイト0x81、0x8D、0x8F、0x90、0x9Dには何も割り当てられていません。
入力ファイルにこれらのバイトが含まれていて、Windows 1252エンコーディングであるかのように扱う場合、それらのバイトは無効な文字として扱われます。通常の状況では、これは入力ファイルがWindows 1252になかったことを意味します。
他のすべてのバイトは印刷可能な文字または制御文字のいずれかをエンコードし、それらの文字はすべてUnicodeに存在するため、UTF-8で明確にエンコードできます。
リンクされた回答が何を主張しようとしているのか私にはわかりません。最後の段落はナンセンスに聞こえます。
あなたが知ることを試みているものにいくつかの光を当てるかもしれないいくつかのさらなる発言：
UTF-8とWindows 1252は、ASCII外では互いに完全に互換性がありません。
これらのエンコーディングは両方とも、テキストを特定のバイト値にエンコードすることはありません。
さらに、特定のバイトシーケンスもUTF-8では無効です
一般に、ファイルをUTF-8またはWindows 1252でエンコードされたテキストが含まれているものとして処理すると、データが失われて破損します。
IDEまたはエディタでファイルのエンコーディングを選択できます。UTF-8のみを使用することをお勧めします。既存のWindows 1252ファイルを変換する必要があります。
誰かがこれについてもう少し光を当てることができますか？
cp1252 デコード関数は、ほとんどが恒等関数です。
cp1252 UCP (UCP = Unicode Code Point)
-------- --------
21 21 (!) (All numbers in hex)
31 31 (1)
41 41 (A)
これにより、seemでUCP（UTF-8ではない）を期待するものもcp1252を受け入れるようになります。リンクされた回答の作成者は、これが事実ではないことを指摘しています。
cp1252 UCP
-------- --------
80 20AC (€)
85 2026 (…)
99 2122 (™)
例外はすべて、80〜9Fの間にあります。
UCPを受け入れるものは iso-8859-1 も受け入れますが、cp1252は受け入れません。
つまり、ソースコードをcp1252からutf-8に一括変換または一括変換すると、文字化けして文字化けしてしまうのですか？
いいえ。cp1252のすべての文字はUnicodeコードにマッピングされるため、適切なツールを使用してUTF-8に正常に変換できます。