こんにちは。
比較的新しい技術で開発しておりなかなか参考文献がなく四苦八苦しています。
現在、.NET Frame Work3.5のPackageクラスを使用してフォルダを圧縮・解凍す
るアプリを作成しています。
URIを作成する箇所でファイル名が日本語の場合に文字化けしてしまい困ってい
ます。
Uri^ uri2 = PackUriHelper::CreatePartUri(gcnew Uri(/test/ああ.txt ,
UriKind::Relative)
uri2の中身が「/test/%E81%E82%E81%E82.txt」となってしまう。
MSDN等で調べてみましたらCreatePartUriでURIを作成する際に「UTF-8」で自動的
にエンコードされてしまうようです。
これをエンコードさせないようにする方法、もしくはエンコードされてしまった
URIをデコードして戻す方法があれば教えて頂けないでしょうか？
System::Web空間にあるHttpUtilityクラスにデコードするメソッドがあったので
すが戻り値がstringのため再度、URIのインスタンスを生成する際に「/test/ああ
.txt」だと不正なURI扱いされてしまいます。
URI作成時にエンコードをかけな方法があれば一番良いのですがそのようなことは
可能でしょうか？
Uri^ uri2 = PackUriHelper::CreatePartUri(gcnew Uri(/test/ああ.txt ,
UriKind::Relative)
string^ hoge1 = uri2::Tostring();
string^ hoge2 = HttpUtility::UrlDecode(hoge1);
hoge2 = /test/ああ.txt
このようにエンコードされたURIをstring型にならデコード出来るのですが・・・。
何とかしURI型を維持したままデコード出来ないでしょうか？
そもそも、エンコードされていないものは URI として不正です。
「/test/%E81%E82%E81%E82.txt」は URI ですが、「/test/ああ.txt」は正しい URI では
ありません。
展開時にデコードするのではだめなのですか？
ここから先は推測になりますが、Package クラスを使って、zip ファイルを扱うアーカイ
バを作ろうとしていませんか。
おそらく、パッケージ内のファイル名が URI でしか表せないと、普通の zip アーカイバ
で展開した際に、ファイル名がエンコードされてしまっているのがご不満なのではないか
と思います。
しかし、Package クラスは OPC（Open Package Conventions）の仕様に従った zip ファ
イルを扱うためのクラスであって、OPC に準拠していない zip ファイル一般を扱うこと
を意図して設計されたクラスではないと思います。
そのため、zip アーカイバを作るための便利なクラスライブラリとして Package クラス
を使おうというのが、そもそも間違いではないでしょうか。
>>aetosさん
さっそくのアドバイスありがとうございます。
>>ここから先は推測になりますが、Package クラスを使って、
>>zip ファイルを扱うアーカイバを作ろうとしていませんか。
はい、お察しの通りアーカイバを作成しようとしています。
>>パッケージ内のファイル名が URI でしか表せないと、普通の
>>zip アーカイバで展開した際に、ファイル名がエンコードされ
>>てしまっているのがご不満なのではないかと思います。
はい、まさにここでつまづいています。
>>zipアーカイバを作るための便利なクラスライブラリとして Package クラス
>>を使おうというのが、そもそも間違いではないでしょうか。
一応、J#のライブラリを使用するアーカイバも作成したのですがライブラリを
インストールしなければならない点がひっかかり行き着いた先がPackageクラス
でした・・・。
>>展開時にデコードするのではだめなのですか？
展開時でも文字化けが回避できれば問題ありません。
Uri1 = /test/%E81%E82%E81%E82.txt
PackagePart packagePartResource =
package.CreatePart(Uri1,
System.Net.Mime.MediaTypeNames.Text.txt);
using (FileStream fileStream = new FileStream(
D:\\test\ああ.txt, FileMode.Open, FileAccess.Read))
{
CopyStream(fileStream, packagePartResource.GetStream());
}
private static void CopyStream(Stream source, Stream target)
{
const int bufSize = 0x1000;
byte[] buf = new byte[bufSize];
int bytesRead = 0;
while ((bytesRead = source.Read(buf, 0, bufSize)) > 0)
target.Write(buf, 0, bytesRead);
}
サンプルがC#になってしまいすみません。最終的には圧縮はストリームで書
き込みを行っていますのでこのタイミングでデコード出来れば良いのですが
・・・。これが厳しそうであれば展開時でも問題ありません。
> 展開時でも文字化けが回避できれば問題ありません。
もちろん可能でしょう。
展開も同じように書庫内のストリームから展開先のファイルストリームにコピーするよう
にすれば、展開先のファイル名は任意に設定できますよね。
ただし、それはそのように実装したあなたのアプリを使って展開すればの話であって、他
のアーカイバ、例えば WinZip とかを使った場合は不可能（エンコードされた名前で展開
される）でしょう。
ついでに、先ほど簡単なアプリを作って Package クラスで zip ファイルを作ってみまし
たが、自動的に [Content_Types].xml というメンバが作られますね。
普通のアーカイバで展開すると、このファイルも展開されてしまいます。
もしそれを望まないのなら、やはり Package クラスは諦めたほうがいいと思います。
Package クラスをどうしても使わなければならない事情がない（他のライブラリでもよ
い）のであれば、例えば #ZipLib など使ってみてはいかがでしょうか。
http://www.icsharpcode.net/OpenSource/SharpZipLib/Default.aspx
>>aetosさん
いろいろとアドバイスありがとうございました。
とりあえず同じPackageクラスを使用して作成した展開処理にてデコード処理を
噛まして展開時にファイル名の文字化けがなくなっていることを確認できました。
今回、Packageクラスにこだわった理由としてはJ#のクラスやziplibだと外部ライ
ブラリを使用しなければならないため極力、既存のクラスのみで駆使して作成した
かったのです。
>>自動的に [Content_Types].xml というメンバが作られますね。
>>普通のアーカイバで展開すると、このファイルも展開されてしまいます。
>>もしそれを望まないのなら、やはり Package クラスは諦めたほうがいいと思いま
>>す。
今回はPackageクラスで作成したアーカイバのみを使用してフォルダを圧縮＆解凍す
るため[Content_Types].xmlが含まれても特に問題ありません。
>>ついでに、先ほど簡単なアプリを作って Package クラスで zip ファイルを作って
>>みましたが、
本件は一応、解決済みなのですが別問題としてこのクラスを使用して圧縮ファイルを
作成した時に何故かJPEGやビットマップファイルがサイズ的に圧縮されていない気が
します・・。CreatePartメソッドの引数で圧縮モード(CompressionOption)が設定で
きるようですがこれを設定すると圧縮前より圧縮した後のほうがサイズが大きくなっ
てしまっているようです・・。う～ん何故でしょう。謎ですね。
>>aetosさん
いろいろとアドバイスありがとうございました。
とりあえず同じPackageクラスを使用して作成した展開処理にてデコード処理を
噛まして展開時にファイル名の文字化けがなくなっていることを確認できました。
今回、Packageクラスにこだわった理由としてはJ#のクラスやziplibだと外部ライ
ブラリを使用しなければならないため極力、既存のクラスのみで駆使して作成した
かったのです。
>>自動的に[Content_Types].xmlというメンバが作られますね。
>>普通のアーカイバで展開すると、このファイルも展開されてしまいます。
>>もしそれを望まないのなら、やはり Package クラスは諦めたほうがいいと思いま
>>す。
今回はPackageクラスで作成したアーカイバのみを使用してフォルダを圧縮＆解凍す
るため[Content_Types].xmlが含まれても特に問題ありません。
>>ついでに、先ほど簡単なアプリを作って Package クラスで zip ファイルを作って
>>みましたが、
本件は一応、解決済みなのですが別問題としてこのクラスを使用して圧縮ファイルを
作成した時に何故かJPEGやビットマップファイルがサイズ的に圧縮されていない気が
します・・。CreatePartメソッドの引数で圧縮モード(CompressionOption)が設定で
きるようですがこれを設定すると圧縮前より圧縮した後のほうがサイズが大きくなっ
てしまっているようです・・。う～ん何故でしょう。謎ですね。
JPEGは多少なら増えることはあるよ。
JPEGはすでに圧縮されているファイルであり
バイナリエディターで見ればわかるが同じデータが並ぶことの少ないデータだから。
無駄に時間かかるだけ。
ビットマップファイルはPC画面をスクリーンキャプチャしたものなど
同じデータが並びやすいものなら圧縮できるはず。
>>wclrp ( 'o')さん
アドバイスありがとうございます。
>>JPEGは多少なら増えることはあるよ。
>>JPEGはすでに圧縮されているファイルであり
>>バイナリエディターで見ればわかるが同じデータが並ぶことの少ないデータだから。
>>無駄に時間かかるだけ。
>>ビットマップファイルはPC画面をスクリーンキャプチャしたものなど
>>同じデータが並びやすいものなら圧縮できるはず。
大変勉強になります。ただ他のLhaca等のアーカイバを使用して同じフォルダ
をZip圧縮するとあからさまにPackageクラスで圧縮したZipフォルダの方がデ
スク上のサイズが大きくなってしまいなおかつZipフォルダ内のそれぞれのフ
ァイルについて圧縮率が0%になっていたのでもしかしたら全く圧縮されていな
いのかなと思ってしまいました。そもそも圧縮した結果が他のアーカイバと同
じ結果を期待してはダメなのでしょうか？
度々すみませんがPackageクラスでのアーカイバ作成の良い参考ページがほとんどな
いため教えていただけると助かります。
>>aetosさん
>>同じになるとは限らないでしょうね。
>>Package クラスを使わない他のアーカイバであっても、違うアーカイバを使
>>うだけで結果は異なることがあります。
なるほど～、いろいろなアーカイバでもう少し試してみることにします。
>>wclrp ( 'o') さん
>>ビットマップファイルはPC画面をスクリーンキャプチャしたものなど
>>同じデータが並びやすいものなら圧縮できるはず。
上記試してみました。確かにPC画面をスクリーンキャプチャしたビットマップだ
と圧縮され理想どおりの圧縮率になりました。ただし写真などのビットマップは
やはり圧縮前より圧縮後のほうがサイズが大きくなってしまうようです(><)
画像に左右されずにどんなビットマップでも均等に圧縮をかけたいのですがこれ
をPackageクラスに臨んではダメなのでしょうかね。ちなみにJ#のライブラリを使
用したアーカイバだと画像に左右されずに圧縮されます。
> 確かにPC画面をスクリーンキャプチャしたビットマップだと
> 圧縮され理想どおりの圧縮率になりました。
> ただし写真などのビットマップはやはり圧縮前より圧縮後のほうが
> サイズが大きくなってしまうようです(><)
圧縮の基本的な考え方は、「似たようなデータが並んでいるところを、より小さなデータ
量で置き換える」というものです。
ビットマップで言えば、似たような色が並んでいる画像はより小さくなりますが、写真の
ように様々な色が精緻に使われているような画像は、そもそも小さくなりにくいのです。
> 画像に左右されずにどんなビットマップでも均等に圧縮をかけたいのですが
> これをPackageクラスに臨んではダメなのでしょうかね。
Package クラスに限らず、どんな圧縮アルゴリズムにも「どんなデータも均質に圧縮す
る」ことは望めません。
> 画像に左右されずにどんなビットマップでも均等に圧縮をかけたいのですが
もしそうなら、「どんな画像も情報量は変わらない」ことになりません?
極論すれば「どんな画像も真っ白なのと変わらない」てことに。ありえねー。
うーーん、
Packageクラスって圧縮形式はZIPってことでいいんんでしょうか？
ZIP形式にも基本の使用があるけれど、フリーでソースも公開しています。
そのため、そのソースを利用したいろんな圧縮ツールが出てます。
しかし、僕の予測で基本はunix付属のZIPだと思います。
aetosさんが推薦した「ZIPLIB」になるんでしょうか。
WINDOWSで基準なのがシェアウエアで「WINZIP」だと思います。
Packageクラスがどういう仕様か分かりませんが基本の仕様は同じだと思います。
もしこだわるのなら、Packageクラスをやめて
aetosさんが推薦した「ZIPLIB」を利用するのがいいと思います。
JEPGファイルは圧縮率を変えられたはずですね。
仮にビットマップファイルを作ってみてそれをフリーの変換ソフトで
無圧縮のJEPGファイルを作成し、それをZIPに変換すると変わると思います。
aetosさん
>>圧縮の基本的な考え方は、「似たようなデータが並んでいるところを、
>>より小さなデータ量で置き換える」というものです。
>>ビットマップで言えば、似たような色が並んでいる画像はより小さくな
>>りますが、写真のように様々な色が精緻に使われているような画像は、
>>そもそも小さくなりにくいのです。
なるほど、圧縮についてそこまで深く勉強したことがなかったので大変に
参考になりました。ただ写真のように色が精緻に使用されているものに関
してサイズが小さくなりづらいというのは納得出来たのですが逆に圧縮後
のサイズの方が大きくなってしまう件に関してはどうも腑に落ちません。
Packageクラスが精緻な画像だと正しく処理してくれないようなものなので
しょうか？
επιστημηさん
>>もしそうなら、「どんな画像も情報量は変わらない」ことになりません?
>>極論すれば「どんな画像も真っ白なのと変わらない」てことに。ありえねー。
確かにおっしゃるとおりでした(汗)上にも述べましたが私が腑に落ちないとこ
ろは精緻な画像だと圧縮がかかりづらいことは納得出来たのですが逆に圧縮後
のサイズのほうが大きくなってしまうことに関してやっぱり疑問が残ります。
返信する
最新の投稿: お久しぶりです、いかがお過ごしでしょうか。 最新のメンバー: gantez 最近の投稿 未読の投稿
