优化：将各分类菜单聚合到一个导航菜单下
This commit is contained in:
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: F:\ 上的回收站已损坏。是否清空该驱动器上的"回收站"?
|
||||
author: 查尔斯
|
||||
date: 2021/12/01 22:36
|
||||
categories:
|
||||
- Bug万象集
|
||||
tags:
|
||||
- Windows
|
||||
---
|
||||
|
||||
# F:\ 上的回收站已损坏。是否清空该驱动器上的"回收站"?
|
||||
|
||||
## 问题描述
|
||||
|
||||
近期打开移动硬盘时，经常弹出一个提示框，提示内容是：**F:\ 上的"回收站"已损坏。是否清空该驱动器上的"回收站"?**
|
||||
|
||||
|
||||
|
||||
这个提示框出现过好多回了，除了第一次见到时担心数据丢失，所以比较重视，后来次数多了，点过 “是”，也点过 “否”，只要当下不再影响我就先忽略了。
|
||||
|
||||
但今天在公司打开时，它还没完没了的弹，我决定给它 "上一课"。
|
||||
|
||||
::: tip 笔者说
|
||||
|
||||
先说明一下我的这块移动硬盘情况，我把它分了两个区，在我的工作电脑上分别占据 E盘、F盘，E盘 打开没问题，打开 F盘就弹出这个提示。
|
||||
|
||||
:::
|
||||
|
||||
## 解决方案
|
||||
|
||||
### 尝试1：重新插拔移动硬盘
|
||||
|
||||
我首先考虑的是不是接触不良类的问题，于是我在电脑上弹出了移动硬盘，然后把硬盘接线也重新插拔了一下，再插到电脑上。
|
||||
|
||||
再次打开该盘，依然如此，问题未解决。
|
||||
|
||||
### 尝试2：重启电脑
|
||||
|
||||
我又考虑是不是电脑本次出了点故障，于是我重启了电脑。
|
||||
|
||||
|
||||
|
||||
果然，问题还是没解决了。
|
||||
|
||||
::: tip 笔者说
|
||||
|
||||
不过，重启的确应该成为解决问题的优先方法，毕竟有这么个说法："重启可以解决世间 90% 的问题"。巨石强森的电影《摩天营救》里不也是这么演的嘛。很明显，我遇到了剩下那 10% 的问题。
|
||||
|
||||
:::
|
||||
|
||||
### 尝试3：删除回收站
|
||||
|
||||
行吧，再次回归问题本身，它一直提示是回收站损坏，而且，此时我突然想到周末在使用 FreeFileSync 比较 NAS 和硬盘数据时，我看到过这块硬盘中有多一个 recylce 名词的目录（图标也是回收站图标）。
|
||||
|
||||
而除了系统回收站，其他硬盘回收站其实对我都无所谓，那就想法找到并干掉它。
|
||||
|
||||
然而，即使我开启了隐藏的项目显示，窗口下肉眼仍无法找到它，那就使用 CMD 吧。
|
||||
|
||||
以管理员身份打开 CMD，复制下方命令，改成你那提示的错误盘符，回车，再输入 y 确定后删除。
|
||||
|
||||
```shell
|
||||
# $RECYCLE.BIN 是回收站名称
|
||||
# rd 是删除命令
|
||||
# /s 代表除目录本身外，还将删除指定目录下的所有子目录和文件，适用于删除目录树。
|
||||
# f:\ 根据你自己提示的是哪个盘报错，你就将 f 改成哪个盘
|
||||
rd /s f:\$RECYCLE.BIN
|
||||
```
|
||||
|
||||
|
||||
|
||||
问题解决了。
|
||||
395
repos/categories/issues/2021/12/08.for循环中删除集合元素隐藏的陷阱.md
Normal file
395
repos/categories/issues/2021/12/08.for循环中删除集合元素隐藏的陷阱.md
Normal file
@@ -0,0 +1,395 @@
|
||||
---
|
||||
title: for循环中删除集合元素隐藏的陷阱
|
||||
author: 查尔斯
|
||||
date: 2021/12/08 20:00
|
||||
categories:
|
||||
- Bug万象集
|
||||
tags:
|
||||
- Java集合
|
||||
---
|
||||
|
||||
# for循环中删除集合元素隐藏的陷阱
|
||||
|
||||
## 前言
|
||||
|
||||
**C：** 今天在审查代码时，发现某位同事提交的代码中有一个比较基础性的错误。
|
||||
|
||||
这部分需求的主要目的是将集合中指定的元素删除掉，而这位同事采用的方法是用 for 循环来循环集合索引，然后通过索引从集合中取出每一个元素，判断是否是要删除的元素，如果是就直接删除掉。
|
||||
|
||||
**大概意思的代码，如下：**
|
||||
|
||||
```java {11,15}
|
||||
// 创建集合，并初始化数据
|
||||
List<Integer> list = new ArrayList<>(4);
|
||||
list.add(1);
|
||||
list.add(2);
|
||||
list.add(3);
|
||||
list.add(4);
|
||||
|
||||
// 删除元素值为 2 的元素
|
||||
for (int i = 0; i < list.size(); i++) {
|
||||
if (Objects.equals(list.get(i), 2)) {
|
||||
list.remove(i);
|
||||
}
|
||||
}
|
||||
|
||||
System.out.println(list); // [1, 3, 4]
|
||||
```
|
||||
|
||||
笔者知道，肯定有同学会好奇，这结果是正确的啊，哪里有什么问题？的确，这个思路没问题，问题的关键是这位同事采用的循环方式存在问题。
|
||||
|
||||
别着急，接下来，笔者就带各位同学好好测试一下。
|
||||
|
||||
## 测试代码
|
||||
|
||||
### 基础for循环中删除
|
||||
|
||||
直接放代码吧，下方是使用基础的 for 循环（循环索引）来实现的集合元素删除，比之 前言 中的代码，无非是要删除的元素 2 有重复，变成了两个。
|
||||
|
||||
```java {30,33}
|
||||
/**
|
||||
* List集合-循环中删除元素-测试
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/8 20:59
|
||||
*/
|
||||
@DisplayName("List集合-循环中删除元素-测试")
|
||||
public class ListRemoveEleInForLoopTest {
|
||||
|
||||
private List<Integer> list;
|
||||
|
||||
/** 初始化数据 */
|
||||
@BeforeEach
|
||||
public void init() {
|
||||
list = new ArrayList<>(5);
|
||||
list.add(1);
|
||||
list.add(2);
|
||||
list.add(3);
|
||||
list.add(4);
|
||||
list.add(2);
|
||||
}
|
||||
|
||||
/** 运行无异常，测试符合预期 */
|
||||
@Test
|
||||
@DisplayName("基础for循环中删除元素测试")
|
||||
void testBasicForLoop() {
|
||||
for (int i = 0; i < list.size(); i++) {
|
||||
if (Objects.equals(list.get(i), 2)) {
|
||||
// IDEA警告：Suspicious 'List.remove()' in the loop
|
||||
list.remove(i);
|
||||
}
|
||||
}
|
||||
System.out.println(list); // [1, 3, 4]
|
||||
Assertions.assertEquals(list.size(), 3);
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
测试结果也是正常的啊，莫非笔者失手了？别着急 ...
|
||||
|
||||
我们再来测试一下，这回我们稍微调整下重复元素的位置，将重复的元素移动到相邻位置。
|
||||
|
||||
```java {30,33}
|
||||
/**
|
||||
* List集合-循环中删除元素-测试
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/8 20:59
|
||||
*/
|
||||
@DisplayName("List集合-循环中删除元素-测试")
|
||||
public class ListRemoveEleInForLoopTest {
|
||||
|
||||
private List<Integer> list;
|
||||
|
||||
/** 初始化数据 */
|
||||
@BeforeEach
|
||||
public void init() {
|
||||
list = new ArrayList<>(5);
|
||||
list.add(1);
|
||||
list.add(2);
|
||||
list.add(2);
|
||||
list.add(3);
|
||||
list.add(4);
|
||||
}
|
||||
|
||||
/** 运行无异常，测试不通过 */
|
||||
@Test
|
||||
@DisplayName("基础for循环中删除元素测试")
|
||||
void testBasicForLoop() {
|
||||
for (int i = 0; i < list.size(); i++) {
|
||||
if (Objects.equals(list.get(i), 2)) {
|
||||
// IDEA警告：Suspicious 'List.remove()' in the loop
|
||||
list.remove(i);
|
||||
}
|
||||
}
|
||||
System.out.println(list); // [1, 2, 3, 4]
|
||||
Assertions.assertEquals(list.size(), 3);
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
测试不通过，why？
|
||||
|
||||
**原因很简单：** ArrayList 是基于数组结构而来的，在实现 E remove(int index) 方法时，也是在操作数组而已。
|
||||
|
||||
**E remove(int index) 方法的源代码，如下：**
|
||||
|
||||
```java {20,25}
|
||||
/**
|
||||
* Removes the element at the specified position in this list.
|
||||
* Shifts any subsequent elements to the left (subtracts one from their
|
||||
* indices).
|
||||
*
|
||||
* @param index the index of the element to be removed
|
||||
* @return the element that was removed from the list
|
||||
* @throws IndexOutOfBoundsException {@inheritDoc}
|
||||
*/
|
||||
public E remove(int index) {
|
||||
rangeCheck(index);
|
||||
|
||||
modCount++;
|
||||
E oldValue = elementData(index);
|
||||
|
||||
int numMoved = size - index - 1;
|
||||
if (numMoved > 0)
|
||||
// 表面看是在拷贝数组，但是源数组和目标数组都是同一个，所以是移动数组元素而已
|
||||
// 例如：[1, 2, 3, 4] -> [1, 3, 4, 4]
|
||||
System.arraycopy(elementData, index+1, elementData, index,
|
||||
numMoved);
|
||||
// 元素数量-1，并清除多余元素
|
||||
// 例如：[1, 2, 3, 4] -> [1, 3, 4, 4]
|
||||
// 最后一个4就是多余的，置为默认值 null
|
||||
elementData[--size] = null; // clear to let GC do its work
|
||||
|
||||
return oldValue;
|
||||
}
|
||||
```
|
||||
|
||||
这样的话就会导致，在循环索引中删除完某个元素，其后面的元素移动到这个元素的位置，但是循环的索引可没回退，这样在取值时就会 **跳过下一个元素** 。（看不懂的话，可以debug一下，很清晰的）
|
||||
|
||||
如果被删除元素的下一个元素不是匹配条件的，那还问题不显，但是如果被删除元素的下一个元素也是匹配条件的，也就会出现刚才测试的结果了。
|
||||
|
||||
知道了问题的根源，要是还想要用这种循环，加一行代码就可以了。
|
||||
|
||||
```java {30,32,35}
|
||||
/**
|
||||
* List集合-循环中删除元素-测试
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/8 20:59
|
||||
*/
|
||||
@DisplayName("List集合-循环中删除元素-测试")
|
||||
public class ListRemoveEleInForLoopTest {
|
||||
|
||||
private List<Integer> list;
|
||||
|
||||
/** 初始化数据 */
|
||||
@BeforeEach
|
||||
public void init() {
|
||||
list = new ArrayList<>(5);
|
||||
list.add(1);
|
||||
list.add(2);
|
||||
list.add(2);
|
||||
list.add(3);
|
||||
list.add(4);
|
||||
}
|
||||
|
||||
/** 运行无异常，测试不通过 */
|
||||
@Test
|
||||
@DisplayName("基础for循环中删除元素测试")
|
||||
void testBasicForLoop() {
|
||||
for (int i = 0; i < list.size(); i++) {
|
||||
if (Objects.equals(list.get(i), 2)) {
|
||||
// IDEA警告：Suspicious 'List.remove()' in the loop
|
||||
list.remove(i);
|
||||
// !!!回退索引!!!
|
||||
i--;
|
||||
}
|
||||
}
|
||||
System.out.println(list); // [1, 3, 4]
|
||||
Assertions.assertEquals(list.size(), 3);
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
### 增强for循环中删除
|
||||
|
||||
显然，在基础 for 循环中删除元素，这种方法并不是最好的，那我们就再来看看其他的循环方式吧。
|
||||
|
||||
简单改动下代码，看看平时出场频率也很高的增强 for 循环会如何？
|
||||
|
||||
```java {29}
|
||||
/**
|
||||
* List集合-循环中删除元素-测试
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/8 20:59
|
||||
*/
|
||||
@DisplayName("List集合-循环中删除元素-测试")
|
||||
public class ListRemoveEleInForLoopTest {
|
||||
|
||||
private List<Integer> list;
|
||||
|
||||
/** 初始化数据 */
|
||||
@BeforeEach
|
||||
public void init() {
|
||||
list = new ArrayList<>(5);
|
||||
list.add(1);
|
||||
list.add(2);
|
||||
list.add(2);
|
||||
list.add(3);
|
||||
list.add(4);
|
||||
}
|
||||
|
||||
/** 运行时异常：java.util.ConcurrentModificationException */
|
||||
@Test
|
||||
@DisplayName("增强for循环中删除元素测试")
|
||||
void testForEachLoop() {
|
||||
for (Integer num : list) {
|
||||
if (Objects.equals(num, 2)) {
|
||||
list.remove(num);
|
||||
}
|
||||
}
|
||||
System.out.println(list);
|
||||
Assertions.assertSame(list.size(), 3);
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
测试中断，删除一个元素后继续循环会抛出运行时异常：java.util.ConcurrentModificationException。 Pass ...
|
||||
|
||||
### 迭代器中删除
|
||||
|
||||
最后，我们再尝试一种循环：迭代器，可能对于部分同学来说，平时使用相对要少一些。
|
||||
|
||||
```java {31,34}
|
||||
/**
|
||||
* List集合-循环中删除元素-测试
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/8 20:59
|
||||
*/
|
||||
@DisplayName("List集合-循环中删除元素-测试")
|
||||
public class ListRemoveEleInForLoopTest {
|
||||
|
||||
private List<Integer> list;
|
||||
|
||||
/** 初始化数据 */
|
||||
@BeforeEach
|
||||
public void init() {
|
||||
list = new ArrayList<>(5);
|
||||
list.add(1);
|
||||
list.add(2);
|
||||
list.add(2);
|
||||
list.add(3);
|
||||
list.add(4);
|
||||
}
|
||||
|
||||
/** 运行无异常，测试符合预期 */
|
||||
@Test
|
||||
@DisplayName("迭代器中删除元素测试")
|
||||
void testIterator() {
|
||||
Iterator<Integer> iterator = list.iterator();
|
||||
while (iterator.hasNext()) {
|
||||
Integer num = iterator.next();
|
||||
if (Objects.equals(num, 2)) {
|
||||
iterator.remove();
|
||||
}
|
||||
}
|
||||
System.out.println(list); // [1, 3, 4]
|
||||
Assertions.assertSame(list.size(), 3);
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
测试通过，这种方式也是平时 **推荐大家采用** 的，而且在 Java 8 中，官方还为我们在 Collection 接口中提供了一个 default 方法来简化集合删除元素。
|
||||
|
||||
```java {28}
|
||||
/**
|
||||
* List集合-循环中删除元素-测试
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/8 20:59
|
||||
*/
|
||||
@DisplayName("List集合-循环中删除元素-测试")
|
||||
public class ListRemoveEleInForLoopTest {
|
||||
|
||||
private List<Integer> list;
|
||||
|
||||
/** 初始化数据 */
|
||||
@BeforeEach
|
||||
public void init() {
|
||||
list = new ArrayList<>(5);
|
||||
list.add(1);
|
||||
list.add(2);
|
||||
list.add(2);
|
||||
list.add(3);
|
||||
list.add(4);
|
||||
}
|
||||
|
||||
/** 运行无异常，测试符合预期 */
|
||||
@Test
|
||||
@DisplayName("迭代器中删除元素测试")
|
||||
void testIterator() {
|
||||
// Java 8 在 Collection 接口中提供的 default 方法
|
||||
list.removeIf(num -> Objects.equals(num, 2));
|
||||
System.out.println(list); // [1, 3, 4]
|
||||
Assertions.assertSame(list.size(), 3);
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
**Collection 接口的 removeIf() 方法的源代码，如下：**
|
||||
|
||||
```java {27,30}
|
||||
public interface Collection<E> extends Iterable<E> {
|
||||
/**
|
||||
* Removes all of the elements of this collection that satisfy the given
|
||||
* predicate. Errors or runtime exceptions thrown during iteration or by
|
||||
* the predicate are relayed to the caller.
|
||||
*
|
||||
* @implSpec
|
||||
* The default implementation traverses all elements of the collection using
|
||||
* its {@link #iterator}. Each matching element is removed using
|
||||
* {@link Iterator#remove()}. If the collection's iterator does not
|
||||
* support removal then an {@code UnsupportedOperationException} will be
|
||||
* thrown on the first matching element.
|
||||
*
|
||||
* @param filter a predicate which returns {@code true} for elements to be
|
||||
* removed
|
||||
* @return {@code true} if any elements were removed
|
||||
* @throws NullPointerException if the specified filter is null
|
||||
* @throws UnsupportedOperationException if elements cannot be removed
|
||||
* from this collection. Implementations may throw this exception if a
|
||||
* matching element cannot be removed or if, in general, removal is not
|
||||
* supported.
|
||||
* @since 1.8
|
||||
*/
|
||||
default boolean removeIf(Predicate<? super E> filter) {
|
||||
Objects.requireNonNull(filter);
|
||||
boolean removed = false;
|
||||
final Iterator<E> each = iterator();
|
||||
while (each.hasNext()) {
|
||||
if (filter.test(each.next())) {
|
||||
each.remove();
|
||||
removed = true;
|
||||
}
|
||||
}
|
||||
return removed;
|
||||
}
|
||||
|
||||
// 省略其他代码...
|
||||
}
|
||||
```
|
||||
|
||||
很显然，官方也是用的迭代器来实现的。
|
||||
|
||||
## 后记
|
||||
|
||||
**C：** 虽然是一个小问题，但是见到的犯错者无数，以前并未当回事，这次遇到正好记录一下，给各位同学一个提醒。
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: Command line is too long. Shorten command line for XXX or also for Spring Boot default configuration？
|
||||
author: 查尔斯
|
||||
date: 2021/12/10 22:11
|
||||
categories:
|
||||
- Bug万象集
|
||||
tags:
|
||||
- IDE
|
||||
- IntelliJ_IDEA
|
||||
---
|
||||
|
||||
# Command line is too long. Shorten command line for XXX or also for Spring Boot default configuration？
|
||||
|
||||
## 问题描述
|
||||
|
||||
今天笔者在公司从测试环境拉取了一个 bugfix 分支之后，等待 Maven 依赖也加载完了，点了【Debug】运行按钮，想起身去接杯水，跳过项目启动的这段时间。
|
||||
|
||||
结果，刚握住水杯，就看到 IntelliJ IDEA 在左下角弹出了一个错误提示框，如下：
|
||||
|
||||
|
||||
|
||||
看提示的意思是命令行太长了，让缩短一下命令行。又点了两下【Debug】运行按钮，依然不依不饶的弹出这个提示，那就放下水杯解决吧。
|
||||
|
||||
|
||||
## 原因分析
|
||||
我想了想原因，就明白什么问题了，给大家贴一下启动的项目程序所在位置。
|
||||
|
||||
- 仓库目录（.git目录）
|
||||
- 项目doc目录
|
||||
- src
|
||||
- 项目源码父级项目目录
|
||||
- 启动入口所在项目目录
|
||||
- src\main\java（三级目录）
|
||||
- com\xx\xxx（N级的包目录）
|
||||
- Spring Boot 项目启动类
|
||||
- 若干模块项目目录
|
||||
- pom.xml
|
||||
|
||||
这个结构，不好多说什么，历史遗留， doc 和源码放在了一个仓库，层级的确挺深，但一般情况下也不会出现此问题，这次算是一个特殊情况。
|
||||
|
||||
|
||||
## 解决方案
|
||||
其实问题解决起来也不难，这种问题笔者以前也遇到过，不过当时也忘了怎么切到了 IntelliJ IDEA 修复提示内，选了一下就结束了。
|
||||
|
||||
而这一次笔者没找到正确的修复入口，所以只能采用手动修改配置的方法了。
|
||||
|
||||
双击打开项目根目录下的 `.idea` 目录，这个目录下都是 IntelliJ IDEA 自动保存的项目配置内容，一般情况下我们不需要关注它，但这次我们需要找到其中的 `workspace.xml` 配置文件，手动修改一下配置。
|
||||
|
||||
|
||||
|
||||
按下 【Ctrl + F】，在弹出的搜索框中，输入【PropertiesComponent】回车，定位到该项配置后，在其所在的 `<component>` 标签内最后部分添加一条属性配置，如下：
|
||||
|
||||
```xml
|
||||
<property name="dynamic.classpath" value="true" />
|
||||
```
|
||||
|
||||
|
||||
|
||||
添加完后，关闭该配置文件即可，再次点击【Debug】运行按钮，项目正常启动了，笔者也该去接水了。
|
||||
249
repos/categories/issues/2021/12/11.SQL 注入攻击风险.md
Normal file
249
repos/categories/issues/2021/12/11.SQL 注入攻击风险.md
Normal file
@@ -0,0 +1,249 @@
|
||||
---
|
||||
title: SQL 注入攻击风险
|
||||
author: 查尔斯
|
||||
date: 2021/12/11 22:51
|
||||
categories:
|
||||
- Bug万象集
|
||||
tags:
|
||||
- SQL
|
||||
- 网络攻击
|
||||
---
|
||||
|
||||
# SQL 注入攻击风险
|
||||
|
||||
## 前言
|
||||
|
||||
**C：** Java 开发者都知道，想要用 Java 连接关系型数据库进行操作，就要学习使用 java.sql 包下的一套 JDBC API，这套 API 的使用步骤，大致如下：
|
||||
|
||||
```java {30}
|
||||
/**
|
||||
* JDBC，模拟登录示例
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/11 22:51
|
||||
*/
|
||||
public class JdbcLoginDemo {
|
||||
public static void main(String[] args) {
|
||||
// 录入登录信息
|
||||
Scanner input = new Scanner(System.in);
|
||||
System.out.print("请输入用户名：");
|
||||
String username = input.next();
|
||||
System.out.print("请输入密码：");
|
||||
String password = input.next();
|
||||
|
||||
// 查询数据库，验证登录信息
|
||||
boolean loginResult = false;
|
||||
Connection conn = null;
|
||||
Statement statement = null;
|
||||
ResultSet rs = null;
|
||||
try {
|
||||
// 1、注册驱动
|
||||
Class.forName("com.mysql.jdbc.Driver");
|
||||
// 2、获取连接
|
||||
conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/school", "root", "root");
|
||||
// 3、创建语句执行平台
|
||||
statement = conn.createStatement();
|
||||
// 4、编写SQL语句
|
||||
// String sql = "SELECT * FROM `user` WHERE `username` = '" + username + "' AND `password` = '" + password + "'";
|
||||
String sql = String.format("SELECT * FROM `user` WHERE `username` = '%s' AND `password` = '%s'", username, password);
|
||||
// 5、执行SQL语句
|
||||
rs = statement.executeQuery(sql);
|
||||
// 6、解析结果集
|
||||
if (rs.next()) {
|
||||
loginResult = true;
|
||||
}
|
||||
} catch (Exception e) {
|
||||
e.printStackTrace();
|
||||
} finally {
|
||||
// 7、释放资源，先开后关
|
||||
try {
|
||||
if (rs != null) {
|
||||
rs.close();
|
||||
}
|
||||
if (statement != null) {
|
||||
statement.close();
|
||||
}
|
||||
if (conn != null) {
|
||||
conn.close();
|
||||
}
|
||||
} catch (SQLException e) {
|
||||
e.printStackTrace();
|
||||
}
|
||||
}
|
||||
|
||||
// 输出登录结果
|
||||
System.out.println(loginResult ? "登录成功！" : "登录失败！用户名或密码错误！");
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
上方是一个非常经典的 JDBC 模拟登录示例，同样的，很多同学可能一眼就看出来了，它存在着一个严重的攻击漏洞：SQL 注入攻击。
|
||||
|
||||
今天，咱们就一块来聊聊 SQL 注入（SQL Injection）这个东西。
|
||||
|
||||
## SQL 注入攻击简介
|
||||
|
||||
SQL 注入（SQL Injection）作为一种比较常见的网络攻击方式，在学习 JDBC 时就肯定会得到老师的重点提醒。它的出现原因就是因为开发者编写的 SQL 语句，采用拼接的方式来接受输入参数。
|
||||
|
||||
看看上方代码的第 4 步骤，一条 通过用户名和密码来查询用户记录 的简单查询 SQL，它在接受用户名和密码两个输入参数时，是直接拼接到查询 SQL 语句上的。
|
||||
|
||||
```java
|
||||
// 下方两种形式都一样，笔者个人相对更喜欢使用格式化字符串而已
|
||||
// String sql = "SELECT * FROM `user` WHERE `username` = '" + username + "' AND `password` = '" + password + "'";
|
||||
String sql = String.format("SELECT * FROM `user` WHERE `username` = '%s' AND `password` = '%s'", username, password);
|
||||
```
|
||||
|
||||
假设是一个正常的用户输入：
|
||||
|
||||
- 用户名：admin
|
||||
- 密码：123456
|
||||
|
||||
那最终执行的查询 SQL 语句，如下：
|
||||
|
||||
```sql
|
||||
SELECT * FROM `user` WHERE `username` = 'admin' AND `password` = '123456';
|
||||
```
|
||||
|
||||
这倒是没什么问题，但是如果是一个攻击者恶意的输入：
|
||||
|
||||
- 用户名：luanShuDe（胡乱输入的）
|
||||
- 密码：luanShuDe' OR '1' = '1（密码也是胡乱输入的，重点在后面部分）
|
||||
|
||||
那最终执行的查询 SQL 语句，如下：
|
||||
|
||||
```sql
|
||||
SELECT * FROM `user` WHERE `username` = 'luanShuDe' AND `password` = 'luanShuDe' OR '1' = '1';
|
||||
```
|
||||
|
||||
胡乱输入的用户名和密码肯定查询不到结果，但是密码后面的内容由于是 SQL 语法，直接拼接到查询 SQL 语句内，最终也是会执行的，1和1是恒等的，而 OR 运算符是只要一个条件满足，就匹配，所以结果就会查询出所有的用户记录。
|
||||
|
||||
这就导致本该登录失败的情况，却判定登录成功了！也就达成了一次相对简单的 SQL 注入攻击了。
|
||||
|
||||
## 解决方案
|
||||
|
||||
### JDBC 的 PreparedStatement
|
||||
|
||||
问题是要解决的，而且 JDBC 早就提供了相应的解决方法。那就是采用 Statement 的子接口 PreparedStatement，使用步骤如下：
|
||||
|
||||
::: tip 笔者说
|
||||
|
||||
Prepared 从单词意思上就知道是：准备好的，有准备的。
|
||||
|
||||
PreparedStatement 的对象包含了编译好的 SQL 语句。这种 “准备好” 的方式不仅能提高安全性，解决 SQL 注入问题，而且在多次执行同一个 SQL 时，无需再编译，能够提高效率。
|
||||
|
||||
:::
|
||||
|
||||
```java {27}
|
||||
/**
|
||||
* JDBC，模拟登录示例
|
||||
*
|
||||
* @author Charles7c
|
||||
* @date 2021/12/11 22:51
|
||||
*/
|
||||
public class JdbcLoginDemo2 {
|
||||
public static void main(String[] args) {
|
||||
// 录入登录信息
|
||||
Scanner input = new Scanner(System.in);
|
||||
System.out.print("请输入用户名：");
|
||||
String username = input.next();
|
||||
System.out.print("请输入密码：");
|
||||
String password = input.next();
|
||||
|
||||
// 查询数据库，验证登录信息
|
||||
boolean loginResult = false;
|
||||
Connection conn = null;
|
||||
PreparedStatement ps = null;
|
||||
ResultSet rs = null;
|
||||
try {
|
||||
// 1、注册驱动
|
||||
Class.forName("com.mysql.jdbc.Driver");
|
||||
// 2、获取连接
|
||||
conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/school", "root", "root");
|
||||
// 3、编写SQL语句，使用 ? 进行参数占位
|
||||
String sql = "SELECT * FROM `user` WHERE `username` = ? AND `password` = ?";
|
||||
// 4、创建语句执行平台
|
||||
ps = conn.prepareStatement(sql);
|
||||
// 5、设置参数
|
||||
ps.setString(1, username);
|
||||
ps.setString(2, password);
|
||||
// 6、执行SQL语句
|
||||
rs = ps.executeQuery();
|
||||
// 7、解析结果集
|
||||
if (rs.next()) {
|
||||
loginResult = true;
|
||||
}
|
||||
} catch (Exception e) {
|
||||
e.printStackTrace();
|
||||
} finally {
|
||||
// 8、释放资源，先开后关
|
||||
try {
|
||||
if (rs != null) {
|
||||
rs.close();
|
||||
}
|
||||
if (ps != null) {
|
||||
ps.close();
|
||||
}
|
||||
if (conn != null) {
|
||||
conn.close();
|
||||
}
|
||||
} catch (SQLException e) {
|
||||
e.printStackTrace();
|
||||
}
|
||||
}
|
||||
|
||||
// 输出登录结果
|
||||
System.out.println(loginResult ? "登录成功！" : "登录失败！用户名或密码错误！");
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### MyBatis 的 #{}
|
||||
|
||||
在平时的开发中，我们基本上都在采用 ORM 框架来解决持久层问题，MyBatis 作为一个在国内常用的半自动 ORM 框架，底层就是对 JDBC 的封装，简化了大量模板化的代码。
|
||||
|
||||
如果你也使用了 MyBatis，那么在 SQL 语句传参时，一定要注意使用 #{} 的方式，它最终的实现就是 JDBC 的 PreparedStatement。
|
||||
|
||||
### 特殊符号检查过滤
|
||||
|
||||
MyBatis 还有一种 ${} 也可以来接受参数，但是这种方式最终就是直接在 SQL 语句中拼接输入参数，所以它存在 SQL 注入攻击的风险。
|
||||
|
||||
如果真的想用，可以采用对输入参数进行特殊符号检查过滤。检查过滤的代码，可参考如下：
|
||||
|
||||
```java
|
||||
public class CheckUtils {
|
||||
/**
|
||||
* 校验条件参数不可包含特殊字符，并且小于255个字符
|
||||
*
|
||||
* @param 条件参数内容
|
||||
* @throws Exception 具体错误信息
|
||||
*/
|
||||
public static void checkCondition(String param) throws Exception {
|
||||
if (param != null) {
|
||||
String regEx = "[`~!@#$%^&*+=|{}':;',\\[\\]<>?~！@#￥%……&*（）+|{}【】‘；：”“’。，、？]|\n|\r|\t";
|
||||
Matcher matcher = Pattern.compile(regEx).matcher(param);
|
||||
if (param.length() < 0 || param.length() > 255) {
|
||||
throw new Exception("查询条件最长字符255！");
|
||||
}
|
||||
if (matcher.find()) {
|
||||
throw new Exception("查询条件中不应包含特殊字符！");
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
当然了，笔者个人认为基本上能用 ${} 的地方都可以采用 #{} 替代。不过，倒也是见过一些同事在写代码时坚持用 ${} ，代码片段类似如下：
|
||||
|
||||
```sql
|
||||
SELECT * FROM user WHERE username LIKE '%${username}%'
|
||||
```
|
||||
|
||||
的确，LIKE 模糊查询时，后面模糊条件的 `%` 等符号是不能直接出现在 SQL 语句里的，而是要写在由 `'` （单引号）引起的字符串内。但是 MyBatis 的 `#{}` 又无法写在由 `'` （单引号）引起的字符串内，即无法直接写成 `'%#{username}%'` （如果你不相信，可以自行尝试一下，看看控制台会有什么 “惊喜” 输出），这应该就是这部分同事不得不采用 `'%${username}%'` 写法的原因。
|
||||
|
||||
好在，笔者这正好也提供一种解决方法，可以解决此问题，那就是使用 SQL 函数 CONCAT()，代码片段类似如下：
|
||||
|
||||
```sql
|
||||
SELECT * FROM user WHERE username LIKE CONCAT('%', #{username}, '%')
|
||||
```
|
||||
|
||||
没错，既然要拼接字符串，那就用 CONCAT() 函数，这个函数就是专门用来拼接字符串的，在拼接时可以使用 #{} ，所以也就不会存在 SQL 注入的问题了。
|
||||
60
repos/categories/issues/2021/12/13.无法访问F盘。文件或目录损坏且无法读取.md
Normal file
60
repos/categories/issues/2021/12/13.无法访问F盘。文件或目录损坏且无法读取.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: 无法访问 F:\。文件或目录损坏且无法读取。
|
||||
author: 查尔斯
|
||||
date: 2021/12/13 22:57
|
||||
categories:
|
||||
- Bug万象集
|
||||
tags:
|
||||
- Windows
|
||||
---
|
||||
|
||||
# 无法访问 F:\。文件或目录损坏且无法读取。
|
||||
|
||||
## 问题描述
|
||||
|
||||
笔者这块西数的移动硬盘最近真的是问题频发，前段时间无法删除损坏的回收站，这两天在家里电脑上插上之后，双击 F 盘提示已损坏，较之以前问题更甚。
|
||||
|
||||
这的确给了笔者一个 “惊喜”，最近两周好像没开 Drive 备份到 NAS 。硬盘要是坏了，这两周的东西还能剩下多少就不好说了。
|
||||
|
||||
不过好在最后问题解决了，跟笔者来一起看看解决方法吧。
|
||||
|
||||
|
||||
|
||||
|
||||
## 解决方案
|
||||
### 尝试1：尝试检查与修复
|
||||
|
||||
首先，在出现问题的磁盘上【右键】单击，然后选择【属性】。
|
||||
|
||||
|
||||
|
||||
在弹出的【属性】对话框中，选择【工具】选项卡，然后点击【检查】按钮。这个功能是用来检查磁盘文件系统错误的，检查完还会有个错误修复的环节。
|
||||
|
||||
|
||||
|
||||
可惜的是，不知道是笔者这台电脑登录的账号权限问题，还是系统错误，这项修复手段，笔者用不了。
|
||||
|
||||
|
||||
|
||||
### 尝试2：命令行修复
|
||||
|
||||
还是老规矩，桌面可视化中的功能只是一种手段，每一项功能都有其对应的系统命令。
|
||||
|
||||
按下【Windows】键，弹出【开始】菜单，直接输入【cmd】来在菜单中搜索。搜索出来后，在【cmd.exe/命令行】上【右键】单击，选择【以管理员身份运行】。
|
||||
|
||||
|
||||
|
||||
在弹出的 CMD 命令行窗口中，输入以下命令：
|
||||
|
||||
```bash
|
||||
# 这条命令是用来检查磁盘并修复的，中间的 f: 换成你出现上方问题的盘符即可。
|
||||
chkdsk f: /f
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
等待检查修复结束，笔者的 F 盘又回来了。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user