刚刚用host模式启动试了，并不是这个原因，这是一个bug而已
那可能是docker的问题 看看能不能找个原生Linux测试一下 WSL也行
刚刚官方测试了，WSL上正常的，只有docker里面会发生问题，目前不知道是否两个docker版本都有问题
docker镜像底层换成centos试试？现在docker镜像底层系统是ubuntu 20.04.6 LTS，感觉这个系统太垃圾所以导致出来的docker有问题
或者这个docker镜像包是怎么做的，我做一个试试
可以换个基底试试
但我觉得可能是docker的问题的可能性比较大
已确认是docker镜像底层系统ubuntu 20.04字符编码转换的问题，boost::filesystem::path::codecvt()会失败，有中文文件名的种子应该都会出错。还没研究出怎么解决，估计是少了什么库
看来我没猜错，符号的问题，这么说来vnc版本和webgui两个版本都会出问题，，，之前居然没人测试出来反馈（或者其它用户不太懂，以为是死种）
把镜像底层系统改成centos7或者centos9、centos10吧，别用ubuntu了
直接问ai说是少了个locales运行库
如果在 Docker 容器中处理带有中文字符的文件名遇到问题，以下是一些建议来确保正确处理中文字符：
-
设置 Locale 为 UTF-8：
确保容器内的环境已设置为支持 UTF-8。你可以按照以下步骤设置：
RUN apt-get update && \ apt-get install -y locales && \ locale-gen zh_CN.UTF-8 && \ update-locale LANG=zh_CN.UTF-8 ENV LANG zh_CN.UTF-8 ENV LANGUAGE zh_CN:zh ENV LC_ALL zh_CN.UTF-8 -
运行时设置 Locale：
如果不能在 Dockerfile 中设置，可以在命令行运行容器时指定：
docker run -e LANG=zh_CN.UTF-8 -e LANGUAGE=zh_CN:zh -e LC_ALL=zh_CN.UTF-8 <your_image> -
验证文件存取：
确保在代码中使用
std::wstring或其他 Unicode 支持的字符串类型，以正确处理文件路径和名称。 -
Boost 版本更新：
更新到最新的 Boost 版本可能会提供更好的 Unicode 支持。
-
确保源代码支持 Unicode：
检查源代码确保处理 Unicode 字符，尤其是在读取文件名或路径时。
如果按照这些步骤设置后问题仍然存在，请检查可能的日志或错误信息，以获得更多的调试线索。
docker镜像可以把同时把内核打包进去，不要用宿主机的共享内核
就像这样，每个docker镜像都有自己的独立内核，比如说6.1内核支持iouring模型，网络性能会比epoll更高一些
不知道独享内核要不要调用虚拟化，，如果要的话那还是共享内核吧，因为vps服务器是没办法二次虚拟化
VNC版docker下载没问题，测试过了。应该是两个docker版本底层镜像有差别造成的，毕竟一个有图形界面库，对多语言支持比较完善，一个没有图形界面，默认只支持英文
现在vnc和webui两个版本的Dockfile都是FROM ubuntu:20.04
共享内核的方式我还没看过怎么弄
看来确实是基底的问题 可能是缺少某些依赖
可能其他非拉丁字母语言也会出现问题
话说win下对特殊字符的转译其实也有点问题 虽然不常见
但是有条件的话还是修一下比较好
其实最简单的方法就是写入文件的时候也将特殊字符使用下划线替代
现阶段 界面内显示 和配置文件中记录的都是转换后的文件名
但是创建的文件 依然使用原始名称 导致出现找不到文件的问题
centos已经停止维护了 也许我们应该考虑一下其他的发行版本
我觉得用Debian更好。关于多语言环境，应该要安装 locales和locales-all。
详细看这里：
https://www.debian.org/doc/manuals/debian-reference/ch08.zh-cn.html
还有为了正确显示亚洲文字应该安装字体，我用fonts-noto-cjk 和fonts-noto-cjk-extra
centos 6 7 8停止维护不代表9 10也停了
使用6 7的旧版系统最重要的是能够安装使用tcp加速
等官方看怎么弄了，大便系统确实比ubuntu好，但是大便系统也全方面不如centos
bitcomet-webui docker版 v2.12.2 已发布，修复了无法下载包含非英文字符文件名的种子文件的问题。
最后发现其实很简单，只需要dockfile里增加一行环境变量
ENV LANG=C.UTF-8
可以了，就是这个webgui要优化下，不然添加磁力每次都要下拉一下滚动条才能显示下载按钮
我是指这个按钮被挤下去了
在修一下那个磁盘写入缓存释放后，进程内存不释放的问题，在调度sendfile函数Linux下就完美了
或者有了sendfile后，直接把写缓存改成64M就可以避免内存占用过大无法释放了（但是过小写缓存影响下载性能，还是看看怎么释放进程内存比较好）
总算能用了，距离完美还差一点
把Windows窗口上的所有设置搬运到网页上是个大工程
可以直接配置文件形式先实现
/opt/1panel/docker/compose/bitcomet-webui/BitComet
完整的docker版本搭建教程
Linux centos 7安装1panel面板搭建容器docker用法，在vps服务器中使用编排功能搭建比特彗星bitcomet-webui版本
仓库
https://hub.docker.com/r/wxhere/bitcomet-webui
services:
sandbox:
container_name: bitcomet-webui
image: wxhere/bitcomet-webui:latest
volumes:
# mounts the host directory into the container to store config files
- ./BitComet:/root/.config/BitComet:rw
# mounts a host directory into the container to store downloaded files
- ./Downloads:/root/Downloads:rw
ports:
# BitComet WebUI port
- 6080:6080
# BitTorrent ports
- 6082:6082
- 6082:6082/udp
environment:
- BITCOMET_WEBUI_PORT=6080
- BITCOMET_BT_PORT=6082
- WEBUI_USERNAME=admin
- WEBUI_PASSWORD=itzmx.com
访问服务器 ip:6080 登录比特彗星
配置文件和下载的文件存储在路径
/opt/1panel/docker/compose/bitcomet-webui/BitComet
/opt/1panel/docker/compose/bitcomet-webui/Downloads
注：如果要修改配置文件请先停止容器，修改完成后在启动，这样才能修改成功
linux 调用的可用内存有错误，会导致判断这个异常，取的是free，正确要取MemAvailable
<MinFreePhysMemMB>1024</MinFreePhysMemMB>
真实内存使用量应该可以通过算法得出
used = total - free - buff/cache
centos6里真实内存空闲剩余量直接看
-/+ buffers/cache
或者这个公式
真实剩余内存 = free + buff + cache
新系统centos7的话有个专门的指标为available，显示当前剩余真实内存
cat /proc/meminfo | grep MemAvailable | awk '{print $2}'
全系统通用获取真实剩余内存
awk '/MemFree/ {free=$2} /Buffers/ {buffers=$2} /^Cached/ {cached=$2} END {print free + buffers + cached}' /proc/meminfo
现在比特彗星Linux版本调用的是这个free，是错误的
还有就是申请过的写入磁盘缓存，进程无法回收的问题，会一直占用在进程上（有可能是TCP发起建立产生的内存，C语言通病）
配置文件也应该默认开启这个，不然重启下容器就全都变成停止运行了
甚至可以把所有的配置文件参数都做成docker环境变量给写进去
还有由于没有界面，有什么办法添加到手机版？手机版浏览器打开也没办法呼出右键选择，安卓那个贴反馈过
极空间用户
基本纯小白
安装后 端口访问不了 完全不知道问题出在了哪里
部署了 bitcomet-webui ，路由器做了端口转发，还是一直端口阻塞，要怎么排查？
你好，请问webui模式可以常驻运行吗？没有像别的软件那样弹出新的root@xxx…#，
你好，请问webui模式可以常驻运行吗？没有像别的软件那样弹出新的root@xxx…#
./bitcometd &