これは僕がPerl言語に出会い、惚れ込み、ドハマりし、苦しみ抜いて得たノウハウを徒然なるままに垂れ流しているエッセイです。
多くを期待してはいけません。エッセイですから。^^)
読むのが面倒な方は、最後の赤字のみ読んで、次の記事へGo！
僕がPerlに出会ったのは研修医２年目の平成7年頃。出身大学にキャンパスネットが敷設され、配布されたSun LX ワークステーションでWEBサーバを立ち上げるべく準備をしていた頃だった。
当時のSun LX ワークステーションに付属のccではhttpdをコンパイルするなど到底無理で。当時のワークステーションのccは、最新版のオープンソースのGNU C (gcc)とglibcをコンパイルするためしか存在価値が無かった。ｇｃｃ関連のソースをダウンロードし、夜な夜なコンパイル。SUN のcc は手ごわくて、一筋縄では行かなかった。当時研修医だったので、そりゃあ、やる事いっぱいあって、先輩からも怒られっぱなしだし、ホントに大変だったけど、睡眠時間（命）を削りながら、ひたすらccの吐くエラーや警告と戦った。文献は全て英語ね。
やっとの思いでhttpdをコンパイルしWEBサーバを立ち上げ、悦に浸っていたところ、、、、まぁ、いつものことだが、上司が急に「センセイはPerlはご存じですか？」と尋ねてきた。上司からセンセイと呼ばれることに違和感を感じる方がいると思うが、そう言う世界もあるんです。「CGIという、WEBサーバでプログラムを動かすのに使われる言語だそうです。」と、おっしゃる。負けず嫌いで知ったかぶりの僕は「調べてみます。」と答え、その場は終わった。
折しも当時のPerlはver4から5へと大きく変革する激動の時代。「まずは実績のあるperl4を使ってみよう」と、苦しみ抜きながら何とかコンパイルし、四苦八苦しながらCGI用のスクリプト言語として使えるようになった。
僕自身、学生時代は80系CPUのアセンブラにドハマりしており、それまでは高級言語と言えばC、C++位しかまともには使ってこなかった。（というか、遅すぎて使い物にならなかったと言うのが本音ね。）なので、perlのもつ文字列と数値の型変換の自由さ、連想配列や正規表現の素晴らしさと、その処理速度の速さに惚れ込んだのは言うまでもない。
以来、Perl沼にどっぷりとハマってしまった。今ではpythonも使うけど、ちょっとした処理は全てPerlで書きます。考えるように書けるので。
その後、苦労を重ね、WEBサーバ上のperl-CGIで、ゲームや業歴管理システム等、様々なWEBシステムを試作した。
例えば「箱入り娘」とか。実は今でも最新のPerl風にメンテナンスし、このサーバで動かし続けている。興味がある方は、以下のボタンから遊んでみて欲しい。
Unixの世界では、もはや欠かせない存在感を放つまでになったperlであったが、やはりASCIIを基本とするシングルバイト圏で開発されたシステムであったため、マルチバイトである日本語や中国語等を扱うのは困難を伴った。
ちなみに日本工業規格JIS漢字コード(ISO-2022-JP)は「K-ON」漢字ON「K-OFF」漢字OFFと、漢字モードを切り替えるコードが挿入される仕様となっており、日本語文字列の字数カウントや分割・結合時に、K-ON、K-OFF文字の処理を行わなければならず、正直とても使い物にならなかった。こんな仕様を考えた人間を何度恨んだことか。なお現在でも日本語電子メールの本文は7bitJIS漢字コードがRFC標準となっている。めんどくせ～
日本語JISコードの取り扱いにくさを解消するために、関係各社が協議し、日本語Shift JIS (SJIS)が開発された。SJISは、１バイト目が特定の範囲のコードの場合に２バイトコード（漢字文字）であると判断可能であったため、「K-ON」「K-OFF」コードが不要となり、大変扱いやすかった。
当時、最も安く入手可能であったパソコンのOSは、その多くがMicrosoft社が開発したMS-DOS、Windowsを採用していた。文字コードは日本Microsoftが、半角カナを扱えるように、Shift-JISに独自に改良を施した「CP932」を採用した。日本国内の各ベンダも独自のSJIS漢字コードや外字定義を行ったため、他社のパソコン間でプログラムを移植する際には困難となった。日本の国産パソコンのガラパゴス化である。
これらのSJISをベースとする文字コードの２バイト目にはunixでは特殊コードに相当するバックスラッシュ"\"を含む漢字がいくつか存在し、Unixシステムのソースやデータベース内に日本語が紛れ込むと、稀に「コンパイルできない」、「システムがアボートする」、「文字化けする」等のトラブルが発生した。
そこで、UNIXシステムでマルチバイト文字を取り扱うためのコード体系としてEUCが策定された。EUC-JP（Extended UNIX Code Packed Format for Japanese、日本語EUC）は、その日本語バージョンである。中国語、韓国語バージョンも存在する。しかし日本語EUCでは半角カナ文字が扱えなかったため、またまたMicrosoftはWindowsで半角カナを扱えるようにするために、CP51932という独自のEUC-JPコードを策定し採用した。本当に勝手な会社ではあるが、当時の日本語ワープロで半角カナは絶対的に必須だったのである。自分も半角カナが扱えなくなると怒り狂っただろう。当然ながら半角カナはHTML等のWEBシステムではトラブルを発生させたため、技術者間ではWEBページでの半角カナの利用はご法度とされた。
当時WEB-CGIではJcode.plという、SJIS (CP932)を、EUC-JPに変換する為のライブラリが必須であった。HTMLでもCGIでも、EUC-JPコードで記述さえすれば、トラブルが発生しなくなった。少なくとも日本国内では。
その後、世界中にInternetが広まり、日本と韓国、中国間で電子メールのやり取りが行われるようになった。WEBブラウザも、世界各国の文字コードに対応する必要性に迫られた。この当時は、兎に角、各社のブラウザが文字化けと戦う日々であったように思う。
Unicode (UTF-8,16,32)は1993年（平成5年）に策定された。そう聞くとかなり古くに策定されたと思う。簡単に言えば、UTF-32は、単純に全てのコードを32ビットで表現するものであった。これらはアメリカやヨーロッパ圏から、データ量が４倍になるという理由で受け入れられなかった。結局、最も複雑難解であるが効率が高かったUTF-8が広く使われるようになった。この複雑怪奇なUTF-8にオープンソース系のシステムが対応するのには、その後10年以上かかったように思う。まだ対応の途上と言えよう。
以上、延々と述べて来たが、シングルバイト圏で発明されたperlでマルチバイトを扱うためには、これらの文字コードの特性を把握しておく必要がある。また2025年1月の現在でも、UTF-8に対応しているはずのライブラリが、localeが日本語cp932・韓国・中国の場合には未対応である旨の警告を発し、稀に突然フリーズすることがある。このことを理解した上で、この素晴らしいPerlを便利に使いこなして欲しい。
オープンソースなんだから、日本人が治せってことですよね〜！！！😥
