先日、技術グループで誰かが愚痴っているのを見ました。今やAIがコードを書くのがこんなに強力で、CopilotやCursorを開けばコードが水道水のように流れ出てくるのに、なぜまだベテランプログラマーがASCIIコード表をめくっているのか？これって上古時代のものじゃないのか？グループはすぐに沸き立ち、同調する人もいれば、ある古参が淡々とこう返しました：「いつか午前3時までデバッグする日が来たら、なぜかわかるよ。」
正直に言うと、ASCIIコード表というものは、確かに地味に見えます。一枚の表、128文字、0から127まで、各数字が一文字に対応しています。スペースを打つと32、改行を打つと10、大文字のAは65、小文字のaは97。これだけのもので、小学校の情報の授業でも習ったかもしれません。しかし問題は、実際に仕事をする時になると、あなたが思うよりずっと重要だということです。
AIがコードを書くのは確かにすごい。ソートアルゴリズムを生成させれば、1秒でコメント付きで書いてくれます。REST APIを書かせれば、エラー処理まで追加してくれます。しかしAIには欠点があり、時々「でっち上げる」ことがあります。特に文字エンコーディングを扱う時、一見問題なさそうなコードを生成し、実行してもエラーは出ないのに、結果が正しくないことがあります。例えばテキストファイルを処理させると、改行文字を\nとしてマッチングするのに、ファイル内は実際には\r\nで、このコードはLinuxでは問題なく動くのに、Windowsではおかしくなる。そんな時どうする？ASCIIコード表をめくるんです。13はキャリッジリターン、10はラインフィード、16進エディタで0D 0Aの並びを見れば、すぐに問題がどこかわかります。
もっと隠れたケースもあります。例えば古いシステムをデバッグしていて、インターフェースが返すJSONのあるフィールドが明らかに空に見えるのに、プログラムは空でないと判断する。プリントしてみると、中に\u00A0があり、これはノーブレークスペースと呼ばれ、ASCIIコード表で160に対応するものです。肉眼では全く見えませんが、コードロジックはそれに引っかかっています。そんな時ASCIIコード表を引っ張り出して調べると、ああ、160で、32ではない。判定条件を変えれば問題解決。AIだけに頼ると、大回りさせられて、結局自分で表を調べることになります。
ベテランプログラマーがASCIIコード表をめくるのは、AIを使えないからではなく、AIに頼れないものがあることを知っているからです。AIが得意なのはパターン認識とコード生成ですが、低レベルの詳細の把握は、時には一枚の表には及ばないことがあります。ASCIIコード表はプログラマーの九九の表のようなもので、見た目は簡単ですが、肝心な時に命を救います。コードを長く書いていると気づくでしょう。多くの奇妙な問題は、最終的に文字エンコーディングに行き着きます。文字化け、切り捨て、比較失敗、正規表現の不一致、十中八九ASCIIコードに関係しています。
しかも表をめくること自体、大した手間ではありません。ブラウザを開いて、ASCIIコード表検索と検索すれば、1秒のことです。あるいはよく使うものを覚えてしまえば：32はスペース、48から57は数字の0から9、65から90は大文字、97から122は小文字。これらを覚えれば、普段16進データを見る時に、心に余裕が持てます。ベテランプログラマーは新しいツールを排斥しているのではなく、捨ててはいけない基本があることを知っているだけです。AIがどんなに強力でも、それはただのツールで、本当に判断するのは人間です。文字エンコーディングすら理解していないのに、AIが生成したコードを本番環境に直接投入できますか？
だからベテランプログラマーがASCIIコード表をめくるのを笑わないでください。彼らがめくっているのは表ではなく、経験であり、自信です。いつか隠れた\rや\u00A0に人生を疑うほど悩まされた時、あなたも黙ってあの表を開くでしょう。