2020年の東京オリンピックが決まりました。ご多分にもれず我が家の子どもたちも東京オリンピック見に行く気満々でずいぶんと喜んでおりました。

「みんなで見に行こうねー」なんて盛り上がってる子どもたちも７年後となると長男は19歳、長女は16歳。たぶん友達と行くんだろうなあ。娘はもしかしたら彼氏と行くのかなあ・・・・。なんて思いながら「ま、オマエは19歳、オマエも16歳だからなあ、たぶんその頃はお父さん、お母さんとじゃなくて、友達と行くって言うんだろうな」なんて言ったら「やだ、お父さんといっしょに行くもん！」なんて言ってくれる娘にお父さんメロメロ。そうか、そうか。じゃ、７年後を楽しみにしてるよ。娘は体操を、息子は柔道を見に行きたいそうで、どっちもチケットとるの大変だなあ。

ちょくちょく利用するハンバーガーショップで注文する時に（すべての店じゃないんだけどいくつかの店舗で）

おめしあがりですか？

と聞かれる。そのたびに心の中で小さく「あたりまえだろ」と突っ込んでいる。

店内でお召し上がりですか？それともお持ち帰りですか？

という質問を省略して「お召し上がりですか？」と言ってるんだとはわかる。わかるんだが、わかるんだが、質問の要点は召し上がるかどうかじゃなくて、店内かどうかだろ？　これじゃ持ち帰りするときの受け答えなんて

店員「お召し上がりですか？」
オレ「いいえ」

・・・・・・・変だろ？変だよな。これじゃオレ、食べるつもりがない食べ物を買いに来たってことになっちゃうよな。だいたいにして食べるもの売っておいて「おめしあがりですか？」って聞くの変だろ。意味ないだろ。そうだよね、オレ間違ってないよね？ね？ね？

質問文を短くしたいなら

店内ですか？

じゃないのか？　でもこれだとぶっきらぼうな感じを受けてしまうから敬語表現になっている「おめしあがりですか？」の方を使ってるんだろうと好意的に解釈・・・・・・いや、でも、変だ。敬語表現を含みつつできるだけ短いフレーズで質問したいなら

お持ち帰りですか？

が適切なんじゃなかろうか・・・・・・・ブツブツブツ・・・・・・・。

ちょっと文字コードの話。0と1というデジタルデータが７個で１セットとしたら

0000000
0000001
0000010
0000011
0000100
・・・・・・全部で128通りある。1000001に「A」とか、1110010に「r」とか、0100011に「#」とか0/1の７個セット（128通り）に文字を割り当てたのがASCIIと呼ばれるコンピュータでの文字情報記録方法の始まり。例えば「Love」という文字は 1001100 1101111 1110110 1100101 というデジタルデータで記録する。英語なら大文字、小文字、数字、記号など全部あわせても128通りもあれば十分だったんだな。その後、ドイツ語やスペイン語などの独特な文字も記録できるように0/1を１つ増やして合計8個の0/1を１セット256通りの組合せにしてこれに文字を割り振る方式が一般化している・・・んだと。

ところが日本語だとひらがな、カタカナ、漢字と膨大な数の文字があるので0/1が8個でも全然足りない。そこで0/1を16個１セットにして65,536通りに文字を割り当てることにした。16個の0/1の（65,536通りの）組合せにどんな文字を割り当てるかは JIS とか Shift-JIS とか EUC-JP とかいくつかの流派が存在してる。この流派が「文字コード」。たとえば「久」という字は Shift-JIS だと 1000101101110110 に割り当てられてて、EUC-JP だと 1011010111010111 に割り当てられている。日本語の文字コードだけでも複数の流派があるんだが、言語ごとにどの組合せにどの文字を割り当てるかは各国が独自に決めている。結局 1001000010111101 という組合せでデータが記録されていた時、それがいったいどんな文字なのかはそれが Shift-JIS なのか EUC-JP なのかはたまた中国語なのか韓国語なのか、どの文字コードで記録されてるかによって違う。コンピュータが文字コードの判断に失敗するとデータを作った人の意図とは別の字が表示されてしまう。これが文字化け。だから日本語、中国語、韓国語など文字コードが異なる文字情報を一つのデータの中に記録するのは結構難しい。

グローバル化によって英語、日本語、中国語、ハングル、ベトナム語、アラビア語などなど世界中にある膨大な数の文字を一つの文字コード体系で記録する方法が必要になってきた。そのためには0/1が16個１セットの65,536通りでは全然足りない。そこで「ユニコード」。最大48個の0/1を１セットと考える（１セットの0/1個数が48個に決まってるわけじゃなくて最大48個と可変になっているところもミソ）。すると組合せは・・・・まあ無限とも思えるような組合せを作ってそこに世界中の文字を全部割り当てちゃおうという壮大な話。ユニコードにもいくつか流派が存在するが、一般的なUTF-8では「久」という字は 111001001011100110000101 に割り当てられている。ユニコードを使えば世界中の文字を一つのコードで記録できる。1980年代から大手IT企業が中心になって検討が始まっていたのでもうかれこれ30年経っている。当然ながら最近のWindowsやMacならユニコードを理解できるように作られているし、システム内部もユニコードを積極的に利用している。

中国市場を無視できない化粧品業界でも、日常的に日本語、英語、中国語が入り乱れる文書の作成やデータの作成が必要になってきた。だからウチの会社が作ってるデータベースも文字情報はユニコードで記録するし、画面表示もユニコードで出力する。システム全体で文字情報はユニコードを使う。これが俗にいう「多言語対応」ということ。

さて、データベースに記録されているデータを一覧表形式でファイルとしてダウンロードしたい場合、業界標準で汎用性が高いcsv形式（カンマ区切りテキスト）で出力することが多い。しかし一覧表形式のデータを取り扱う事実上の世界標準ソフトであるはずのEXCELがcsvをまともに扱えないとんでもなくクソ仕様なソフトで、多くのプログラマがEXCELのクソ仕様にあわせたクソ形式のcsvファイルを出力しなければならないという涙腺崩壊物語な状況にあることは以前書いた通り。

さて、csvファイルの中味はデータをカンマで区切ったテキストファイル。日本語、英語、中国語を混在させるなら文字はユニコードで出力する必要がある。ところがユニコードで書き出したcsvファイルをEXCELで開くと見事に文字化けする。えーっ！！。メモ帳で開けばちゃんと中を見ることができる。なのにEXCELで開くと文字化けする。文字コードの判定に失敗するのだ。失敗するというかどうやらEXCELはcsvファイルを開くときに何の判断もせず文字が Shift-JISで記録されていると決め打ちしてるらしい。なんで決め打ちすんの？メモ帳ですら文字コードは何かなぁ？って考えて適切な文字コードで開いてくれるのに、なんでEXCELは何も考えずにShift-JISって決め打ちして開いちゃうのさ。

はあぁぁぁぁ・・・・・・・・

しかし！前回同様、EXCELがユニコードで記録したcsvファイルをまともに開けない問題についても諸先輩プログラマの方々が解決策を編み出してくれているのだ。その解決法とは

(1)ユニコードにもいくつかの流派があって、主流のUTF-8ではなくUTF-16LEで出力する
(2)ファイルの先頭にUTF-16LEであることを示すBOMと呼ばれる特殊な非表示文字を出力しておく
(3)データの区切りをカンマではなくタブにする

以上の方法で出力した csvファイルならダブルクリックしたときにEXCELが文字化けせずに読み込んでくれる。めでたしめでたし

って、ちょっと待て！！

カンマで区切るんじゃなくてタブで区切るだと？　そ、それは comma separated values（.csv）ではなく tab separated values（.tsv）なのでは？　か、か、カンマ区切り・・・・カンマ区切り・・・・カンマ・・・・こうして、タブで区切ったカンマ区切りテキストを出力するという自分がバカなんじゃないかと思うようなプログラムを書くことになる。タブ区切りで出力したファイルに.csvという拡張子を付けなければならない屈辱感。まあユーザからすればダブルクリックしてEXCELでちゃんと開いてくれりゃカンマで区切ってあろうがタブで区切ってあろうが関係ないんだろうけどね。

嗚呼、EXCELなんてこの世から消えてしまえっ！！！