エクスポートした日記ファイルの絵文字化けを診断する方法
エクスポートした日記で絵文字が正しく表示されない場合は、まず文字が誤ったエンコーディングでデコードされたのか、エクスポート時に置換されたのか、あるいは正しくデコードされているもののアプリやフォントで表示できないのかを判断します。必ず複製したファイルで作業し、元のバイト列を維持したまま、プレーンテキストエディタと日記のインポート機能の両方で同じテキストを比較してください。エンコーディング設定の変更で修正できるのはデコードの不一致のみであり、すでに置換されたり削除されたりした情報を復元することはできません。
「文字化け」の状態を特定する
問題が発生しているエントリを1つ詳しく観察してください。😀 が入るべき場所に `😀` のような予期しない文字列が表示されている場合、UTF-8のバイト列が別のエンコーディングで解釈された可能性があります。これは一般に「文字化け（mojibake）」と呼ばれます。バイト列が誤った前提でデコードされたために表示がおかしくなっている状態です。これは原因の手がかりにはなりますが、どのエンコーディングでファイルが生成されたかを断定する決定打にはなりません。
`` が表示されている場合は状況が異なります。これは Unicode の置換文字（U+FFFD）であり、解釈できない文字の代わりとして使用されます。Unicodeの[用語集（glossary）](https://www.unicode.org/glossary/#replacement_character)では、これを「代替グリフ（replacement glyph）」と区別しています。フォントやレンダラーは文字を描画できない場合に四角（豆腐）を表示することがありますが、基底の文字自体は損なわれずに残っている場合があります。一部の絵文字だけが四角で表示される場合は、ファイルのエンコーディングを変更する前に、最新の別のアプリやフォントで表示を確認してください。
トラブルシューティング前にベースラインを保持する
エクスポートファイルのコピーを作成し、オリジナルは変更せずに保管してください。ファイル拡張子、エクスポート元のアプリ、そして該当するフレーズの表示状態を記録します。可能であれば、日記内の既知の絵文字と、元のアプリまたは過去のエクスポート内の同じエントリを比較してください。唯一のコピーを繰り返し開いて保存することは避けてください。テキストエディタが新しくデコードされたテキストをバイト列として再書き込みし、可逆的だった表示実験を取り返しのつかないものにしてしまう恐れがあります。
エンコーディングを選択できるエディタで、コピーをプレーンテキストとして開きます。まずは日記アプリのドキュメントに記載されているエンコーディングを試してください。不明な場合で、ファイルが一般的な最近のテキストエクスポートであれば、UTF-8 を確認用の候補とするのは妥当ですが、オリジナルに上書き保存するための前提にしてはいけません。それぞれの候補で、問題のテキストとその周囲の通常の文字を比較します。ファイル全体が一貫して正しく表示されることのほうが、たまたま絵文字が1つ正しく見えたことよりも確実な証拠になります。
再書き込みせずにデコードをテストする
エディタのエンコーディング表示を変更することで、奇妙な文字列が期待どおりの絵文字になり、周囲のテキストも読めるようになった場合、そのエクスポートには誤って解釈されただけで無傷のバイト列が含まれている可能性があります。保存せずにコピーを閉じ、有望だった設定で再度開いて確認してください。その後、日記アプリのインポートまたは開くワークフローにエンコーディングの選択肢が文書化されているかを確認し、実際の再インポートにはそのワークフローを優先して使用します。
[Unicode UTF FAQ](https://www.unicode.org/faq/utf_bom.html) では、不正な形式の UTF-8 バイトシーケンスはエラーを引き起こすか、U+FFFD などのマーカーで処理される場合があると説明されています。つまり、デコーダーが表示またはインポートの時点で、すでに無効な入力を置き換えてしまっている可能性があるということです。その処理の後にエンコーディングを切り替えても、必ずしも元のバイト列が復元されるわけではありません。唯一のコピーに対して、デコードできない文字を暗黙的に置き換えてしまうような「修復」や変換オプションは使用しないでください。
エンコーディングの問題とグリフの欠落を切り分ける
別のビューアで絵文字が正しく表示される場合は、ファイルを変更する前の証拠としてその比較結果を記録しておきます。単に見た目を変えるためだけにエクスポートファイルを書き直すことは避けてください。
どのビューアでも同じ位置に U+FFFD や疑問符（?）が含まれている場合は、元の日記や以前のエクスポートと比較してください。ファイル内に保存されてしまった代替文字は、フォントを変更しても復元できません。回復できるかどうかは、その文字が保持されている別のコピーが存在するかどうかにかかっています。
CSVとJSONを異なるインポート経路として扱う
`.csv` 拡張子だけでは使用された文字コードは分からず、表計算ソフトが独自のインポート設定を適用してしまうことがあります。Excel デスクトップ版の場合、Microsoft は[テキストおよび CSV ファイルのインポート/エクスポート ガイド](https://support.microsoft.com/en-us/excel/get-started/import-or-export-text-txt-or-csv-files)の中で、**データ > テキスト/CSV から** およびテキスト読み込みウィザードを使用したインポート手順を説明しています。読み込む前にプレビューを使用し、絵文字、行と列の区切り、隣接するテキストを確認してください。プレビューが正しければ、選択したインポート経路がファイルを意図通りに読み込んでいる証拠となりますが、元ファイルを上書きする理由にはなりません。
JSON の場合は、ファイルをそのまま保持し、CSV として扱うのではなく JSON に対応したインポーターを使用してください。[RFC 8259 JSON 仕様](https://www.rfc-editor.org/rfc/rfc8259#section-8.1) では、閉じたエコシステムの外部でシステム間送受信される JSON には UTF-8 が義務付けられています。また、JSON 文字列は文字を直接表すことも、エスケープして表すこともできると説明されています。`\\u263A` のようなエスケープが見られるからといって、直ちに破損しているとは限りません。JSON パーサーは有効なエスケープを解釈するはずです。JSON が無効であるかインポーターがパースエラーを報告する場合は、作業を中断し、当て推量で記号やバイトを編集せずに正確なファイルを保持してください。
再試行、再エクスポート、または中止を判断する
次の順序で進めてください：(1) 元の日記とエクスポートファイルを比較する、(2) 想定されるエンコーディングと、適切であれば UTF-8 表示を用いて複製ファイルを検査する、(3) 別のビューアでグリフの欠落による挙動がないか確認する、(4) 適切な CSV または JSON インポーターでファイルをプレビューする、(5) 元のアプリで絵文字がまだ正しく表示されている場合は、文書化されたテキストエンコーディングで再度エクスポートを試みる。変数は一度に1つずつ変更し、結果は個別に記録してください。
どの表示やインポーターを使っても元の文字が現れず、ファイルに置換文字やその他の代替データしか含まれていない場合は、再エンコードによる復元を期待しないでください。デコード設定を変更しても、どの絵文字が破棄されたかを推測することはできません。別のエクスポート、バックアップ、または無傷の日記エントリを探し、新しいファイルに再度エクスポートした上で、利用する前にプレビューを確認してください。