想定外の事案
遭遇した事案の概要です。
- PC初心者38人に同じ見本を示し、英数字だけのExcelシートを作成・保存してもらう
- 半角文字での入力を前提としていたが、全角文字の混入は想定していた
- OS は Windows 10 で、日本語入力は MS-IME のみ
- 事後に入力内容を確認する都合上、CSVファイル（シフトJIS）でも保存
- 確認時に3人のCSVファイルから「?」に化けている文字が見つかった
- 元になるExcelファイルを開くと、3人とも化けた文字は全角の D だった
なぜ、PC初心者がこのような怪しい文字を入力したのでしょうか？
表題と「全角文字の D」で理由を察した方もおられると思いますが、世間ではあまり注意されていないようなので（Qiita内のコメントで1件見つけました）、小ネタとして書き留めておきます。
内容的には、こちらの記事に近いものかもしれません。
（記号以外の文字にも紛らわしいものが多いという意味で）
Excel上で検証
状況を簡単に再現してみます。（Windows 11 + MS-IME にて再現）
下図でセルA1が問題の文字です。セルA2は全角大文字の D です。
MS明朝 48ポイントで表示していますが全く見分けがつきません。
CSV保存で文字化けしているので、シフトJIS外の文字と思いますがASC関数をかましてみます。
やはりセルA1は、ASC関数で半角になりません。
セルA2は、ASC関数で半角になります。（これが普通）
さて、セルA1の文字は何者か？
原因と対応
当初から入力に全角文字が混入することは想定していましたが、ローマ数字は想定外でした。
正直言って、シフトJISで保存しなければ気がつかなかったと思います。
なぜ混入が頻出したのでしょうか？
D の罠
MS-IME の場合は、「D」に要注意です。
MS-IME の初期化および学習内容を消去して入力の様子を再現してみます。
IME オンの状態で「D」キーを押すと...
１番目の候補は U+00D0, ２番目の候補が問題の U+216E です。
（この２文字が最上位の候補とは...😩）
さらにスペースキー２回で、候補に「環境依存」表示が出ます。
（ちなみに TAB キーを連打した場合は、候補に「環境依存」表示は出ません。）
「環境依存」が表示されるものの、５番目の候補が問題の U+216E、６番目の候補が U+217E で、PC初心者が選択する可能性は十分考えられます。
なお、D 以外のローマ数字（I, V, X, L, C, M）は変換候補の上位には入っていませんでした。
とはいえ、これらの文字も混入の可能性は存在します。
Unicode正規化で対応可能
Excel上の対応としては個別に置換することになりそうですが（下に追記あり）、テキストデータの場合はローマ数字（U+2160 から U+217F）を Unicode正規化（NFKC または NFKD） を使って半角英字に変換できます。
例として U+216E の場合
'\u216E'.normalize('NFKC')
from unicodedata import normalize
normalize('NFKC', '\u216E')
"`u{216E}".Normalize([Text.NormalizationForm]::FormKC)
上記は全て半角文字の "D" を返します。
Excel + Script Lab アドインで処理（追記）
(2024.6.28 追記)
Google Sheets の場合は Apps Script で正規化できますが、Excel の場合は Script Lab アドインで JavaScript を使って正規化できます。
Script Lab を使ったユーザー定義関数の作成例です。
過去に記事を投稿したことを忘れていました。
Script Lab は今年の4月以降、環境によって使えないことがあるようです。
上のスクショは Microsoft 365 Apps for enterprise での様子ですが、Office LTSC 2021 では、正規化が働かないという不具合がありました。
また、Microsoft 365 for the web は正常動作しました。
おわりに
（自分の環境では）「ATOK」や「Google 日本語入力」で、「D」の変換候補にローマ数字は出てきません。今回の事案は MS-IME の仕様が影響したと思われたため、表題を「MS-IME の罠」にしました。
入力者の習熟度や環境によって、思わぬ文字の混入があり得るということは教訓にしておきます。