HTTPS 是现在网站的标配了，很多服务都是必须使用 https，如果你不使用的话，浏览器可能就不会对你非常友好了。 如果你不想使用商业的 CA 秘钥的话，你可以使用 Let’s Encrypt 来进行加密。 使用 Let’s Encrypt 唯一不好的地方就是每 3 个月要更新一次，当然你也可以使用自动的更新来处理就好了。 我们需要通过安装插件来实现： 获得 SSL 加密需要的 pem 秘钥。 设置 certbot 能自动更新秘钥。 需要前提条件 已经安装好了 Nginx并且配置好了虚拟主机 安装好 python3-certbot-nginx 插件 对 Nginx 虚拟主机的配置方法我们就不详细说了，你可以自己搜索下进行配置。 安装 python3-certbot-nginx 插件 安装的命令非常简单： 执行下面的命令就可以了：sudo dnf install python3-certbot-nginx 需要注意的是，我们这个命令是带有 nginx 插件的。 还有一个官方的是不带有插件的，不建议装那个，因为非常不好配。 获得 pem 秘钥 运行下面的命令 sudo certbot certonly --nginx，需要后面添加 nginx 参数才可以了。 通过下面的寂寞我们可以看到，这个工具将会检测到你的本地服务器上有几个虚拟主机。 然后你需要选择你需要的一个来进行安装。 在安装成功后，会生成我们需要的 pem 秘钥。 配置你的虚拟主机 找打你的虚拟主机文件，然后将生成的秘钥配置上去就可以了。 例如我们的虚拟主机配置：     我们首先在上面配置了 80 端口的重定向，然后将生成的 2 个秘钥文件的指定位置配置上去就行了。 然后重启 Nginx 服务器，然后检查你的网站的 HTTPS 情况。 检查网站 HTTPS 情况 可以使用一些第三方的网站来进行检查，也可以直接使用浏览器来检查。     主要看看网站有没有正常的重定向，和 SSL 证书的过期时间。 上面的证书看起来签发的是泛域名。 https://www.ossez.com/t/nginx-lets-encrypt-https/14034

正如我们在上面文章提到的内容，在英文语境中上面 2 个方法还是有区别的，在中文环境下主要表达就是字符串压缩。   JDK 6 使用的压缩字符串方法，主要原因是我们修改了 String 的存储结构，char[] 在 Java 的很多地都会用到，并且 String 因为这个修改就只能接受使用 char[] 为参数的构造方法了。 在很多算法中，String 的操作又严重依赖 char[] 数组，如果我们进行这样修改的话，很多程序的代码都会需要跟着修改，这个显然是不划算的。 在后面我们使用的缩小字符串的处理方案来说也会有问题的，同样也会增加一些不少的问题，例如会导致一些方法修改为内部方法 intrinsified 同时一些 JIT compiler 编译的代码也需要进行改进。 因为存储方式的改变，也会有一些反人类的情况会出现： LATIN-1 的 indexOf(String) 方法调用的是内部方法，但是 indexOf(char) 不是小的。 在 UTF-16 环境下，这 2 个方法都可以使用相同的内部方法，这个问题只会对 LATIN-1 字符集的 String 字符串有影响，并且也会在后续的版本中修正。 整体来说使用缩小字符串（ Compact String）的效率更高一些。 你可以将 Java 应用程序的 Heap 内存空间 dump 出来后进行分析，针对 String 的改进不会对你应用程序的提高产生非常显著的影响，如果你的程序有很多逻辑上面的问题，修改程序上面的逻辑问题比考虑如何使用 String 要实际得多。 但是对 JVM 来说这种提高还是有必要的。 性能的不同 让我们通过下面的一个简单的测试来看看启用缩小字符串（ Compact String）配置和不启用这个配置对性能产生的异同。 long startTime = System.currentTimeMillis(); List strings = IntStream.rangeClosed(1, 10_000_000) .mapToObj(Integer::toString) .collect(toList()); long totalTime = System.currentTimeMillis() - startTime; System.out.println( "Generated " + strings.size() + " strings in " + totalTime + " ms."); startTime = System.currentTimeMillis(); String appended = (String) strings.stream() .limit(100_000) .reduce("", (l, r) -> l.toString() + r.toString()); totalTime = System.currentTimeMillis() - startTime; System.out.println("Created string of length " + appended.length() + " in " + totalTime + " ms."); 在这里，我们首先使用一个基本的方法来创建 1千万个 String 字符串，然后使用默认开启的配置来看看上面的代码的输出： Generated 10000000 strings in 854 ms. Created string of length 488895 in 5130 ms. 同样的，我们禁用 JVM 的这个参数 -XX:-CompactStrings 参数选项再来看看输出： Generated 10000000 strings in 936 ms. Created string of length 488895 in 9727 ms. 通过上面的代码，我们可以看到上面 2 个参数修改后对比的输出并不是非常的明显，但是也可以看到有明确的性能提升。   https://www.ossez.com/t/java-9-string/14024

从 Java 9 开始，JDK 开始引入了一个叫做 缩小字符串（ Compact String）。 在中文语境下，压缩和缩小都是削减的意思，很多时候是可以通用的，但是实际上还是有区别的。 JDK 9 的处理方式是不改变字符串存储使用的 char[] 数组，而是根据字符集来进行处理。 当 String 在创建的时候，如果我们知道这个字符集使用的 LATIN-1 来表示的话，我们就使用一个字节来存储。 如果是中文，或者我们知道不能用 1 个字节来存储的话，我们还是使用 2 个字节来存储，与原来的存储方式保持一致。 换句话说就是尝试用 1 个字节来存储我们可以存储的自己，而不再浪费存储空间。 现在我们需要知道的问题就是，针对 String 的操作是不是会因为这种存储格式的改变而有影响呢，因为我们在数组中存储了 2 个字符集， LATIN-1 和 UTF-16 字符集之间的混合操作是不是会受到改变？ 本文章的后续部分就对这种情况进行一些说明和演示，来让我们大致了解这个改进对我们的影响。 针对日常使用 Java 的开发人员来说，这个改变是感觉不到的，至于你使用的比较等操作还是会按照正常的处理方式来处理，对你来说这个是透明的。 Java 9 中的字符串实现 直到现在，我们应该非常明确的了解到 Java 中存储 String 是使用 char[] 来处理的，这个是没有改变的。 首先，我们先定义一个 char[] 数组 private final char[] value; 然后我们再定义一个 byte[] 数组： private final byte[] value; 定义一个 coder 变量： private final byte coder; 这个 Code 的变量可以为下面 2 个值： static final byte LATIN1 = 0; static final byte UTF16 = 1; 大部分情况下，Stgring 将会对 Coder 进行判断，然后根据值使用不同的实现： public int indexOf(int ch, int fromIndex) { return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex) : StringUTF16.indexOf(value, ch, fromIndex); } private boolean isLatin1() { return COMPACT_STRINGS && coder == LATIN1; } CompactString 在 JVM 中是默认启用的，如果你不想启用，你可以使用下面的参数告诉 JVM 不使用 String 压缩功能： +XX:-CompactStrings coder 是如何工作的 在 Java 9 的 String 类实现中，有关字符串的长度是下面的方法来进行计算的： public int length() { return value.length >> coder; } 如果 String 只含有 LATIN-1 字符的话， coder 的值为 0，那么获得 String 字符串长度的方法就直接返回字节数组的的长度，因为你这个数组的长度就是一个自己一个元素。 在另外的一种情况，如果 Stirng 使用了 UTF-16 字符集的话，coder 的值为 1 Java 将会使用数组中存储的元素的字节实际长度来返回，这是因为数组中存储的字符可能是 2 字节的。 需要注意的是，这个修改是针对 String 的内部修改，针对绝大部分开发者来说，所有有关 String 的处理方法都是透明的。 如果你想了解更多 String 有关的内部实现，这个是你值得深入的地方。 https://www.ossez.com/t/java-9-string/14024

JDK 考虑开始对字符串进行优化是从 Java 6 开始的。 从 JDK 6 update 21 版本更新开始，我们可以为 JVM 添加下面的参数: -XX:+UseCompressedStrings 上面参数的主要目的就是将 String 存储使用的 char[] 数组修改为 byte[] 数组。 简单来说就是存储粒度更小，能够提供更多的空间利用率。 但是，这个参数在 JDK 7 后被移除了，主要原因可能是因为修改了存储结构导致的一些不可以预料的情况。 https://www.ossez.com/t/java-9-string/14024

见过下面的代码吗？ List strings = IntStream.rangeClosed(1, 10_000_000).mapToObj(Integer::toString).collect(toList()); 在数字中间还带有一个下划线，这是几个意思？ 官方解答 官方的说法来了，在页面： Underscores in Numeric Literals 中进行了说明。 简单来说就是从 Java SE 7 的版本开始，程序中的数字可以使用下划线来进行分割（_）以便于为程序提供更好的可读性。 你可以对一个比较长的数字，使用下划线来进行分隔，以便于你不会数错 0。 我们的理解就是 JDK 在编译的时候，将会对数字中间的下划线进行处理，应该就是简单的替换掉下划线了。 例如我们常用的使用逗号作为千分符，这里直接使用下划线代替就可以了。 在使用的时候也是有一些限制的，不是随便都行的。 使用的限制是： 不能在数字的开头和结尾使用，说人话就是不能以下划线开头和结尾。 不能在小数点的前后使用。 不能在使用 F 和 L 为后缀之前使用。 官方文档中也列出一些常用的用例。     如果你使用 IDE 的话，也不用担心，如果语法是错误的，IDE 会给出提示的。     和上面的图一样，IDE 就直接告诉你这个地方是错误的，按照要求修改下就好了。   https://www.ossez.com/t/java/14032

其实很简单的配置就可以了： server { listen 80; listen [::]:80; return ^ 301 https://$host$request_uri; } 因为 IPv6 的表示方式和 IPv4 不一样，所以你需要新添加一行 listen [::]:80; 就可以了。 然后你在你的 DNS 上配置 IPv6，你的服务器也是可以正常解析地址的。 https://www.ossez.com/t/nginx-ipv4-ipv6/14031

我们都知道 Strings 在 Java 中使用 char[] 数组来实现的。 每一个 char[] 数组中的元素将会使用 2 个字节（byte）的存储空间，这是因为 Java 最初的实现使用 UTF-16 字符集。 如果你不需要存储其他语言，你的语言只有英文，或者 ASCII 码就可以满足的情况下，Java String 使用的 char[] 数组中存储的字符元素还是会使用 UTF-16 字符集，那么就会导致存储一个字符的时候，我们使用了 2 字节，16 位。但是，因为我们又全是因为，那么存储的这个字符的前 8 位全部都会为 0。 因为 ASCII 使用单字节存储，这明显是一个存储空间的浪费。 实际上，很多字符存储都需要使用 2 字节，比如 UTF-8，比如 GBK，但是针对因为和 拉丁文 LATIN-1 使用 1 个字节的存储就够了，很显然这里有一个可以改进的空间。 在 JDK 9 之前，Java 不管什么字符都一股脑的使用 2 字节存储，在 JDK 9 以后，Java 对这里进行了改进。 同时我们知道 Java 是使用 String Pool 来存储的，String Pool 通常使用了 JVM 的 heap 内存空间，Heap 内存空间又是 JVM 垃圾清理程序活动的地方。 在老的设计中，String 占用了 2 个字节，但是很多时候可能用不到，如果我们对这里进行了改进的话，我们也能提高垃圾清理程序的工作量。 显然这个是需要重新考虑的问题。 在本页面中，我们将会讨论在 JDK 6 中使用的 Java String 的压缩选项和在 JDK 9 中使用的新的方法。 这 2 种方法主要目的就是为了降低 String 在 JVM 中内存消耗，提供空间利用率。   https://www.ossez.com/t/java-9-string/14024

当你设置好 Nginx 服务器后，并且你也相信你的虚拟主机都设置好了。 但是你就是老看到一个 403 的错误，这个绝大部分情况是因为 SELinux 造成的。 解决办法 首先运行命令： setenforce 1 然后查看下你的程序能不能通过 URL 正常的访问。 如果能够正常访问的话，这个就铁定是 SELinux 的问题了。 你还可以运行下面的命令，将 http 加入到信任的列表中： semanage permissive -a httpd_t 在完成上面的设置后，可以重启服务器，让你的配置生效。 https://www.ossez.com/t/nginx-403/14029

Semanage是 用于配置SELinux策略某些元素而无需修改或重新编译策略源的工具。 这包括将Linux用户名映射到SELinux 用户身份以及对象（如网络端口，接口和主机）的安全上下文映射。 Semanage是 用于配置SELinux 策略某些元素而无需修改或重新编译策略源的工具。 如果没有 Semanage，你要对 SELinux 配置的话就比较麻烦，但是 SELinux 又是现在 Linux 的标配了，所以这个包也就变得很重要了。 检查要安装的包 有时候，你可能不知道要安装的包是什么。 运行下面的命令： dnf provides semanage 然后你可以看到下面的输出，在下面的输出中，你会看到一个名为： policycoreutils-python-utils-3.2-1.fc34.noarch 的包名称以及版本号。 在安装的时候是不需要提供版本号的。     安装 当你找到包的名称后，运行命令： sudo dnf install policycoreutils-python-utils 就可以了，在这里你不需要提供版本号。 dnf 会自动帮你安装最新的包。 校验安装 输入命令 semanage -h 如果你能够看到下面的输出的话，就说明你的安装已经成功了。 [fedora@src conf.d]$ semanage -h usage: semanage [-h] {import,export,login,user,port,ibpkey,ibendport,interface,module,node,fcontext,boolean,permissive,dontaudit} ... semanage is used to configure certain elements of SELinux policy with-out requiring modification to or recompilation from policy source. positional arguments: {import,export,login,user,port,ibpkey,ibendport,interface,module,node,fcontext,boolean,permissive,dontaudit} import Import local customizations export Output local customizations login Manage login mappings between linux users and SELinux confined users user Manage SELinux confined users (Roles and levels for an SELinux user) port Manage network port type definitions ibpkey Manage infiniband ibpkey type definitions ibendport Manage infiniband end port type definitions interface Manage network interface type definitions module Manage SELinux policy modules node Manage network node type definitions fcontext Manage file context mapping definitions boolean Manage booleans to selectively enable functionality permissive Manage process type enforcement mode dontaudit Disable/Enable dontaudit rules in policy options: -h, --help show this help message and exit 上面提供了这个命令可以使用的帮助。     至此，配置已经完成了。   https://www.ossez.com/t/fedora-semanage/14028

乱码是所有程序员都经历过的噩梦。 拯救你生命的只有 UTF-8。 如果你不知道用什么字符集，用 UTF-8，如果没有强制要求，也用 UTF-8，相信我，没错的。 从上面的网页使用的编码就知道为什么了。如果你的公司还在使用 ISO-8895-1 的话，你可以好好鄙视下，说明这公司负责技术的不行嘛。     如果你公司是中文公司，被强制使用 GBK 或者 GB18030，你就不要鄙视了，因为使用 GB 字符集是在中国大陆销售的软件的强制标准，但是还使用 GB 2312 的话，你也可以鄙视下了。 欧美的编码 欧美常常使用的编码是不适合中文使用的，换句话说就是你写的代码没有办法接受中文的输入也没有办法存储中文，当然也没有办法存储日韩文字了。 ASCII 编码 (American Standand Code for InformationInterchange) 的缩写 ASCII 码是计算机最开始支持的基于拉丁字母的编码，一个字符用一个字节表示，只用了低 7 位，最高位为 0，因此总共有 128 个ASCII码，范围为 0~127。 这个编码应该是大学计算机课程的第一节课，就是要学习 ASCII 编码。     这个字符集简单来说就是只能用于英文，字符集太小，啥都存不下。 ISO-8859-1 编码 ISO -8859-1编码 是单字节编码 ，向下兼容ASCII，其编码*范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。 因为 ASCII 字符集实在太小了，现在就有了 ISO-8859-1。 对我们来说这个字符集的最大问题就是不能支持中文，韩语，日文，在欧美国家用用还行。 但是很多软件默认都使用 ISO-8859-1，欧美国家的程序员又没有太多字符集的需求，因此很有可能会默认就使用这个字符集，所以你也可以吐槽下。 中文字符集 中文字符集就是我们常用的 GB 字符集了。 GB是 国标 两字的拼音首字，2312 是标准序号。GB 有 3 个版本，按照字符集的大小排序，其实也是按照发布时间排序。 GB2312 最早的中文字符集，和 ASCII 字符集一样，字符集太小，很多汉字打不出来，异体字也打不出来。 GB2312 规定对收录的每个字符采用两个字节表示。 GBK 即汉字国标扩展码。 GBK编码，是对GB2312编码的扩展，因此完全兼容GB2312-80标准。GBK编码依然采用双字节编码方案，其编码范围：8140－FEFE，剔除xx7F码位，共23940个码位。共收录汉字和图形符号21886个，其中汉字（包括部首和构件）21003个，图形符号883个。GBK编码支持国际标准ISO/IEC10646-1和国家标准GB13000-1中的全部中日韩汉字，并包含了BIG5编码中的所有汉字。GBK编码方案于1995年12月15日正式发布，这一版的GBK规范为1.0版。 Windows 95 系统就是以GBK为内码，又由于GBK同时也涵盖了Unicode 所有CJK汉字，所以也可以和Unicode 做一一对应。 从 2000 年以后的程序设计相关，如果是中文的话，基本上都会使用 GBK 字符集了，已经不怎么使用 GB2312 字符集了。 因为 GBK 的字符存储得更多，生僻字也可以显示了。 GB18030 2000年3月17日发布的汉字编码国家标准GB18030编码，是对GBK编码的扩充，覆盖中文、日文、朝鲜语和中国少数民族文字，其中收录27484个汉字。 GB18030字符集采用单字节、双字节和四字节三种方式对字符编码。兼容GBK和GB2312字符集。 它完全兼容ASCII码与GBK码。 GB18030 是对 GBK 编码的进一步扩充，字符集更大，可以存储的汉字更多。 但是针对 Web 开发来说，其实我们也用不到那么多汉字，所以现在很多网站还是在使用 GBK 的编码。 BIG5 这个简称就是繁体中文使用的，主要在台湾，香港地区使用。 BIG5编码又称大五码，是繁体中文字符集编码标准，共收录13060个中文字，其中有二字为重复编码。 BIG5重复地收录了两个相同的字：“兀、兀”（A461及C94A)、“嗀、嗀”(DCD1及DDFC)。 适用于台湾和香港地区的繁体中文系统软件等。不过由于编码本身存在的问题，已经基本改用 Unicode 编码了。 BIG5 目前已经不怎么使用了，我们在这里列出来就是想说明下曾经还有一个这样的编码而已。 Unicode 你的救星来了。 Unicode(统一码、万国码、单一码、标准万国码)编码就是为了表达任意语言的任意字符而设计的。 目前的情况是大部分程序，数据库，通讯协议都会使用 UTF-8 编码。 使用 UTF-8 编码能够适配所有的字符集并且不容易出现乱码问题。 如果你不知道你要什么编码，用 UTF-8 编码就没错的了。 Java 中 String 字符串的存储是使用 UTF-16 编码存储的，在 JDK 9+ 以后的版本，Java 对 String 的存储进行了压缩以增加空间使用率。 如果你是早期的程序员，你一定经历过转码的痛苦，不要想太多，UTF-8 才是你的真爱。   https://www.ossez.com/t/topic/14022