こんばんは、寒暖の差が激しい日が続きますが、確実に春が近づいているのを感じているWebプログラマーの篠田です。
以前にお話させて頂きました「Web制作で絶対に使ってはいけないエディタ！」で文字コードが重要というお話をしましたが、使ってはいけないエディタ以外でも油断していると罠に引っかかり、文字化けに苦しむというお話をご紹介したいと思います。
テッパン文字コード「UTF-8」
実はWebブラウザで日本語が取り扱える文字コードというのは４種類あります。
簡単にご紹介していきましょう。
創世記に活躍した過去の人「Shift-JIS」
むかしむかし、iPhoneが存在していないWeb界隈でメジャーに使われていた日本語を取り扱える文字コードです。
Microsoft製品の基本文字コードとして現在もExcelなどではよく見かけますが、最新のHTML5などで作られているWebページではまず見かけなくなった過去の人。
文字化けの温床にもなるやっかいな文字コードとして有名。
そして、特殊文字（①㈱など）が確実に文字化けをすることでも有名。
また、ガラケーの基本文字コードでもあったのでプログラマーとして何度、苦汁を飲まされたことか。。。
絶対選んではいけない文字コード不動の「No.1」
PHP４時代にこの文字コードで作っていました「EUC-JP」
PHP7がリリースされて３ヶ月あまりですが、その昔まだ「PHP4がでたー！！」とか騒いでいた時に使っていたのは「EUC-JP」でした。
プログラムは「EUC-JP」、HTMLは「Shift-JIS」という今考えるとなんとも頭の悪い組み合わせがデフォルトだった時代がありました。
プログラムを扱う文字コードとしては楽な文字コードでしたが、常に文字コード変換を使わないいけない面倒くささに辟易していたのもいい思い出です。
メールの文字コードといえば「ISO-2022-JP」またの名を「JISコード」
現在でこそ、いろいろなメーラーがありますが、10年ほど前はMicrosoft大帝国時代。
その当時は今は亡き「Outlook Express」か「Outlook」が主流で、プログラムからメールを送信するときはこの「ISO-2022-JP」にして送信しないと文字化けがするという素敵仕様だったのでお世話になりました。
Webページを作るときにはまず使わない文字コードですが、現在でもブラウザの文字コード欄にはしっかりと「ISO-2022-JP」の名前が刻み込まれています。
日本語最強文字コード「UTF-8」
現在の主流文字コード。
特殊文字もアラビア文字も中国語、簡体字、ハングル文字なんでもござれの最強文字コード。
もちろん、HTMLもPHPもこの文字コード１つで文字化け無しで作れるので、文字コード変換なんて言うまどろっこしいことは一切しなくていいという幸せ体験ができるようになりました。
※Web業界歴6年以上ぐらいになると、これが幸せと思えるのですが。。。
なんだか、愚痴が４０％ぐらい含まれた文章になりましたが、日本語圏で使われている文字コードがどんなものがあるのかは何となくご理解いただけたかと思います。
そんな最強「UTF-8」にも１つ気をつけておかないと文字化けの恐怖に絶望する場合がありますので、見ていきましょう。
BOM（ボム）という地雷
文字コードを選択するときは「UTF-8」にすればいいんだね！と思ってくださいと言えれば簡単だったのですが、実はそうは行かない場合があります。
下記の画像はWindowsで使われているエディタの１つ「TeraPad」のプロパティ画面です。
何かおかしなところがありますね。
最強の「UTF-8」が２種類あるではないですか！？
実はエディタによっては「UTF-8」と「UTF-8N」の２種類が表示される場合があります。
ここで、先ほどの話ですが安易に「UTF-8最強！！！」と言って「UTF-8」を選んでしまうとBOMという地雷を盛大に踏み抜いてしまい、文字化けに悩まされます。
BOMの基本の「き」
正式名称を「バイトオーダーマーク（byte order mark）」といい、その頭文字を取って「BOM（ボム）」と言っています。
「BOM」は、プログラムがテキストデータを読み込むときに、事前にUnicodeで表現されたテキストデータであるということを示すため数バイトの【見えない文字】のことをいいます。
昔のMac（この場合はMacintoshをさす）と昔のWindows（この場合はMS-DOSをさす）の間で正常なUnicode（UTF-8の大本みたいな文字コード）でのデータのやりとりをするためにはBOMが必要だった時代がありました。
※MS-DOSは本当はWindowsとは異なるOSであり別物。あくまでイメージとして昔のWindowsと表現してます。
また、XMLをUTF-16で表す場合は「BOM」は必須の設定になっていたりもします。
ただ、現在においてこの「BOM」を必要とする機会は殆ど無く、特に「UTF-8」においてはBOMがなくても動作するよう作られており、逆にBOMがあることで文字化けのリスクを負うようになります。
なので最強と呼んでいる「UTF-8」というのは「BOMなし」の「UTF-8」のことを指します。
上記を踏まえて先ほどの「UTF-8」と「UTF-8N」どちらが「BOMなし」でしょうか？
正解は「UTF-8N」が、最強「UTF-8」になります。
この「UTF-8N」というのが「BOMが付いていないUTF-8」のことを指します。
ただし、最近主流のエディタには「UTF-8N」などという表記は殆ど見かけません。
日本製のエディタの一部でその生存を確認する程度になっています。
※「TeraPad」がその貴重なエディタの１つといえます。
エディタによっては「BOM」という項目をチェックボックスで選択できるようになっています。
もし、このチェックボックスにチェックが入っているときは、ソッと外して保存しましょう。
ここが怖いよ「BOM付きUTF-8」
さて、BOMというものを知った上で、BOM最大の恐怖についてご紹介しておきましょう。
実は、最近のエディタでは、ぱっと見ただけでは「BOM付き」か「BOMなし」かが分からないというものがあります。
例えば、Macのエディタ「CotEditor」には「BOM」の設定がそもそも無かったりして
「BOM付き」であっても「BOMなし」として認識します。
これの怖いところは、間違って「BOM付き」で保存したファイルで文字化けをしていても、「BOM」をスルーするエディタでは「UTF-8」としか表示されないので「BOM」が原因であることに気づきにくいという点です。
なので「あれ？UTF-8なのに文字化けしている！？」という現象に遭遇したらとりあえず再度UTF-8で保存しなおせばBOMが消えてくれて問題が解決するはずです。
BOM付きが無双するとき
最後に、厄介者のBOMですが、これが活躍する場面が実はあります。
それは、CSVファイルをPHPなどで作る場合です。
通常、CSVはMicrosoft Excelで開くことがほとんどだと思います。
※KINGSOFT Officeを使っているとかは少数派なので無視！
Microsoft Excelの標準文字コードは「Shift-JIS」で、「UTF-8」でCSVを作るとバッチリ文字化けします。
そのため、CSVをわざわざ「Shift-JIS」に変換して書き出したりしていましたが、実はMicrosoft Excelは「UTF-8」を認識することができます。
そう、「BOM付き」であればね。
Microsoft Excelは良く言えば「真面目」、悪く言えば「融通が利かない」という感じで文字コードを認識しています。
そのため、BOMなしでは正しくUTF-8と認識できず標準の「Shift-JIS」で文字を解釈してしまい、文字化けしてしまいます。
しかし、「BOM付きUTF-8」としてCSVを書き出せば、あら不思議。文字化けせずにExcelで開くことができます！
※具体的なコードはまた別の機会に。
まとめ
最強のUTF-8を使いこなすには「BOM」の存在を理解していないと突然文字化けという地雷を爆発させてしまう恐れがありますが、原因さえわかっていれば対処は容易なはずです。
すこしでも、BOMで爆発する不幸なWeb関係者が減ることを祈っております。
現場の業務フローに寄り添ったWebシステムをお求めなら、私たちALAKIにご相談ください。
ALAKIは経営者様が感じている問題点と、実際にWebシステムを利用される現場スタッフ様が直面している課題を、弊社システムエンジニアが丁寧に聞き取り、お客様と共にシステムを作り上げていきます。
業務改善が実現できるWebシステムをお求めの方は、是非ALAKIにご相談ください。
