古法后端入门

• 大小 ── 默认设置下 3.5 MB 的手机照片被拒，12 MB 连回复都没有（实测）
• 名字 ── 同名被覆盖，带 ../ 的名字写到存放位置之外（实测）
• 内容 ── 内容是文字的 .jpg 被当作“图片”收下（实测）
• 重复使用・偏差 ── 同一收据附到 2 份申请，没进数据库的文件留了下来（实测）

先朴素地写。窗口用 multipart/form-data 接收文件，负责人按收到的名字放进文件夹，数据库里写一行目录。登录沿用上一讲的。

# 朴素版负责人（NaiveReceiptService.java）
@Transactional
public Receipt store(String expenseId, MultipartFile file, String user) throws IOException {
    String name = file.getOriginalFilename();
    Files.copy(file.getInputStream(), dir.resolve(name), StandardCopyOption.REPLACE_EXISTING);  // 原样使用收到的名字
    Receipt r = new Receipt(UUID.randomUUID().toString(), expenseId, name, file.getContentType(), file.getSize(),
            "-", name, user);
    receipts.insert(r);  // 即使这里失败，文件也已经放下了
    return r;
}

public byte[] read(String name) throws IOException {
    return Files.readAllBytes(dir.resolve(name));  // 按收到的名字读取
}

# 目录表（setup12.sql）
-- 第 12 讲：收据目录（文件本身在磁盘上），以及用于比较的 bytea 版
create table if not exists receipt (
  id            uuid          primary key,
  expense_id    varchar(20)   not null references expense(id),
  original_name varchar(100)  not null,
  content_type  varchar(100),
  size          bigint        not null,
  sha256        char(64)      not null,
  stored_name   varchar(255)  not null,
  uploaded_by   varchar(30)   not null,
  created_at    timestamptz   not null default now()
);

发送了 3 个文件：手边的收据图片（0.04 MB）、手机照片大小的文件（3.54 MB）、大照片（12.05 MB）。

# 用 3 种设置发送 3 种大小（新井，朴素版窗口）
                   receipt-small 0.04 MB     photo-phone 3.54 MB       photo-big 12.05 MB
  默认             200                       413                       没有回复（中途被切断）
  提高到 10MB      200                       200                       没有回复（中途被切断）
  ＋ swallow 20MB  200                       200                       413

Spring Boot 默认每个文件最多 1 MB。手机照片光这一条就得到 413（太大）。上限提高到 10 MB 后手机照片通过了，但 12 MB 的照片连回复都没有。Tomcat 在拒绝前会把剩余的正文读掉丢弃，默认最多 2 MB；超过就会在写回复之前切断连接。画面上只会显示“通信错误”。

# 在 application.properties 里加的 3 行
spring.servlet.multipart.max-file-size=10MB
spring.servlet.multipart.max-request-size=10MB
server.tomcat.max-swallow-size=20MB

把读掉丢弃的量（swallow）放宽到 20 MB 后，12 MB 的照片也收到了 413 和理由。上限应按“业务需要的大小”来定；在画面一侧发送前也检查大小，会更友好。

手机和扫描仪起的名字大多差不多。如果新井和古井都发了 receipt.jpg 呢？如果名字里带着 ../ 呢？

# 按收到的名字存放（朴素版）
  arai   receipt.jpg (md5 a67175fb) → EXP-2026-5020  200   disk receipt.jpg = a67175fb
  furui  receipt.jpg (md5 7260a48c) → EXP-2026-5101  200   disk receipt.jpg = 7260a48c  ← 新井的收据没了
  DB:   EXP-2026-5020|receipt.jpg|receipt.jpg   EXP-2026-5101|receipt.jpg|receipt.jpg
  disk: receipt.jpg
  arai   ../written-outside.jpg → 200   store/naive/ = ['receipt.jpg']   store/ = ['written-outside.jpg', 'outside.txt']
# 同样的名字，用 fixed 版
  arai   ../written-outside.jpg → 200   originalName = ../written-outside.jpg   store/receipts/ = ['32005963-9319-4470-877a-0aaae252428a']

目录有 2 行，磁盘上只有 1 个。新井的收据被古井的收据悄悄覆盖了。../written-outside.jpg 这个名字，Tomcat 和 Spring 都原样交了过来，文件被写到了存放位置之外。

解决办法是存放时的名字自己取。fixed 版用 UUID（不会冲突的编号）作名字，原名只作为“显示用”留在目录里。

随文件一起送来的 Content-Type（是图片还是 PDF），和名字一样是发送方的自我申报，扩展名也一样。把内容是文字的 fake.jpg 以“image/jpeg”发送。

# 内容与发来的种类（Content-Type）
  fake.jpg          image/jpeg       e3 81 93 e3   naive 200 image/jpeg       fixed 415 不接收
  receipt-small.jpg image/jpeg       ff d8 ff e0   naive 200 image/jpeg       fixed 200 image/jpeg
  receipt.png       image/png        89 50 4e 47   naive 200 image/png        fixed 200 image/png
  receipt.pdf       application/pdf  25 50 44 46   naive 200 application/pdf  fixed 200 application/pdf
  receipt.png       image/jpeg       89 50 4e 47   naive 200 image/jpeg       fixed 200 image/png
# 用内容开头判断（FileType.java）
public static String detect(byte[] h) {
    if (h.length >= 3 && (h[0] & 0xff) == 0xFF && (h[1] & 0xff) == 0xD8 && (h[2] & 0xff) == 0xFF) return "image/jpeg";
    if (h.length >= 8 && (h[0] & 0xff) == 0x89 && h[1] == 'P' && h[2] == 'N' && h[3] == 'G') return "image/png";
    if (h.length >= 5 && h[0] == '%' && h[1] == 'P' && h[2] == 'D' && h[3] == 'F' && h[4] == '-') return "application/pdf";
    return null;  // 不作为收据接收
}

朴素版把文字文件当作图片收下，PNG 被说成“是 JPEG”就原样记成 JPEG。fixed 版用内容开头的字节判断：JPEG 以 ff d8 ff、PNG 以 89 50 4e 47、PDF 以 %PDF- 开头，都不是就 415。种类也不按申报，而按内容来记录。

开头正确，不代表整个内容都安全。业务中还会加上病毒检查，或把图片读进来重新绘制一遍的处理。

报销特有的问题：同一张收据附到另一份申请上呢？这就是重复申请。fixed 版在接收时取内容的指纹（SHA-256），记进目录。

# 把同一张收据附到 2 份申请上
  receipt-small.jpg → EXP-2026-5021   200  sha256 1b3b466198a4c17d…
  receipt-small.jpg → EXP-2026-5022   409  同じ領収書が EXP-2026-5021 に付いています

想把同一张照片附到 5022 时，指纹与 5021 的收据一致，得到 409。改了名字，指纹也不会变。不过重新拍的照片指纹不同，所以这是防止“不小心”的机制。审批人核对金额和日期的工作不会因此消失。

收下之后，还需要显示的窗口。朴素版做成了“收到名字，就返回那个文件”的窗口。

# 按名字返回的窗口（朴素版）
  GET /api/v12/naive/files?name=receipt.jpg     → 200  37850 字节
  GET /api/v12/naive/files?name=../outside.txt  → 200  85 字节  これは、領収書の置き場所の外にあるファイルです（練習用）
# 按编号返回的窗口（fixed 版）
  arai   → arai's   receipt  200
           Content-Type: image/jpeg
           Content-Disposition: attachment; filename="________.jpg"; filename*=UTF-8''%E9%A0%98%E5%8F%8E%E6%9B%B8%EF%BC%88%E6%96%B0%E5%B9%B9%E7%B7%9A%EF%BC%89.jpg
           X-Content-Type-Options: nosniff
           Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  arai   → furui's  receipt  404
  furui  → arai's   receipt  200
           Content-Type: image/jpeg
           Content-Disposition: attachment; filename="________.jpg"; filename*=UTF-8''%E9%A0%98%E5%8F%8E%E6%9B%B8%EF%BC%88%E6%96%B0%E5%B9%B9%E7%B7%9A%EF%BC%89.jpg
           X-Content-Type-Options: nosniff
           Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  arai   → none     receipt  404
# 按编号返回的窗口（V12Controller.java）
@GetMapping("/api/v12/receipts/{rid}")
public ResponseEntity<FileSystemResource> download(@PathVariable String rid, @AuthenticationPrincipal LoginUser u) {
    Receipt r = receipts.find(rid, u);
    return ResponseEntity.ok()
            .contentType(MediaType.parseMediaType(r.contentType()))  // 由内容决定的种类
            .header(HttpHeaders.CONTENT_DISPOSITION, ContentDisposition.attachment()
                    .filename(r.originalName(), StandardCharsets.UTF_8).build().toString())  // 保存时的名字
            .body(new FileSystemResource(receipts.path(r)));
}

按名字返回的窗口，用 ../outside.txt 连存放位置之外的文件都返回了。用同样的办法把配置文件或密钥文件返回出去，就是被称为路径遍历（path traversal）的漏洞（这里只在自己的练习环境中、用放好的无害文件确认）。

fixed 版按目录编号接收。由编号查目录，再用第 11 讲的负责人确认能否看这份收据所属的申请，不行就 404。回复里带有由内容决定的种类、attachment（不打开、直接保存）、用于日文名字的 filename*，以及不让浏览器猜测种类的 nosniff。nosniff 和不缓存的指示是 Spring Security 加上的。

文件在数据库之外，进不了数据库的事务。没写进目录的文件留下来会怎样？把名字设成 150 个字符（目录列最多 100 个字符），故意让写目录的 insert 失败。

# 用 150 个字符的名字发送（目录列最多 100 个字符）
  naive  → 500   receipt rows = 0   files on disk = 1
  fixed  → 500   receipt rows = 0   files on disk = 0
  ERROR: value too long for type character varying(100)

朴素版先放文件再写目录，所以 500 之后，磁盘上留下了 1 个不属于任何人的文件。fixed 版先写临时文件、检查、写目录，最后才改成自己的名字。写目录失败时临时文件被删掉，磁盘上什么也没留下（名字长度本该在入口就返回 400）。

# fixed 版负责人（ReceiptService.java 的 store）
@Transactional
public Receipt store(String expenseId, MultipartFile file, LoginUser u) throws IOException {
    claims.find(expenseId, u);  // 是否可看的申请（第 11 讲），不是则 404
    String type;
    try (InputStream in = file.getInputStream()) {
        type = FileType.detect(in.readNBytes(8));  // 用开头 8 字节判断种类
    }
    if (type == null) throw new ReceiptRejectedException(HttpStatus.UNSUPPORTED_MEDIA_TYPE, "JPEG・PNG・PDF だけ受け付けます");
    Path tmp = Files.createTempFile(dir, "up-", ".part");
    try {
        String sha = copyWithSha256(file, tmp);  // 一边写临时文件，一边取内容指纹
        Receipt same = receipts.findBySha(sha);
        if (same != null) throw new ReceiptRejectedException(HttpStatus.CONFLICT, "同じ領収書が " + same.expenseId() + " に付いています");
        String id = UUID.randomUUID().toString();  // 存放时的名字由自己来取
        Receipt r = new Receipt(id, expenseId, file.getOriginalFilename(), type, file.getSize(), sha, id, u.getUsername());
        receipts.insert(r);
        Path dest = dir.resolve(id);
        Files.move(tmp, dest, StandardCopyOption.ATOMIC_MOVE);
        deleteIfRolledBack(dest);  // 数据库回滚时，文件也删掉
        return r;
    } finally {
        Files.deleteIfExists(tmp);
    }
}

为了应对移动之后提交失败的情况，还登记了“回滚时也删除文件”的善后处理。即便如此，遇到断电这类情况，偏差也不会是零。另外准备一个深夜去找出目录里没有的文件并清理的任务，是常见做法。

也可以把文件本身放进数据库（bytea）。用约 0.94 MB 的照片 20 张比较了一下。

# 把约 0.94 MB 的照片 20 张放到磁盘和数据库（bytea）
  disk      468 ms     18,753,622 字节
  bytea    1043 ms     19,529,728 字节  (pg_total_relation_size)
  src                  18,753,622 字节

在浏览器开发者工具里看一看下载回复的 Content-Type・Content-Disposition・X-Content-Type-Options，就能明白“如何显示”是由服务器决定的。