社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

文字コード第八回:文字化け

文字コードって、とっても難しいです。

そんな文字コードの中で、悩まされることが多い文字化けの理解が深まるように解説します。

1.JIS X 0208 の拡張

なぜなのか理由はわかりませんが、JIS X 0208 には空き領域が大量にあります。

純粋な JIS X 0208 で使用している区は、1 〜 8 区、16 〜 84 区のみで、9 〜 15 区、85 〜 94 区の 17 * 94 = 1,598 文字のエリアが未使用となっています。

この未使用領域(主に 9 〜 15 区)を各コンピューターメーカーがそれぞれ統一することなく利用していたため、機種依存文字(環境依存文字)というものが登場しました。

あるコンピューターで表示できていた文字が、別のコンピューターだと表示できなかったり別の文字になってしまう問題です。

WindowsPCも昔はPCメーカーによって機種依存文字が異なりましたが、マイクロソフトが CP932 として統一したことで、Windows内では文字の統一がされました。

f:id:SystemEngineers:20210815124628p:plain

UTF-8が主流になってきた今でも、例えばWindowsでメールに「①」と書くと、Macでは「(日)」と表示されるなど、一部のソフトウェアでは機種依存文字の問題は残り続けています。

f:id:SystemEngineers:20210815125415p:plain

2.ASCⅡ と JISX 0201 問題

ASCⅡ と JISX 0201 は、2 文字が同じ文字コードで別文字になります。

有名な 5C と 7E です。

同じ文字コード 5C でも ASCⅡ は「 \(バックスラッシュ)」、JIS X 0201 は「 ¥(円記号)」です。7E の場合、ASCⅡ は「 ~(チルダ)」、JIS X 0201 は「 (オーバーライン)」です。

この差は例えば、EUC-JP( ASCⅡ )を使用している UNIX で「 \ 」と入力したのに、CP932( JIS X 0201 )を使用している日本版Windowsで見ると「 ¥ 」になってしまうような現象となります。

ちなみに米国の Windows は ASCⅡ を使用しているので、5C は「 ¥ 」ではなく「 \ 」です。つまり Windows のパスの区切り文字は実は「 \ 」であって、「 ¥ 」なのは日本だけなのです。

この差はフォントによっても発生してしまいます。

例えば WindowsOS の場合、「 MS Pゴシック」で 5C を入力すると「 ¥ 」になりますが、「 Arial 」で 5C を入力すると「 \ 」になります。同じ文字を入力しても、フォントを変更すると見た目の文字が変わってしまいますので、アプリケーションでフォントを指定する場合には、注意が必要です。

3.波ダッシュ問題

「東京〜大阪」、「3時〜5時」、「300名〜500名」のように使われる「〜」も文字化けの原因になります。

原因は、Unicode に見た目の区別がつかない 2 つの「〜」があるためです。

一つは波ダッシュの U+301C「〜」、もう一つは全角チルダの U+FF5E「~」。

Shift-JIS の波ダッシュは 8160 ですが、全角チルダの文字は存在しません。

文字コード変換の際に、8160 を U+301C に変換してくれればいいのですが、ツールによっては、8160 を U+FF5E に変換するものがあります。そのようなツールで U+FF5E に変換した後、それをまた別の変換ツールで Shift-JIS に戻そうとすると、U+FF5E に相当する文字がないために文字化けしてしまいます。

他にも Windows で「〜」を入力すると、全角チルダ( U+FF5E )になり、Macで「~」を入力すると波ダッシュ( U+301C )といった違いでも文字化けすることがあります。

このような問題は、波ダッシュが頻繁に使われるので有名ですが、他にも双柱「‖」( 8161 → U+2016 / U+2225 )や負符号「−」( 817C → U+2212 / U+FF0D )、ダッシュ「—」( 815C → U+2014 / U+2015)、セント記号「¢」( 8191 → U+00A2 / U+FFE0 )、ポンド記号「£」( 8192 → U+00A3 / U+FFE1 )、否定「¬」( 81CA → U+00AC / U+FFE2 )といったものがあります。

4.見た目が同じ問題

波ダッシュと似たような話ですが、これも Unicode 特有の問題で丸数字の問題があります。

「①」は、U+2460 と U+2780 の2つがあります。U+2460 が日本で使われている「普通の①」です。U+2780 は欧米の DTP でよく使われてきた「Zapf dingbats」という装飾文字のフォントに含まれる記号類をとりこんだものです。

見た目は同じでも、例えば「①( U+2460 )」で検索したら、実際の文字は U+2780 だったので検索にヒットしなかったといった悲しいことも起こります。

「A」も厄介です。ラテン大文字「A( U+0041 )」 とギリシア大文字アルファ「Α(  U+0391 )」は区別がつきません。

その他にUnicodeには結合文字という厄介なものがあります。

結合文字とは、例えば「バ」の文字コードは U+30D0 ですが、「ハ( U+30CF ))」と濁点の「 ゛( U+3099 )」でも「バ」と表示させることができます。文字コード2文字分で1文字になるので、とても厄介です。1文字の濁点「 ゛(U+309B)」もあるのでさらに厄介です。

「バ」(U+30D0)

「バ」(U+30CF、U+3099)*結合文字( 1 文字だけど 2 文字分の文字コード

「ハ゛」(U+30CF、U+309B)*「ハ」+「 ゛」の 2 文字

この結合文字を使うと「か゚」のような文字も作れてしまいます・・・。

そんな結合文字ですが、普通に文字変換を使っていれば扱うことはないと思いがちですが、Mac のファイル名は自動的に結合文字に変換されてしまうので( Unicode の NFD という正規化形式を採用しているためです)、意外と身近に存在しているのです。

5.CSVExcel で開くとき

これはピンポイントの問題ですが、CSV をダブルクリックして Excel で開く場合、Excel は Shift-JIS( CP932 )として開きます。

もし CSV を他の文字コードで作っていると、文字化けしてしまうのです。

CSV を Shift-JIS で作れば文字化けしませんが、元の文字コードUnicode だと Shift-JIS で扱っていない文字が数多くあるため、それらの文字が Shift-JIS にすると文字化けしてしまいます。

最近は Web からの入力は UTF-8 の場合が多いので、CSVUTF-8 で作るケースが多いです。

UTF-8CSV を作って、それをダブルクリックして Excel で開くと文字化けしてしまうので、それを防ぐ方法として BOM があります。

BOM 付きの UTF-8CSV を作成すると、ExcelCSV文字コードUTF-8 と認識してくれるので、文字化けせずに CSV を開くことができます。

その場合の注意点としては、CSV をアプリケーションで取り込む場合、BOM の存在を認識していないと、最初の制御コードも文字として処理してしまうことです。

Windows で動くソフトウェアは、どんどん UTF-8 になっていって、Excel もデフォルト文字コードUTF-8 になっているのに、なぜか CSV を開くときだけ Shift-JIS で開いてしまうのは、マイクロソフトの嫌がらせとしか思えません。 

 【振り返り】

第八回は、文字化けでした。

文字コードの説明は以上となります。

第一回:概要
第二回:符号化文字集合
第三回:文字符号化方式(前編)
第四回:文字符号化方式(後編)
第五回:サロゲートペア
第六回:IVS
第七回:文字コードの歴史
第八回:文字化け