↵ 改行コード・エンコード変換
テキストの改行コード (LF / CRLF / CR)、BOM、文字コード (UTF-8 / Shift-JIS / EUC-JP)、インデント (タブ ⇔ スペース)、行末空白、重複空行をまとめて変換します。
🔒 プライバシーについて
- ・すべての変換はブラウザ内 (TextEncoder / TextDecoder API) で完結します
- ・テキスト・ファイル内容は一切サーバーに送信されません
- ・保存ログ・履歴・データベース等は存在しません
📂 ファイルをドラッグ＆ドロップ、またはクリックで選択 (任意)
変換結果
📖 つまずきやすいポイント
改行コード (LF / CRLF / CR)・BOM・文字コード・インデント・行末空白をまとめて変換します。処理はブラウザ内で完結します。改行コードは目に見えないので、問題は「変換したいとき」ではなく「混ざっていることに気付かないとき」に起きます — Git の差分が全行になる、シェルスクリプトが動かない、PHP が謎のエラーを出すといった症状の裏に、たいていこれがあります。
| ケース | 何が起きるか | どうする |
|---|---|---|
| Git の差分がファイル全体になる | 1 行しか直していないのに 全行が変更として表示されるなら、ほぼ確実に改行コードが変わっています。原因は 各自の core.autocrlf の設定が違うことで — Windows の既定 (true) はチェックアウト時に CRLF へ、コミット時に LF へ変換しますが、macOS と Linux の既定 (false) は何もしません。混在したチームでは保存するたびに改行が反転し、レビューが不可能になります。エディタの設定が「開いたファイルの改行を維持」なのか「常に LF」なのかでも結果が変わります。 |
.gitattributes をリポジトリに置いて、* text=auto eol=lf と書いてください — これは個人設定と違ってリポジトリに入るので、全員に同じ規則が適用されます。core.autocrlf は各自の環境変数なので、チームで揃える手段としては当てになりません。Windows 用のバッチファイルなど CRLF が必要なものは *.bat text eol=crlf と個別に指定します。既に混在してしまっている場合は、git add --renormalize . を 1 回だけ実行して、全ファイルを規則どおりに正規化してください — これは巨大な 1 コミットになるので、他の変更と混ぜず、単独でコミットしてレビューを飛ばすのが実務的です。 |
| BOM のせいで動かない | BOM (Byte Order Mark) はファイルの先頭に付く 3 バイトの見えない印です。UTF-8 では本来不要ですが、Windows のメモ帳などが既定で付けます。実害の代表例は — PHP ファイルの先頭に BOM があると、<?php より前にその 3 バイトが出力され、headers already sent エラーになります。シェルスクリプトでは #!/bin/bash の前に BOM が入って shebang が認識されず、実行できません。JSON パーサーの多くは BOM で構文エラーになります。いずれも「見えない 3 バイト」が原因なので、ファイルを何度見返しても分かりません。 |
UTF-8 では BOM を付けないでください。UTF-8 はバイト順の曖昧さが無い符号化なので、BOM の本来の役割 (バイト順の指示) がそもそも不要です。唯一の例外は、Windows の Excel で開く CSV — BOM が無いと Excel が日本語環境で Shift-JIS として読み、文字化けします。この 1 点だけは BOM を付ける理由があります。判別は簡単で、file コマンドが UTF-8 Unicode (with BOM) text と表示するか、head -c 3 file | xxd が efbb bf を返すかです。「なぜか動かない」ファイルに出会ったら、内容を疑う前に先頭 3 バイトを見てください — 数秒で切り分けられます。 |
| タブとスペースが混ざって構文エラーになる | 言語によってインデントの扱いがまったく違います。Python 3 はタブとスペースの混在を明確に拒否し、TabError を出します — 画面上は同じ幅に見えるので、コピー＆ペーストで混ざったときが最も見つけにくいです。YAML はタブを一切許しません — インデントとして使うと必ずパースエラーになります。逆に Makefile はレシピ行がタブで始まらなければならず、スペースにすると missing separator になります。「見た目が同じで意味が違う」という性質は、どの方向にも事故を起こします。 |
.editorconfig をリポジトリに置いて、拡張子ごとに決めてください — ほとんどのエディタが追加設定なしで従うので、チーム全員に同じ規則が適用されます。実務的な既定は Makefile と Go はタブ、それ以外はスペースで、Go は言語の公式フォーマッタがタブを使うので議論の余地がありません。[Makefile] と [*.go] に indent_style = tab、それ以外に indent_style = space と書けば十分です。既に混在している既存ファイルは、このツールで一括変換してください — ただし変換は 1 コミットにまとめ、機能の変更と混ぜないでください。エディタで「空白文字を表示」を有効にしておくと、そもそも混ざらなくなります。 |
行末空白の一括削除には 1 つだけ例外があります — Markdown では行末の半角スペース 2 個が「改行」を意味します。一括削除すると、意図した改行が消えて段落がつながります。Markdown を扱うなら、この処理は避けるか、削除後に表示を確認してください (そもそも行末スペースに頼らず空行で段落を分けるほうが安全です)。もう 1 点、文字コードの変換は不可逆です — UTF-8 から Shift-JIS へ変換すると、Shift-JIS に存在しない文字は失われます。絵文字、丸数字の一部、ローマ数字、そして 波ダッシュ (〜) のように「見た目は同じだが別のコードポイント」の文字が該当し、置き換え文字になるか、そのまま消えます。変換する前に必ず元のファイルを別名で残してください — 変換後のファイルから元に戻すことはできません。このページの処理はすべてブラウザ内で完結するので、入力したテキストが送信されることはありません。
📖 使い方
-
1
テキスト/ファイルを入力テキストエリアに貼り付けるか、ファイルをドラッグ＆ドロップで読み込みます。
-
2
変換オプションを選ぶ改行 (LF/CRLF/CR)、BOM、エンコード、インデント、行末空白、重複空行をまとめて指定します。
-
3
変換してコピーまたは保存結果をクリップボードへコピー、またはファイルとしてダウンロードできます。
❓ よくある質問
Shift-JIS で出力できないのはなぜ？
BOM とは？付けるべき？
ファイルはサーバーに送信されますか？
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。