linux_1

「Linuxのキーボードで¥（円記号）キーを押したのに、画面にはバックスラッシュ（\）が出てしまう」
「ファイルパスをコピーしたら C:\Users が C:¥Users に化けて、別物に見える」
Linuxを触り始めた人がほぼ全員ぶつかる、地味だけど気になる現象です。

この記事では、Linuxで ¥（円記号）を入力するとバックスラッシュ \ として表示される理由と、SSHターミナル接続とコンソール接続での挙動の違い、Windowsから移ってきた人がつまずきやすいポイントまでを整理します。
結論から言うと、これは「文字化け」でも「キーボードの故障」でもなく、設計上そうなる仕様です。

そもそも¥とバックスラッシュは同じ文字コード

キーボード上は別のキーに見える ¥（円記号）と \（バックスラッシュ）ですが、内部的には 同じASCIIコード「0x5C」 に割り当てられています。

ASCIIは1960年代にアメリカで策定されたコード体系で、0x5Cには元々 \（バックスラッシュ）が定義されていました。
1970年代に日本でJIS X 0201（半角カナを含む7ビット文字セット）が策定されたとき、ASCIIとの互換性を保ちつつ「日本独自の文字」を入れる必要があり、0x5Cに \ ではなく ¥ を割り当てる選択がされました。

つまり、内部のバイト列としては同じ「0x5C」が、表示するフォントによって \ に見えたり ¥ に見えたりするだけ、というのが現象の正体です。

SSHターミナル接続では¥に見えやすい

日常的にLinuxを操作するときは、Windows/MacからSSHクライアント（TeraTerm、PuTTY、Windows Terminal、iTerm2 など）でリモート接続するパターンが大多数です。

このときキーボードから打った文字も、画面に表示される文字も、すべてSSHクライアント側のフォントで描画されます。
Windowsの標準的な日本語フォント（MS Gothic、Yu Gothic、Meiryo など）は、0x5Cを ¥ として描く設定が一般的なので、¥キーを押すと画面に ¥ が出ます。


ターミナル画面

表示は ¥ でも、サーバー側のLinuxに届くデータは「0x5C」です。
シェルスクリプトでエスケープに使う \n（改行）も、Windowsからの入力では実体的には「0x5C + n」が送られているので、正しく改行として解釈されます。

コンソール接続だとバックスラッシュに見える

一方、Linuxサーバーに直接ディスプレイとキーボードをつないで操作する コンソール環境 や、仮想マシンのコンソール画面（VirtualBox／VMwareの直接表示、サーバーのIPMI/KVM-over-IP など）では、Linux側のフォントが描画に使われます。

LinuxのデフォルトコンソールフォントはASCII準拠で、0x5Cを \（バックスラッシュ）として描くものが多いです。
そのため、同じキーを押しても画面表示は \ になります。


コンソール画面

キーボードや日本語環境の設定が壊れているわけではなく、純粋に「描画フォントが違うだけ」です。

どちらでも動作上の問題はない

表示が ¥ でも \ でも、シェルやスクリプトの挙動は完全に同じです。
以下のようなコマンドはどちらの環境でも問題なく動きます。

・echo "Hello\nWorld"（バックスラッシュn でエスケープ）
・find . -name "*.txt" \;（行末バックスラッシュで改行エスケープ）
・cd /home/user/data（パス区切りに関与せず）

心配なときは、実際にバイト列を確認すれば「内部的に同じ文字」であることが分かります。
どちらも 0x5C で同一です。データとしては区別がつきません。

Windowsから移ってきた人がつまずきやすいポイント

1. Windowsのパスをコピペすると¥が混ざる
C:\Users\name\Documents をWindowsからコピーしてLinuxの設定ファイルに貼り付けると、Windowsの日本語フォントでは ¥ として記録されたものが、Linux側のエディタによっては別の表示になります。
しかし内部コードは同じ 0x5C なので、Linux のシェルや Perl／Python はバックスラッシュとして正しく解釈します。

2. JIS配列キーボードと US配列キーボードで打ち方が違う
日本語JIS配列の ¥ キーは、US配列キーボードにはありません。
US配列で同じ文字を打ちたい場合は、右上のバックスラッシュキー（Enterキーの上）を押します。
これも結局は「0x5Cを送る」キーなので、Linuxからは同じ入力として扱われます。

3. UTF-8の本物の「¥（U+00A5）」が入ると別物になる
Webブラウザや一部の日本語入力システムでは、「円記号」を Unicode の U+00A5（YEN SIGN、UTF-8だと 0xC2 0xA5 の2バイト）として入力する場合があります。
これはASCIIの 0x5C とは別の文字なので、シェルでエスケープに使うと意図通りに動きません。

0x5C 以外のバイト列なら別文字、と覚えておけば判別できます。

4. 「同じパスを書いたのに動かない」と感じる典型ケース
WindowsからメモしておいたファイルパスをLinuxに持ち込んだとき、見た目は C:¥Users¥name、Linuxでは C:\Users\name。書いた文字が違うから動かないのでは、と疑いたくなりますが、ほとんどは描画フォントの差だけでデータとしては同じです。
本当に動かない原因は見た目ではなく、UTF-8全角￥が混入したか、改行コードがCRLFのまま残っていたかのどちらかが大半です。

プログラミングフォントで¥と\を視覚的に区別する

ターミナルやエディタで ¥ と \ をはっきり描き分けたい場合、日本語対応の等幅プログラミングフォントを選ぶと迷いが減ります。Ricty、HackGen、Cica、Source Han Mono（源ノ等幅）などは、ASCII側の \ を素直にバックスラッシュとして描くため、コードとパス文字列を読み違えにくくなります。

VS Code なら settings.json の editor.fontFamily に「'HackGen', 'Consolas', monospace」のように並べておくと、シェルスクリプトを開いたときも \n のバックスラッシュが読みやすくなります。フォントを切り替えるだけで見た目の混乱は半分以上消えるので、手早い対処になります。

SSHクライアントごとの表示差と設定ポイント

同じサーバーにSSHでつないでも、クライアント側の設定で見え方は変わります。

PuTTY：「Window > Translation」の文字コードを UTF-8 に、フォントを Yu Gothic Mono などに変えると 0x5C は ¥ として描かれます。Consolas ならバックスラッシュ表示。

Tera Term：「設定 > 端末」の漢字コードを UTF-8 に揃え、日本語等幅フォントを選びます。古い設定でEUC-JPになっているとファイル名表示まで化けます。

Windows Terminal / iTerm2：プロファイルのフォントを「HackGen」「Cascadia Code」などに切り替えると 0x5C の描画が変わります。どのクライアントも届くバイトは同じで、違いは画面表示だけです。

本記事のまとめ

Linuxで¥がバックスラッシュに見える（あるいはその逆になる）のは、ASCIIコード 0x5C に対する フォント描画の違い だけが原因です。
データとしては同じバイト、シェルやスクリプトの動作も同じ。Windowsから移ってきた人が最初にぶつかる「あれ？」の正体はこの1点に集約されます。

状況	表示される文字	内部コード
SSHクライアント（日本語フォント）	¥	0x5C
Linuxコンソール（ASCIIフォント）	\	0x5C
UTF-8の本物の円記号	￥	0xC2 0xA5（別文字）
シェルエスケープ \n	環境次第	0x5C 0x6E

---

• 次のページへ：LinuxにもWindowsのようにマウス動作のみで動作するものと、コマンドでの動作のものがあるのでしょうか？
• この記事の属するカテゴリ：Linuxの質問へ戻る