shift-jis と utf-8 の混在問題に関する記事(リンクリスト)に戻る
Windows は当初 ‘shift-jis’ という文字コードで日本語に対応していた。
Mac も昔は ‘shift-jis’ に対応していた。
Linux は ‘euc-jp’ という文字コードで日本語に対応していた。
‘shift-jis’ や ‘euc-jp’ は日本の文字コードで中国や韓国や台湾やタイなど他の国の文字には対応していない。
他の国では、それぞれその国の文字コードを用意して母国語に対応していた。
英数字と一部の記号(!,#,$,%,& など)だけは、ASCIIコードという規格でどの国でも使用できる。
ASCIIコード以外の文字は各国でバラバラに実装されていた。
しかし近年は世界標準規格の Unicode の実装方法の一つである UTF-8 を標準的文字コードとして対応している。
Unicode はその文字コードの中に全ての国の文字を定義しており、これに対応していれば世界のどの国のOSでも、世界中の国々の文字を扱う事ができる。
この変更は Mac や Linux に置いても同様で、全ての OS において UTF-8 だけでテキストの交換ができるように変更されたわけだ。
しかし、Unicodeは新しい文字コードなので、Windows,Mac,Linux の、どのOSにでも「古いデータ」や「古いシステム」を扱うときは昔使用していた shift-jis や euc-jp を扱う必要がある。
特に Windows は昔から 互換性を大事にする OS で、過去のデータやソフトウェアが確実に使えるように、古い機能系を残している。
代表的な古い機能は cmd.exe というシェルで、俗に言う「コマンドプロンプト」の事だ。
コマンドプロンプトは shift-jis しか扱えない。
UTF-8 を表示しようとすると文字化けする。
検索も編集も標準機能では UTF-8 には対応していない。
コマンドプロンプトは旧システムとの互換性の為だけに残されている機能なので、Microsoftも将来的にコマンドプロンプトを UTF-8 に対応させる可能性はほぼない。
今後は Windows のシェルは Power Shell が主体になる。こちらは Unicode に対応している UTF-8 だけではなく UTF-16, UTF-32 にも対応している。
昔の OS は、電子メールは jis を、テキストの処理は shift-jis,euc-jp を使用していた。 今は、全て utf-8 を中心に 一部は utf-16,utf-32 を適正に合わせて使い分ける。
Windows環境で使用できる文字コード
現在の Windows 10 において、代表的なコマンドやツールで、それぞれどの文字コードが使用でき、どの文字コードが使用できないのか、簡単に調べてみた。
文字コードが良く分からない人は以下の記事をどうぞ。
日本語文字コード(utf,shift_jis,eucとBOM:encoding)を一気に解説する
cmd.exe(コマンドプロンプト)
cmd は そこで使用できる dir,type,cd など標準コマンド全てで shift-jis しか使用できない。 .bat ファイルなどのスクリプトファイルも同様である。
utf-8 など Unicode には全く対応していない。
また、これから対応する事もないだろう。
Windows は標準シェルを Power Shell に置き換える方針なので、cmd は通常はスタートメニューに公開していない。
[Win]+[S]キーを押下して cmd.exe を検索すると起動できる。
findstr
コマンドプロンプトで UNIX の grep のような検索ができるコマンドに ‘ findstr ‘ がある。 このコマンドも shift-jis のテキストだけしか検索対象にしない。
utf-8,utf-16LE など Unicode のテキストファイルは無視される。
現在の Windows 10 のテキスト環境は utf-8 で統一されており、標準的なテキストファイルを扱うと findstr では検索できない事になる。
メモ帳
Windows 標準のテキストエディタである ‘ メモ帳 ‘ は、複数の文字コードに対応している。
しかし新規作成は BOMなしの utf-8 しか保存できない。
他の文字コードを選択する事はできない。
shift-jis のテキストファイルを新規作成する事もできない。
読み込む事かできる文字コード(encoding)を以下に示す。
jis 不可(文字化けする)
shift_jis 編集可能
euc-jp 不可(文字化けする)
BOM有り_utf-8 編集可能
BOM有り_utf-16LE 編集可能
BOM有り_utf-16BE 編集可能
BOM有り_utf-32LE 不可(BOM_utf-16LEと誤認する)
BOM有り_utf-32BE 不可(文字化けする)
BOMなし_utf-8 編集可能
BOMなし_utf-16LE 不可(文字化けする)
BOMなし_utf-16BE 不可(文字化けする)
BOMなし_utf-32LE 不可(文字化けする)
BOMなし_utf-32BE 不可(文字化けする)
編集可能なテキストに関しては、読み込んだ文字コード(encoding)を維持したまま編集し保存できる。
shift-jis のテキストを開き、編集して保存しても shift-jis のままである。
shift-jis のテキストを新規作成する場合は cmd で
echo dummy > text.txt
というコマンドを実行してやると shift-jis のテキストファイルを作成出来る。
後はこれを「メモ帳」で編集すれば shift-jis のテキストファイルを編集できる。
私は「秀丸」を使用するからこんなことはしないが。
Power Shell
Windows 10 の標準シェルは cmd.exe(コマンドプロンプト) から ‘ Power Shell ‘ に置き換えられた。
今後はバッチファイル(.bat や .vbs)などのシェルスクリプトも ‘ Power Shell ‘ の「.ps1」に置き換えられていく。
Power Shell は version 6.2 以降なら、.NET Framework や .NET Core で扱える全ての文字コードに対応できる。
世界中のほぼ全ての文字コードに対応できると思って良い。
最新の Power Shell の version は、7.0 である。
旧 version 5.1 (画面の青いやつ)を使用している人も多いと思うが、v5.1 では、shift-jis,euc-jp などは使えない。 最新版をダウンロードしてインストールしてください。
Power Shell は複数バージョンが共存可能なので、既存アプリケーションとの互換性を気にする必要はないです。
PowerShell/Get-ChildItem|Select-String
ちなみに PowerShell で、shift-jis コードを grep や findstr のように検索する時は以下のようにする。
Get-ChildItem -Path ".*.txt" -Recurse | Select-String -Pattern '国債発行' -Encoding "shift_jis"
Get-ChildItem がテキストファイルを検索して、その内容を全て標準出力に出力する。
それをパイプで繋いで Select-String に渡し、-Pattern で指定した文字列を含む行だけを標準出力に出力する。
-Encoding で指定した文字コード(encoding)を主な処理対象とする。
但し、BOM付きUnicodeテキストは無条件で検索対象に含まれる。
PowerShell で、shift-jis コードを扱う時必要になるだろう。
WSL2(Ubuntu 18.04)
WSL とは、Windows Subsystem for Linux の略で、Windows 10 上で Linux を使用できるWindowsの新機能だ。
最新バージョンは 2 で、Windows 10 の 2004 アップデートから使用可能になった。
これを ‘ WSL2 ‘ と呼ぶ。
WSL2 では複数の Linux ディストリビューションに対応している。
取りあえず、WSL2 の Ubuntu18.04 で文字コード対応を試してみた。
WSL2 の Ubuntu では bash から
cd /mnt/c
と入力すると Windows の C: を参照することができる。 ファイルの編集やフォルダー作成も可能だ。
/mnt の配下にドライブレターが並ぶ。
D: のある人は、/mnt/d が有るだろう。
ここで、grep コマンドを使用して、Windowsファイルの様々な文字コードのテキストを検索してみた。
結果としては、BOM有無両方の utf-8 だけを検索対象にし、それ以外は無視された。 shift-jis も euc-jp も検索できない。
utf-16LE.BE も検索できない。
これは Ubuntu が utf-8 だけを編集対象にしているからだろう。
Linux ディストリビューション次第なのだと思う。 コマンドやアプリにもよると思うが、Ubuntu では utf-8 以外は扱えないと考えるべきだろう。
Ubuntu の vim も試してみたが、utf-8 はBOMの有無にかかわらず編集可能。 utf-16LE も編集可能だった。
しかし shift-jis も euc-jp も utf-16BE も文字化けして閲覧できなかった。
utf-8 以外は扱わない方が良いと思う。
NTFS と Windows System 基幹部
Windows のシステム内部で使用しているエンコーディングは utf-16LE で統一されている。
ファイルシステムの NTFS も utf-16LE を使用している。
Excel など MS-Office の内部文字コード(encoding)も utf-16LE を使用している。
例えば VBA で文字列を作成すると Excel 内部では utf-16LE を使用している為、文字数が1文字なら、バイト数は2バイトだったりする。
もし shift-jis なら ASCII 7bitコードは 1バイトになるはずである。
インテルCPUも伝統的に LE なので、 utf-16LE の方が扱い安く、処理速度も高速になるはずである。
バイト数なども utf-16LE はシステム的に数えやすい。
秀丸
秀丸はエンコードを指定すればどの文字コード(encoding)でも読み取れる。
自動判定もそこそこ正確だ。
BOMなし utf-32 などは誤読するが、手動で指定してやれば編集できる。
新規作成するとデフォルトで shift_jis になる。 保存する文字コードは自由に選択できる。
秀丸 grep
秀丸 grep は、
BOM有りなら utf-8, utf-16LE, utf-16BE, utf-32LE, utf-32BE すべて検索する。
shift-jis, jis, euc-jp も検索し、BOMなし utf-8 も検索してくれる。
かなり優秀だ。
当たり前の事だが、BOMなしの utf は自動では検出できない。
VS-CODE
BOM有りなら utf-8, utf-16LE, utf-16BE は編集できる。
utf-32 は編集できない。
BOMなしは、utf-8 だけ編集できる。
当たり前の事だが、BOMなしの utf は自動では検出できない為、編集以前に認識できない。
shift-jis, euc-jp は自動検出でき、編集可能である。
jis は編集できない。
VS-CODE は Linux 対応しているので euc-jp も編集対象にしているのだろう。
新規作成するとBOMなしの utf-8 になる。 保存する文字コードは選択できない。
vim (Windows版)
BOMの有無に関係無く utf-8, utf-16 を正確に識別し、編集可能だ。
utf-16 は LE も BE もどちらも対応している。
jis, shift-jis, euc-jp も正確に識別し、編集可能だ。
utf-32 は編集できない。
Windows版 vim はかなり優秀である。
Excel による CSV 編集
Excel は標準では shift-jis と utf-16LE に内部で対応している。
VBA など使用するとそれが明白になる。(これは後で解説する)
しかし、CSV ファイルの入出力は、必ずしもExcel 標準には従っていない。
ユーザーの都合と Windows の仕様に合わせて、shift-jis と BOM有りutf-8 に対応している。
Excel は元々、shift-jis の CSV をサポートしていた。 Excel 2013 以前のバージョンでは shift-jis の CSV しか扱う事ができない。
Excel 2016 以降、 BOM有りutf-8 の CSV を読み書きできるようになった。
Excel365 も同様である。
CSVファイルは BOM のあるテキストファイルを utf-8 と解釈し、 BOMなしテキストファイルを shift-jis と解釈する。
業務システム開発などでは、BOM により文字コード(encoding)をキチンと管理しなければならない。
utf-16,utf-32 の CVS はサポートしていない。 shift-jis と BOM有りutf-8 だけサポートしている。
Excel VBA
Excel は標準では shift-jis と utf-16LE に内部で対応している。
VBA の中のソースコードでは、他の文字コード(encoding)は未対応である。
VBScript(WSH)
各文字コードで動作確認した結果は以下になる。
shift-jis 正常動作する
jis 文字化け動作する
euc-jp 文字化け動作する
utf-8_BOMなし エラーで動かない
utf-8_BOM有り エラーで動かない
utf-16LE_BOMなし 正常動作する
utf-16BE_BOMなし 正常動作する
utf-16LE_BOM有り 正常動作する
utf-16BE_BOM有り エラーで動かない
utf-32LE は全部 エラーで動かない
utf-32BE は全部 起動もしない
正式対応しているのは
shift-jis
utf-16LE_BOMなし
utf-16LE_BOM有りだけろう。
utf-16BE_BOMなし は偶然動いているだけだと思う。
utf-16LE は Windows 内部の標準文字コードなので、動作するのだと思う。
shift-jis は、WSH が登場した当時の Windows 標準文字コードである。
VBScript(WSH) の全てが、shift-jis でコーディングされているはずだ。
VBScript(WSH) は、cmd や .bat と同様、過去の製品である。
将来 utf-8 に対応する見込みはない。
ADO
Excel(Access) VBA や、VBScript(WSH) で、shift-jis, utf-16LE 以外の文字コードのファイルを入出力する場合は ADODB.Stream を使用してコード変換して対応する。
ADO は以下のレジストリに登録してある文字コードが使えるらしい。
HKEY_CLASSES_ROOTMIMEDatabaseCharset in the Windows Registry.
ADO は大半の文字コードに対応できる。
主用 RDB(DBMS)
Oracle
SQL Server
PostgreSQL
MySQL
などの主用なRDB(DBMS)は全て、主要な文字コードに対応している。 shift-jis, euc-jp, utf-8 は、問題なく使用できる。 utf-16 も対応している物もある。
ただ utf-8 は、nvarchar, nchar などのように変数型が異なる扱いになっている事が多いので、注意が必要である。
扱い方は DBMS ごとに異なるので、それぞれのマニュアルを参照されたし。
DBMS の内部では、utf-32 を使用している事が多いはずなので、Unicode 対応に問題はないはずである。
オンラインバンク・クレジットカード
三井住友銀行のオンラインバンクは shift-jis の CSVをダウンロードする。
クレカの 三井住友VISA, dカード, cedinaカードも全部 shift-jis の CSVをダウンロードする。
マネーフォワードも shift-jis だった。
世間一般に、会計系の CSV 出力ファイルは、まだまだ shift-jis が主流のようだ。
古いバージョンの Excel を使用しているユーザーも多いので、utf-8 のCSVには移行し難いのだろう。
Excel 2013 以前のバージョンを使用しているユーザーはまだまだ多い。 Excel 2013 以前のバージョンでは utf-8 の CSV ファイルを読み込めない。
まとめ
Windows環境の文字コードの混在はかなり不便な状況だ。
cmd や Excel の古いバージョン はまだまだ使われているし、すぐには無くならない。
cmd は shift-jis にしか対応していないし、将来対応するとも思えない。
Windows は utf-8 を標準とする改修を行っているが、社会がすぐには utf-8 に対応できない。
Windows の Microsoft は互換性を大切にする会社なので、ユーザーの古い情報資産を廃棄したりしない。
昔からそうだった。
MS-DOS のソフトウェアやデータ資産だって、長い間 Windows で使用できていた。
16bit の MS-DOS版の「一太郎」が、32bit の Windows95 でも動いていたからね。
相当、無茶して互換性を補償していたのだろう。
本来、16bit のアプリが、32bit の OS で動くはずがないのだ。
この辺に Microsoft らしさが現われている。 これからもそうだろう。
一方 WSL2 が本格導入されるが、Linux は大半が、utf-8 にしか対応していない。 shift-jis のテキストは無視される。
Mac は以前は shift-jis に対応していたが、今は全て utf-8 に統一されている。
Linux も Mac も過去の資産をアッサリ捨てて、utf-8 に完全対応しているのだ。 Windows も対応しなければ取り残されてしまう。
しかし、Windows は最も普及したOSで有るが故に、文字コードの全面変更ような抜本的規格の変更が最も難しい立場にいる。
shift-jis から utf-8 への変更は、難しいだろう。 特に、ユーザーが使用する文字コードの規格を変更するのが難しい。
Excel で今まで使用してきた、shift-jis の CSVを全部 utf-8 に変更するとなると、簿記会計を担当してきた人達は悲鳴を上げるかも知れない。
shit-jis と utf-8 をシームレスに共存しながら移行できれば良いのだが、cmd から Power Shell への新技術移行のどさくさ紛れに一気に移行しようとするから、結果的に cmd系の処理の残留という中途半端な状況に陥っている。
cmdを utf-8 に対応した方が早いのではないかとも思ってしまう。
Windows 環境で完全に shift-jis から utf-8 へ移行を完了するのはかなり先の話になると思う。
オンラインバンクやクレジットカードの会社が未だに shift-jis をメイン文字コードにしているのだから、一般企業が utf-8 に移行できるわけがない。
企業のITシステムはしばらく shift-jis で作られ続けるのではないかと思われる。
今まで、あまり気にしてこなかったが、意外な障害を発見してしまった気がする。
この問題は、もう少し考えてみたいと思う。
また、文字コード問題をテーマに次の記事を書くと思う。
しばらく付き合って欲しい。
