文字列

今回はいよいよ文字列を扱います。文字列。最も多用されるデータ型でもあり，Swiftを含め，およそありとあらゆるプログラムも文字列で表記されています（注1⁠）⁠。にもかかわらず，筆者は今までSwiftにおける文字列を扱うのにモジモジしてきました。それには深いわけがあります。

> Swift ’s String and Character types provide a fast, Unicode-compliant way to work with text in your code. -- The Swift Programming Language

「SwiftのStringおよびCharacter型は，高速でUnicode準拠したテキスト処理を提供します⁠」⁠。「⁠高速」はとにかく，「⁠Unicode準拠」というのがななかの難物なのです。なぜ難物なのか。それを知るためには，コンピュータにおける文字列処理の歴史を紐とかねばなりません。

注1）

ScratchやPietのように画像として表記するプログラミング言語もないわけではありませんが。

A Brief History of Characters

文字列＝＝文字の列。前世紀までは，文字列というものの理解はその程度で間に合っていました（表1⁠）⁠。

0と1という2種類の数値しか根源的に扱えない電子計算機（あえてこう書く）において文字を扱うにあたり，先人たちがやったのは基本的に次のものでした。

• 各文字に番号を振り
• その番号を並べる

往時のプログラマたちにとって幸いなことに，当初扱わなければならない文字列は英語のみ。そして英語というのは必要な文字種がとても少ない言語でした。アルファベット26文字，大文字と小文字を区別しても52文字。アラビア数字を加えても62文字。これにスペースやタブや改行などを加えても，7bits＝128種類にらくらく収まったのです。これが，現在でも使われているASCII。量産されているCPUで扱える最も小さなデータ型である1byte＝8bits（注2）にそのまま入れても1bitあまります。

注2）

厳密にはbyteというのは「あるCPUで扱える最小のデータ型」のことでCPUごとに異なるものですが，現在量産されているCPUはほぼすべて1byte = 8bitsになっています。ちなみに峻別したい場合，8bitsは1octetと呼びます。

2byte文字の誕生と混乱

文字とは1byteに収まるものであり，それを並べたものが文字列である。

そのような時代が長いこと続きました。

その原則を破ったのが，日本です。カナだけでも48文字，しかもカタカナとひらがなと2種類。これだけでも8bitに収まらないのに，さらに数千種類の漢字も扱いたいとなると1つの文字を表現するのに12～13bitsは必要。しかも漠然と並べるのではなく，ASCIIとの共存も考えると1つの文字を表記するのに2bytesは必要……こうして登場したのがShift-JISでありEUC-JPでありISO-2022-JPです。ここで注目すべきは，各文字に振られた番号はJIS X0208という単一の規格なのに，それをどう並べるかで複数の規格が乱立したことです。それぞれ一長一短あるのですが，そうなってしまった理由は，「⁠最後に正しいものではなく，今すぐ使えるものを」という「電子立国日本の現場圧力」ではなかったかと思われます。インターネットどころかパソコン通信すらまだ一般的ではなく，データ互換性はせいぜいメーカーがそれぞれ自社製品のみ担保されていた時代，まず大事だったのはパソコン，いやワープロ（もはや死語？）で入力できて出力できることだったのです。

Unicodeの誕生

その状況は，ネットの登場で一変します。コンピュータは単独で使用するものから，他のコンピュータ，強いてはそのコンピュータのユーザ同士をつなげるものとなったのです。そんな時代，各国ごとにバラバラの規格を使っていたのではメーカーはたまったものではありません。各国ごとに乱立していた「ASCII＋自国語文字コード」から，世界共通の文字コードへの移行の機運は高まっていたのです。「⁠世界共通の文字コード⁠」⁠，それがUnicodeです。

最初に登場した段階におけるUnicodeは，過去との互換性はほとんど気にかけていませんでした。Shift-JISやEUC-JPといったASCII互換の日本語文字コードが可変長だったのに対し，1.0段階のUnicodeは16-bit固定長。ここにカナもハングルも日中韓の漢字も全部収める予定だったのです。そのためには，各国で用いられている文字コードをまとめて割り振るのではなく，並べ替えが必要となりました。それが（悪名高き）Han Unificationです。それの何が問題だったかといえば，文字コード変換。Unicode以前の日本語文字コードの相互変換は，元になる「背番号」が共通だったこともあり単純計算でOKだったのが，変換表が必要になったのです。

Unicodeの不幸

その一方で，Unicode陣営も1.0の「ゼロベースで文字列を再定義する」やり方がそのままではうまく行かないことに気づいてきました。まず，「⁠同じ文字に同じ番号」という原則が破られます。Unicodeコンソーシアムのベンダ自身が，それまでの文字コードからUnicodeに変換したあとの逆変換がきちんと成立することを求めたからです。かくして半角カナも生き残りました。次に，16bitではとても足りないことに気がつきました。それを解決すべく，Surrogate Pairというものが登場しました。16bitで1文字から，「⁠文字によっては16bit，2つで1文字」というわけで，固定長という原則がここに崩れたのです。その代償として，Unicodeでは最大(16 + 1) *2**16 == 1,114,112文字まで扱えるようになりました。そしてASCII互換性も，UTF-8で解決されました。1文字の長さは1～4bytesの可変長になる代わりに，ASCIIはこれまでどおり1byte。ASCIIを前提としていた数多のソフトウェア，とくにCコンパイラでもそのまま扱えます。

我々にとって不幸だったのは，「⁠使えるUnicode」である2.0が登場する直前に，「⁠インターネット爆発」が起こってしまったこと。とくにJavaとJavaScriptが1文字16bitとしてしまったのは今もなお尾を引いているのは本誌の読者であればご存じでしょう。おかげで絵文字の長さはそのままでは2文字になっちゃうとか...

文字コード統一の奇跡

Han Unificationのような「理念の押し付け」のあとに，Surrogate PairsやUTF-8のような「日和見（ひよりみ⁠）⁠」⁠。それだけの犠牲を払って，世界をUnicode化するだけの価値はあったのでしょうか？

私自身，Perl 5.8のUnicode化という形でその片棒を担いだ以上，中立の立場とはとても言えないということをあらかじめお断りしたうえで言えば，その価値は確かにあったと断言します。Unicode以前の世界，小はワンライナーから大はOSに至るまで，ソフトウェアには各国語版がつきものでした。EmacsにはNemacs，PerlにはJPerl，Mac OSには漢字Talk……。しかし今や，世界中で使用されるソフトウェアは真の意味で世界的です。EmacsもPerlもOS Xも日本語版はもはや不要。iOSやAndroidにいたっては，その誕生時点からUnicodeを前提にできています。インターネットの普及によりTCP/IP以外の通信プロトコルは事実上滅亡しましたが，それによって世界が画一化したようにはとても思えません。我々の遺伝子だって，RNA-DNA-タンパク質というシングルアーキテクチャであることを考えれば，文字コードのように基礎的なデータ構造が（およそHan Unificationの混乱を除けば）統一できたのは奇跡なのではないでしょうか。