mdのエクスポート/インポート：運用でハマらない設計

md_export_import_practical 2026-02-08 18:40:00 / 運用 / エクスポート / インポート / 文字コード / 改行

# mdのエクスポート/インポート：運用でハマらない設計

mdは軽い一方で、運用すると「意外な落とし穴」が出ます。
この章では、ありがちな事故を先に潰す視点でまとめます。

---

## 1) エクスポート（保存）で意識すること

### 文字コード

基本は **UTF-8** が安定です。
Windows環境で扱うなら、ツールによってはBOMの有無が話題になります。
ただし現代の多くの環境では「UTF-8で保存」だけで問題になりにくいです。

### 改行コード

- `\n`（LF）が基本
- 環境によってはCRLFで保存される

mdはだいたい吸収しますが、
**差分（diff）**が大きく見える事故があるので、Git管理するなら改行統一が無難です。

---

## 2) インポート（読み込み）で意識すること

### “何をどこまで対応するか”を決める

mdのすべての拡張に対応しようとすると沼です。
現実的には次のどちらかに割り切るのが強いです。

- **学習/メモ用途**：見出し・箇条書き・コードだけ対応で十分
- **公開文書用途**：外部ライブラリ（marked等）やサーバー側変換を採用

このページのインポートは「学習用途」の想定なので、
**ブラウザ内で軽くプレビュー**できる範囲に絞っています。

---

## 3) 画像パス問題（地味に一番ハマる）

mdの画像はたいてい相対パスで書きます。

```md
![top](./images/top.png)
```

でも、インポートしたmdが別フォルダにあると、相対パスが崩れます。

### 対策案

- 公開サイト運用なら、画像を `https://...` の絶対URLに寄せる
- もしくは、mdと画像を同じフォルダ構成で配布する

---

## 4) 他ツールへのインポート（Notion / GitHub / Qiita）

同じmdでも表示が変わるのは普通です。

- Notion：独自の取り込みが入る（表や装飾が変わることがある）
- GitHub：GFM（GitHub Flavored Markdown）で拡張が多い
- Qiita：独自拡張や記法の差が出る

> 結論：
> “同じ見た目”を狙うより、
> **「崩れても意味が通る」書き方**が強い。

---

## まとめ

- エクスポートはUTF-8/LFを基本に
- インポートは用途に応じて対応範囲を決める
- 画像パスが一番事故りやすい
- 表示の差は前提として、文章設計で耐える

このページの「mdインポート/エクスポート」について