ITビジネス

2017年1月 9日 (月)

EmEditorでUTF-8の自動検出

/*
この記事はEmEditorに何らかの問題があることを指摘するものではありません。EmEditorは優れたテキスト・エディタで、当然今後も使い続けます。特定の使い方をする場合に気をつける点をまとめたものです。
*/

現在携わっているプロジェクトで、UTF-8で作成されたテキスト・ファイルを扱っており、内容の確認や変更にEmEditorを使っています。EmEditorは、文字コードの種類を自動検出する機能を持っており、普段はシフトJISであろうが、UTF-8であろうが、テキスト・ファイルを開く際には、特別な操作をすることなく開くことができます。

先日、とあるプログラムで作成されたファイル(UTF-8のテキスト・ファイル)を開こうとしたところ、下図のようなメッセージが表示されました。

これまで、そのプログラムで作成されたファイルは何度も開いたことがあり、このようなメッセージが表示されることはありませんでした(UTF-8のテキスト・ファイルとして開かれる)。

プログラムや文字コードの変換を実行しているミドルウェア、データ提供元システムのマスタなど、原因を探ってみたのですが、はっきりしません。

20170108

結果から言うと、データには何ら問題はなく、EmEditorの操作方法の問題でした。

ここで、[一覧からエンコードを選択する]→[OK]→次の画面で[UTF-8(BOM無し)]→[OK]とするのが正しい操作方法です。
仮に[現在のエンコードで開くことを続行する]→[OK]とすると、ファイルはシフトJISのテキスト・ファイルとして開かれて、下図のように文字化けを起こします(文字列の末尾の部分)。

20170108_3

いろいろ調べてみると、EmEditorの(正確にはEmEditorが使用している、エンコードを判別するWindows APIの)使用、制約であることが判明しました(そのやりとりが書かれたサポートページがあったのですが、URLを控え損ねてました)。

この現象が発生したテキスト・ファイルを見ると、UTF-8固有のコード(1個の文字を表すのに、シフトJISのコードとUniCodeのコードが異なる文字)が現れるのがずいぶん後ろの方にあることがわかりました。それより前にある文字は、シフトJISとUniCodeで同じコードで示される文字(US-ASCII。ざっくり言うと半角英数字)のみです。このような場合には、自動検出が行われず、エンコードを選択することを要求するメッセージが表示されるようです。

そこで実験してみました。
大量のUS-ASCIIの文字列のあとにUTF-8固有のコードの文字列(ここでは、半角カタカナの「テスト」)を含むテキスト・ファイルを作成し、US-ASCIIの文字列を増減させながら、その境目を探るものです。結果は、下記のようになりました。

(1) US-ASCIIが163839バイト以上の場合→自動検出できない→メッセージが表示される(エンコードを選択して開く)。

(2) US-ASCIIが163838バイトの場合→EUCのテキスト・ファイルとして開かれる→UTF-8の部分は文字化け。
 これは想定外でした。普段EUCを使わないので細かくは書けないのですが、半角カタカナ「テスト」の一部がEUCのコードと同一でそのように判定されたものと思います。

20170108_1

(3) US-ASCIIが163837バイトの場合→→自動検出できない→メッセージが表示される(エンコードを選択して開く)。(1)と同じです。

(4) US-ASCIIが163836バイト以下の場合→自動検出される→UTF-8のテキスト・ファイルとして開かれる。

20170108_2

「163836」というサイズはぴんとこないのですが、前述の「EmEditorが使用しているWindows API」のパラメタのサイズのような気もしますし、もっと何か深いところに制約があるような気もします。

###

文字コードの自動検出のAPIは、私も使ったことがあり、これまで意識したことはなかったのですが、同じような問題を抱えていると思います。

最近購入した本では、自動検出の方法を解説する一方で、その制約についても触れていました。

Sc_20170106175802


Sc_20170106175752

ファイルをすべてワークエリアに展開し、テキストの全体を検査すれば自動検出の精度は上がるかもしれませんが、ファイルが巨大な場合などを考えると現実的ではなく、素直にファイルを開くときにエンコードを指定して開く、というのが正解といえると思います。

2017年1月 3日 (火)

「現状通り」や「最小限の変更」の方針が経費の削減や品質の劣化の抑制につながるか

先日、同業の知人と飲みに(私はソフト・ドリンク)行ったときの話。

会社の統合が予定されていて、一方の会社のシステムに他方のデータを載せる、というのが原則とのこと。同業ではあっても、細かなデータの形式は、当然異なるわけで、それなりのシステム(プログラム)の改修が必要になりますよね。中には「変更不要」と判定されるサブシステムもあるのかもしれないけれど、無数の処理の前後関係の整合をとったり、ハードウェアやネットワークなど、環境の変更とは無縁ではいられないはずです。

だから、変更不要の判定が、すなわち何もしなくてもよい、ということにはならないはずですが、昨今、経費(≒要員)が抑制されるのが当たり前ですから、ホントに何もしないわけです。「現状通り」が原則となり、変更が必要な場合でも「最小限の変更」が原則とされてしまう。
すると、複数のシステムを接続してのテストが開始されたとたんに、おびただしい量のトラブルが発生する。うまくいかないのは当たり前です。

変更不要の判断だったり、何もしなくてもよいとする判断だったりは、システムの現状が正確に、精密に記録されていて、技術的な知識に明るくない人にも判断できる材料(≒ドキュメント)があらかじめ用意されていればいいわけですが、大半のお客様はシステムの開発、保守に関してITベンダに丸投げするのが一般的ですから、そういう材料は内容や制度が十分ではなかったり、そもそもなかったりということも少なくありません。

そうすると、必要が生じた段階でドキュメントを作成するわけですが、必要が生じたからといって、お客様やITベンダの文章力が、急激に向上することはありません(もともと文章力が優れている、ということもまずありません)。
また、それはあくまで現時点でのシステムの内容を記述したものに過ぎないので、そこに新しいデータを載せる、というようなことは考慮されません。既存のシステムと新たに載せるデータとのすりあわせは、別の作業が必要になるはずです。ところが「現状通り」が原則とされてしまっているので、それ以上の検討はされることがない。
後続のシステムにデータを連係して、初めて問題が発覚する、というのはこのような経緯によるものです。

変更が必要になる場合でも、「最小限の変更」にとどめる、との原則があるため、データの正規化やコードの統一などということにパワーがさかれることはなく、まずは新たに載せるデータをそのまま取り込むことが原則になります。
新たなデータを取り込むところは、確かに作業が軽くて済むというメリットがあるかもしれません。ところが、そこで作成されたデータを後続のシステムが使う場合、データ分析の手間はそれぞれの後続のシステムで発生します。たとえば、3つのシステムで使うのであれば手間は3倍です。分析だけではなく、開発または変更の手間も増えるはずです。

「現状通り」「最小限の変更」が、経費の削減や品質の向上(品質の劣化の抑制)につながるかといえば、実際には根拠のない幻想に過ぎない、ということなんだ、と。

・・・というようなことを語り合いましたが、どこの会社のことなのか、業種がなんなのか聞くのを忘れてました。ざんねーん。

無料ブログはココログ

最近のツイート