在 IntelliJ IDEA 中执行 Maven 编译时，控制台输出出现乱码，显示为 ���... 等不可读字符。

[INFO] Compiling 2724 source files to /path/to/target/classes
[INFO] /path/to/SomeService.java: ���������������

问题原因

根本原因

从 IntelliJ IDEA 2025.2 版本开始，Maven 的执行方式发生了重大变化：

1. 旧版本（2025.1 及之前）

   • 直接调用 java.exe 执行 Maven

2. 新版本（2025.2 及之后）

   • 通过 cmd.exe /c（Windows）或 shell（macOS/Linux）来启动 Maven
   • 可以从控制台输出结果看到这个变化

编码冲突

• Windows 系统：cmd.exe 默认使用 GBK 编码
• 项目源码：通常使用 UTF-8 编码
• 结果：编码不一致导致中文和特殊字符显示为乱码

为什么传统方法无效

即使你已经设置了以下配置，问题仍可能存在：

1. IDEA 的 File Encoding 设置为 UTF-8
2. Maven 配置中指定 -Dfile.encoding=UTF-8
3. pom.xml 中配置了编码属性：

   <properties>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
   </properties>
   

原因：Maven 通过 cmd/shell 启动后，JVM 可能仍未正确继承或使用 UTF-8 编码。

解决方案

方法：设置 JAVA_TOOL_OPTIONS 环境变量

通过在 IDEA 中为 Maven 设置 JAVA_TOOL_OPTIONS 环境变量，强制 JVM 使用 UTF-8 编码。

详细步骤

1. 打开 IDEA 设置

Windows/Linux:

• 快捷键：Ctrl + Alt + S
• 或菜单：File → Settings

macOS:

• 快捷键：Cmd + ,
• 或菜单：IntelliJ IDEA → Preferences

2. 导航到 Maven Runner 配置

按照以下路径进入：

Build, Execution, Deployment
  └─ Build Tools
      └─ Maven
          └─ Runner

3. 添加环境变量

找到 Environment variables 字段：

1. 点击右侧的文件夹图标或输入框
2. 添加新的环境变量：
   • Name: JAVA_TOOL_OPTIONS
   • Value: -Dfile.encoding=UTF-8

完整格式：

JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8

4. 应用设置

1. 点击 Apply 按钮
2. 点击 OK 关闭设置窗口

5. （可选）清除缓存并重启

如果问题仍存在，可以清除缓存：

1. 菜单：File → Invalidate Caches...
2. 勾选相关选项
3. 点击 Invalidate and Restart

注意：大多数情况下无需重启，设置会立即生效。

验证方法

重新执行 Maven 编译命令（如 mvn compile 或 mvn clean install），检查控制台输出是否正常显示中文。

适用范围

受影响的版本

• IntelliJ IDEA 2025.2 及更高版本

受影响的系统

• Windows：最常见（cmd.exe 默认 GBK）
• macOS：可能受影响
• Linux：可能受影响（取决于系统 locale 设置）

技术原理

JAVA_TOOL_OPTIONS 环境变量

JAVA_TOOL_OPTIONS 是一个特殊的 JVM 环境变量：

• 作用：在 JVM 启动时自动应用指定的选项
• 优先级：高于其他配置方式
• 生效范围：对所有通过该环境变量启动的 Java 进程有效

为什么这个方法有效

1. IDEA 通过 shell/cmd 启动 Maven
2. Maven 进程继承 JAVA_TOOL_OPTIONS 环境变量
3. JVM 在启动时自动应用 -Dfile.encoding=UTF-8
4. 所有输出使用统一的 UTF-8 编码

其他注意事项

pom.xml 中的编码配置

虽然这不是解决乱码的主要方法，但仍建议在 pom.xml 中明确指定编码：

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <maven.compiler.encoding>UTF-8</maven.compiler.encoding>
</properties>

这可以确保：

• 源代码编译使用正确编码
• 资源文件处理使用正确编码
• 报告生成使用正确编码

全局 Maven 配置

如果需要在命令行中也使用 UTF-8，可以在 ~/.mavenrc（macOS/Linux）或环境变量中设置：

macOS/Linux:

# ~/.mavenrc
export JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8"

Windows:
在系统环境变量中添加：

变量名: JAVA_TOOL_OPTIONS
变量值: -Dfile.encoding=UTF-8

相关资源

• IntelliJ IDEA 官方文档 - Maven
• Maven 编码配置最佳实践

总结

IntelliJ IDEA 2025.2 版本改变了 Maven 执行方式，导致编码传递出现问题。通过在 IDEA 的 Maven Runner 配置中设置 JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 环境变量，可以强制 JVM 使用 UTF-8 编码，从而彻底解决乱码问题。

此方法简单有效，无需修改系统配置或项目代码，设置后立即生效。

非技术指导性文章，用简单的例子描述下什么是多线程以及队列

一般一个多线程任务设置会涉及到如下专业名词：
核心线程数
最大线程数
队列长度
还有个不太常用到的拒绝策略

例子：
假设有一个银行，这个银行就是一个业务进程。
1、最开始没有银行，只有一个小桌子，做了一个经理，所有来办理业务的人都只能在他这，等他办完前一个才能处理下一个
2、后来发现办理太慢，决定盖一个银行，招一些人
3、银行里有一些职员，还有一些业务窗口，其中一些是正式窗口，就是一直开放的，一些是临时窗口。
4、当有用户来办理业务时，经理首先看正式窗口是不是空闲，如果空闲就让他直接去办理，不空闲的话，在看下能不能开临时窗口，如果能开就去临时窗口，如果临时窗口也满了，就给他排队取号。
5、因为银行的空间是有限的，所以排队的人数也是有限制的的。
6、当排队的人数达到了最大限制，就需要经理来选择怎么做，是直接告诉他回去，还是经理自己帮他办理，当经理帮他办理时，就回到了最开始阶段，后面的人就只能经理处理完当前的人的业务，再去处理下一个。

在上文中：
客户就是要消费的任务，经理就是主进程
最开始时只有经理，是单线程
当有了银行时，就是一个线程池：职员就是CPU，正式窗口就是核心线程，正式+临时窗口就是最大线程，队列长度就是排队限制

当一个用户在办理业务时，他有可能需要填写一些东西（IO），当他填东西时，可以认为职员（CPU）是在等待他填完，这个时候他就可以去其他窗口处理其他人的业务（CPU调度）。也就是说窗口其实可以比职员多的，但是太多也没有意义，因为一个人不可能顾得上200个窗口。

对于6就是队列满的时候的拒绝策略，一般默认的策略是主进程自己处理，那就是这个经理处理，同时整个业务阻塞，也就是整个银行入口都卡住。

最近发现这本书，但是没找到中文版，正版的也没出版，用gpt4o简单翻译了一下，有需要的自取（如有侵权联系我删除：vacuityv@icloud.com）

每次章节开头部分有些问题，正文翻译还行

一部不常用的支持快捷指令且可以正常钉钉打卡的iOS（ >=iOS13）设备

2、前提条件

登录钉钉，打开极速打卡，最好测试一遍打卡是否正常，设备要在打卡范围内，有网络，无锁屏密码，最好一直插着电源避免没电关机

3、实现步骤

1、添加快捷指令

1.1、不带通知

https://www.icloud.com/shortcuts/559159372fb342209b44b354fada18f0
复制到浏览器打开或者扫码添加

1.2、微信通知

[联系人请手动写微信的昵称备注，不需要在通讯录选择到，要是发送不成功的话，给siri 授权下微信联系人]
https://www.icloud.com/shortcuts/d09f98ac0b4d45c18a16939d3d0bdf13

1.3、短信/iMessage通知

[要是发送不成功的话，给siri 授权下通讯录，急的更改手机号]

2、打开自动化，点击右上角添加

3、点击创建个人自动化

4、选择特定时间

5、时间选择早上8:10，重复选择每天，点击下一步

6、搜索快捷，选择运行快捷指令，选中我们第一步添加的“随机打卡”

7、点击下一步，把运行前询问关闭，点击完成

8、同样的3-8步骤添加晚上18:30的自动化

附录1：快捷指令说明

获取1-30之间的一个随机数，将随机数的值赋给s，等待s秒后，打开钉钉，等待10s后，回到主屏幕，可按实际需要修改

附录2：允许不受信任的快捷指令

打开“快捷指令”App 并运行任意快捷指令。
前往“设置”>“快捷指令”。
打开“允许不受信任的快捷指令”。只有在您运行过快捷指令之后才会看到这项设置。

最近，Claude 发布了其最新版本 Claude 3，我计划将其集成到我的聊天网站 AI-Chat (AI-Chat)上。我访问了官方网站，发现只提供了 Python 和 TypeScript 的 SDK。遗憾的是，我在 GitHub 上并没有找到 Java 版本的 SDK。因此，我决定亲自动手编写一个，并且打算将其发布到 Maven 仓库中以便他人使用。
在寻找发布到 Maven 仓库的教程时，我发现互联网上的大多数指南都已过时。没有办法，我只能自己摸索整个流程。接下来，我将记录整个过程，希望能帮助到有相似需求但又遇到相同困难的其他开发者。

注意：已经不是在这个网站操作了：https://issues.sonatype.org，现在是在https://central.sonatype.com，网站上的很多教程依然是前者。

注册账号

去Maven Central注册账号

生成token

点击右上角头像，选择“View Account”，之后 **Generate User Token
**，为自己生成一个token信息，记录下来。配置到本地maven的settings.xml:

<servers>
    <server>
      <id>central</id>
      <username>XXXXX</username>
      <password>CSDCEDEDEDEDE</password>    
    </server>
</servers>

配置Namespace

点击右上角头像选择 View Namespace，为自己添加一个Namespace（是你要发布的包的groupid中的域名）。我这边用的是自己的域名，所以直接添加，然后他需要你增加一个TXT的解析记录，添加好点击验证，等待他验证结束就可以了。

GPG配置

配置GPG密钥，这部分自行搜索处理 ，也可以参考：Working with PGP Signatures。
生成之后查看下本地的密钥：

注意，以下部分的 CA925CD6C9E8D064FF05B4728190C4130ABA0F98 即为后面要用到的keyId

$ gpg --list-keys
/home/mylocaluser/.gnupg/pubring.kbx
---------------------------------
pub   rsa3072 2021-06-23 [SC] [expires: 2023-06-23]
      CA925CD6C9E8D064FF05B4728190C4130ABA0F98
uid           [ultimate] Central Repo Test <central@example.com>
sub   rsa3072 2021-06-23 [E] [expires: 2023-06-23]

记得要把 gpg key 上传：

注意 {keyid} 替换为你自己的

gpg  --keyserver hkps://keyserver.ubuntu.com --recv-keys {keyid}

POM配置

配置你要上传的项目的pom文件，添加：

注意修改对应的部分你的项目的实际值

<name>ai-java-sdk</name>
<description>a java sdk for ai apis.</description>
<url>https://github.com/vacuityv/ai-java-sdk</url>
<licenses>
    <license>
        <name>The Apache Software License, Version 2.0</name>
        <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
</licenses>
<developers>
    <developer>
        <name>xxx</name>
        <email>xxx@icloud.com</email>
    </developer>
</developers>
<scm>
    <connection>scm:git:git://github.com/vacuityv/ai-java-sdk.git</connection>
    <developerConnection>scm:git:ssh://github.com:vacuityv/ai-java-sdk.git</developerConnection>
    <url>http://github.com/vacuityv/ai-java-sdk/tree/master</url>
</scm>
<distributionManagement>
    <repository>
        <id>central</id>
        <name>central-releases</name>
        <url>https://s01.oss.sonatype.org/</url>
    </repository>
</distributionManagement>

以及：

注意 {keyid} 替换为你自己的

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>3.3.0</version>
            <executions>
                <execution>
                    <id>attach-sources</id>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <version>3.6.3</version>
            <executions>
                <execution>
                    <id>attach-javadocs</id>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                    <configuration>
                        <doclint>none</doclint>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-gpg-plugin</artifactId>
            <version>3.1.0</version>
            <executions>
                <execution>
                    <id>sign-artifacts</id>
                    <phase>verify</phase>
                    <goals>
                        <goal>sign</goal>
                    </goals>
                    <configuration>
                        <keyname>{keyid}</keyname>
                        <passphraseServerId>{keyid}</passphraseServerId>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.sonatype.central</groupId>
            <artifactId>central-publishing-maven-plugin</artifactId>
            <version>0.4.0</version>
            <extensions>true</extensions>
            <configuration>
                <publishingServerId>central</publishingServerId>
                <tokenAuth>true</tokenAuth>
                <autoPublish>true</autoPublish>
            </configuration>
        </plugin>
    </plugins>
</build>

发布

至此所有前置操作都结束了，然后直接运行

mvn deploy

发布，再次过程会验证签名和上传文件。发布成功后在第一步注册的网站点击头像然后点击 “View Deployments” 就可以看到自己发布的文件了

总结

本来，将软件包发布到 Maven 中央仓库应该是一项相对规范和普遍的操作。互联网上也确实存在大量的指导教程，但随着时间的推移和流程的更新，我发现当前可见的大多数教程已经不再适用。这一现象导致我在尝试将自己编写的 Java SDK 发布到 Maven 时，花费了大量不必要的时间和精力。
为此，我决定撰写这篇文章，记录下我在发布过程中的探索和发现。通过这篇文章，我希望能够为那些在同样路径上或将面临类似挑战的开发者们，提供一份实用的参考，从而避免他们重复我的弯路，节省宝贵的时间。
如果你在使用过程中遇到了问题，也欢迎留言一起探讨。

上个公司经常有一种需求：有些服务部署在内网（内网无法访问互联网），但是同时又需要访问一些我们需要的第三方服务，最开始我们采用的方式是对每个需要访问的外网单独申请外网权限。如果项目的机房权限管理严格审批繁琐的话，这个流程会变得很长。

后来发现其实java的启动参数可以直接添加代理参数：

-Dhttp.proxyHost=172.20.6.4 -Dhttp.proxyPort=7777 -Dhttps.proxyHost=172.20.6.4 -Dhttps.proxyPort=7777 -Dhttp.nonProxyHosts="172.20.6.*" -Dhttps.nonProxyHosts="172.20.6.*"

这段的意思是http和https流量都经过 172.20.6.4 的 7777 端口代理出去，然后忽略 172.20.6.* 的地址，这个地址可以写多个。这个代理我们通常用的都是 goproxy ：
snail007/goproxy: 🔥 Proxy is a high performance HTTP(S) proxies, SOCKS5 proxies,WEBSOCKET, TCP, UDP proxy server implemented by golang. Now, it supports chain-style proxies,nat forwarding in different lan,TCP/UDP port forwarding, SSH forwarding.Proxy是golang实现的高性能http,https,websocket,tcp,socks5代理服务器,支持内网穿透,链式代理,通讯加密,智能HTTP,SOCKS5代理,黑白名单,限速,限流量,限连接数,跨平台,KCP支持,认证API。

某次我在处理自己的服务时，需要在国内网络访问国外的某个服务，所以我就想在国外的某个服务器部署一下简单的 http 代理，但是这样就需要把我的代理服务暴露在公网，因此需要加一层认证服务。查了一下 goproxy 本身其实是支持认证的，但是属于付费模块，而我不想为这个简单的个人需求付费，因此只能自己尝试解决。

在分析了需求以及参考了很多已有的项目之后，在chatgpt的帮助下实现了简单的http代理，目前支持安装为服务、服务的启动关闭以及重启、密码认证、请求方ip白名单、目标地址白名单等，详细信息可查看项目的说明文档：

https://github.com/vacuityv/vacproxy

主要配置如下：

name: vacproxy

bind: 0.0.0.0:7777

# 日志配置/log file config，默认在当前目录的vacproxy.log
#log: /Users/vacuity/log/vacproxy.log

# 代理鉴权配置，enabled为true且user和password均不为空代表鉴权
auth:
  enabled: false
  user: test
  password: 1234

# 请求ip白名单，放空代表不限制
inAllowList:
#  - 127.0.0.1
#  - 192.168.100.*

# 目标域名/ip白名单，放空代表不限制
outAllowList:
#  - weixin.qq.com
#  - alipay.com
#  - baidu.com

目前已经在个人项目使用了一段时间，运行良好。

chatGPT 的表现出乎人的意料，很多人想把它用在日常工作中，因此我自己做了一层对接，可以让大家在没有特殊网络的情况下也可以使用：
https://chat.vacuity.me

本文主要是想记录一下对接过程中几个意外的点，方便大家了解。

上下文

大家都知道目前与 chatGPT 对话是有上下文的，比如：

你：中国的首都是哪里
chatGPT：中国的首都是北京。
你：日本的呢
chatGPT：日本的首都是东京。

第二句你只问了“日本的呢”，他通过上下文意识到你要问的是“日本的首都”。用过目前的智能语音助手的人就知道这个上下文有多么重要：他保证了对话的连续性。
那在和 gpt 对接中这个是怎么实现的呢，答案其实有点奇怪：把历史对话上传。
比如 A 代表你，B 代表 gpt ，发生了如下一段对话：
A：A1
B：B1
A：A2
B：B2
A：A3
B：B3
在每一次和 gpt 交互时，发送的数据都是一个列表，列表的每一项包含对话的内容和角色，比如
在A1时，发送过去的是：

[
  {"user": A1}
]

在A2时，发送过去的是：

[
  {"user": A1},
  {"assistant": B1},
  {"user": A2}
]

也就是说每次对话其实都重复发送了前面所有的对话历史

消耗

chatGPT 和其他的生成式 ai（比如 Google 的 Gemini ）计算消耗用的都是 token 。token 可以理解为AI世界中的字数，关于token的计算有很多开源库可以实现，我目前用的java的一个库：
knuddelsgmbh/jtokkit: JTokkit is a Java tokenizer library designed for use with OpenAI models.

而且还有一点要注意的是gpt不仅对你发送的数据需要计费，对他回答的同样是需要计费的，比如上面的对话，
第一轮对话消耗：A1+B1
第二轮对话消耗：A1+B1+A2+B2，前两轮总消耗：（A1+B1）+ （A1+B1+A2+B2）
同理可算出这段对话的总消耗：
（A1+B1）+（A1+B1+A2+B2）+（A1+B1+A2+B2+A3+B3）

因此问和前面对话无关的新的问题时，最好新开一个对话，这样可以减少消耗，以及最大化的利用token限制。

模型对比

日常使用的时候，简单的问题其实 gpt3.5 和 gpt4 没有太大差别，但是遇到一些比较专业的问题或者逻辑性比较强的时候，gpt4 会比 gpt3.5 强很多。我也对接了一下 Google 的新模型 gemini-pro，目前来看和 gpt3.5 差不多，在一月份他们会发布 gemini-ultra，据说会对标 gpt4，可能会带来更好的效果。
还有一些国内的模型，我查看了一下他们的计费，发现普遍比 gpt 和 gemini 的高很多，同时效果又不会更好，因此就暂时没有进行对接了。

Assistant

我同时也对接了 openai 的 assistant，基本上就是gpts，可以在对话中传输文件，同时他会自己写函数以及调用函数，可以进行对话、读文档、生成文档等，功能还是比较强大的。但是由于目前 openai 还不支持 assistant 的流式传输，所以每次要等他生成完一个回答才能获取到回复内容，因此响应感觉起来会比较慢。

近期由于centos免费版本不再更新，因此把目前的服务器都切成了ubuntu，记录一下自己的处理过程。
以下仅记录自己的处理过程，其他人如对root登录等有意见请忽略我的做法。

请尽量确保你知道每条命令的意义再执行。

登录用户处理

编辑 /etc/ssh/sshd_config 文件；

sudo vim /etc/ssh/sshd_config

找到配置参数：PermitRootLogin ，将该参数后面的值修改为 yes
找到配置参数：PasswordAuthentication ，将该参数后面的值修改为 yes
设置root密码，然后刷新ssh

sudo passwd root

然后重启 ssh 服务

sudo systemctl restart ssh

至此已经可以用root登录ubuntu了。

以下步骤均在root登录情况下执行

更新

apt update

mysql

安装mysql

apt install mysql-server
systemctl status mysql

修改表名大小写敏感

由于我安装的是mysql8，默认表名是大小写敏感的，因此需要改成不敏感（注意这个修改操作需最好刚装好就修改，一旦已经有数据了处理起来就很麻烦），同样以下仅针对mysql8，如其他版本有不同情况请自行搜索处理。
首先打开配置文件：

vim /etc/mysql/mysql.conf.d/mysqld.cnf

在最后添加一行（1表示不敏感）：

lower_case_table_names = 1

之后重启服务：

systemctl restart mysql

不出意外会遇到如下错误：

Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xeu mysql.service" for details.

这是由于我们更改了大小写敏感，所以原来有些数据会不适配导致重启失败，直接去看错误日志

vim /var/log/mysql/error.log 

果然看到如下报错

2023-11-30T10:28:13.150498Z 1 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('1') and data dictionary ('0').
2023-11-30T10:28:13.150633Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2023-11-30T10:28:13.150663Z 0 [ERROR] [MY-010119] [Server] Aborting

这里听从chatgpt的建议：
删除就数据并重新初始化（请自行备份数据）：

rm -rf /var/lib/mysql/*
mysqld --initialize

之后重启服务：

systemctl start mysql

至此服务正常启动。

重置密码

默认好像root只能localhost登录且没有密码，我们需要登录并设置密码：

mysql -uroot -p

此处我的密码忘记了(后面发现是因为执行initialize后会重新生成密码，在/var/log/mysql/error.log可以看到生成的密码)，因此用到了重置密码[以下仅针对mysql8版本]：

# 首先停止mysql
systemctl stop mysql
# 然后修改配置，在mysqld添加：
[mysqld]
skip-grant-tables

# 然后启动
systemctl start mysql
# 然后不用密码进入mysql[需要密码直接回车]
mysql -uroot -p
# 将密码置空
use mysql;
update user set authentication_string = '' where user = 'root';
# 退出
quit

删除上面的 skip-grant-tables 配置之后重启数据库服务：

systemctl restart mysql

设置密码

# 登录数据库，提示输入密码时直接敲回车
mysql -u root -p
# 设置密码
ALTER USER 'root'@'localhost' IDENTIFIED BY 'your_password';

建库、创建用户并授权

# 创建数据库
create database vac_db;
# 创建用户
create user 'vac_user'@'%' identified by 'abc@123';
# 授权
grant all privileges on vac_db.* to vac_user;
# 刷新
flush privileges;

TODO

未完待续…

一个调用chatgpt进行翻译的chrome插件

地址：

GPTranslate-翻译

对鼠标选中文本利用chatgpt翻译，由于网络原因可能速度会比较慢，推荐在对速度不敏感而对翻译的流畅性较高的情况下使用。可以点击扩展图标选择目标语言。

Интернет-магазин Chrome

这是一个主要用来更改http请求头部的简单chrome扩展，有任何使用问题以及建议可以移步https://github.com/vacuityv/modifyHeaders 进行反馈

本文不涉及任何高深技术难点，仅记录解决问题的过程，供自己在下次遇到的时候参考。
最近在对接工行的对账平台，需要使用sftp配合rsa私钥下载对账单，翻看了以前的代码以及网上搜索了一下，发现代码实现的话用jsch比较方便。
然后开始代码实现，然后发现网上大部分是通过密码或者私钥文件登录，但是这边不想存储文件，所以废了点时间找了直接通过私钥字符串来实现：

jsch.addIdentity("id_rsa", key.getBytes(), null, null);

本地密钥对是通过工行提供的工具来生成的，私钥类似于这种：

MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCP3OMU9GXXXXXXXX...XXXXXX4W0F7bIvUZeuurhxv8MfER3B/H8hErSia81+HY=

是没有头部和尾部的
然后第一遍尝试果然出错了：

Caused by: com.jcraft.jsch.JSchException: invalid privatekey: [B@44e81672

于是开始仔细查看，然后发现应该是缺少头部和尾部，于是把私钥的头部为尾部加上，变成如下格式：

-----BEGIN RSA PRIVATE KEY-----
XXX...XXX=
-----END RSA PRIVATE KEY-----

再试一次，还是同样的错误，我一度怀疑是不是工行的工具有问题
后来在网上搜索rsa的密钥格式时，发现原来有pkcs1和pkcs8的区别，但是此时我粗心的没看他们具体区别是什么（毕竟大段的英文很费脑），只是简单的看到有区别，于是我去网上找了个简单的函数，可以把私钥在pkcs1和pkcs8之间转化，由于我也不确定我自己的是1还是8，因此两个都执行了，最后确定我的是8，然后转成1之后拼上头尾，果然可以了，正常事情到这里应该结束了，毕竟已经解决了
但是我又思考了下，jsch这么多人用，没道理不支持pkcs8，最终在官网发现这么一行：

	•	supporting private keys in OpenSSL(traditional SSLeay) and PKCS#8 format.

也就是说他们应该是支持的，那为什么我的不行呢
于是只能去看了下1和8的示例，参考文档：
cryptography - PKCS#1 and PKCS#8 format for RSA private key - Stack Overflow
然后发现原来1的头部和尾部是 “BEGIN RSA PRIVATE KEY” 和 “END RSA PRIVATE KEY”，而8的是“BEGIN PRIVATE KEY”和“END PRIVATE KEY”，果然是我的问题，我直接把1和8的转换函数都删了，然后在私钥拼了不带“RSA”的头尾：

-----BEGIN PRIVATE KEY-----
XXX...XXX=
-----END PRIVATE KEY-----

果然可以了
本来就只要拼一个正确的头尾的事情，走了很多弯路 😮‍💨

JSch login using RSA private key

Translate the blog into English:

This article does not involve any technical difficulties, just records the process of problem-solving for reference the next time it is encountered.
Recently, when integrating with ICBC's reconciliation platform, it is necessary to use SFTP in combination with an RSA private key to download the account statement. After reviewing previous code and searching online, it was found that using JSch is more convenient for code implementation.
Then I started implementing the code and found that most online examples log in using a password or a private key file. However, on this side, I did not want to store the file, so I spent some time finding a way to implement it directly using the private key string:
jsch.addIdentity(“id_rsa”, key.getBytes(), null, null);

The local key pair was generated using a tool provided by ICBC, and the private key is similar to this format: MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCP3OMU9GXXXXXXXX…XXXXXX4W0F7bIvUZeuurhxv8MfER3B/H8hErSia81+HY=

There are no headers and footers.
The first attempt resulted in an error: Caused by: com.jcraft.jsch.JSchException: invalid privatekey: [B@44e81672

So I carefully checked it, and then realized that it should be lacking the headers and footers. Therefore, I added the headers and footers to the private key, making it in the following format:
-----BEGIN RSA PRIVATE KEY-----
XXX…XXX=
-----END RSA PRIVATE KEY-----

After trying again, the same error occurred. I once doubted whether there was a problem with ICBC's tool. Later, when searching online for the format of the RSA key, I found that there is a difference between pkcs1 and pkcs8, but at that time I carelessly did not see the specific differences between them (after all, long English is very taxing), but only briefly noted that there is a difference. So, I went online to find a simple function that can convert the private key between pkcs1 and pkcs8, because I was not sure whether mine was 1 or 8, so I executed both, and finally confirmed mine was 8. Then, after converting it to 1 and adding the headers and footers, it worked. This should have been the end of the normal events after solving it.
But then, I thought again. So many people use JSch, it doesn’t make sense that it doesn’t support pkcs8. Eventually, I found a line on their official website: • supporting private keys in OpenSSL (traditional SSLeay) and PKCS#8 format.

This means they should support it. So why didn’t it work for me?
Therefore, I had to look at examples of 1 and 8, and found reference documentation:
https://stackoverflow.com/questions/48958304/pkcs1-and-pkcs8-format-for-rsa-private-key

Then I found out that the headers and footers for 1 are "BEGIN RSA PRIVATE KEY" and "END RSA PRIVATE KEY", while for 8 it is "BEGIN PRIVATE KEY" and "END PRIVATE KEY". Indeed, the problem was mine. I directly deleted the conversion functions between 1 and 8, then added the headers and footers to the private key without "RSA":
--—BEGIN PRIVATE KEY-----
XXX…XXX=
-----END PRIVATE KEY-----

This worked.
It was just a matter of adding the correct headers and footers, but I took a lot of detours 😮‍💨

若批评不自由，则赞美无意义
还是去年的时候，公司的行政部门突然要我们开始填对他们的评价，大致有这些：姓名、部门、对某个负责此部门的行政的评价。在某一次被催着写评价之后，我就很随意的对某位行政说：如果要评价最好做成匿名的，这样大家才会写真实的想法。在某一次评价时，我发现果然变成了匿名的。
本来这是一件挺好的事情，没过多久，就出了意外：某个员工在填写问卷时写了不友善的话语。其实从我本人的角度来说，这反而是好事，不管那位员工的评价是真是假是好是坏，都代表了他的想法。你可以认为他说的不对，直接忽略他就好。但是我们的某位负责人在某个管理群里进行了好长一段控诉，甚至要求各个部门对员工进行宣导。这个操作就让我看不懂了。如果这样的话，是不是这个评价只能说好话，那还需要评价干嘛，反正都是好的。
记住一句话：若批评不自由，则赞美无意义。
反正在那次事件之后我们的评价就在钉钉进行了，虽然依然不用写姓名与部门，但是我知道在钉钉肯定会与我们的个人信息进行关联了，也就是再也没有匿名了，那这样统计出来的评价肯定分数很高，但是同时也失去了意义。
在某次闲着无聊的时间，我就在思考怎么实现一个公司内部的完全匿名的系统，需要保证只有公司的人才能参与，但是所参与的活动又不能与真实人进行任何形式的关联，同时在某种程度上又要保证每个人只能参与一次。
首先，我设想给每个员工分配一个随机的字符串，作为激活密钥。然后员工用这个激活密钥去激活设置自己的账号和密码，以后的活动都根据这个账号参与。对于普通不限制参与次数的活动，比如评论等，则只记录数据本身，不和用户做任何关联。随遇需要限制参与次数的活动，比如投票，则员工投票时，对员工的账号进行哈希计算，保存哈希值与投票选项。但是这样有个问题就是从数据库还是可以看出来同一个员工参加多次投票的结果，虽然还是不知道真实身份，但是从多个不同投票的结果有可能泄漏一些信息。有一种方式解决这个问题，就是员工账号加上投票时间戳进行哈希计算，然后保存哈希值与投票时间戳，但是这样有个问题是某个新的投票进来时，为了验证这个账号是否已经投过票，需要去数据库遍历当前投票的所有已参与的哈希与时间戳，然后账号与每个时间戳进行哈希然后进行比较，这个时间成本是很高的，目前我还未想到有什么其他方式可以解决这个问题。

参考官方在ubuntu上安装的文档：
How to install & setup Ghost on Ubuntu 16.04, 18.04 and 20.04

创建用户并给权限

1、创建用户vacuity：

[root@VM-0-14-centos ~]# adduser vacuity

2、赋予用户root权限
首先确保文件 /etc/sudoers 中，这行代码未被注释。

%wheel  ALL=(ALL)       ALL

然后执行：

[root@VM-0-14-centos ~]# usermod -g wheel vacuity

更新yum

[root@VM-0-14-centos ~]# yum update

安装 NGINX

[root@VM-0-14-centos ~]# yum install nginx

安装mysql

此处自行安装

安装node

[root@VM-0-14-centos ~]# yum install nodejs

注意ghost官方关于node版本说明：Supported node versions for self-hosted installs of Ghost
仅支持12.x和14.x，推荐14.x，其他版本均不支持.

查看node版本：

[root@VM-0-14-centos ~]# node --version

我这边显示版本是
v10.24.0
因此需要升级

升级node

安装n

[root@VM-0-14-centos ~]# npm install -g n

安装指定版本

[root@VM-0-14-centos ~]# n 14.17.5

切换 nodejs 版本

编辑bash_profile：

[root@VM-0-14-centos ~]# vim ~/.bash_profile

在末尾添加：

export N_PREFIX=/usr/local  （node实际安装位置）
export PATH=$N_PREFIX/bin:$PATH

如果你用上文方法安装的话，node的实际安装位置应该为 /usr/local/bin

执行 source 使修改生效

[root@VM-0-14-centos ~]# source ~/.bash_profile

这时候再查看 node -v 发现版本切换成功了

安装 Ghost-CLI

[root@VM-0-14-centos ~]# sudo npm install ghost-cli@latest -g

安装 Ghost

创建目录

创建目录: sitename 可以改为你喜欢的任意名称（英文，此处我用的ghost）

[root@VM-0-14-centos ~]# sudo mkdir -p /var/www/sitename

设置目录（替换为你前面创建的用户名称，此处我的为vacuity）：

[root@VM-0-14-centos ~]# sudo chown <user>:<user> /var/www/sitename

赋予权限：

[root@VM-0-14-centos ~]# sudo chmod 775 /var/www/sitename

切换到目录：

[root@VM-0-14-centos ~]# cd /var/www/sitename

运行安装程序

切换用户为前面创建的用户

[root@VM-0-14-centos ~]# su vacuity

运行安装命令：

[vacuity@VM-4-2-centos ghost]$ ghost install

┌──────────────────────────────────────────────────────────────────────────────┐│    The current Node.js version (10.24.0) has reached end-of-life status.     ││ Ghost-CLI will drop support for this Node.js version in an upcoming release, ││                     please update your Node.js version.                      ││                See https://ghost.org/docs/faq/node-versions/.                │└──────────────────────────────────────────────────────────────────────────────┘
✔ Checking system Node.js version - found v10.24.0
✔ Checking logged in user
✔ Checking current folder permissions
System checks failed with message: 'Linux version is not Ubuntu 16, 18, or 20'
Some features of Ghost-CLI may not work without additional configuration.
For local installs we recommend using `ghost install local` instead.
? Continue anyway? (y/N)

出现上面意思是官方的ghost默认只支持ununtu，而我们用的centos，这里直接输入y，代表继续

经过一段时间之后：

Enter your blog URL: (http://localhost:2368)：

此处我输入：https://vacuity.me

接下里就是一堆输入确认，此处注意尽量不要用默认的设置，比如不要让他设置系统服务啥的，因为他是采用ununtu的命令行，跟centos的并不兼容，所以会失败，nginx与证书之类的也需要自己设置，然后结束也不用自动启动。

手动启动：

[vacuity@VM-4-2-centos ghost]$ ghost start

接下来就是ng反向代理与https证书等的配置了。

到这里就差不多结束了，如果有其他问题欢迎邮件咨询（点击网页最底部的Contact标签联系）

最近一段时间也是忙于项目，加上自己的懒惰，所以本该六月完成的拖到了现在。

最近在对一个项目进行重构，原项目是公司有五年历史的老项目了，各种逻辑盘根错节，这里不是要吐槽原项目不好，事实上经过五年没有重构任何项目都会变得臃肿和难以理解，不然shitmontain都是怎么来的。

大学时候，周末没打游戏而是早上就去了图书馆，学习了一天，到图书馆闭馆铃声响起才收拾东西回去。在寂静的芙蓉湖边拍了一张照片，感觉到真不容易，但是一天并没有学到很多东西。

我们有时候太沉迷于自己所付出的时间与精力，但是这些付出本身并没有什么意义，除了用来感动自己。
是因为实际的功劳都很难量化，所以大家都喜欢用苦劳来代替，毕竟时间是可以简单的测量与统计的。这就导致我们在忙了一件事情到很晚的时候，就会容易感动自己，拍张照发个朋友圈，不管是工作的事情还是个人的事情，都会让人感觉自己付出了很多，但是很少有人在乎成果：做成了什么，以及，是否非要这样做才能做成。
其实有时候需要思考下，到11点的原因是什么，是问题真的棘手，是效率问题，是逻辑混乱导致做了很多无用功，还是因为白天划水了，这个才是关键。
我们接受到的教育很多时候会试图告诉我们过程比结果重要，但是其实大家都知道大部分时候结果比过程重要多了。只有在我们的结果不尽如人意或者根本没有结果的时候才需要用过程来表达自己的所谓“成果”，其实这并没有什么意义，特别是工作上。
工作算是最能体现这当面的了。有的人花半小时做完一件事，毫无感觉去做下一件，同样的事情有的人从早上做到晚上11点，然后感到非常不容易，然后发一条朋友圈收获一堆点赞。只是随便举个例子，外面的人永远也不知道那件事的难易程度，是确实需要这么久还是因为太菜，好像也没有人关心，大家都默认是事情难做。不过这样也挺好的，最起码显得大家都很努力。但是对自身来说，还是需要稍微注意，可以欺骗别人，但是不要感动自己。睡前可以自己回想一下事情为什么做了这么久，别人做更久还是更快。当然如果一个人连这个都衡量不出来，那我觉得，就这样吧
写这点字也是断断续续持续了几周时间，先就这样吧

去年做了一年偏管理类工作，感觉不喜欢目前公司的管理模式。给我的感觉整个就是一个效率低下的笨重机器在缓慢爬行，负重还在逐渐增加，整个笨重的身躯随时有可能塌下来。
感觉是太多人只考虑自己的利益。其实工作中考虑自己是没有问题的，但是在公司利益和个人利益之间需要有一个合理比例以达到某种平衡。比例太小，人就比较自私；太大了别人会觉得你很蠢。现在的感觉是有些人这个比例接近零。悲伤的故事。
在这种情况下就换了一个部门，做回研发工作。也接触了算是公司目前最“畅销”项目的代码，从比较偏研发的角度说一下自己的思考，或者叫乱想。

项目本身

这个项目本身是个支付平台。在接触这个项目之前，我认为这个项目的重点应该在于支付渠道、对账、数据监控等。但是了解了之后，才知道我的认知只是其中的一半。
这个项目最初是两个项目合起来的：支付平台和预交金平台。所以除了支付本身，另一半主要是和院内业务的交互。而且，院内业务在日常开发的比重尤其大。
观察部门人员的周报，感觉其实很大一部分人在做的都是和his系统对接的工作。支付平台项目中的大部分开发在做的其实是对接院内系统，这有点本末倒置。在这部分，其实需要做个解耦，把项目主要功能拆成三大部分来处理：支付、院内和整合。

模块

主要模块

支付模块就专门处理支付渠道，主要考虑和钱有关的订单业务，把自己当作一个收款方或者首款渠道的前置，负责连接用户和微信支付宝等，只负责到收款。至于为什么收款以及收款之后做什么，这部分不需要考虑。
院内模块就专门处理和院内的对接，这部分不涉及任何渠道。简单来说，就是一个和his交互的模块，而不考虑其他。
整合模块就需要考虑完整的流程，主要负责调用前两个模块来实现整个业务完整流程。比如在患者进行处方结算这个环节：患者首先进行查询处方并进行预算，这部分是his业务，整合模块调用院内模块，获得预算信息。然后根据预算金额，整合模块调用支付模块进行下单收款。当整合模块收到支付告诉他已收到款之后，就再告诉院内模块这个款已收到，需要告诉his这个处方已结算完成。
分成三部分之后整个项目更加的容易排查和扩展。首先是可以拆分给不同团队或者部门来做，避免一个改动影响整个项目，这可能会造成灾难性后果。其次，可以方便新人熟悉项目。一个新人只需要理解他自己做的其中一部分，做院内的不需要知道收款情况，他要开发的接口就是假设钱已经收到，他甚至不需要其他部分的配合，专注于实现自己的接口并提供出去即可。当第一次看到这个项目有一万七千多个文件的时候，内心是感到很不可思议的。还有就是可以减少项目的维护成本。按照这种结构来说，支付模块只有在对接新的渠道时候才需要改动，整合模块只有在院内流程改动的时候才需要调整，院内模块只有在院内接口改动的时候才需要开发。每一次的改动就意味着有一定几率引入新的bug，因此，越少的改动就意味着越少的维护。如果一定要改，那就尽量减少受影响的模块数量吧。

其他模块

后台管理也是不可缺少的一部分，这部分来说主要是一些配置与业务查看。这部分的接口应尽量由整合模块来提供，以保证数据链路完整性的同时保证其他两个模块功能的纯粹性。
除了以上，我觉得还需要做一些“边角”。比如数据监控与数据展示。以我所在公司的水平来说做专门的数据处理可能有点吃力，但是简单的数据整合以及展示还是可以做的，而且很有必要。虽然现在我们的项目都是私有化部署，但是不排除未来有一些很小的医院，私有化部署对他们和对我们都是没有必要的。对他们来说增加了开支，硬件成本和网络成本都是很大的；对我们来说则增加了维护成本。这时候saas化就很有必要。这个我看到目前的团队和产品经理也有在考虑。
假设我们已经做好了一个云平台，那这个云平台上面要展示的数据其实应该更多，要尽量把那些私有化部署医院的一些非敏感数据整合进来。好的数据对公司的管理层以及市场人员都是很有用的，退一步来说，部门对上层汇报成绩的时候数据是最好的表达方式。

模块开发

项目叫支付平台，而最大的工作量是对接院内his，这应该是很不合理的情况。针对这种情况，我觉得应该出一份标准的文档，由院内his按照标准文档提供接口，只有实在没有办法提供的时候才由我们适配，不然的话这个问题永远无法解决。

基础数据

还有一个问题就是关于基础数据的问题。比如有A和B两个module同时需要访问一张表x，那正常应该做的是A或B提供访问x的service，或者单独一个模块C用来提供对x的增删改查之类的操作。而现在项目的处理方式是在A和B单独处理，就导致多份dao层的出现。目前我想的是单独出来一个module然后把dao和xml先移进去，然后A和B先直接把这个包进去，后续再改由新module提供dubbo服务出去。

代码质量

其实最初想写这篇文章，就是因为这部分。但是没想到啰啰嗦嗦写了这么多其他内容。支付平台算是公司的核心产品了，我觉得我以前在代码质量方面高估了对它的期望。不知道是项目发展到一定规模必然质量下降还是其他原因，反正情况不是很好。
由于本身的水平所限，我想说的都是很简单的，一般初级软件开发人员都应该做到的。
300行的函数。相信这种函数每个开发人员看到之后感受到的只有绝望吧。面对一个屏幕都无法展示完整，包含层层叠叠if语句的函数，有时候真的无从下手，我是配合onenote边做笔记逐行查看，才大致理解了整个函数，这个函数几乎不可维护。这种一般就是后来开发人员没有很好的及时对函数就行梳理以及重构引起的，越积越多，最终几乎没人愿意主动来处理他，处理不好很容易出错。对这种情况，我的建议是当函数超过50行的时候就强制要求拆分。每个人的所有提交进行自动扫描，如果包含超过50行的函数拒绝提交。而且要求对每个函数进行功能说明。这样一个300行的函数会被拆成6-7个小函数，而且是有功能说明的小函数，对代码阅读性有很大提升。
重复的查询。在业务逻辑比较复杂的情况下，有时候会出现很多层调用：入口函数A调用B，然后B调用C，然后C调用D。这个时候就会出现如下情景：A里面需要使用数据库的数据a，此时BCD都不需要。当某一天某一个开发人员改动逻辑发现在D中需要数据a的时候，他可能并没有去从入口一步步从A看到D，他只是关心了D中需要什么，于是他再一次在D中查询了数据库。同样的，假设这个逻辑很长，这个数据可能被查了很多遍。在没有做数据缓存的情况下，会导致同样的数据库查询一遍遍执行，很不合理而且影响程序性能。对这种情况首先应该增加数据缓存，其次还要提高开发人员的基本素质，当更改某个流程时，应对整个流程有充分的了解，避免重复性工作。
代码冗余。只说一句，sonar插件让我看到一个if-else if-else中，第一个if和最后一个else中的代码块是完全一样的，表示很无奈。
复杂或者奇怪的sql。其实很多人并没有系统的学过数据库这门课程，所以他们设计表结构的时候有些随心所欲，这部分就不说了。但是有些人喜欢在网上搜一些有些奇怪或者说很复杂的sql语句用在代码中，对不同数据库的兼容性就会很差。其次，数据库的性能相对于程序一般都不是很好，复杂的sql对整个项目的性能有很大影响。还有就是，sql进行要符合常人的思维习惯。我曾经看到数据查询接口的入参叫callCount，值为2，我觉得我肯定发现了一个隐藏的bug，因为这个查询应该查的是callCount为1的值。但是当我启动项目执行的时候发现返回值并没有出错，让我百思不解。我只能用断点一步步执行，最终发现在sql中他写的是 CALL_COUNT < ${callCount}。看到这里我的内心真的五味杂陈。我不知道为什么开发的时候要把等于1这么正常的情形反常的写成小于2，可能有我不知道的故事吧。
还有其他的小问题就不说了，逼死强迫症。

命名规范

这部分在我来这家公司之前是完全没有思考过的，直到我看到了在一张表中各个字段的奇怪命名方式。一个人对一张表的字段竟然可以添加不同的前缀，这是很不可思议的。至于单词拼错的情形，不说也罢。
真正想说的其实是整个公司的命名统一问题。比如身份证字段，所有项目都应该有个统一的名称，比如：idNo，那么前端在需要身份证号的时候就直接取idNo字段，而不是每个项目起一个名字。实际项目开发中，有看到一个类表示同一种id的字段竟然有好多个，就是因为命名不统一，后面的维护人员并不知道前人写的那个名字和自己的是同一个，无形中就增加了代码维护成本。针对这种只能定义公司自己的命名仓库，每个人需要定义一个新的名字之前都要去查询，如果没查到才能提交新的名字给命名库，只有在命名库采纳之后才允许使用。这当然会增加一些额外的工作量，但是我认为是可以接受的。

关于前端

其实现在的我是没什么资本来讲前端的。所以可能讲的不对或者不合适，不过我自己的博客，应该只要不违法都可以说。好久没大量写过前端了其实，应该接近三年。
在上个公司有写过很多，还用react-native开发过完整的一个网站，并在H5/iOS/android多平台上线，曾经也算是略有心得。其实我们公司的前端页面更偏向于后端的增删改查，大部分也不需要很复杂的前端技巧，这个时候组件化或者说可视化我觉得是完全有可能做到的。不要一讲到可视化就觉得很高端，如果我们只需要实现简单的首页功能与菜单排布，列表预定样式选择配置，我觉得是很容易实现的。
针对首页，开发很多模块出来，比如轮播模块，菜单模块，列表展示模块，然后定义好数据格式。这样的话在后台通过拖拽排布然后配置，就可以定义好一个首页，至于背景色这些就更加简单了。
至于列表页，可以预设几种样式，然后同样通过配置决定加载哪一种，我觉得这些是完全可以实现的。这部分配合一些参数转化，前端根本不需要关心是医院列表还是医生列表，只需要知道数据源，数据转化，列表模版即可自动展示列表。
至于表单页详情页更加不用说了。虽然真正的可视化编程很难，但是配置化的可视化并非不能实现。完全可以遇到新的需求时就以组件的形式做出来，然后入库，随着一点点的扩充，是有可能实现大部分功能的。这并不会很难实现，而且实现过程也不会增加很大额外工作量，但是后期真的可以减少很多前端的工作量。

最后

整篇说是思考，最终更偏向于吐槽。项目在发展过程中还是需要花一些时间定期做些代码方面的优化和重构，不然越积越多，最后整个项目很可能变成一个shit mountain。至于公司层面，我不知道怎么说，应该是我的眼界或者阅历不够。树木还不够大就已经开始生虫子了，需要真正有权利的人来做一些修剪的工作。