日々の思う事

第8話 UTF-8N問題

UTF-8N（ユーティーエフエイトエヌ）問題

　UTF-8とはISO/IEC10646とUnicodeで使える8ビット符号単位（1～4byteの可変長）の文字符号化形式及び文字符号化スキームである。

UTF-FSSとか呼ばれたりもする。これは第2バイトに「/」（半角スラッシュ）の文字コードが来ないために、Linuxでディレクトリを区切る半角スラッシュコードと混同しない文字コード体系だったために、ファイルシステムに優しい文字コードなどと呼ばれた。

　デメリットもある。実は漢字やかな表現のShift-JISと比べると、２バイトではなく３バイトで表現するために、１．５倍のファイルサイズになる。

文字符号によってはさらに増えて４バイトの物も有り得る。

テキストサイズ＝文字数ではないので、文字数をカウントしようとすると、頭から全部数えていく必要がある。

　これはあくまでも８ビットのASCII文字コードのテキストを処理するソフトウェアの多くがそのまま使える事を強く意識して作られている。

まあそれでも、若干の修正は必要である。修正しない場合でも、致命的な誤動作をしてファイルを壊すとかはしない。

たぶんにして正しい結果が得られずに、何も無かったかのように終了してしまうかエラーを起こして止まると言うのが殆どの場合だろう。

　……

　まあ、ごく普通にPCをつかってる人は、こう言う事をまず意識しない。

私がこれを意識したのはAndroidのタブレットで文章を作って、それをグーグルドライブ経由で、ＰＣ側と共有した時だった。

Windowsに普通に入ってるアクセサリーのノートパッドはShift-JISかUnicodeかUTF-8形式でしかファイルを閲覧できない。なのでこれで開くとUTF-8Nは勿論文字化けする。

逆にShift-JISで作成した文章をグーグルドライブで共有して、Androidで受け取って開くと文字化けしている。

しかしUTF-8に変換して、Androidの方で受け取るとこれは文字化けしない。

これは困った。

Androidの方で文章を気軽に作ってPCに送り込むとUTF-8Nなのだ。

Windows10の中ではUTF-8Nは異質であって、扱えていない。

　結局その時は、PCのほうをUTF-8Nで意識して編集できるように、フリーのテキストエディターを探して入れた。

ちなみにUTF-8NというNのついてるのは日本の特殊事情を考慮した呼び方であって、公的にそう呼ばれている訳では無い。

だから他の国ではUTF-8Nと言う呼び方はほとんど知られていない。

　さあ、さてこれで問題解決。ならいいのだが、そうもいかない。

自作小説の中でとある間違いで村の名称をあちこち表記を間違えていた。

　さて。これが全部でどのくらいあるのか。

凡そ、対象になりそうなのは６０話くらいで、１話は５千から６千文字くらいある。

つまり大体３０万文字程度の中から人力、つまり目視で探すのは大変だ。

ファイル６０本を１つ１つ見て行ったら、たいへんな時間がかかり見落とすかもしれない。

　それでWindowsのコマンドラインで「Findstr」コマンドで検索しようとしたが１つも見つからない。

おかしい。

何度もオプションを見直し、やり方がまずいのかと首をひねった。

そして気が付いた。UTF-8Nに対応していないのだ。

たぶん、全てUTF-8でやればよかったのだろう。

　実はWindows10はUTF-8Nには完全には対応していない。

これをやっていた時は気が付かなかった。

　エクスプローラーの検索でWindowsSearchはUTF-8NにおいてはASCIIコードの部分しか全文検索出来ない事が知られている。インデックスが作成できないのだ。

そして全文が非ASCIIコードな文字だった場合、全く何も検索しない。

つまりUTF-8のBOM付きでエンコードしてないとWindows10は正しく扱えない。

しかしそうなるとAndroidの方で作った文書にはBOMが付いていない。

なおBOMとはバイト順（オーダー）マークの事である。

　やれやれである。

　どうやってもコマンドラインで文字コード指定は出来ないので、これは多数の文字コードを扱えるテキストエディターによる検索しかないなと、とあるテキストエディターを使ったのだが、これがまたマルチファイルでの検索は出来ない。

　こういうのは通常はプログラム作成やってた時は『ＧＲＥＰ』と呼ばれる外部コマンドツールで解決するのだ。

これは元々はLinux等で、プログラム開発する時は必ず使うツールだ。

こんなもの程度でも、Windowsには実装されていなくて誰かが作ったフリーソフトを拾って、有り難く使わせて貰う事になる。

　エディターから文字列を指定して、ディレクトリーを指定すれば、あっという間に全部のファイル１００本ほどから、抜き出してくれる。

こう言うのは、元々コンピューターにやらせるべき作業だ。

もうプログラマー現役じゃないので、久しぶりにツールの便利さを実感する。

でタグまでついた形で吐き出された結果をファイルに吐いて、そのファイルを見て、そこで該当箇所にタグジャンプして、修正。

なんだかんだあったが、あっと言う間に終わる。

　このGREPも内蔵したテキストエディターを持っているのだが、これは古いフリーソフトでかなり前に開発が止まっている。

残念なことにWindows10には完全には対応していない。

本当はこっちでやったほうが、遥かに楽である。

このエディターはプログラマー向けに開発されている。

だからGREPも内蔵していて、マルチバイト文字コード自動対応なのだが、Windows10では不具合がある。

だからここでは、そのプログラム名を書かないで置く。

その不具合とは、編集途中で何かのタイミングでキャレットカーソルが表示されなくなるのだ。（行は判る。アンダーライン的な行カーソルを表示できるので。）

最初の頃のWindows10では動いていた。

途中でタブレットの機能を統合したアップデートのあたりで駄目になった。

駄目になっていなければ、お勧めできるエディターだったのだが。

　そんなこんなで、GREP使いたいときだけ、そのエディターを起動する事にした。

　１０年前なら、きっとGREPの機能と正規表現のエンジンを内蔵した、ノートパッド程度のエディターを自作して使っていたのだろうなと思うと、怠惰になった自分を感じる。

　まあ、最近はEmEditorのFree版という手もあるのかもしれないが、手に馴染んでいるツールのほうが使いやすい。

　それに、検索はオープンしている全てのファイルだけでなく、特定フォルダー下のサブフォルダーも含めたすべての対象ファイルで探したい、と言うのはよくある事だ。

プログラムなら特にそうだ。

特定の関数、或いはメソッドが何処から呼ばれているのか。パブリックならあらゆるところで呼んでいるだろうし、変数も同じだ。

そう言うのを探す必要がある場合、こう言う機能が必須なのだ。

上記のFree版はそう言う機能は満たしていない感じだったので、手を出してはいない。

　……

　閑話休題

　自作の小説読み直しには、最近はフリーソフトの縦エディターを入れて、表示だけ、これにして、まず紙媒体のごとく読めるようにしている。

設定は３７文字ｘ１７行にする。大型の単行本なら４４文字ｘ１８行か。３９ｘ１７なら文庫本サイズだ。

３７文字にしているのは、「小説家になろう」のほうの横のサイズに揃えただけである。「カクヨム」なら横は３８文字か。

　マークアップ方式には、「小説家になろう」や「Pixiv」とか「カクヨム記法」他、「青空文庫」とか他にも選べるが、製本する様な事を考えない限りはデフォルト設定で、普通にやる程度のルビには対応してくれるが、デフォルトだと|が要らない状態でルビになるのだが、それはそれで「小説家になろう」だと困る。

(カクヨムだと|なしでもルビになる。）

そこでマークアップは自分の対象とする小説サイトに合わせる。

アルファポリスとか、他のサイトだとどれを選べばいいのか、わたしはまだ試していない。

　さて、ページ設定できるオプションをいれるとページ単位で読めるのだが、原稿チェックとかならページ単位じゃないほうがいい。

背景の色も重要だ。真っ白だと目が痛いので、クリーム色とかにする。

ブルーライトをカットするのだ。

　そんな感じで縦書きで自作小説を楽しむ。

読んでいって、気になる場所は、別のエディターで原稿ファイルを開いて直して、上書き保存。

そうすると他で修正されたのでそれを反映するか聞いてくるので、OKするとその場で新しい原稿が表示されている。

縦書きでの修正には私が慣れていないので、この縦書き状態で訂正はやっていない。

この縦エディターもUTF-8とUTF-8Nには当然対応している。

　……

　次のWindows11はデフォルトでUTF-8Nでコマンドラインが対応してくれるといいな。とは思う。

何しろWindows11は一部のandroidソフトが動くようになるとか言うので、そうなったらなおさら、この辺の文字コードの問題は避けては通れない。

（もっとも２０２１年１０月発表のバージョンにはこの機能は入らないらしい。）

　実際Shift-JISで表現できない文字コードも文部省で追加したのだから、Shift-JISはもう時代遅れになっている。８０年代に設定した文字コードなのでもう、十分役目は終えたと言っていいだろう。（35年？くらい経過している）

　世界の標準はUnicode。

Unicodeではこれを“Unicode Transformation Format-8”と表記しそれで省略してUTF-8なのだ。（UTF-16とかUTF-32とかもある）

　今はもう文字コードはUTF-8の時代なのだが、BOMという面倒臭い問題が絡み付いたままだ。

UTF-8N問題はいつになったら解決されるのだろう。

　こんな煩わしい事があるせいで、私の小説ディレクトリの中はShift-JISフォルダーと（Android用）UTF-8Nフォルダーがある。1つ治すたびに、両方を同期させないといけない。

たぶんどこかで、きっと破綻するな、と自分でも思う。

　いっその事、UTF-8で統一して、androidの方で新規のファイルを作ったり、修正したらPC側でUTF-8に変換して保存すれば、解決するのだろうな。とは思った。

（私の使っている環境に依存している可能性もかなりあるが、Androidの方でファイルを保存すると問答無用でUTF-8Nになる。）

　たぶん、この方向で全部ファイル整理、管理するようにしたほうがよさそうだ。

しかし、この変換を手でやるのはうんざりする。何しろ１００本以上あるのだ。

こう言う作業は間違いなく、ツールで解決すべきなのだが。

追記　2021/09/22

フリーソフトの漢字コード変換ツールで、全ファイルを一括で全て変換。

UTF-８（BOM付）にしました。こんな便利なツールがあったのか。

このあたり、相当私が怠惰なせいで、調べていなかった。

もうこれで２重管理は必要ない。必要なのはバックアップだけだ。

＜了＞