November 17, 2005

Excelで生成した1-2-3形式FileをImportすると文字化けする問題

テーマ:Trouble Info

最近、1-2-3形式(WK4)ファイルからViewにDataをImportすることなどありませんでしたが、とあるお客様でImportしたDataが文字化けして表示されてしまうという問題を経験しましたので、皆さんにも参考になるかと思い、ここに掲載しておきます。


Lotus 1-2-3は今では格安で販売されていたりしますが、新しいReleaseが出てくることも無くなり、利用されている方も少なくなったのではないかと思います。


一方、NotesはViewや文書へのImportはExcelのXLSファイルを直接読み込むことはできないため、Excelで1-2-3形式(WK4)で保存して、Notesで読み込むという処理はよく行われている処理だと思います。


Notesは、Import形式は1-2-3形式とかStructured Textとかが選択できますが、CSVはImportできませんので、ExcelでWK4を生成して、そのDataをViewにImportするという方法をとられています。ExportはNotes 6.5以降でCSV形式をサポートしています。


(訂正とお詫び 始め 2006/09/26)

以下の表現がありましたが、CSV形式のExportはNotes 6.5からサポートされていますが、Importはサポートされていませんので、訂正しお詫び致します。


「特にNotes 6.5以前は、Import形式は1-2-3形式とかStructured Textとかが選択できますが、CSVはImportできませんでしたので、R4.xやR5をお使いの場合は、ExcelでWK4を生成して、そのDataをViewにImportするという方法をとられています。」

(訂正とお詫び 終わり)


Excelと1-2-3の大きな違いとして、ExcelはCell内で文字を入力する際にAlt+Enterで改行(0x0A)を入力することができるのですが、1-2-3は改行を入力することはできません。


1-2-3を使っていれば、改行CodeがCell内の文字に存在することはないのですが、Excelだとできてしまうのです。


元々、Notesは1-2-3のファイルを読み込むということを想定して、改行Code(0x0A)があることなど想定もしていなかったのかも知れません。


1-2-3を使っている限り一切問題は発生しません。



Excelで改行(0x0A)を使った場合、そのCodeは、0x0A 0xXX 0xYY のように改行の後にDBCS Codeが書かれて表現されています。


このDataを1-2-3形式で保存すると、1-2-3はLMBCS(Lotus Multi-Bytes Character Set)という3 BytesのCodeを使って表現されるためにExcelはその形式に合わせてDataを生成するのですが、上記のような0x0A 0xXX 0xYYというCodeがあった場合に、残念ながら、このCodeの前にLMBCSの言語Codeを加えて保存してしまい、0x10 0x0A 0xXX 0xYY というようなDataを生成するのです。


最初に付加された0x10は日本語であることをあらわしています。


しかし、これでは、LMBCSの3 Bytesではなく、4 BytesのCodeになってしまっています。


これを1-2-3で表示してみると、0x0Aの部分が「・」として表示され、読めないDataになるわけではありません。


このようなCodeを含んでしまった1-2-3形式(WK4)ファイルをNotes Clientで読み込むと、3 BytesがLMBCSであると判断し、0x10 0x0A 0xXX と余った0xYYもLMBCS Codeに最適化するために、0x10 0x10 0xYY というCodeに変更して保存するのです。


ここで、皆さんは気が付かれるでしょうが、このCodeだと、LMBCS文字としてExcelで入力された文字を正しく表現していないことになります。


それは仕方のないことで、元々、Excelが吐き出したWK4ファイルが正しくLMBCSを生成していないことに起因しています。


こういった、不正なLMBCS Dataが入ってしまったNotes DBのDataをViewで表示すると、R4.xやR5でUnicode Displayを使わない場合は偶然正常に表示されてしまうのです。


というのも、R5までの標準は文字を表示する場合にccStrというModuleを使って表示するのですが、このModuleは上記で生成された 0x10 0x0A 0xXX 0x10 0x10 0xYY から0x10というLMBCSの言語表現のByteを抜いて0x0A 0xXX 0xYY というDataをOSに渡して表示を行っていたのです。


このDataがくるとWindowsは正常に改行と文字ということがわかり、表示は正常に行われます。


所が、Notes R5からはUnicode Displayが可能になり、Notes 6.xではそれが標準となっていますが、Notes 6.xでは従来のccStrからLCUというModuleに変更され、このModuleはLMBCSのCodeを正しく扱い、0x10 0x0A 0xXX 0x10 0x10 0xYY を二つの文字として表示するようになったのです。


となると、最初の3 Bytesも2番目の3 BytesもLMBCSですから、それをその通りに表示します。


即ち、ここで文字化けが発生するのです。


文字によって、表示は異なりますが、0x0Aだけでなく、その後の文字までもが文字化けを起こし、1-2-3で見た場合とは異なり、0x0A以降の日本語1文字が完全に文字化けしてしまい、読めない状況になるのです。


回避策はないのか?と皆さんは思われることでしょう。


幾つか回避策は存在します。


1.ExcelでAlt+改行を使って 0x0A Codeを入力しないこと


2.Excelで1-2-3形式File(WK4)を生成した後に1-2-3でもう一度保存しなおすこと(しかし、1-2-3をお持ちでない方にはできません)


3.Excelで生成した1-2-3形式FileからNotesのViewにImportした後、再度、Notesから1-2-3形式でExportして、再度Importすること


こういった処理を行えば、0x0Aが排除され正常なDataになります。


しかし、皆さんのDBの中には、過去のDataもあるでしょう。


ExcelからImportしたDataがTextのみのまま、DBの文書のFieldに存在していて、他のFieldにDataが追記されていなければ、処理は容易です。


上記の3の方法でExportしてImportすればTextは直ります。


しかし、ApplicationによってはImport後に、追加FieldにDataを入れたり、Richtext Fieldに設定していたりする場合もあるかも知れません。


また、重要なDataで他のDBから文書Linkされているような場合もあるかも知れません。


そのような場合は、Export/Importだけでは解決ができない場合もあるでしょう。


そのような場合は、文字化けしている部分を見つけて手作業で直すしかうまい方法はないかも知れないのです。


こういった事を起こさないためにも、Excelで1-2-3形式ファイルを生成する場合は注意していただきたいと思います。


DBに不正なCodeが生成されて残ってしまうことも問題ですし、それにより、さまざまな問題が起こるかも知れません。



この問題は、Notes 6.5.6で不正なLMBCSを持ったExcelで生成されたWK4 FileをImportする場合に0x10 0x0Aを発見すると、0x0Aを無視してしまうような修正が行われる予定です。


Excelが生成するLMBCSが不正なのですが、それが直るのはいつになるかわかりませんから、防御策としてNotes側で対応するようです。




皆さんも、お使いのApplicationでExcelからDataをViewにImportしているような場合は、注意してください。


特にNotes R4.xからNotes 6.xに移行される場合はそういうことが無いかのチェックを行うようにした方が安全です。


いいね!した人  |  コメント(0)  |  リブログ(0)

いわまんさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

最近の画像つき記事
 もっと見る >>

コメント

[コメントをする]

コメント投稿

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。