HTML网页中如何实现表单提交至Java后台-html教程-PHP中文网

表单action和method必须与后端@mapping注解路径及请求方法严格匹配，如action="/login"且method="post"时，后端须用@postmapping("/login")接收；name属性值须与@requestparam或实体字段名一致，且需注意csrf、编码、路径相对性等常见问题。

html网页中如何实现表单提交至java后台

表单 `action` 和 `method` 必须匹配 Java 后端接收方式

浏览器提交表单时，只认 action 指向的 URL 和 method（GET 或 POST），Java 后端必须有对应路径和请求方法的处理器。Spring Boot 中常见写法是用 @PostMapping("/login") 接收 POST 表单，此时 HTML 表单的 action="/login" 和 method="post" 缺一不可。

容易踩的坑：

action 写成绝对路径如 action="http://localhost:8080/login" —— 跨域或部署到子路径时会 404；应使用相对路径或 Thymeleaf 的 @{/login}
后端用 @GetMapping 却提交 POST 表单 → 返回 405 Method Not Allowed
表单没写 method="post"，浏览器默认用 GET，后端收不到 requestBody 数据

表单字段名要和 Java 后端 `@RequestParam` 或 `@ModelAttribute` 参数名一致

HTML 表单靠 name 属性传参，不是 id 或 class。比如：<input name="username"> 提交后，Java 端才能用 @RequestParam("username") String user 或绑定到实体类的 username 字段。

常见错误现象：

写了 <input id="username"> 但没写 name → 后端收不到该字段
前端 name="user_name"，后端参数写成 @RequestParam("username") → 报错 MissingServletRequestParameterException
用 @RequestBody 接收表单数据 → 总是为 null，因为表单默认是 application/x-www-form-urlencoded，不是 JSON

CSRF 防护开启时，表单必须携带 `_csrf` 隐藏字段（Spring Security 默认启用）

Spring Security 5.7+ 默认启用 CSRF 保护，所有非 GET/HEAD/OPTIONS/TRACE 请求都会校验 token。不带 token 的表单提交会返回 403 Forbidden，控制台看不到明显报错，容易误判为路径或参数问题。

html-ppt-to-pdf

将使用 `

` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。

下载

解决办法（以 Thymeleaf 为例）：

模板中加 <input type="hidden" th:name="${_csrf.parameterName}" th:value="${_csrf.token}">
纯 HTML 静态页 + Spring Boot，可临时关闭 CSRF（仅开发）：http.csrf().disable()，但上线前必须关掉
用 AJAX 提交时，需从 /csrf 接口或 meta 标签里取 token 并设到请求头

中文乱码问题：前后端字符集要统一为 UTF-8

表单提交中文出现乱码（如 “张三” 变成 “å¼ ä¸‰”），本质是编码不一致。Tomcat 9+ 默认用 UTF-8 解析表单，但低版本或自定义配置可能仍用 ISO-8859-1。

实操建议：

HTML 页面 head 加 <meta charset="UTF-8">
Spring Boot 2.3+ 在 application.properties 加：server.servlet.encoding.charset=UTF-8 和 server.servlet.encoding.force=true
若用 Filter 手动处理，确保 request.setCharacterEncoding("UTF-8") 在获取参数前调用
验证方式：在 Controller 里打印 new String(request.getParameter("name").getBytes("ISO-8859-1"), "UTF-8")，如果能正常显示说明确实是编码问题

真正麻烦的是前后端编码配置分散在 HTML、Tomcat、Spring、数据库连接多个地方，漏掉一处就可能出乱码，调试时优先检查 Content-Type 响应头是否含 charset=utf-8，再查请求体原始字节。