最近のトラックバック

2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Google AdSense2

トップページ | 2009年2月 »

2009年1月

ASP.NETでPDFファイルにパスワード設定

ASP.NET(C#)でPDFファイルにパスワード設定するサンプルを紹介する。
このサンプルではiText#(iTextSharp)というフリーライブラリーを利用する。


■iTextSharpの準備方法
iTextSharpはSourceForgeここからダウンロードできる。
必要な物は以下の通り。

DLL 説明
itextsharp.dll iTextSharpのDLL
iTextAsian.dll 日本語リソースのDLL
これらDLLファイルをASP.NETプロジェクトのBinフォルダに配置すればOK。
詳しくはここを参照。


■ASP.NET(C#)サンプル
利用するメソッドは以下の通り。


PdfWriter.SetEncryption(
    PdfWriter.STRENGTH128BITS,
    <読み取り時のパスワード>,
    <書き込み時のパスワード>,
    PdfWriter.AllowCopy | PdfWriter.AllowPrinting);


利用サンプル概要は以下の通り。
OnceMail Labから実行結果及び全ソースを確認できる。

using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;

 :
 :
 :

/// <summary>
/// PDFファイルにパスワード設定
/// </summary>
/// <param name="sSrcFilePath">入力ファイルパス</param>
/// <param name="sDustFilePath">出力ファイルパス</param>
/// <param name="sReadPassword">読取パスワード</param>
/// <param name="sWritePassword">書込パスワード</param>
private static void fnSetPdfPassword(string sPdfFilePath, string sReadPassword, string sWritePassword)
{
    PdfReader reader = null;
    Document doc = null;
    PdfWriter writer = null;
    try
    {
        // 一時ファイル取得
        string sTempFilePath = Path.GetTempFileName();
        // PDFファイルからPDFReaderオブジェクト作成
        reader = new PdfReader(sPdfFilePath);
        // 出力ファイルのDocumentオブジェクト作成
        doc = new Document(reader.GetPageSize(1));
        // 出力ファイルのPdfWriterオブジェクト作成
        writer = PdfWriter.GetInstance(
            doc, new FileStream(sTempFilePath, FileMode.OpenOrCreate));
        // 出力ファイルにパスワード設定
        writer.Open();
        writer.SetEncryption(
            PdfWriter.STRENGTH128BITS, sReadPassword, sWritePassword,
            PdfWriter.AllowCopy | PdfWriter.AllowPrinting);
        // 出力ファイルDocumentを開く
        doc.Open();
        // アップロードPDFファイルの内容を出力ファイルに書き込む
        PdfContentByte content = writer.DirectContent;
        for (int i = 1; i <= reader.NumberOfPages; i++)
        {
            // 新ページ作成
            doc.NewPage();
            // 入力ファイルのページ取得
            PdfImportedPage pipPage = writer.GetImportedPage(reader, i);
            // 入力ファイルのページ内容をダウンロードファイルに挿入
            content.AddTemplate(pipPage, 0, 0);
        }
        // 文章プロパティ設定
        doc.AddKeywords((string)reader.Info["Keywords"]);
        doc.AddAuthor((string)reader.Info["Author"]);
        doc.AddTitle((string)reader.Info["Title"]);
        doc.AddCreator((string)reader.Info["Creator"]);
        doc.AddSubject((string)reader.Info["Subject"]);
        // 出力ファイルDocumentを閉じる
        doc.Close();
        // オリジナルファイルと一時ファイルを置き換える
        File.Delete(sPdfFilePath);
        File.Move(sTempFilePath, sPdfFilePath);
    }
    finally
    {
        // 後始末
        if (writer != null)
            writer.Close();
        if (doc != null)
            doc.Close();
        if (reader != null)
            reader.Close();
    }
}


■関連ページ

開発前に考えること

ASP.NETで業務フレームワークを作成する前に以下のことを押さえておきたい。


1つずつ業務フレームワークとの関係を考えていきたい。


■情報の公開形態
「ASP.NET=Webアプリケーション」であるが、実際には2種類に分別できる。

  • インターネットアプリケーション
  • イントラネットアプリケーション
どちらもブラウザ上で動くため、開発方法も同じと思いがちだが全く別物として扱った方が良い。
なぜならイントラネットと比べインターネットは数段難しい場合が多いからである。

インターネットが難しいと思ういくつかの例をあげると以下のようなものがある。
  • 利用ブラウザが絞りづらい/絞れない。
  • 過剰なセキュリティ対策が必要。
  • ユーザ接続数が爆発的に増える場合がある。
  • 利用時間が24時間365日のためリリースが難しい。
  • ユーザ管理の難しさ。
  • 金銭系の処理の取り扱い。
  • セッションタイムアウトの取り扱い。
  • ブックマーク登録を考慮する必要がある。
  • 不具合におけるユーザ通知・謝罪など。
これらの多くは開発に直接影響がでる。
またページ毎に対策を打つのは余りに効率が悪く且つザルになる可能性が高い。
この点を忘れると開発後期に大きな影響が出る。


■ユーザの主に利用しているブラウザ
利用ブラウザの違いはHTML・CSS・JavaScriptに影響する。
ASP.NET独自の自動ブラウザ判別機能を使う場合は良いか自前でコーディングする場合は注意が必要である。
また利用ブラウザが増えると開発/テスト工数が増えるため注意が必要である。
なお個人的な経験ではサポート範囲を以下に絞っている場合が多いと思われる。

情報の公開形態 主なサポート範囲 理由(推測)
イントラネット Internet Explorer 6.0以上 企業PCのOSはWindowsがデフェクトスタンダードであるため必ずInternet Explorerがインストールされている
インターネット PC:Internet Explorer 5.5以上,Firefox 2.0以上 携帯:ドコモ,au,ソフトバンク PCは2008年末頃のネット調査でInternet ExplorerとFirefoxを加えれば80%以上のブラウザを占めている。
携帯電話は上位3社で国内90%以上のシェアを占めている。


■ユーザの主に利用しているアプリケーション
意外かもしれないが「ユーザの主に利用しているアプリケーション」は把握しておいた方が良い。
なぜなら「ユーザの使い勝手向上=ユーザが使い慣れたアプリケーションの操作に近い」となる場合が多いからである。
逆説的にいえば「使い勝手が悪い=使い慣れない操作方法」とも言える。

また操作方法と近くて異なるもので「スタイルの統一」というのがある。
たとえば、以下のものが分かりやすいとユーザにとって親切であると考えられる。

  • ヘッダー・フッター
  • 見出しスタイル
  • 必須入力項目のスタイル
  • エラー文言の配置位置・文字列
  • 入出力系コントロールの配置位・大きさ
  • ボタンコントロールの配置位置・大きさ

個人的な意見では以下のアプリケーションを参考にすると良いと考えている。
  • Microsoft Office(主にExcel/Word/PowerPoint)
  • Yahoo/MSNなどの大手検索サイト、または官庁系のサイト

多くの人がよく利用するアプリケーションのトップはブラウザ・メーラー・Office製品だろう。
サイトではYahoo・Google・MSNをトップページにしている場合が多いと思う。
これらを抑えることでユーザの使い勝手向上に一歩近づく。

開発が始まってからのスタイル・操作方針の統一は結構手間取る。
初期段階で操作方針を決めきめておくことでこの問題は回避できる。
また初期段階で決まれば業務フレームワークに含めることでシステム全体統一や開発の効率化しやすいメリットも生まれる。


■他システムとの連動方式
他システム連動が無いシステムは、ほとんど無い言ってよいだろう。
主な連動方法に以下のものがある。

  • DB接続
  • FTP転送(XML・CSV・TSVファイル)
  • WebAPI(XML)

[DB接続の場合]
Oracle・SQLServer・DB2・MySQLなどシェア・フリーで様々な製品がある。
接続方式もADO.NETプロバイダ、OLEDBプロバイダ、ODBC、DB専用プロバイダなど様々である。
自システム用DBやシステム拡張時の追加DBを考慮すると、複数の選択肢を選べ、統一的なプログラムを記述できることを事前に考えておく必要がある。

[FTP接続の場合]
ほとんどの場合.NET Framework標準機能で賄える。
場合によっては遅延影響を考慮する必要がある。

[WebAPI接続の場合]
FTP接続と同じく、ほとんどの場合.NET Framework標準機能で賄える。
遅延影響の他に接続上限を考慮する必要がある。

DB接続の場合、.NET Framework2.0からの機能でDbProviderFactoryという複数DB操作を統一化したインタフェースがある。多くの問題が解決できるため業務フレームワークを作る際に考慮した方が良い。
FTP接続、WebAPIの場合、業務フレームワークの一部に組み込むことで各種問題の解決をしやすい場合が多い。


■ユーザ認証の方針
比較的見逃がしがちだがユーザ認証方式は早めに叩く必要がある。
認証方式は「パスワード方式」が一般的だが、最近は「シングルサイオン」を利用している場合もの多い。
また認証がOKでも「ページ全体・ページの一部の利用権限(ロール)」を許可/不許可する必要がある場合がほとんどである。
これらを個々のページで作りこむと統一性やセキュリティフォールになりかねない。
業務フレームワークに認証・許可処理を大きく緩和できる。
なおASP.NETの認証機能は意外と小回りが利かないため、拡張が必要になることが多い点に注意してほしい。


■最大・平均ユーザー数(=セッション数)
■ハード・災害等に障害における耐久性
これら項目はソフト開発だけでなくミドルウエアやハードウエアも考慮する必要がある。
また業務フレームワークを作る際にも避けて通れない個所である。

[利用ユーザ数]
利用ユーザが少ないうちはそれほど問題がない。しかし多くなるとにつれ負荷分散を考慮する必要がある。
負荷分散は「ハードウエアを使ったロードバランサー」と「ソフトウエアを使ったNLB」の2種に分かれる。
どちらの場合もセッションやキャッシングの利用方針に影響を与える。
セッションやキャッシングは共通フレームワークと綿密な関係にある場合が多く、開発前に確定しないと後戻りの作業や場合により大幅な修正が発生する必要がある。

[ハード・災害等に障害における耐久性]
対障害性の確保として電源の2重化・バックアップ・サーバクラスタリング等の方法がある。
特に開発に大きな影響があるのがDBサーバの「サーバクラスタリング」である。
DB障害発生時にも業務を止めない方式としてセッションの格納先をDBするケースが多いと思うが、 これはセッション管理方針をDB格納に以下の対応をする必要がある

  • セッションに格納できるデータ型はシリアル化可能なデータだけである。
  • セッションに大きなデータを含めてはならない。
前者は開発環境から運用環境に移動した場合に型変換不具合として発生しやすい。
後者は運用後、しばらくしてからメモリー不足という形で不具合として上がる必要がある。
どちらも業務フレームワークを作る際、または開発環境を作る際に気をつけておくと、ある程度緩和できる。

業務フレームワークの目的

個人的にASP.NETで開発をする場合、業務フレームワークを用意した方が開発効率が良いと感じている。
このことは幾つかのシステム開発に携わった人からは同意いただけると思う。
しかし実際に開発してみると意外と情報がなかったり、担当システムとは異なる場合も多いと思う。
本ブログでは独自解釈であるが業務フレームワークについて書いていこうと思う。
なお一般的な解釈と異なる点も多いとため「これは違う!」という意見も多いと思うが、本ブログ独自解釈のため笑ってスルーしてほしい。


本ブログでの業務フレームワークの定義は以下のものとする。

  • 該当システムに特化したオリジナルのフレームワークである。(.NET Frameworkとは別物)
  • 業務共通部品の一部である。


業務フレームワークを作る目的は以下のものである。

  • チーム開発効率の効率化。
  • UIの統一化。
  • スタイルの統一。
  • 全体的なセキュリティの向上。
  • 保守性の向上。
  • 高い柔軟性と拡張性。


次回以降では、トピック的に投稿していこうと思う。

トップページ | 2009年2月 »

Google AdSense


  • ---

Amazon ウィジェット

  • ウィジェット

@niyo_naのツイート

無料ブログはココログ

Google Analytics