JavaのPart.getSizeメソッドの使い方を完全ガイド!初心者でもわかるアップロードファイルのサイズ取得
Javaの基礎を体系的に整理しながら学習したい方には、 資格対策としても定評のある定番教材が参考になります。
Javaプログラマ Silver SE 17 教科書をAmazonで見る※ Amazon広告リンク
生徒
「先生、Javaでアップロードされたファイルのサイズを調べたいんですけど、どうすればいいですか?」
先生
「その場合は、javax.servlet.http.PartインターフェースのgetSize()メソッドを使えば、ファイルサイズ(バイト単位)を取得できますよ。」
生徒
「バイトで返ってくるんですね!じゃあ、表示するときにはKBとかに変換して表示すればいいんですね?」
先生
「そうです!それでは具体的な使い方を見てみましょう。」
1. getSizeメソッドとは
Part.getSize()メソッドは、Servletでファイルアップロード処理を行うときに使用するメソッドで、アップロードされたファイルのサイズ(バイト単位)を取得します。
たとえば、100KBのファイルをアップロードした場合、getSize()は102400(バイト)という値を返します。
2. HTMLフォームの例
ファイルアップロードには、enctype="multipart/form-data"を指定したHTMLフォームが必要です:
<form action="/upload" method="post" enctype="multipart/form-data">
<input type="file" name="uploadFile">
<button type="submit">アップロード</button>
</form>
3. ServletでgetSizeを使う方法
JavaのServletでは、@MultipartConfigを使ってファイルアップロードに対応し、request.getPart()でPartオブジェクトを取得できます。
@WebServlet("/upload")
@MultipartConfig
public class UploadServlet extends HttpServlet {
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
Part filePart = request.getPart("uploadFile");
long fileSize = filePart.getSize();
System.out.println("アップロードされたファイルのサイズ: " + fileSize + " バイト");
}
}
4. ファイルサイズの単位変換
ファイルサイズはバイト単位で返されますが、ユーザーに表示する場合はKBやMBに変換することが一般的です。
long fileSize = filePart.getSize();
double fileSizeKB = fileSize / 1024.0;
double fileSizeMB = fileSize / (1024.0 * 1024);
System.out.printf("サイズ: %.2f KB (%.2f MB)%n", fileSizeKB, fileSizeMB);
5. ファイルサイズ制限とgetSizeの使いどころ
アップロードされたファイルがサーバー側の制限を超えていないかどうかを確認するのにもgetSize()は便利です。
例えば:
if (filePart.getSize() > 5 * 1024 * 1024) { // 5MB超
throw new ServletException("ファイルサイズが大きすぎます。");
}
6. getSizeを活用したログ出力や解析
アップロードされたファイルのログ出力や、サイズごとの処理振り分けなど、getSize()は多くの場面で活用できます。
- 管理者向けにアップロードログを記録
- サイズが小さい画像はメモリ処理、大きい画像はディスク保存など
- バッチ処理で一定サイズ以上のファイルのみ処理対象に
7.まとめ
全体像の再確認
これまでの学習ではアップロードの入り口から受け付けの検証そして結果の表示に至るまでの流れを一歩ずつたどった。中心にあるのはファイルの大きさであり受付直後に正確な値を手に入れ判断と記録と表示へつなげる。特にサイズの取得と単位の変換と上限の判定の三点は切り離せない基礎である。数値をむやみに丸めず元の値で比較し表示は人に読みやすい書式へ整える。これだけでも体験は安定し運用はぐっと楽になる。
実装ではフォームの設定と受け付けの注釈としきい値の設計が肝心である。入力側には許容される大きさと推奨の形式を明記し送信前の不安を減らす。受け付け側では測定した値を記録に残し後日の調査や傾向分析に役立てる。違反が起きた場合には原因と次の一手を明確に示し再試行への導線を断たない。こうした地味な工夫が使いやすさと信頼感を支える。
単位と丸めの扱い
人に見せる値はキロバイトやメガバイトが理解しやすい。だが判定は必ず元のバイトで行う。境界付近では小さな丸め誤差が合否を左右するからである。表示用の桁数は用途により揃え四捨五入か切り上げかを先に決めておく。複数の画面で同じ関数を用いれば表記がぶれず迷いが減る。単位が異なる記録を比較する場合も最終的には共通の尺度へそろえておくと整合が取りやすい。
制限設計と受け付けの方針
受け付けの上限は一件ごとの枠と合計の枠を分けて考える。前者は偶発的な巨大内容を抑え後者は同時送信の集中を和らげる。小さな内容は一時領域で処理し大きな内容は保存領域へ直行させると負荷が滑らかになる。制限に触れた場合は明確な理由と対処の提案を添える。画像なら解像度の調整や圧縮文章なら不要部分の削除や形式の見直しなど具体的な手立てを示すと離脱が減る。
ログと監視の設計
記録には時刻と識別子と大きさと判定結果を最低限として残す。しきい値を越えた場合は実測値と基準を併記し再現しやすくする。日別や週別の集計を作り傾向を可視化すると混雑の時間帯や予兆が見つかる。異常な増加が続くときは自動送信の暴走や不正な連続試行を疑い段階的な制限強化で防御する。通知の仕組みを用意しておけば担当者が素早く状況を把握でき対処が迅速になる。
画面表示と案内文
画面では入力欄の近くに上限値を強調して示し推奨の拡張子や大きさの目安も添える。成功のときは取り込んだ大きさを伝え想定どおりであると確認できるようにする。失敗のときは理由と選べる次の一手を簡潔に並べる。進行中は待ち時間を見える化し中断が起きても状態を丁寧に知らせる。こうした細部の積み重ねが安心感と信頼感を生み出す。
境界値と試験の着眼点
品質を守るためには境界付近の試験が重要である。上限ちょうどの場合の扱いを仕様として固定し自動で繰り返し検証する。極小の大きさや空の内容が届いたときの挙動も忘れずに確かめる。失敗の道筋では途中で通信が途切れる場合や一部だけが届く場合を再現し穏やかな案内で再試行へ導く。試験の結果は記録と突き合わせて整合を取り後日の調査に役立てる。
複数ファイルと合計判定
複数を同時に受け付ける場合は一件ごとの判定と合計の判定を分け両方の結果を明示する。合計がしきい値を越えたときに受け付け済みの分を取り消すのか分割して許すのかは方針として先に決めておく。一覧では各行の大きさと合計と平均を併記し並べ替えや絞り込みで重い内容を見つけやすくする。履歴の分布を出して種類ごとの偏りを把握すれば上限の見直しと保管戦略の最適化が進む。
保守と拡張に強い設計
将来の変更に備え判定の基準値は一か所へ集約し注釈を添える。表示の文言は部品化して複数画面で整合を保つ。単位変換の関数は独立させ自動試験で桁取りと丸めの安定性を確かめる。記録の形式も早めに統一し長期の分析が継続できるようにする。学びは運用へ反映し手順を育てる。こうした地道な備えが障害時の強さを生む。
チェックリスト
入力欄の説明は明確か。上限値は単位付きで示されているか。受け付け直後に大きさを取得しているか。判定は元の値で行っているか。表示の丸めは統一されているか。成功時と失敗時の案内は対になっているか。記録には時刻と識別子と大きさと判定が含まれているか。日別集計と異常検知は稼働しているか。境界値の自動試験は整備されているか。合計判定と個別判定は分かれているか。これらを一つずつ確かめれば安心感のある受け付けに近づく。
判定と表示と記録を分離した小さな例を示す。読みやすい出力に加え再利用しやすい形を意識している。
@WebServlet("/upload/check")
@MultipartConfig(
fileSizeThreshold = 512 * 1024,
maxFileSize = 5L * 1024 * 1024,
maxRequestSize = 6L * 1024 * 1024
)
public class CheckedUploadServlet extends HttpServlet {
private static final long MAX_BYTES = 5L * 1024 * 1024;
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setCharacterEncoding("UTF-8");
response.setContentType("text/plain; charset=UTF-8");
Part part = request.getPart("uploadFile");
if (part == null || part.getSize() <= 0) {
response.sendError(HttpServletResponse.SC_BAD_REQUEST, "内容が見つかりません。");
return;
}
long size = part.getSize();
boolean ok = size > 0 && size <= MAX_BYTES;
log(request, part, size, ok);
if (!ok) {
response.getWriter().println("上限超過:" + human(size) + " / 上限 " + human(MAX_BYTES));
return;
}
response.getWriter().println("受け付け完了:" + human(size));
}
private static void log(HttpServletRequest req, Part part, long size, boolean ok) {
String who = req.getRemoteAddr();
String name = part.getSubmittedFileName();
System.out.printf("[UPLOAD] who=%s name=%s size=%d ok=%s%n", who, name, size, ok);
}
private static String human(long bytes) {
String[] unit = {"B","KB","MB","GB","TB"};
int i = 0;
double v = bytes;
while (v >= 1024 && i < unit.length - 1) { v /= 1024; i++; }
return String.format("%.2f %s", v, unit[i]);
}
}
// 合計と平均を併記する短い断片
long sum = 0L; int n = 0;
for (Part p : request.getParts()) {
if ("uploadFile".equals(p.getName()) && p.getSize() > 0) { sum += p.getSize(); n++; }
}
System.out.printf("合計=%s 平均=%s%n", human(sum), n>0 ? human(sum/n) : "N/A");
<!-- 画面側の案内文例 -->
<div class="alert alert-info">
<i class="bi bi-info-circle"></i>
<span>上限は<mark class="px-1">五メガバイト</mark>です。大きい画像は解像度の調整や圧縮をご検討ください。</span>
</div>
実例でつかむ判断の流れ
例えば履歴書の画像と身分証の写真を同時に送る場面を考える。片方は軽く片方は重いという状況は珍しくない。そこで各件の判定と合計の判定を順に行い受け付けの可否を決める。軽い方だけ通して重い方は分割や圧縮を促すと待ち時間が短くなり体験が向上する。画面には通過と要対応を並べ結果を一望できる形にする。戻り値の文言は同じ語順で統一し迷いを減らす。
もう一つの例として長時間の通信を伴う大きな文書の受け付けを想像する。途中で回線が不安定になり一部だけ届くことがある。この場合は途中状態を明示し再試行か分割の選択肢を示す。記録には途中で中断されたことを残し原因の推測に役立てる。数回の再試行で改善しないなら別経路の案内や担当窓口の連絡先を出して伴走する。
運用チェックポイント
現場で点検すべき事項を挙げておく。まず案内文が要点から始まっているか。次に上限値が画面の視線経路に置かれているか。さらに履歴の集計が定期的に生成されているか。異常の通知が届いてから一次対応までの所要時間が短いか。これらがそろえば問題の早期発見と再発防止が現実味を帯びる。細やかな観測と穏やかな案内の両輪が安定運用の鍵である。
構成の更新時には試験の自動化を必ず回す。基準値の変更や小さな文言の手直しでも境界の挙動が変わるおそれがある。履歴の形式を壊さないことも重要である。長期の傾向を保つためには列名や単位の揺れを避ける。変更が必要なときは移行の手順を用意し混在期間の解釈を明示する。
用語のつながり再確認
学び直しのために用語の連結を軽く整理する。大きさは測定され判定に使われ表示へ流れる。検証は上限と合計の二つに分かれ記録は監視と分析へつながる。これらの線が一本の道としてつながれば迷いが減り判断が速くなる。言葉を丁寧にそろえることは作業の見通しを良くする近道である。
ミスを防ぐための心得
よくある失敗は丸めた値で判定してしまうことと通知の文言が状況に合っていないことである。前者は境界で誤判定を生み後者は利用者の焦りを増幅する。これを避けるには元の値で比較し表に見える言葉は状況に合わせて選ぶ。数字は信頼の源であり一文字の差が印象を左右する。小さな気配りを重ねれば不安は解け離脱は減る。学びは道具であり道具は人を助けるためにある。
生徒
きょうの学びで判定は元の値表示は読みやすい形という分離の考え方が腹に落ちた。同時に合計の枠と個別の枠を分ける設計の意味も理解できた。
先生
その理解は現場で効く。境界付近の誤差に振り回されず案内文も一貫して整えられる。記録を整備しておけば傾向が見え対策が早く打てる。
生徒
進行中の見せ方や失敗時の次の一手の提示も大切だと分かった。小さな文言の工夫でも迷いが減り安心感が生まれるのですね。
先生
うむ。数字の扱いは細部ほど効いてくる。今日の指針をひな形として積み重ねれば安定した受け付けが実現する。次回は履歴の可視化にも挑戦しよう。