2020年4月
      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    

最近のコメント

最近のトラックバック

無料ブログはココログ

« 2020年3月 | トップページ

2020年4月

2020年4月19日 (日)

Base64で送信されてきたhtmlから画像ファイルの保存と、相対パスに書き換えるプログラム(C#)

ダウンロード - e8b387e69699.zip

ASP.Net(Web Form)で、クライアント側からBase64で送信されてきた画像ファイルを、html文から抜き出して、Webサーバに保存して、相対パスに置き換えるプログラムです。.aspxのプログラムから一部抜粋しています。



using System.Text.RegularExpressions;
using System.IO;

(省略)

#region SaveBase64ToImageAndReplaceUrl/ Base64で送信されたhtmlから画像ファイルをサーバに保存して、URLを置き換える
        /// 
        /// Base64で送信されたhtmlから画像ファイルをサーバに保存して、URLを置き換える
        /// 
        /// html
        /// 置き換えられたhtml
        public static string SaveBase64ToImageAndReplaceUrl(string htmlContent)
        {
            //base64の正規表現 
            string strImg = @"data\:image/(jpeg|png|gif|jpg|bmp);base64\,(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?";

            //正規表現で、Base64を画像ファイルへの相対パスに置き換える
            string content = Regex.Replace(htmlContent, strImg, new MatchEvaluator(ReceiveImage), RegexOptions.Compiled | RegexOptions.IgnoreCase);
            return content;
        }
        #endregion

        #region ReceiveImage / 画像ファイルを受信して、サーバに保存して、相対パスを返す
        /// 
        /// 画像ファイルを受信して、サーバに保存して、相対パスを返す
        /// 
        /// 正規表現で一致したBase64の文字列
        /// 画像ファイルへの相対パス
        private static string ReceiveImage(Match match)
        {
            return ReceiveImage(match.Value);
        }

        /// 
        /// 画像ファイルを受信して、サーバに保存して、相対パスを返す
        /// 
        /// 正規表現で一致したBase64の文字列
        /// 画像ファイルへの相対パス
        private static string ReceiveImage(string imgBase64)
        {
            
            if (imgBase64.Substring(0, 10) != "data:image")
                return imgBase64;

            //拡張子を取得
            string fileExtention = GetImageFileExtention(imgBase64);

            //Base64の先頭部分を取る
            imgBase64 = Regex.Replace(imgBase64, @"data\:image/(jpeg|png|gif|jpg|bmp);base64\,","");

            //バイト配列にしてから、サーバの設置場所にファイルを保存する
            Byte[] imgByteArray = Convert.FromBase64String(imgBase64);

            string SavePath = HttpContext.Current.Server.MapPath("../Upload/");

            string filename = DateTime.Now.ToString("yyyyMMddHHmmssfff") + fileExtention;

            File.WriteAllBytes(SavePath + filename, imgByteArray);

            //相対パスを返す
            return "../Upload/" + filename;
        }
        #endregion

        #region GetImageFileExtention/ 拡張子を取得する
        /// 
        /// 拡張子を取得する
        /// 
        /// Base64のコード
        /// 
        private static string GetImageFileExtention(string imgBase64)
        {
            //ファイルの種類を取得する
            Regex re = new Regex(@"data\:image/(?.*?);base64\,", RegexOptions.IgnoreCase
                                | RegexOptions.Singleline);
            Match match = re.Match(imgBase64);

            //拡張子にして返す
            return "." + match.Groups["fileExtention"].Value;
        }
        #endregion

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」 の感想

 

 

『みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」』(日経BP)を読みました。
私も、一応IT技術者で、IT業界に身を置く身ですし、知人もみずほ銀行の2019年に稼働した勘定系システム「MINORI」の開発に関わっており、開発工数の35万人月の何人月かは、彼の分だったので、書店で並んでいるのに気になって読んでみました。

 

構成としては、2019年に稼働した勘定系システム「MINORI」の開発や今後について、2011年3月に発生した、東日本大震災での義援金受付でのシステムトラブル、2002年4月の第一勧業銀行、富士銀行、日本興業銀行の三行合併の直後に起きたシステムトラブルという、この19年に及ぶみずほ銀行のシステムに関することがまとめられています。
2002年4月の第一勧業銀行、富士銀行、日本興業銀行の三行合併の直後に起きたシステムトラブル、については、以前「動かないコンピュータ」で読んだことがあるような気がするので、再録なのでしょう。

ちょっと残念だったのは、2019年に稼働した勘定系システムについて、やや奇麗事で片付けられているなという感じを受けました。35万人月もかけた、プロジェクトでどんないざこざが起きて、どのようになったのかが、あまり見えなかったのは残念です。

このような大規模システムに関わることは、今の職場ではなさそうですが、それでも気になる事、自分の会社でもやらないといけないと思ったことはありましたので、まとめておこうと思います。

 

2019年に稼働した勘定系システムの開発プロジェクト

ユーザ部門が要件定義時に「現状と同じで」というAS ISの要件定義は、禁止して、あるべき業務フローを考えさせた。

ユーザ部門は、本当に今のままでよろしくということが、多いので、これをやったことは、すごいと思います。
私の経験した中で最悪のパターンは、現状システムから出ている帳票の数字の根拠が分からないのに「これでよろしく」という客がいました。

 

4重チェックでシステム品質を高めた

開発エンジニア(第1線)、開発エンジニアのプログラムを側でチェックする(第1.5線)、情報システム部門の視点で品質を満たしているチェックする(第2線)、業務監査の視点で品質をチェックしている(第3線) 業務監査視点でのチェックをするというのは、なかなかできないことだと思いましたが、システムは社の業務に深く関わることですから、基幹システムですと、これぐらいやらないといけないのかもしれません。

要件定義前に建てたスケジュールの見直し

要件定義をした後に工数を見直した結果、当初の想定より長引く工程があって、スケジュールを見直したようですが、通常ですとベンダーの検収に関わったりして、無理やりなスケジュールのまま突き進まなかったのは良かったのかと思います。

 

ユーザ部門に早い段階でシステムの機能確認をさせた

要件通りに作っても、出来上がったシステムを見て、「あーじゃない、こーじゃない」とユーザ部門が言うのが常ですが、それを早い段階でつぶしていったのだなと思いました。

 

システム切り替え時も入念な準備と訓練を行っていた

システム切り替え時の進捗管理ツールまで作っていたらしいですが、そこまでできなくても事前準備を入念にやったりはできるかなと思います。移行時の「トラブルを想定した訓練も行ったりしていたようで、このあたりは、自分の会社でもやっておいた方が良いかもしれません。

2011年3月の震災直後のトラブル

システムの老朽化対策をしていかないといけない

1回作ったから終わりでは無くて、新規開発ではなくても適宜改修作業はしていかないといけないと思いました。

トラブル発生時の手順や判断基準を予め作っておかないといけない

システムトラブル時に、その場で手順を作ったりせずに、事前に手順や切り戻しのタイミング、役員への連絡するタイミングなどを作らないといけないと思いました。

システムがブラックボックス化するとトラブルが長引く

退職者からの引継ぎが十分でなかったりして、システムの全容を把握できていなかったりすると、ブラックボックス化してトラブルの要因やトラブル解決に時間がかかったりしてしまうようになってしまうなと、心当たりがあることが書いてありました。

 

販売サイトへのリンク

e-honへのリンク
hontoへのリンク

« 2020年3月 | トップページ