テキストエディタとは｜メモ帳・Wordとの違いをバイトで比較・おすすめ8選

テキストエディタのファイルは文字の番号が並ぶだけ、ワープロのファイルは文字と書式をまとめた形式です。

flowchart TD
    A[同じ2行] --> B[エディタで保存]
    A --> C[Wordで保存]
    B --> D[.txt 42バイト<br>文字だけ]
    C --> E[.docx 36,430バイト<br>ZIP＋XML]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13 と python-docx 1.2.0 を使い、同じ2行の文章を UTF-8（LF）・UTF-8 BOM 付き（CRLF）・Shift_JIS（CP932・CRLF）・UTF-16 の .txt と、.docx で作りました。中身は od・file 5.45・unzip で確かめ、Vim 9.1.0016 と GNU nano 7.2 は tmux 3.4 の中で操作して画面を写し取りました（vim は --clean -i NONE、nano は -I で起動し、ホームの設定ファイルは読まず作っていません）。開く時間とメモリは96MBのファイルで3回ずつ測りました。各製品の価格・対応OS・最新版と Windows のメモ帳は、公式サイト・公式の配布ページ・Microsoft の公式ブログで確かめた範囲だけを書いています（確認日 2026年10月29日）。

テキストエディタとは（意味とできること）

この節では、テキストエディタが何をするソフトで、何に使われているのかが分かります。

テキストエディタは、テキストファイル（文字だけでできたファイル）を開いて、書いて、保存するためのソフトです。 単に「エディタ」とも呼びます。保存されるのは文字そのものだけで、文字の大きさ・色・太字・余白といった見た目の情報は保存されません。

文字だけのファイルは、身の回りに多くあります。

多くの製品には、正規表現の検索・置換、フォルダー全体の検索（grep）、色分け（シンタックスハイライト）、文字コード・改行コードの指定、行番号・文字数の表示、マクロ・拡張機能があります。

プログラム向けのものは「コードエディタ」、実行・デバッグまでまとめたものは「IDE（統合開発環境）」と呼ばれます。

テキストエディタとメモ帳の違い

この節では、Windows のメモ帳とほかのテキストエディタが何で違うのかが分かります。

メモ帳（Notepad）も、Windows に付いているテキストエディタの1つです。 「テキストエディタとメモ帳の違い」は、「付属の基本的なエディタ」と「機能を足したエディタ」の違いと考えると分かりやすくなります。

表のメモ帳の内容は、Microsoft のコマンドラインのブログ（2018年5月8日）と Windows Insider のブログ（2025年5月30日）の説明です。設定ファイルに使うなら、書式を使わずに保存します。

テキストエディタとワープロ（Word）の違い：.txtと.docxの中身を比べる

この節では、同じ文章をテキストエディタと Word の形式で保存したとき、ファイルの中身がどう違うのかが実物で分かります。

テキストエディタは文字だけを保存し、ワープロは文字と書式と文書の情報をまとめて保存します。 「こんにちは、RJC。」「2行目です。」の2行を、.txt（UTF-8・LF）と .docx（python-docx で作成）で保存して比べました。

.txt の中身：文字の番号が並ぶだけ

$ od -A d -t x1 utf8_lf.txt
0000000 e3 81 93 e3 82 93 e3 81 ab e3 81 a1 e3 81 af e3
0000016 80 81 52 4a 43 e3 80 82 0a 32 e8 a1 8c e7 9b ae
0000032 e3 81 a7 e3 81 99 e3 80 82 0a
0000042
$ file utf8_lf.txt
utf8_lf.txt: Unicode text, UTF-8 text

e3 81 93 が「こ」、52 4a 43 が「RJC」、0a が改行（LF）です。日本語12文字×3バイト＋英数字4バイト＋改行2バイトで42バイトです。

.docx の中身：ZIP の中に XML

$ file sample.docx
sample.docx: Microsoft Word 2007+
$ head -c 32 sample.docx | od -A d -t x1z
0000000 50 4b 03 04 14 00 00 00 08 00 05 a3 5d 5d ad 52  >PK..........]].R<
0000016 a5 91 95 01 00 00 ca 06 00 00 13 00 00 00 5b 43  >..............[C<
$ unzip -l sample.docx
     1654  2026-10-29 20:24   word/document.xml
   349458  2026-10-29 20:24   word/styles.xml
   438131  2026-10-29 20:24   word/stylesWithEffects.xml
  （ほか14ファイルを省略）
---------                     -------
   826266                     17 files

先頭の PK は ZIP の目印です。本文は word/document.xml に入っていて、段落ごとに <w:p>、文字は <w:t> で囲まれていました。

<w:body><w:p><w:r><w:t>こんにちは、RJC。</w:t></w:r></w:p><w:p><w:r><w:t>2行目です。</w:t></w:r></w:p>
<w:sectPr ...><w:pgSz w:w="12240" w:h="15840"/><w:pgMar w:top="1440" w:right="1800" ...

「RJC」だけを太字にした .docx では、その部分が <w:r><w:rPr><w:b/></w:rPr><w:t>RJC</w:t></w:r> になりました。太字や用紙の大きさ（w:pgSz）は、文字とは別の印として保存されます。 テキストエディタには、この印を保存する場所がありません。

また、grep -c 'こんにちは' sample.docx は0件でした。圧縮されているため、展開（unzip -p）してからでないと見つかりません。

.docxをテキストエディタで開くとどうなるか（vim・nanoの実物）

この節では、ワープロのファイルをテキストエディタで開いたときに何が見え、保存すると何が起きるかが分かります。

.docx をテキストエディタで開くと、ZIP のバイト列が記号の羅列として見えるだけで、本文は読めません。 vim で開いた画面です。

PK^C^D^T^@^@^@^H^@^E£]]­R¥<91><95>^A^@^@Ê^F^@^@^S^@^@^@[Content_Types].xmlµ<95>A
...
"sample.docx" [noeol][converted] 152L, 53908B                 1,1           Top

nano でも同じように PK^C^D^T^@... と表示され、下に [ Read 152 lines ] と出ました。

そのまま保存したら壊れるか

コピーした .docx を、何も変えずに保存して確かめました。

vim と nano はバイトをそのまま書き戻したため、末尾に改行が増えただけでした。読めない文字を置換文字に変えて保存するエディタでは壊れます。 再現したファイルは python-docx が zipfile.BadZipFile: Bad magic number for central directory で開けませんでした。

ファイルをバイトのまま見る道具は、関連記事「バイナリエディタとは｜使い方・おすすめとxxdで読む実例・戻し方」で扱っています。

文字コードの違いとテキストエディタでの注意（UTF-8・Shift_JIS・BOM）

この節では、同じ文字でも文字コードによってバイトが変わること、エディタで文字化けしたときの直し方が分かります。

文字コードは「文字を何番のバイトで表すか」の決まりです。 書いたときと違う文字コードで読むと、文字化けします。同じ2行を4つの文字コードで保存しました。

file は Shift_JIS を名指しせず「Non-ISO extended-ASCII text」と判定しました。BOM の無いファイルの文字コードは、中身から推測するしかありません。 エディタが推測を外すと文字化けします。

vim で Shift_JIS が化けたときの直し方

設定ファイルを読まない vim（--clean）で Shift_JIS のファイルを開くと、次のように化けました。

<82>±<82>ñ<82>É<82>¿<82>Í<81>ARJC<81>B
2<8d>s<96>Ú<82>Å<82>·<81>B
"sjis_crlf.txt" [converted][dos] 2L, 52B
:set fenc? ff? fencs?
  fileencoding=latin1
  fileformat=dos
  fileencodings=ucs-bom,utf-8,default,latin1

vim は fileencodings の順に試し、合わなかったため latin1 で読んでいました。文字コードを指定して開き直すと直りました。

:e ++enc=cp932
こんにちは、RJC。
2行目です。
"sjis_crlf.txt" [converted][dos] 2L, 44B

:set fenc=utf-8 ff=unix
:w
"sjis_crlf.txt" 2L, 42B written
$ file sjis_crlf.txt
sjis_crlf.txt: Unicode text, UTF-8 text

BOM 付きのファイルは :set bomb? が bomb と表示され、:set nobomb で外して保存できました。

nano は UTF-8 として読む

nano 7.2 で同じ Shift_JIS のファイルを開くと、�����ɂ��́ARJC�B と化けました。nano には文字コードを選んで開く機能が無いため、先に iconv -f CP932 -t UTF-8 で変換してから開きます。VS Code は、ステータスバーの文字コードの表示を押すと、別の文字コードで開き直す・保存することができます（公式ドキュメント「Basic Editing」）。BOM 付き UTF-8 は正しく表示され、そのまま保存すると BOM も CRLF も残りました（保存後も ef bb bf で始まっていた）。

Shift_JIS に無い文字

$ cat ext.txt
ハシゴの髙と①と🍣
$ iconv -f UTF-8 -t SHIFT_JIS ext.txt
iconv: illegal input sequence at position 12
$ iconv -f UTF-8 -t CP932 ext.txt
iconv: illegal input sequence at position 24

Shift_JIS は「髙」で、Windows の拡張を含む CP932 は絵文字で止まりました。新しく作るファイルは UTF-8 にそろえると、この問題を避けられます。文字化けの原因は、関連記事「UnicodeDecodeErrorの原因と直し方｜cp932・utf-8・BOM」で扱っています。

改行コード（CRLF・LF）とテキストエディタの扱い

この節では、改行コードの違いと、エディタで見分ける・変える方法が分かります。

改行は、Windows では CR＋LF（0d 0a）、Linux・macOS では LF（0a）の2バイトか1バイトで保存されるのが一般的です。 見た目は同じでも、バイトが違います。

nano で CRLF のファイルを保存すると、欄が File Name to Write [DOS Format]: nb.txt になり、CRLF のまま保存されました。cat -A では LF が $、CR が ^M で見えます。

Git で改行コードがそろわない問題は、関連記事「Git改行コード設定｜autocrlfと.gitattributesの違い」で扱っています。

プログラムをワープロや設定違いのエディタで書くと起きるエラー（原文）

この節では、ワープロ由来の文字や、BOM・CRLF が入ったファイルを動かしたときに出るエラーの原文が分かります。

ワープロは「"」を全角の「“ ”」に変えることがあります。 手元で動かした結果です。

$ python3 q.py          # print(“hello”)
  File "/srv/s4/r17/t36/q.py", line 1
    print(“hello”)
          ^
SyntaxError: invalid character '“' (U+201C)

$ python3 z.py          # 行頭に全角スペース
  File "/srv/s4/r17/t36/z.py", line 2
    　print(x)
    ^
SyntaxError: invalid non-printable character U+3000

$ ./bom.sh              # 先頭に BOM がある bash スクリプト
./bom.sh: line 1: #!/bin/bash: No such file or directory
hi

$ ./crlf.sh             # 改行が CRLF の bash スクリプト
/bin/bash: line 1: ./crlf.sh: cannot execute: required file not found

$ python3 -c "import json;json.loads(open('b.json',encoding='utf-8').read())"
json.decoder.JSONDecodeError: Unexpected UTF-8 BOM (decode using utf-8-sig): line 1 column 1 (char 0)

$ node -e "JSON.parse(require('fs').readFileSync('b.json','utf8'))"
SyntaxError: Unexpected token '', "{"a":1}" is not valid JSON

CRLF のスクリプトのエラーは、bash の版によって bad interpreter: ^M とも表示されます。直し方は関連記事「bad interpreter: ^Mの直し方｜改行コードCRLF」で扱っています。

テキストエディタの選び方（6つの観点）

この節では、テキストエディタを選ぶときに確かめる観点と、大きなファイルを開いたときの実測が分かります。

1. 1使う OS に対応しているかWindows だけ・Mac だけの製品がある。サーバーなら端末で動く vim・nano
2. 2用途に合う機能があるかプログラムなら色分け・補完・拡張機能、文章なら文字数・縦書き・Markdown
3. 3日本語と文字コードの扱い画面の日本語化、Shift_JIS の自動判定、文字コード・改行コード・BOM の指定
4. 4大きなファイルを開けるかログや CSV を開くなら、開く速さとメモリを見る
5. 5価格と、会社で使う条件無料でも利用条件は製品ごとに違う。有料は試用期間のあとに購入
6. 6入手元と更新、AI 機能のデータの扱い公式サイトかストアから入れる。AI の拡張は、どのデータが外に送られるかを確かめる

大きなファイルを開いたときの実測（vim・nano）

1行96バイトのログを100万行（96,000,000バイト）作り、vim と nano で開いて、読み込み完了の表示が出るまでの時間と、そのときのメモリ（RSS）を3回ずつ測りました（tmux の画面を20ミリ秒ごとに確かめた値）。

小さなファイルでは nano が軽く、96MB では vim が速く、メモリも少なく済みました。ログを開く用途なら、使う予定の大きさのファイルで試してから決めると確実です。

テキストエディタおすすめ8製品の比較表（公式情報・2026年10月29日時点）

この節では、よく使われる8つのテキストエディタの価格・対応OS・最新版を、公式の情報で比べられます。

表の値は、2026年10月29日に各製品の公式サイト・公式の配布ページで確かめたものです。 最新版の番号は更新で変わるため、入れる前に公式サイトで確かめます。

• VS Code：公式 FAQ に「VS Code is free for private or commercial use」とあります。ソースコードは MIT ライセンス、配布される製品には Microsoft のライセンスが付きます。
• サクラエディタ：Ver.2.4.3 で動作環境が Windows 10 以降になり、Windows 7/8.1 のサポートが終わりました。
• CotEditor：7.1.0 で動作要件が macOS Tahoe 26 以降になりました。
• Vim・nano：この環境（Ubuntu 24.04）のパッケージは Vim 9.1・nano 7.2 で、公式の最新版より前の版でした。

Windows のメモ帳は Windows に付属しているため、表から外しています。VS Code の入れ方と日本語化は、関連記事「VSCode日本語化の方法｜拡張機能1つで切り替える手順と直らない時の対処」で扱っています。

vimの使い方（最低限の操作とこの環境での実物）

この節では、初めて vim を開いたときに、書いて・保存して・終わるまでの操作が分かります。

vim には「ノーマルモード（操作）」と「挿入モード（文字を書く）」があり、起動直後はノーマルモードです。 そのまま文字を打っても入力されず、命令として扱われます。

手元で、書いたあと保存せずに :q を打つと、次のエラーで止まりました。

E37: No write since last change (add ! to override)           1,9           All

「変更を保存していない」という意味です。:wq で保存した memo.txt は、cat -A で hello vim$ でした。

設定ファイルを汚さずに試すなら、vim --clean -i NONE で起動すると、ホームの .vimrc を読まず、履歴の .viminfo も書きません。モードごとのコマンドは、関連記事「vimコマンド一覧｜モード別早見表と置換・マクロの実行結果つき」で扱っています。

nanoの使い方（最低限の操作とこの環境での実物）

この節では、nano で書いて保存して終わる操作と、画面の記号の読み方が分かります。

nano は起動するとすぐ文字を書けて、使えるキーが画面の下に並んでいます。 ^ は Ctrl、M- は Alt（Meta）のことです。

  GNU nano 7.2                       memo2.txt
                                  [ New File ]
^G Help      ^O Write Out ^W Where Is  ^K Cut       ^T Execute   ^C Location
^X Exit      ^R Read File ^\ Replace   ^U Paste     ^J Justify   ^/ Go To Line

「hello nano」と打って Ctrl+X を押すと、保存するかを聞かれました。

Save modified buffer?
 Y Yes
 N No           ^C Cancel
（Y を押す）
File Name to Write: memo2.txt
^G Help             M-D DOS Format      M-A Append          M-B Backup File
^C Cancel           M-M Mac Format      M-P Prepend         ^T Browse
（Enter を押す）
$ cat -A memo2.txt
hello nano$

• 1vim か nano かは、最初の画面で分かる下にキーの一覧が出ていれば nano、~ が並ぶだけなら vim
• 2Git のコミットで開くエディタは変えられる環境変数 EDITOR や git config core.editor で nano などに変える

よくあるエラー・つまずき（原文つき）

この節では、テキストエディタまわりで出るエラーや表示と、その意味・直し方が一覧で分かります。

テキストエディタの判断表（用途別）

この節では、やりたいことから、どの種類のエディタを候補にするかが分かります。

8製品のどれが上ということはなく、OS と用途で候補が2つほどに絞れます。 表は、公式の情報で確かめた対応OS・価格と、ここまでの実物をもとにした目安です。

よくある質問

Q. テキストエディタとは何ですか？ A. 文字だけでできたファイル（.txt・ソースコード・設定ファイルなど）を作って直すソフトです。文字の大きさや色などの書式は保存しません。

Q. テキストエディタとメモ帳の違いは何ですか？ A. メモ帳も Windows 付属のテキストエディタの1つです。ほかのテキストエディタには、正規表現の置換・複数ファイルの検索・色分け・マクロ・拡張機能など、プログラムや大量の文章を扱う機能が加わっています。

Q. テキストエディタと Word の違いは何ですか？ A. Word は文字と書式をまとめて .docx（ZIP の中に XML）で保存します。同じ2行で、.txt は42バイト、.docx は36,430バイトでした。プログラムや設定ファイルは Word ではなくテキストエディタで書きます。

Q. 無料で使えるテキストエディタはどれですか？ A. 比較表の8製品では、VS Code・サクラエディタ・Notepad++・mi・CotEditor・Vim・nano が無料です。秀丸エディタは試用のあと 4,400円（税込）です。会社で使うときは、各製品の利用条件を公式サイトで確かめます。

Q. 初心者におすすめのテキストエディタは？ A. プログラミングを学ぶなら、3つの OS で同じ操作になる VS Code が候補です。文章が中心なら、国産の製品（Windows はサクラエディタ・秀丸、Mac は mi・CotEditor）が候補です。

Q. 文字化けしたときはどうしますか？ A. 文字コードを指定して開き直します（vim は :e ++enc=cp932）。直ったら UTF-8 で保存し直します。

Q. BOM 付きと BOM 無しの UTF-8 はどちらで保存しますか？ A. プログラム・JSON・シェルスクリプトは BOM 無しにします。手元では BOM 付きの JSON を Python と Node.js が読めず、シェルスクリプトもシバンが働きませんでした。

Q. vim から抜けられません。 A. Esc を何回か押してから、:q!（保存しない）か :wq（保存する）を打って Enter です。E37 が出たら、保存していない変更があります。

Q. .docx をテキストエディタで開いて直してもよいですか？ A. テキストエディタでは直せない形式です。中身は圧縮された ZIP で、本文は読めません。読めない文字を置換して保存するエディタでは壊れることを手元で確かめました。

まとめ

• テキストエディタは文字だけのファイルを作って直すソフト。メモ帳もその1つで、ほかの製品は検索・置換・色分け・拡張機能などが加わる。
• Word は書式ごと保存する。同じ2行で .txt は42バイト、.docx は36,430バイト（ZIP の中に XML が17ファイル）だった。
• 文字化けは文字コードの読み違い。vim は :e ++enc=cp932 で開き直し、:set fenc=utf-8 ff=unix で UTF-8・LF に保存できた。
• 全角の引用符・全角スペース・BOM・CRLF は、Python・Node.js・bash でエラーになる。原文の U+ の番号で正体が分かる。
• 選び方は OS・用途・日本語・ファイルの大きさ・価格と利用条件・入手元の6点。8製品の価格・対応OS・最新版は2026年10月29日時点の公式情報。

参考・出典

確認日はいずれも 2026年10月29日です。

• Visual Studio Code「Updates」：https://code.visualstudio.com/updates
• Visual Studio Code「Requirements」：https://code.visualstudio.com/docs/supporting/requirements
• Visual Studio Code「FAQ」：https://code.visualstudio.com/docs/supporting/faq
• Visual Studio Code「Basic Editing」：https://code.visualstudio.com/docs/editing/codebasics
• サクラエディタ「Releases」（GitHub）：https://github.com/sakura-editor/sakura/releases
• 秀丸エディタ：https://hide.maruo.co.jp/software/hidemaru.html ／ 価格表：https://hide.maruo.co.jp/swreg/price.html
• Notepad++「Releases」（GitHub）：https://github.com/notepad-plus-plus/notepad-plus-plus/releases
• mi 公式サイト：https://www.mimikaki.net/
• CotEditor「Releases」（GitHub）：https://github.com/coteditor/CotEditor/releases
• Vim 公式サイト：https://www.vim.org/ ／ ダウンロード：https://www.vim.org/download.php
• GNU nano 公式サイト：https://www.nano-editor.org/ ／ News：https://www.nano-editor.org/news.php
• Microsoft Command Line「Introducing extended line endings support in Notepad」（2018年5月8日）：https://devblogs.microsoft.com/commandline/extended-eol-in-notepad/
• Windows Insider Blog「Text formatting in Notepad begin rolling out to Windows Insiders」（2025年5月30日）：https://blogs.windows.com/windows-insider/2025/05/30/text-formatting-in-notepad-begin-rolling-out-to-windows-insiders/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。