本を読む

読書やコンピュータなどに関するメモ

濁点問題

　こんにちは。これは編集者アドベントカレンダーの12月4日の記事です。

　この記事では、濁点問題という極めてちっちゃい話題を取り扱います。なにせ1文字の片隅ですし。

　編集者の一般的な仕事についてのちゃんとした話題は、ほかの方々の記事にご期待ください。私も期待しています。

百聞は一見にしかず

　濁点問題を理解するために、まずはMicrosoft Wordの画面キャプチャーをご覧ください。

　赤丸で囲んだ2つの文字は、同じ「が」という文字に見えます。しかしこれは、「が」と「が」という異なる文字です。スペルチェックの波線が付いているほうが「が」です。

この記事は何ではないか

　濁点問題というと、比較的詳しい方には、ファイル名の問題と思われがちです。iOS 10でのKindleアプリの不具合なども問題になりましたし。が、ここで扱うのはファイルの内容（テキスト）のほうの問題です。

　ファイルのテキストの問題も、原理としてはファイル名の問題と同根です。ただ、テキストのほうの問題は認知度が低くて見過ごされがちです。また、正規化されないという問題により、一括処理したときにトラブルを起こす可能性があります。

私が意識したころ

　私がこの問題に遭遇したのは、2015年のことでした。Macを使っている著者様から送られてきた原稿テキストの中で、濁点や半濁点が付いていた文字のうち、テキストエディタの文字列検索にヒットしない文字があるという現象があったのです。ちょっと調べてみると、微妙に違う文字になっているようです。

　それからちらほらと、Macで書かれたMicrosoft Wordファイルやテキストファイルの中で、同様の現象を目にするようになりました。

　私の主な仕事範囲は、IT系出版物です。いまIT関連の文章を商業出版物に書くような技術者の方には、Macが高い普及率を誇ります。編集者にとっては、あらかじめ注意しておきたいポイントです。

どこで起こるか

　この問題は、Unicode文字集合による現象です。そのため、Shift JISなどJIS文字集合ベースの文字コードのテキストでは起こりません。

　Microsoft OfficeのようなUnicodeベースのアプリケーションや、UTF-8などUnicodeベースの文字コードで書かれたテストファイルで起こりえます。

Unicodeの濁点や半濁点

　Unicodeには濁点や半濁点の表しかたが2種類あります。想像しやすいのは、「が」を「が」という1文字として表す方法ではないでしょうか。この形式を「合成済み文字」と呼びます。

　もう1つの方法は、「が」を「か」と「゛」（相当）の2文字の組み合わせで表現する方法です。この「゛」の部分には、単体で使う濁点ではなく、組み合わせ専用の文字を使います。この形式を「結合文字列」と呼びます。

　文書中の濁点や半濁点を合成済み文字に揃えるのを「NFC（Normalization Form Composition）」正規化と呼びます。反対に、結合文字列に揃えるのを「NFD（Normalization Form Decomposition）」正規化と呼びます。NFD正規化されたUnicodeを、通称で「UTF8-MAC」と呼ぶこともあります。

　ちなみに、細かくいうとNFCやNFDは濁点と半濁点の正規化だけではありません。が、とりあえずここでは濁点と半濁点だけに話を留めておきます。

Macと結合文字列

　Windowsを使っていると、外で作られた文書を除けば、意図していないところで結合文字列が入力されることはありません。

　しかし、Macでは意図せずに結合文字列が使われることがあります。最初にちょっと触れたファイル名などはその一つです（HFS+ファイルシステムの場合）。

　ファイル名にとどまらず、Macではテキスト中にも意図せずに結合文字列が使われることがあるようです。挙動を見て推測した限りでは、Webブラウザーなどほかのアプリケーションから、テキストエディタやワードプロセッサにテキストをコピー＆ペーストすると、そこで結合文字列が使われるように見えます。実験したわけではないのであくまで推測ですが。

困ること

　テキスト中に結合文字列が混じって何より頭の痛い点は、正規化されていないことです。普通に日本語入力した文字列は合成済み文字で入力されます。そこに、コピー＆ペーストで結合文字列が入ると、テキスト全体ではNFCでもNFDでもない非正規化状態となります。

　それが直接トラブルとなるケースに、検索や置換があります。テキストエディタの機能で「ユーザー」を「ユーザ」に（あるいはその逆に）置換したつもりが、結合文字列の「ザ」が入っていた部分はヒットしないと、表記不統一となってしまいます。

　また、Microsoft Wordでは、よくも悪くも合成済み文字と結合文字列が同じように表示されます。しかし、アプリケーションによっては結合文字列だと表示が違う（「か」と「濁点」がわずかに離れて表示される）という場合もあります。印刷機でどうなるかは怖いので試したことはありません。

　なにより、同じはずの文字が2通りの異なる文字として入っているのは、気持ち悪いですよね。

NFC正規化する（コマンド編）

　さて、テキストを一気にNFC正規化する方法を見てみましょう。

　私はLinuxデスクトップを主に使っています。Linuxデスクトップでは、さまざまなコマンドを使ってテキストを処理できるのが強みです。最近では、Windows 10のWSLでもまったく同じことができるでしょう。なお、ここではWSLやコマンドを使う準備については割愛します。

　Linuxのコマンドにはテキストの文字コードを変換するものがあり、そこでNFC正規化もやってくれます。Macでも同じだと思いますが、試していないので念のため。

　文字コードを変換するコマンドにnkfがあります。nkfは、変換元と変換先の文字コードを指定して実行します。この文字コードとして「utf8-mac」（NFD正規化されたUTF-8）が指定できます。

$ nkf --ic=utf8-mac --oc=utf-8 source.txt > dest.txt

　ただし、nkfでは「utf8-mac」は変換元にのみ指定できます。つまり、NFC正規化のみです。

NFC正規化する（エディタ編）

　テキストエディタにNFC正規化やNFD正規化の機能が備わっている場合もあります。

　私が日頃使っているGNU Emacsには、リージョン（選択範囲のようなもの）をNFC正規化する「ucs-normalize-NFC-region」と、NFD正規化する「ucs-normalize-NFD-region」の2つのコマンドがあります。

　そのほかのエディタにも同様の機能があるかもしれませんが、よく知りません。

ワープロでは？

　案件によっては、Microsoft Wordなどのワープロ文書で原稿をやりとりすることがあります。Googleドキュメントで文書を共有して作業することもあるでしょう。

　ワープロ文書でも結合文字列が入っていることがあります。フォーマットを保ったまま（プレーンテキストにせずに）NFC正規化をかける機能が欲しいところですが、私の調べた限りではなさそうです。

　Microsoft WordやLibreOffice Writerなどのワープロや、Googleドキュメントでは、マクロ言語（外部DSL）を使って1文字ずつ見ていけば変換できそうな気もします。ただ、そうしたマクロ言語はいちど文書に組み込まなければ使えないのが面倒なところです。

　一つの試みとして、Microsoft Wordの.docxファイルを処理するdocx-normarize-nfcというプログラムを試作してみました。20行未満の簡単なPythonスクリプトです。これは、.docxファイルをZIPアーカイブとして開き、文書本体のXMLテキストを開いてNFC正規化し、ZIPアーカイブに書き戻すというものです。