発生事象

とあるシステム開発に携わっていた際、顧客から「特定のファイルを取り込もうとすると、システムがクラッシュしてしまう」と不具合報告をいただきました。
ファイルを連携してもらい、中身を確認するも目検では特に問題は見つからず…
デバッグしていくと、特定文字列でクラッシュしていることがわかりました。

謎の文字列

デバッグして実際に見つけたのが下記の文字列です。

A.「データ」
B.「データ」

Aは比較用にこちらで手打ちしたもの、Bがデバッグで見つけたものです。
上記2つの文字列は見た目上同じに見えますが、sakuraエディタに貼り付けると下記のような状態になります。

さらに、これらはExcel上で表示するフォントによっても見え方が異なります。

文字コード検査をやってみる

恐らく文字コードが原因だろうと目星をつけ、それぞれを文字コード（UTF-8）で表してみました。
Aの結果

Bの結果

文字コード的にも全然違いました。
そもそもBの「デ」は、「30C6 + 3099」で成り立っているようです。
なるほど、ということは日本語カナ入力の＠で出てくる「゛」を使っているのでは？と思い検証した結果が下記です。

「テ゛ータ」の文字コード検査結果

「゛」の文字コードは「309B」であり、どうやら別物のようです。
状況をまとめると下記になります。

こうなってくると、ユーザーがわざわざ文字コード（3099）を使って入力しているとしか考えられません。

※一応やろうと思えばできる
①全角で文字コードを入力

②文字コード変換

③入力できる

しかしながら当然そんなわけないため、（IT初学者の私にとっては）シンプルに謎でした。

原因について

社内で助言を求めたところ、OS起因説が浮上しました。
調べてみると、どうやらMacOSで作成したファイルをWindowsで確認した場合や、MacOSで作成したPDFやWord内の文字をコピーし、Windowsで張り付けをした場合に文字化けを起こす可能性があるようです。
この場合の文字化けとは、「日本語の濁点が入浴されたと思わしき部分（2バイト文字）が「?」と表示されたり、かな/カナ文字と濁点部分が分離されて表示される現象」 らしく、本件の原因を説明しうる現象でした。

この文字化け現象はどうやら基本ソフト(OS)のファイルシステムの違いに関係するようです。Windowsが導入しているファイルシステム「NTFC」に対し、MacOXが導入しているファイルシステムは「HFS Plus」です。双方のファイルシステムのUnicodeを正規化する過程（WindowsやLinuxはNFC方式が採用され、MacOXはNFD方式が採用されています）での形式に違いがあり、MacのUnicode（＝NFD形式）で入力した文字はWindows環境へ横断すると濁点部分が分離するなど正しく情報を読み取れない現象が発生してしまうようです。
（引用：https://www.sanei-fcg.com/blog/2019/09/18/1239/）

これだ！と思いユーザに確認しましたが、「社内ではMacOSを使っていないが、該当ファイルを渡してくれる別会社がMacOSを使っているかもしれない（わからない）」とのこと…原因は闇の中…

とはいえ、システム不具合については運用でカバーいただく形で落ち着き、原因については自分なりに納得できるものを得られたため、本件はクローズとなりました。

まとめ

発生当初はどうなることかと思いましたが、結果的に文字コードのみならずOSのファイルシステムにまで踏み込んだ知見を得られました。
皆さんも文字コードで躓いた際は、OS起因を疑ってみてはいかがでしょうか。

参考文献

文字コード判別：http://www.shurey.com/js/works/unicode.html
濁点関係：https://www.asahi-net.or.jp/~ax2s-KMTN/ref/unicode/u3040.html
OS横断時の文字化け①：https://www.sanei-fcg.com/blog/2019/09/18/1239/
OS横断時の文字化け②：https://www.chihayafuru.jp/tech/index.php/archives/2460