Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=GBK 新版IDEA编码格式GBK问题 maven命令Picked up JAVA_TOOL_OPTION

📋 问题概述

问题现象

在使用新版IDEA执行 Maven 构建项目时,控制台输出警告信息:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=GBK 

🔍 问题排查过程

第一阶段:初步判断与假设

初始假设:系统环境变量设置了 Java 编码为 GBK

第二阶段:环境变量验证

cmd

# 检查环境变量 echo %JAVA_TOOL_OPTIONS% # 输出:%JAVA_TOOL_OPTIONS%(表示变量未显式设置) 

排查结果:系统环境中并未手动设置 JAVA_TOOL_OPTIONS 变量

第三阶段:深入排查IDEA配置

怀疑方向:IDEA内部设置或配置文件指定了GBK编码

检查项包括:

  1. IDEA VM OptionsHelp → Edit Custom VM Options
  2. Maven Runner配置Settings → Build Tools → Maven → Runner
  3. 项目配置.idea 目录下的配置文件
  4. Maven配置文件settings.xml 和 pom.xml

排查结果:IDEA配置中未发现显式的GBK编码设置

第四阶段:系统级排查

关键发现:通过检查 Windows 区域设置,定位问题根源

检查步骤:

  1. 控制面板 → 时钟和区域 → 区域
  2. 管理标签页 → 更改系统区域设置
  3. 发现未勾选"Beta版:使用Unicode UTF-8"

🎯 问题根本原因分析

核心原因

Windows 中文系统区域设置的默认行为 + IDEA自动检测机制

具体机制

1. 系统层行为
2. IDEA特殊行为

猜测机制:新版IDEA可能具备:

  • 自动系统扫描:启动时扫描系统区域设置
  • 智能编码配置:根据区域自动设置编码
  • 环境变量注入:自动配置JAVA_TOOL_OPTIONS
3. 问题触发流程
IDEA启动 ↓ 扫描系统区域设置(发现中文中国) ↓ 自动配置编码为GBK("智能"行为) ↓ 注入JAVA_TOOL_OPTIONS=-Dfile.encoding=GBK ↓ Maven构建时继承此设置 ↓ 控制台显示警告信息 

💡 解决方案实施

方案选择:修改系统区域设置

实施步骤详解

步骤1:访问区域设置

开始菜单 → 设置 → 时间和语言 → 语言和区域 或 控制面板 → 时钟和区域 → 区域 

步骤2:进入高级设置

1. 点击"相关设置"下的"管理语言设置" 2. 在弹出的窗口中点击"更改系统区域设置" 

步骤3:启用UTF-8支持

1. 勾选"Beta版:使用 Unicode UTF-8 提供全球语言支持" 2. 点击"确定" 3. 根据提示重启计算机 

步骤4:验证修改效果
重启后,在IDEA中执行:

mvn clean compile 

输出变为:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

Read more

Flutter 组件 pathfinding 的鸿蒙化适配实战 - 驾驭极致拓扑寻踪大坝、实现 OpenHarmony 分布式端高性能 AI 寻路、迷宫拓扑与工业级路径导航核方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 pathfinding 的鸿蒙化适配实战 - 驾驭极致拓扑寻踪大坝、实现 OpenHarmony 分布式端高性能 AI 寻路、迷宫拓扑与工业级路径导航核方案 前言 在鸿蒙(OpenHarmony)生态的分布式工业巡检、高性能游戏开发或者是对空间计算有极其严苛要求的 0308 批次智能仓储应用中。“复杂环境下的路径最优解计算与实时障碍避让维度”是衡量整个系统智慧化程度的最终质量门禁。面对包含数万个节点的网格地图、海量动态变化的货架坐标、甚至是由于跨设备同步产生的 0308 批次拓扑逻辑海洋。如果仅仅依靠简单的“直线欧式距离”或者是干瘪的广度优先搜索(BFS)。不仅会导致在处理大型复杂地图时让系统如同在逻辑废墟中盲人摸象。更会因为计算耗时指数级爆炸,让移动端在进行路径导航时瞬间陷入死机盲区。 我们需要一种“逻辑先行、代价建模”的空间演算艺术。 pathfinding 是一套专注于无缝整合全球公认顶级算法 A*、Dijkstra 以及二叉堆

By Ne0inhk
复杂SQL性能突围:代价驱动的连接条件下推策略与工程实践

复杂SQL性能突围:代价驱动的连接条件下推策略与工程实践

文章目录 * 引言:当“逻辑清晰”遇上“性能陷阱” * 一、问题根源:高选择性条件为何“鞭长莫及” * 1.1 客户场景还原 * 1.2 业界面临的两大核心难点 * 1.2.1 语义等价性(Equivalence) * 1.2.2 代价评估(Cost) * 二、传统优化器的“无力感” * 三、金仓数据库的破局之道:等价 + 代价的双重驱动 * 3.1 阶段一:等价性判定(Can we push?) * 3.2 阶段二:代价模型评估(Should we push?) * 四、效果验证:从全表扫描到精准过滤

By Ne0inhk
Spring Boot 消息队列与异步通信

Spring Boot 消息队列与异步通信

Spring Boot 消息队列与异步通信 21.1 学习目标与重点提示 学习目标:掌握Spring Boot消息队列与异步通信的核心概念与使用方法,包括消息队列的定义与特点、Spring Boot与ActiveMQ的集成、Spring Boot与RabbitMQ的集成、Spring Boot与Kafka的集成、Spring Boot异步通信的基本方法、Spring Boot的实际应用场景,学会在实际开发中处理消息队列与异步通信问题。 重点:消息队列的定义与特点、Spring Boot与ActiveMQ的集成、Spring Boot与RabbitMQ的集成、Spring Boot与Kafka的集成、Spring Boot异步通信的基本方法、Spring Boot的实际应用场景。 21.2 消息队列概述 消息队列是Java开发中的重要组件。 21.2.1 消息队列的定义 定义:消息队列是一种异步通信机制,用于在应用程序之间传递消息。 作用: * 实现应用程序之间的异步通信。 * 实现应用程序之间的解耦。 * 提高应用程序的性能。 常见的消息队列: * Activ

By Ne0inhk
Java 中间件:RabbitMQ 延迟队列(死信交换机实现)

Java 中间件:RabbitMQ 延迟队列(死信交换机实现)

👋 大家好,欢迎来到我的技术博客! 📚 在这里,我会分享学习笔记、实战经验与技术思考,力求用简单的方式讲清楚复杂的问题。 🎯 本文将围绕Java中间件这个话题展开,希望能为你带来一些启发或实用的参考。 🌱 无论你是刚入门的新手,还是正在进阶的开发者,希望你都能有所收获! 文章目录 * Java 中间件:RabbitMQ 延迟队列(死信交换机实现) ⏳ * 什么是延迟队列?🤔 * 典型应用场景 🌟 * RabbitMQ 原生不支持延迟队列?那怎么办?🚫➡️✅ * 核心思想 💡 * 关键概念详解 🔑 * 1. TTL(Time-To-Live)⏱️ * 2. 死信(Dead Letter)⚰️ * 3. 死信交换机(DLX) & 死信路由键(DLK)🔄 * 4. 延迟队列的构建逻辑 🧩 * 环境准备 🛠️ * 启动 RabbitMQ(Docker 方式) * Spring Boot 项目搭建 🏗️ * 定义交换机、队列与绑定关系 📦 *

By Ne0inhk