Zip 製品における日本語ファイル名について

Zip コンポーネントを使用して日本語のファイル名を持つファイルをアーカイブした場合、他のツールで展開しようとすると文字化けすることがあります。

これは、Zip コンポーネントでは既定値ではシステムの既定値エンコーディングを使用するため、日本語 Windows 以外の Windows で日本語拡張機能を使用し日本語ファイルを保存しようとした場合に使用されるエンコーディングが Shift-JIS 以外のものになってしまうことで発生します。この問題に対処するために、Zip コンポーネントには Encoding コンフィグパラメータが用意されています。Shift-JIS ファイル名のメンバーファイルを格納する際には、

zip.Config("Encoding=SJIS");

のようにすることでメンバファイル名として指定された日本語文字列を、Shift-JIS コードに変換した上でZip アーカイブのファイル情報に書き込みます。

なお、書き込まれたファイル名の文字セット情報はアーカイブの情報としては持ちませんので、メンバファイル名をどの文字セットで解釈するかはプログラマの責任において行って頂くことになります。

アーカイブ生成時に指定した文字セットと、展開時に指定した文字セットが異なる場合、ファイル名を正しく扱うことができません。

アーカイブ作成と展開で日本語ファイル名が正しく処理されない場合には、この Encoding コンフィグパラメータをお試しください。

補足: この Encoding コンフィグパラメータは、メンバファイル名だけでなく同時にパスワード文字列にも影響を与えます。Encoding=SJIS が設定されている場合は、パスワード文字列も Shift-JIS 文字列としてアーカイブに書き込まれます。逆に言うと、ファイル名とパスワードは異なる文字セットを利用することはできません。

バージョン番号、ビルド番号の調べ方

/n software 製品のサポートをご利用いただく際には、ご利用製品のバージョン番号やビルド番号が重要な意味を持ちます。これは、製品は日々修正を加えられ進化しており、バージョン番号やビルド番号が異なる場合、動作や応答に違いがある可能性があるのです。従って、的確なサポートを受けるためにはこれらを把握しておく必要があります。

では、以下にこれらの番号の調べ方をまとめておきましょう。

ご利用いただいている製品のインストーラ (setup.exe) が手元にある場合 setup.exe を起動します。起動直後に表示されるスプラッシュスクリーンにバージョン番号およびビルド番号が記載されています。 インストール済みの製品自体で調べる場合 Windows 製品の場合 当該製品の DLL ファイルを右クリックし、ファイルプロパティで製品バージョンを表示します。 .NET 製品の場合は、実行時に以下のコードを実行することでも製品バージョンを知ることができます。 System.Console.WriteLine(snmptrapmgr1.GetType().Assembly.FullName); この結果表示されたものが 8.0.2991.0 であれば、Version 8.0 Build 2991 であることを表します。 Java 製品の場合は、以下のような簡単なコードをコンパイルし実行することで知ることができます。 V8 の場合: System.out.println(ipworks.AboutPropertyEditor.getVersion()); V6 の場合: System.out.println(ipworks.AboutPropertyEditor.VERSION); この結果表示されたものが 8.0.0.2938 であれば、Version 8.0 Build 2938 を意味します。 注: Windows 製品と Java 製品では、ビルド番号の表示位置が異なります。

Control.Invoke / InvokeThrough について・その後

先の記事で紹介した Control.Invoke の件ですが、V8 では .NET CF Edition でも InvokeThrough プロパティがサポートされるようになりそうです。

これにより .NET Edition でもイベント周りのコードディングが簡略化され作成が容易になると思います。現時点では IP*Works! V8 (Core) の社内テストビルドにのみ実装されていますが、特に問題が発生しなければ順次他の製品にも反映されると思います。

Command プロパティについて

IP*Works! 製品では、各コンポーネントは準拠する規格 (あるいはデファクト・スタンダード) に則りメソッドやプロパティを設計してあります。

通常の用途であれば、当該コンポーネントに用意されているこれらのメソッドやプロパティを使用することでほぼ問題なく通信を行うことができます。

しかし、サーバ側が独自の拡張コマンドを使用する場合や、IP*Works! 製品が準拠している規格が改訂され新たにコマンドが追加されたような場合には、既存のメソッドやプロパティでは対処しきれないことがあるかも知れません。

このような場合には、Command プロパティを使用して対応することができます。

この Command プロパティにコマンド文字列を代入すると、当該コマンドがサーバに対し送信されます。

Command プロパティに対するサーバからの応答は、LastReply プロパティまたは PITrail イベントを使用して取得します。

このプロパティは、当該コンポーネントの実装するプロトコルがテキストコマンドおよびテキスト応答を使用する場合にのみ提供されます。例えば、IP*Works! V8 Core では以下のコンポーネントでのみこのプロパティをご利用いただけます。

• FileMailer
• FTP
• HTMLMailer
• IMAP
• NNTP
• POP
• Rexec
• Rshell
• SMTP
• SNPP
• Telnet

例えば FTP には Command プロパティが提供されていますが、よく似た処理をするはずの TFTP には提供されていません。これは、前者はテキストベースのコマンド/応答をサポートしていますが後者はバイナリコードによるコマンド/応答で動作することによります。

About Box (ライセンスダイアログ) について・その2

先日の投稿では .NET Edition におけるライセンスの認識方法を示しました。これは WinForm を前提としていましたが、ASP.NET では少々状況が異なります。

ASP.NET には 1.1 および 2.0 が存在します。

ASP.NET 1.1 アプリケーションでは、WinForm の場合と同様に licenses.licx を用いた Microsoft .NET Licensing Scheme を使用します。従ってその対処法も先の投稿と同じです。

一方 Visual Studio 2005 の ASP.NET 2.0 アプリケーションの場合はちょっと複雑な手順を要します。

1. ソリューションエクスプローラ内で、licenses.licx を右クリック


2. ランタイムライセンスの作成を選択

これにより、App_Licenses.dll が生成されますので、これを作成した ASP.NET 2.0 アプリケーションとともに配布する必要があります。

About Box (ライセンスダイアログ) について

比較的高い頻度でサポートに寄せられるお問い合わせに、「IP*Works! の製品版をインストールしたのに、About Box (ライセンスダイアログ) が表示される」というものがあります。今回は .NET Edition を例に、ライセンスの仕組みと対処法を解説してみたいと思います。

NET Edition では、製品ライセンスに Microsoft Licensing scheme を使用します。これにより、ライセンス済みのコンポーネントをフォームにドロップした時点で "licenses.licx" という名称のファイルが自動生成され、埋め込みリソース (embedded resource) として当該プロジェクトに自動追加されます。Visual Studio .NET 内でライセンス済みコンポーネントを使用するにはこのファイルが必要で、このファイルが存在しないあるいはファイル内に正しい情報が記載されていない場合、About Box が表示されます。

ではフォームを使用しないアプリケーションの場合や、フォームを使用するけれど動的にコンポーネントを生成する場合はどうすれば良いでしょうか。

このような場合には licenses.licx ファイルを手で作成することで対処します。このファイルはライセンス済みコンポーネントの情報から成る行で構成されています。各行にはコンポーネント名およびライブラリ名が記述されています。例えば、nsoftware.IPWorks.dll の NNTP コンポーネントを使用するのであれば licx ファイルには

nsoftware.IPWorks.Nntp, nsoftware.IPWorks

という行が含まれることになります。

なお既定値では Visual Studio は上記以外の付加情報 (バージョン番号やカルチャ等) もこの行に含めます。もしライセンス上の問題が発生した場合は、これらの付加情報を削除し、前述の2項目 (コンポーネント名およびライブラリ名) のみにしてみると状況が改善することがあります。

licenses.licx に関する注意事項:

1. licx ファイルを手作業で作成する場合は、ソリューションエクスプローラを通じて当該プロジェクトに対する埋め込みリソースとして追加されなければなりません。
2. licx ファイルは "licenses.licx" という名称でなければならず、また当該プロジェクトのルートディレクトリに配置されなければなりません。(サブフォルダに配置することはできません。)
3. 開発対象がクラスライブラリの場合は、呼び出し側アプリケーションに対し当該 licenses.licx ファイルをクラスライブラリとともに配布する必要があります。さらに、呼び出し側アプリケーションは当該製品がアクティブ化済みになっているマシン上でコンパイルされなければなりません。（簡単に言えば、クラスライブラリはそれ自身は royalty-free で配布することは認められていません。)

最後にもう1つ注意すべき点があります。Visual Studio .NET はプロジェクト名に空白文字 (" ") が含まれている場合、正しく licx ファイルを認識しないという問題があります。もしプロジェクト名がこれに該当する場合は、プロジェクト名から空白文字を除去するか、別の文字に置き換えてからプロジェクトをリビルドしてみてください。

明けましておめでとうございます。

いよいよ2008年が始まりました。

皆様は初詣に行かれましたでしょうか。

私は３が日明けの１月４日に、妻の実家に近い伊勢神宮の外宮に行きました。ちょうど各党の党首の参拝と重なってしまったようで、某党の党首や総理の参拝にぶつかりかなりの混雑で少々難儀をしました。

その時、こういった場合の移動プラン等はどのくらい公開されるのかに興味を持ちました。

要人は常にテロを避けるための隠密性と、活動をアピールするための公開性の両方のバランスを考え行動する必要があるでしょう。また、提供する情報の粒度（詳細さ）もいろいろなレベルがあります。

これはコンピュータで提供するサービスのセキュリティと利便性の最良の落とし所を決めるのとちょっと似ているなぁ、などと思いました。

まぁ、一般人としては事情を知らずに現地に行っても、混雑を避けうる程度の情報はその場で得られるくらいはして欲しい、という愚痴にすぎませんが (^_^);