Java代码在转换为UTF-8编码后,Eclipse编译运行没有问题,但是用Maven编译时,抛出非法字符65278错误. 原因在于,转换后文件头部带有BOM信息,而Maven不支持,删掉文件头的BOM信息即可. 可以通过以下命令,在命令行中批量删除文件中BOM信息: perl -pi.bak -w -e 's/^\xEF\xBB\xBF' *.java 然后,删除.bak后缀的备份文件: rm *.java.bak 现在可以查看文件中是否,还带有BOM信息,可以通过以下命令查询: grep -

linux 检测远程端口是否打开   检测远程端口是否打开   常用telnet 110.101.101.101 80方式测试远程主机端口是否打开.   除此之外还可以使用:   方法1.nmap ip -p port 测试端口   nmap ip 显示全部打开的端口   根据显示close/open确定端口是否打开.   方法2. nc -v host port   端口未打开返回状态为非0  

之前都是用cleanbom.php来去除BOM的.今天运行提示没有异常文件,但是用Fiddler还是看到了EF BB BF,删除缓存也无效,将cleanbom.php上传到生产环境也提示没有异常. 这里充分鄙视下Beyond Compare,也是怪我不会用.要对比出BOM,需要使用“二进制比较”而不是“基于规则的比较”. 为什么cleanbom.php也没能发现呢,猜测原因是权限不足,无法列出某些文件夹. 所以还是补习了一下linux系统下该怎么处理: grep -r -I -l $'^\xEF

找了几个 linux 下检测出口地址的(前提是能访问外网). curl ifconfig.me curl ipinfo.io/ip curl ipecho.net/plain

今天很是郁闷,写了一个php接口,返回的是标准的json字符串,但是调用的php 就是无法json_decode(),返回错误码为4,最后终于找到原因,原来是蒙一个文件中有bom头,最后采用一个命令 全部去掉bom头:find . -type f -exec sed -i 's/\xEF\xBB\xBF//' {} \;

1. 清空缓存 > /proc/sys/vm/drop_caches 2. 测试读取速度 a. 将/dev/zero中数据按1M的数据单位写入testfile,共写512个单位,并不通过缓存 conv=fdatasync b. 运用Linux自带的简单测试工具命令 # hdparm -t /dev/sda

#nmp# nmap 127.0.0.1 #netstat# netstat -anlp | grep 22 #telnet# 服务器端口即使处于监听状态,但是防火墙iptables屏蔽了该端口,是无法通过该方法检测端口是否开放 #屏蔽与关闭# 对应服务器开启,一般端口就开启了,不能访问,可能是由于防火墙的限制,导致端口被屏蔽了.

1.查找bom头文件 grep -r -I -l $'^\xEF\xBB\xBF' ./ 2.替换bom头文件 find . -type f -exec sed -i 's/\xEF\xBB\xBF//' {} \;

<?php //有些php文件由于不小心保存成了含bom头的格式而导致出现一系列的问题.以下是批量清除bom头的代码 if (isset ( $_GET ['dir'] )) { //config the basedir $basedir = $_GET ['dir']; } else { $basedir = '.'; } $basedir="."; //默认可以是当前的文件夹 $auto = 1; checkdir ( $basedir ); function checkdi

检测 tls # openssl s_client -connect intl.jdair.net: -tls1

在linux中,文件系统将所有的磁盘都并入一个虚拟目录下,在使用新的存储媒体之前,需要把它放到虚拟目录下,这项工作称为挂载. 1.mount命令 mount会输出当前系统上挂载的设备列表,要在虚拟目录中挂载设备,需要以root用户身份登录.或者是以root身份运行sudo命令. 手动挂载命令:mount -t type device directory 如:手动将U盘的/dev/sdb-1 挂载到/media/disk,可用下面命令:mount -t vfat /dev/sdb1 /media/

1. 直接遍历/proc目录 int find_pid_by_name( char* pidname, pid_t *pidlist) { #define READ_BUF_SIZE 256 DIR *dir; struct dirent *next; int i = 0; dir = opendir("/proc"); if (!dir) { printf("Cannot open /proc"); } while ((next = readdir(dir)) !

常用telnet ip port 方式(如telnet 172.17.193.18 5902)测试远程主机端口是否打开,或者用于测试当前环境与远程主机的端口之间的防火墙开通与否. telnet [root@oldboy ~]# telnet baidu.com 80 Trying 123.125.114.144... Connected to baidu.com (123.125.114.144). #==>出现Connected表示连通了,说明百度的80端口开放的 Escape charact

前言: 昨天,在文章:终于等到你:CYQ.Data V5系列 (ORM数据层,支持.NET Core)最新版本开源了 中, 不小心看到一条留言: 然后就去该地址看了一下,这一看,顺带折腾了一天. 今天,就和大伙分享下折腾的感觉. 在该开源地址中,代码有C++和C#两个版本,编码的整体风格倾向与于C++. 主要的时间,花了在对于检测无BOM的部分,顺带重温了各种编码的基础. 建议在看此文之前,先了解下编码.和BOM的概念. 有BOM的编码检测 对于一个文件,或者字节流,就是一堆二进制: 如果传输的

http://czmmiao.iteye.com/blog/1058215 概述 随着硬盘容量.速度的快速发展,硬盘的可靠性问题越来越重要,今天的单块硬盘存储容量可轻松达到1TB,硬盘损坏带来的影响非常巨大. 不同的文件系统(xfs,reiserfs,ext3)都有自己的检测和修复工具.检测之前可以先使用dmesg命令查看有没有硬件I/O故障的日志,如 果有,先用fsck看看是不是文件系统有问题,如果不是则可以使用下面介绍硬盘检测和优化方法来修复它. grep"error"/va/lo

概述  随着硬盘容量.速度的快速发展,硬盘的可靠性问题越来越重要,今天的单块硬盘存储容量可轻松达到1TB,硬盘损坏带来的影响非常巨大.不同的文件系统(xfs,reiserfs,ext3)都有自己的检测和修复工具.检测之前可以先使用dmesg命令查看有没有硬件I/O故障的日志,如果有,先用fsck看看是不是文件系统有问题,如果不是则可以使用下面介绍硬盘检测和优化方法来修复它. grep"error"/va/log/messages*;Linux检测硬盘坏道 使用SMART检测硬盘 SMA

BOM的介绍 在github上写md文件的时候,发现生成自己blog时,报出一个错误是让使用UTF-8编码,然后在Notepad++上把文件转成UTF-8时,发现菜单中有"UTF-8无BOM编码格式". 上网查了一下BOM的定义:byte order mark这个是为UTF-16和UTF-32准备的,用于标记字节序(byte order). 「UTF-8」和「带 BOM 的 UTF-8」的区别就是有没有 BOM.即文件开头有没有 U+FEFF. BOM的爱恨情仇 知乎上有个比较好的文章

摘自:http://www.cnblogs.com/findumars/p/3620078.html   几周前还在为BOM的问题苦恼着...正如@梁海所说,“不含 BOM 的 UTF-8 才是标准形式”,的确是这样,无BOM使用得更多些,所以个人还是推荐一般情况下用无BOM的形式吧,除非有问题的时候,再考虑换有BOM的.Windows系统保存的都是有BOM的,所以你可以看到,用记事本保存一个UTF-8的txt,其实是有BOM的,这一点需要注意.另外不同的文本编辑器对于有无BOM的称呼也略有不同

UTF-8 不需要 BOM,尽管 Unicode 标准允许在 UTF-8 中使用 BOM.所以不含 BOM 的 UTF-8 才是标准形式,在 UTF-8 文件中放置 BOM 主要是微软的习惯(顺便提一下:把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明,这也是微软的习惯).BOM(byte order mark)是为 UTF-16 和 UTF-32 准备的,用于标记字节序(byte order).微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 A

起因是公司iOS端竟然加载除了HTML代码,百思不得其解,查文献,原来如此... UTF-8 不需要 BOM,尽管 Unicode 标准允许在 UTF-8 中使用 BOM.所以不含 BOM 的 UTF-8 才是标准形式,在 UTF-8 文件中放置 BOM 主要是微软的习惯(顺便提一下:把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明,这也是微软的习惯).BOM(byte order mark)是为 UTF-16 和 UTF-32 准备的,用于标记字节序(byte or

这三篇可以看下: http://www.zhihu.com/question/20167122 http://www.cnblogs.com/DDark/archive/2011/11/28/2266085.html https://segmentfault.com/a/1190000004321605 UTF-8 不需要 BOM,尽管 Unicode 标准允许在 UTF-8 中使用 BOM.所以不含 BOM 的 UTF-8 才是标准形式,在 UTF-8 文件中放置 BOM 主要是微软的习惯(顺