记录一下netty做ws服务器的小坑 实现网页的即时通讯，顺便还可以传输文件，对于聊天使用的TextWebSocketFrame，因为是字符串，也就是序列化反序列化的事，一般都没什么问题。对于文件传输，首先就考虑到了二进制帧传输第一个小坑指定WebSocketServerProtocolHandler的大小太小了，我只给了1m，就导致了传输小文件可以正常传输，文件超过限制就会直接给客户端断掉连接，在调试的时候我一直觉得是前端的问题，也是困扰了好久，最后给每个channel都打上日志才发现文件传输一半给客户端断开连接了。第二个小坑这个才是让我最头疼的，，使用二进制帧传输文件必然要用到自定义二进制数据，我的想法也是先用一个int四个字节表示文件名的字节长度，，然后服务端先读取到文件名的长度，接着就能读取文件名了，最后才是文件的二进制数据。二进制数据格式还是很简单的，但是我一调试服务端读取到的int都是值特别大的，显然读取到的不正确，我在前端页面各种调，确定发送的int就是文件名的长度，服务端一直不能匹配，我在服务端也是确定除了使用readInt读取的数据不匹配，后面的二进制数据都是对的。最后查了很多资料才意识到，java默认按照大端字节序去读取存储整数，而JavaScript中，Int32Array是按照本地字节序（通常是小端字节序）来表示整数数组的。这下问题就解决了，netty处理起来也很方便，使用readIntLE()就可以正常拿到文件名的长度了最后再列一下大端字节序跟小端字节序的区别：在小端字节序中，最低有效字节（即数值的最右边字节）被存储在最前面的地址中，而最高有效字节（即数值的最左边字节）被存储在最后面的地址中。例如，当一个 32 位整数 0x12345678 在小端字节序中被存储时，它的四个字节将分别按照 0x78, 0x56, 0x34, 0x12 的顺序存储。在大端字节序中，最高有效字节被存储在最前面的地址中，而最低有效字节被存储在最后面的地址中。例如，当一个 32 位整数 0x12345678 在大端字节序中被存储时，它的四个字节将分别按照 0x12, 0x34, 0x56, 0x78 的顺序存储。

npm 淘宝镜像到期了 npm淘宝镜像切换至淘宝的新镜像域名// 1. 清空缓存 npm cache clean --force // 2. 切换新源 npm config set registry https://registry.npmmirror.com // 3. 查看源是否设置成功 npm config get registry到这里就可以正常使用npm命令安装需要的工具了。如( npm install -g cnpm )

mavne普通项目打包成jar运行 pom文件添加<build> <plugins> <!-- Maven编译插件 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <source>11</source> <target>11</target> </configuration> </plugin> <!-- Maven JAR插件 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>3.2.0</version> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> <mainClass>com.suxii.Application</mainClass> </manifest> </archive> </configuration> </plugin> <!-- Maven Assembly插件 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>3.3.0</version> <configuration> <archive> <manifest> <mainClass>com.suxii.Application</mainClass> </manifest> </archive> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> </configuration> <executions> <execution> <id>make-assembly</id> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> </build>

java使用日志 maven工程中引入日志门面框架 <!--日志门面--> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>2.0.7</version> </dependency>引入日志实现框架<!--logback 日志实现--> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.4.8</version> </dependency>在resource目录下配置 logback.xml 文件<?xml version="1.0" encoding="UTF-8" ?> <configuration> <!-- 配置集中管理属性 我们可以直接修改属性的value值 格式：${name} --> <property name="pattern" value="[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} %c %M %L [%thread] %m%n"></property> <!-- 日志输出格式： %-5level %d{yyyy-MM-dd HH:mm:ss.SSS}日期 %c类的完整名称 %M为方法 %L为行号 %thread为线程名称 %m或者$msg为信息 %n换行 --> <!--定义日志文件保存路径属性--> <!--win写/log会在盘符根目录，logs/在项目根目录--> <property name="log_dir" value="logs/"></property> <!--控制日志输出的appender--> <appender name="console" class="ch.qos.logback.core.ConsoleAppender"> <!--控制输出流对象 默认System.out 改为System.err--> <target>System.err</target> <!--日志消息格式配置--> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>${pattern}</pattern> </encoder> </appender> <!--日志文件输出的appender--> <appender name="file" class="ch.qos.logback.core.FileAppender"> <!--日志文件保存路径--> <file>${log_dir}/logback.log</file> <!--日志消息格式配置--> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>${pattern}</pattern> </encoder> </appender> <!--root logger 配置--> <root level="ALL"> <appender-ref ref="console"/> <!-- <appender-ref ref="file"/>--> </root> </configuration>在java文件中引入使用public static final Logger logger = LoggerFactory.getLogger(Application.class);finish