@msg7086 了解关键了，结合 @ipwx 对 utf-8 的强调，可以这么理解吧？可无限扩展的 Unicode+8 位为基本单元的可变长度的 utf-8，足以适应未来可预见的扩展需求，并保证存储效率和后向兼容性。

在手动运行备份任务十几分钟后，收到无法连接的监控邮件了，不清楚为什么有这么长时间的延迟，服务器端备份进程还在继续，本地监控的下载速度一直稳定在 120-160k 之间，可能是锁表什么的吧。无论如何问题明确了，hoory ！感谢提供排查思路。
@nowheretoseek @redford42 @hefish @ysc3839

刚才大致明白怎么回事了，明天中午验证下。
我本地有个定时任务，每天中午用 ssh+mysqldump 备份服务器上的数据库，这个站未压缩的数据库有 170M+，而这台服务器带宽很小，所以很可能是我备份数据库时占满了带宽，导致新连接不能被接受；考虑到连接静态站时没问题，也可能时备份数据表时锁表什么的导致数据库不响应，总之很大可能是这个定时任务导致的。刚才手动运行备份任务验证下没有重现，明天中午再验证吧。
@redford42 @hefish @ysc3839

@ipwx 只是设问，我也知道涉及的概念在不同层面上，而我很可能混用了他们。的确基本只是在字符串的角度考虑问题，不大能从 int 、byte 、char 、char[]的角度理解，这是个硬伤。

@halfdb 是这么个意思，表达很清楚。

@wdssmq 二进制因为包含一些 ASCII 范围内的控制字符或不可见字符，不便显示，也会在复制过程中损坏，并且某些传输协议对二进制不够友好（协议内使用了某些字符的组合作为控制字符使用等等）。base64 现在的主要作用是避免了这些问题，代价是增加了 1/3 的体积。这样理解对吧？

谢谢各位，你们说的知识点和思路我大致都了解些，我想问的其实是目前操作系统的设计中 Unicode 的耦合度，是完全可插拔的，还是说底层上有相当程度的耦合。之所以假设外星文明语言，如前说为了符合字符量很大（超过 CJK 总量）这样一个假设，使其无法放到现在的 Unicode 集合中，只能搞一个 New Unicode 。（这跟将一个少数民族的文字放入当前的 Unicode 体系中有些区别）
所以，再次这么表述下问题：如果有上述需求，是不是做些体力活设计出这个 New Unicode 以及相应的字体，就可以几乎无成本的显示、处理这些新的语言文字了？（几乎无成本是说做些配置或修改少数一点代码什么的）@ipwx 提到的有些文件系统会考虑编码是我想知道而之前不知道的情形之一。
@ipwx @msg7086 @binux @cmdOptionKana

谢谢，理解认同大家的意思，因为知识有限，我对一些概念的理解和表述可能存在层次混乱什么的，重新提一下问题：
我的主要想法是计算机世界的现状是 Unicode 有巨大影响力，一些编程语言有底层的 Unicode 支持，操作系统层面会不会也有为了适应它而做的耦合？毕竟好像暂时不用考虑新的类似 Unicode 的编码方案。当然如果出现了新的语言，而 Unicode 可以轻松将其纳入自己的编码体系中，就不是这个层面的问题。
一些轻量的 Linux 环境，默认只有 en 语言支持，要显示、接受输入其它语言，就用 locale-gen 添加，这些支持当然也是通过特定库、模块实现的。而似乎无法想象没有 en （ ASCII ）支持的操作系统。
那么如果现在有这么个需求，要用计算机处理一个字符量很大的新文明语言，比如字符量是 CJK 的总和还多些，那么是否可以比较容易、低成本的实现一个新的 Unicode2，并将其在 windows 、linux 等操作系统上跑起来？
@nowheretoseek @iotwd @ayase252 @bitdepth @cmdOptionKana @wanguorui123 @ipwx

管理员大大，求删 12 楼或仅保留第一行，谢谢！
@Livid @Kai @Olivia @GordianZ @sparanoid @Girlphobia

@Rever1e 搞错了，12 楼的不是 custom table 的，没必要尝试了，代码写太久了给自己看糊涂了……

@ysc3839 就是在运行站点的服务器测试的，明天中午加-vv 试试。

@nowheretoseek @AoEiuV020 @lakehylia @Rever1e @blackshow @noe132 @polaa @sujin190 @ipwx 谢谢各位，学习了，之前对替换是密码和从字频入手破解有些了解，也了解了 base64 大致原理，但还是感觉破解起来有点难度，所以小范围用过，没想到竟这么脆弱，并且有现成工具。

@nowheretoseek @redford42 @hefish @ysc3839 补充个信息，就是中午问题重现时，测试发现重启后问题消失，所以应该不是腾讯云服务器网络方面的问题。

行首的空格没了，pastebin 发了一下： https://pastebin.com/Mr94f31q

@hefish 分了两部分，80 端口和 443 端口的，80 的自动跳到 443，并且 www 的自动跳到主域名；再就是为了减少恶意爬虫骚扰，用了个 https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker，以下是完整配置，去除了注释：
```
# xxx.conf
<VirtualHost *:80>
Protocols h2 h2c http/1.1
ServerName xxx.com
ServerAlias www.xxx.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/xxx/public

<Directory /var/www/html/xxx/public>
Header set Access-Control-Allow-Origin *
Options -Indexes +FollowSymLinks
Include /etc/apache2/custom.d/globalblacklist.conf
DirectoryIndex index.php
AllowOverride All
Require all denied
</Directory>


ErrorLog ${APACHE_LOG_DIR}/xxx_error.log
CustomLog ${APACHE_LOG_DIR}/xxx_access.log combined

RewriteEngine on
RewriteCond %{SERVER_NAME} =xxx.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
RewriteCond %{SERVER_NAME} =www.xxx.com
RewriteRule ^ https://xxx.com%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

# xxx-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName www.xxx.com
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.xxx.com
RewriteRule ^ https://xxx.com%{REQUEST_URI} [END,NE,R=permanent]
SSLCertificateFile /etc/letsencrypt/live/xxx.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxx.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

<VirtualHost *:443>
Protocols h2 h2c http/1.1
ServerName xxx.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/xxx/public

<Directory /var/www/html/xxx/public>
Header set Access-Control-Allow-Origin *
Options -Indexes +FollowSymLinks
Include /etc/apache2/custom.d/globalblacklist.conf
DirectoryIndex index.php
AllowOverride All
Require all denied
</Directory>

RewriteEngine on
RewriteRule .* - [E=REQ:%{THE_REQUEST}]

ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client %a] %M% ~ Referer: %-{Referer}i ~ Request: %{REQ}e ~ UserAgent: %{User-Agent}i"
ErrorLog ${APACHE_LOG_DIR}/xxx_error.log
CustomLog ${APACHE_LOG_DIR}/xxx_access.log combined

SSLCertificateFile /etc/letsencrypt/live/xxx.com-0001/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxx.com-0001/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

```

@ysc3839 中午问题重现时 curl 连接了以下，等了很久报错：`curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to xxx.com:443`

@hefish 谷歌过，没找到类似描述的问题，用 2.4 很久了，配置模板也一直用，用了好几个地方，就这个出问题。

@ysc3839 是同 80 端口，apache 下不同的 virtual host 。监控邮件显示”The monitor is currently DOWN (Connection Timeout)“

@hefish 一直没来得及学会 nginx 的配置，apache 学的早比较习惯了，希望先解决这个问题。