DEV Community: YuDi

哎，写一篇人生感慨

YuDi — Fri, 08 Aug 2025 00:07:17 +0000

最近看到了一篇文章。说如果让一个民族失去战斗力，那么只需要做到下面这句话。那就是：“只需要抽掉男人脊梁，拿掉女人羞耻。”就可以摧毁整个民族。
所以，”去雄计划“就是这样的。去雄计划会让男人变的娘气十足，可以让女人走向风俗产业。是一个真正的可以摧毁一个民族至今为止最完美的计划。
可以说，我本人就是这个计划中最真实的中招人。我这一生就会觉得那些脸蛋水润光滑的，头发长长的理成中分吹的膨松的，身材瘦瘦的笔直的，穿着西装革履的男人就是喜欢。看着那些穿着黑丝吊带袜的女人，紧身短衣的，身材纤瘦的女人就是喜欢。所以，我个人觉得我是真的中了”去雄计划“的招儿了。但自己已经是一个40多岁近50岁的70后的人了。世界观、人生观、价值观早就定形了。不可能再改变了。所以，今生一定是被”去雄计划“腐蚀了，没办法了也改变不了了。就只能是这样的渡过自己的这一生了。

VC写Windows服务程序

YuDi — Thu, 08 May 2025 03:10:00 +0000

之前写的后台的控制程序，我采用的都是用VC或者是C#写完之后然后采用AlwaysUp或者是nssm把自己写的后台程序再给做成一个Windows的服务程序。但后来想了想为什么不自己直接写一个Windows的服务程序呢。所以就开始了写服务程序的历程。
首先大致的说一下C#语言写一个Windwos服务程序的方法。说实话C#想写一个Windows服务程序相对的要简单的多。因为C#已经都给准备好了。就在创建项目的选择Windows服务项目就可以了。然后再添加一个服务安装的组件，改一下相关的配置，如：服务名、启动类型、启动权限或者叫启动时的用户。这些信息就可以了。在写代码的时候只要在开始的里面写上服务启动时需要做的工作，在结束里面写上服务停止时需要收尾的工作就大功告成了。
下面主要是说一下采用VC写Windows服务程序。这个我个人觉得相对来说有几个坑需要避。
第一个坑就是如果你从网上查的话都会说用VC写Windows服务程序的入口主函数是ServiceMain()这个函数。而实际并不是，实际上的程序入口还是从main()这个函数开始的。只不过在这个函数中我们不能做太多的事情，必须要尽快的调用StartServiceCtrlDispatcher()这函数来启动ServiceMain()函数。而且ServiceMain()这个函数的名字也并不一定就是这个，可以自定义。只不过你在网上查的人都会采用这个函数名而已。并非VC语言的规定或者约束。这个函数也只不过是在调用StartServiceCtrlDispatcher()函数的时候的一个参数而已叫什么名字并不重要。
第二坑就是服务状态的变换问题，只有你有ServiceMain()函数中调用了SetServiceStatus()函数来告诉Windows操作系统你的服务程序是开始启动了还时正在运行之中还是正在停止之中才可以。在这方面我从网上查了好长时间没有一个写的清楚的。我开始的时候以为这个函数没什么大用于是把相关的代码给删掉了，结果就会发生服务程序的状态无法改变。比如你在启动服务的时候没有及时的状态改成正在运行的话那么Windows的服务控制台就会一直启动这个服务直到启动超时而报错最后服务的状态就会卡在启动状态无法将服务停止或者删除。如果你能将服务状态进入到正在运行状态，但在发出停止服务的时候如果不能将服务的状修改成停止的话那么Windows也会一直停止这个服务直到停止超时而报错。而且这个服务的状态也会卡在停止的状态无法改变。
第三个坑就是在ServiceMain()函数中在用SetServiceStatus()函数把服务的状态修改成“正在运行”的状态之后必须要调用WaitForSingleObject()函数把这个服务的主线程给卡住然就是是一直等待发出服务停止的信号。所以在真正的主线程中你是无法再做其它的任何的工作的。故如果要想写好一个完整的Windwos服务程序就必须在ServiceMain()函数调用WaitForSingleObject()函数之前将你想做的事情都给加载完毕之后再调用WaitForSingleObject()函数将主线程卡住一直等待停止服务的指令。当停止服务的指令来临的时候再调用SetServiceStatus()函数把服务的状态修改成已经停止。
第四个这个不算是坑了这个算是一个常识。就是服务程序的调试问题。如果想调试Windows服务程序那么就只能采用“附加到进程”的方式。即先从Windows的服务管理器中启动服务，然后从Visual Studio的“调试”菜单中选择“附加到进程”的选项然后再选择自己程序的那个进程就可以了。
总结一下，那就是不论是VC写Windows服务程序还是C#写Windwos服务程序，都会有一个开始服务的初始化函数。而初始化函数中不能有死循环，但一般的服务程序又必须要用死循环，所以一个完整的Windwos服务程序一定是一个多线程的，在初始化的时候就启动其它的想要加载的死循环的线程。还会有一个程序的销毁函数，同样在销毁函数中也不能有无法完成的循环。最后就是Windwos服务程序的调试必须采用附加到进程的方式来进行。

了解一下字符的编码和集合

YuDi — Tue, 03 Dec 2024 07:32:28 +0000

今天我们来了解一下字符的编码与集合。我们在日常的电脑或是手机使用过程中会遇到“乱码”的问题。比如你用电脑写了一往篇文章，但用手机看的时候就看不懂了。成为了“乱码”。而实际上并不是你写的文章成为了乱码。而是你写的文章在保存的时候用的编码与你显示的时候用的设备的编码不一致。这样就会出现了显示成“乱码”的情况。
而我今天要说的就是这个问题。首先说一下题目的意思。在现在用的电子设备中，显示的都是这种可见的字符。所有的电子产品都一样无一例外。而显示的这种字符在电子设备中都要以二进制的形式来进行。因为我们众所周知的电子产品只认识一种东西都就是二进制。那么我们就需要用一种方法把这种字符用二进制给表示出来，然后用二进制给保存起来。当我们想要用它的时候再从保存的地方给取出来，当然这个时候取出来的也是二进制，再把这些二进制数据按照保存时的字符的编码给翻译成需要显示的字符然后再显示出来。在这个过程中，我刚才提到了字符的编码。还有一个就是字符的集合简称字符集。
本人所知道的最古老的字符集就是ASCII字符集。一共有127个字符。当然其中既有可见字符也有一些是不可见字符。其中就包括0-9的数字，A-Z的大写和小写字母。当然也有一些西文符号。实际上我们现在用的电脑键盘就是一个ASCII字符集的最好表现。
上面啰里啰唆的写了那么多，连最基本的概念都没写清楚。那就是对于字符来说，有字符集和字符编码的两个概念。对于最早的时候是没有这种区分的。比如在上世纪的时候几乎是没有分别的，主要也就是几个因素决定的，其中最主要的原因就是最早的存储器价格太过于昂贵本人最早在上世经90年代的时候接触的电脑内存只有1M就算是硬盘也不过40M的电脑，采用的DOS操作系统。在这种级别的机器上不可能用于保存一个字符就采用4个字节。那个时候就只有ASCII这种字符编码。写到这里又要多说一句本人对ASCII有非常敬佩之情，虽然本人的英文水平非常的低。说实话在这个网站写文章本来应该是用英文的，但本人的英文真的是不行。用英文根本写不出一个像样的文章。也表达不出来我本人的情感于是最后还是决定我的文章都用中文来书写。
在本人的认知范围内只有ASCII既是字符集又是字符编码。虽然说既是字符集又是编码的还有GBK、GB2312、Big5等。但其它的真的是不值一提，本人觉得都只是过渡的东西。根本就算不上一个成熟的字符集或是编码。
自从电子产品的字符集开始国际化的时候字符集和编码也就开始出现了不一致的问题。开始的时候就是ASCII既是字符集又是编码。后来随着电子产品在世界的流行，就出现了非英文的国家也要使用电子产品。然而这个时候的电子产品仅支持英文，所以非英文国家就想办法对电子产品开始了本国化的改造。就拿中国大陆来说，就是对电子产品的简体中文化，所以就出台了最开始的一级字库和二级字库我本人的记忆中一级字库是3千多个汉字，二级字库也是3千多个汉字加在一起就是6千多个汉字。这时的电子产品最小的还是桌面化的电脑而当时要解决的也就是几个问题。第一个就是汉字的编码问题，也就是字符集的存储。这时就把这6千多个汉字用了两个字节给存储起来。这个就是GB2312简体中文字库了，一共6千多个汉字。后来又觉得6千多个汉字还是有些少了于是就又加了一部分就是后来的GBK简体中文字库。也是采用了两个字节来存储。用两个字节存储的意思就是采用两个字节将GB2312或是GBK字符集的汉字所在的位置给存储起来。然后就是要解决第二个问题，那就是汉字的显示问题。因为就算是你把汉字给存储起来了但显示的时候只能显示英文那么看到的还只能是“乱码”根本不知道存储前到底写的文本是什么。所以就要解决汉字的显示问题。当然最后还有一个就是汉字的输入问题。也就是现在用的“输入法”。在解决了这三个问题之后当时的电子产品就可以用GB2312或者是GBK字符集了。到现在ASNI采用的也是这种，也就是到现在为止的Windows采用的默认字符集。至于ASNI我们稍候会详细的讨论。
下面我说一下字符集（英文：Character Set）与字符编码（Character Encoding）的区别。实际上上面说了半天早就应该说这个问题了。或许这个问题应该放在最前面写的。在早期的时候，比如我上面写的DOS时代是没有这么详细的差别的。只是后来电子产品的国际化才出现了这两个概念的不同。字符集是纯纯的一种字符的集合。在字符集里面只是规定了有多少个字符，每一个字符对应的位置而已。而字符的编码才是在电子产品中真正起到作用的东西。只不过这两个概念有好多交叉的地方，而且这两个概念也很相近，甚至有很多都搞计算机编程多年的人都搞不清楚这两个概念的差别。
常用的字符集和字符编码：
一、常见的字符集：
ASCII：个人认为是最常见的最经典的字符集，同时也是编码。可以说是唯一个既是字符集又是字符编码的经典也是其它字符集和字符编码的基础。
GB2312：是比较早期的简体中文字符集。这种字符集后来采用的是两个字节的编码来存储。
GBK：是一个比较经典的简体中文的字符集。这种字符集是GB2312的一个扩展，完全包括GB2312，也是采用了两个字节的编码来存储。也是至今为止Windows操作系统用于保存简体中文的默认字符集。
Big5：这个字符集是繁体中文的字符集，也是采用了两个字节来存储。由于本人只懂中文所以只能写出来中文的各种字符集或是编码。其它文字的本人也不了解。
ASNI：这个字符集是一种变化的字符集，在存储英文的时候会采用ASCII；在存储简体中文的时候会采用GBK；在存储繁体中文的时候会采用Big5；在存储日文的时候会采用另一个字符储，在存储韩文的时候还会用一种韩文的编码。一般来说都是采用两个字节来存储除英文以外文字。也就是说如果采用这个字符集的话那么在不同文字的电子设备上面会显示出不同的文字。为文字的显示或是相互之间的翻译带来了诸多的不便。上面写到Windows简体中文默认的是采用GBK字符集，而实际上Windows采用的就是这种字符集。也就是说如果你在Windows操作系统中用记事本写了一段话，如果你是在简体中文版里面写的。那保存之后你到了日文版中，那么你看到的很有可能并不是“乱码”而是另一段驴唇不对马嘴的话。这个就是这种字符集让人无语之处。
USC-2：这个是一个早期的国际化的字符集。一共有65536个符号正好是两个字节可以存储的下来。开始的时候就是打算采用这种字符集就做为国际化的最终字符集，但这个国际化不可能只满足这么几个符号。所以，这种字符集出现的时间不长就被USC-4给取代了所以采用固定两个字节长度的编码方式也就很少有人在用了。但对这个字符集进行了支持的也就只有Windows操作系统和微软公司生产的部分软件，如SQLServer数据库。
USC-4：这个字符集应该是现在世界上采用最多的字符集。到目前为止也是一直在扩展。也正是这个字符集的出现才真正的区分了字符集和字符编码的问题。这个字符集几乎包括了世界上所有文字符号。其信息量也是非常的大。
二、常见的字符编码：
ASCII：无论是字符集还是字符编码第一个要说的都是这个ASCII。绝对到目前为止最为经典的字符编码。就是由于其之前使用的量太大导制后面的编码都必需要考虑跟这个编码的兼容性问题。如果与这个编码的兼容性不好的话可能就要面临被淘汰。
UTF-16：这种编码方式主要是用来存储USC-2字符集的，所以开始的时候这种编码就是采用的固定两个字节的长度进行字符的存储。可是后来USC-4出现之后这种编码又提出了如果超USC-2的符号就自动采用四个字节来存储。所以，这个就是一个“鸡肋”形的编码方式了。一般来说已经很少采用了，不过到现在Windows中的C#程序和SQLSERVER数据库的默认字符串的编码还都是采用了这种编码方式。如果想用其它的编码字符串就要显式的在程序中进行修改。而这种编码方式对ASCII编码的兼容方式就是前127个字符就是ASCII编码而前面的那个字节就全为零。
UTF-32：这种编码方式是一种用来存储USC-4字符集的编码方式。采用固定的四字节存储方式。这种编码总的来说如果保存的东西主要是英文即ASCII编码中的字符的话那么就会浪费非常的大，就是存储一个明明只用一个字节就可以的东西就需要四个字节。这样存储空间会有很大的浪费。比如在写HTML的程序的时候那些HTML的标签。全部都会是ASCII中的字符如果采用UTF-32来存储的话那就会膨胀四倍。所以，这种编码方式普遍也是不受欢迎。
UTF-8：这种编码方式是目前采用的比较多的编码方式。采用了变长存储采用一个字节至六个字节的存储方式，可以用来存储USC-4字符集中的所有字符。采用这种字符编码后所存储的内容不论在哪里都会是同一个字符。这种字符的编码方式也把各种语言之间的翻译有了比较简单的方式。也是目前的Unix系列的操作系统采用的国际化的字符编码方式。之前看到过一个文章写的就是在网页上面列出来的文件列表，但点击下载后就说找不到这个文件。其原因就是现在的网页上显示用的一般都是UTF-8编码。而Windows操作系统中保存文件如果是除英文以外的文件名称的话，就会用了不同的编码，所以在查找文件的时候就无法找到。这个时候就要把文件名给转换一个字符编码。转换的时候还要看保存这个文件的操作系统是什么。如果是Windows系列的那就要用ASNI，如果是Uni系列的操作系统的话就可以直接用网页传过来的名字去访问文件了。现在的市面上的主要数据库大多数也都是采用UTF-8来存储国际化的文字符号。

在大陆下载huggingface模型

YuDi — Mon, 18 Nov 2024 05:03:28 +0000

这两天想自己部署一个stable diffusion玩玩。还好自己现在的电脑是领导在这半年内给配的，查了一个笔记本的显卡配置是一个4050的显卡。自己想了想如果是自己用的话应该是够用了。所以就从网上查了一下如何部署。首先是到stable diffusion的官网上下载了一个stable diffusion 3.5。然后就是下载Python。由于之前安装的Python是3.13版本的。这次一用还不行。于是从网上查了一下，说是版本太高，在下载各种依赖的时候需要下载Pytorch，而Pytorch支持的Python不能太高。没办法就把之前的Python3.13给卸载了。又从官网上下载了一个Python3.10.11（本来想下载一个Python3.10.15但不知道为什么官网不提供这个版本的下载，只是说有这个版。然后就一直往下找一直找到了3.10.11才有下载网址于是就下载了此版本）然后安装好了。这下下载了stable diffusion3.5的依赖。下载的时候还有插曲，那就是官网给的下载Pytorch的GPU版本的CDUA是11.8版的。我看了一下，在requirements.txt文件中把--extra-index-url https://download.pytorch.org/whl/cu118 改成了如下图：

--extra-index-url https://download.pytorch.org/whl/cu124 后下载的。而且如果直接下载也不行。会下载不了，还要修改成国内的库的网址我当时用的是：https://pypi.tuna.tsinghua.edu.cn/simple （清华大学的镜像）总算是顺利的下载完了。到了下载模型的时候才是郁闷的开始。
开始就想从huggingface.co网站下载。可是就是打不开。没办法就暂时放弃了。后来一想，这个肯定有解决的办法于是就从网上查了好长时间。结果发现可以从国内的镜像网站下载。网址是：https://hf-mirror.com/ 于是就到了这个网站。结果发现还真有stable diffusion 3.5这个模型。但要想从这个网站下载这个模型还是需要有huggingface.co网站的授权（即token）没办法。后来想我有一个同事可以“翻墙”由于找到这个同事用他的翻墙出去到huggingface.co申请了一个账号，然后又申请了一个授权，这些到是都不难很快就搞定了。但在用huggingface-cli真正的下载模型的时候又有问题了。到不是别的，总是提示我要下载的模型不存在。说是什么模型的路径不对。我真是无语了……从网上查了好多资料竟然没有一个人写的清楚的。我真是……哎。
后来经过本人的多次试验。才知道用huggingface-cli下载模型的正确用法（Windows）：

首先开一个Winodws的PowerShell，注意必须是PowerShell不能是普通的CMD窗口。
Windows PowerShell
版权所有（C） Microsoft Corporation。保留所有权利。

安装最新的 PowerShell，了解新功能和改进！https://aka.ms/PSWindows

PS C:\Users\Administrator>D:          转到相应的盘符下
PS D:\> cd D:\Source\SD3.5            转到相应的文件夹下
PS D:\Source\SD3.5> .venv\scripts\activate   激活Python虚拟环境
(.venv) PS D:\Source\SD3.5> $env:HF_ENDPOINT = "https://hf-mirror.com"   将下载的源改为国内的镜像网站
(.venv) PS D:\Source\SD3.5> huggingface-cli download stabilityai/stable-diffusion-3.5-large --local-dir models --include "sd3.5_large.safetensors" --token hz_************         
在download后面写的就只写到模型的名称。如果你只想下载sd3.5_large.safetensors一个模型文件的话，就要在后面用--include写清楚了。从网上查的也可能用通配符。如写成“*.safetensors”才可以。不能直接把要下载的文件写到download后面，本人就是开始一直这样写就怎么也下载不了。

至此才将想要的模型给下载完毕了。

Python 连接PostgreSQL

YuDi — Wed, 06 Nov 2024 03:01:16 +0000

这两天我写了一个项目，由于本人比较喜欢用PostgreSQL数据库，故就选用了此数据库。从网上查了一下说是用psycopg此数据库连接的“驱动”（本人比较喜欢这样叫）可是在安装了这个驱动之后，发现只要一引用这个包就会报错。开始以为是安装的文件有问题。于是就把安装的这个给卸载了。又重新安装了一次。但情况依然，后来就觉得是安装的版本不对。就安装了psycopg2（为Python2.x版本用的）这个驱动。但也同样是不行。后来没办法，就一行代码一行代码的调试。当时真是郁闷的不行，甚至怀疑自己这么多年的码农生涯的方向有问题了。是自己的识知固化了自己的想法。是想法有问题了。最后在一行一行的调试代码的情况下。发现了如果Python想用psycopg驱动连接PostgreSQL数据库的话那么还需要有另外的驱动。有三种途径。
其代码在psycopg/pq/init.py

第一种：就是再安装一个psycopg_c包，但我安装了一下这个包就安装失败。于是就查了一下这个包的安装问题。得到了如果安装这个包需要有C语言的客户端。但本人不想再安装一个C语言的客户端，于是放弃了这个。
第二种：就是要安装psycopg_binary这个包，这个包依本人看就是一个纯的Python的包。没有其它的要求（也许是有，只是我的项目已经满足了这些要求。反正最终我选择的就是这个），安装完成。之后再试就可以正常的连接PostgreSQL服务器了。
第三种：就是要安装一个C语言的客户端类库。这种方式我本人没有测试，也只是看了看里面的代码，就是一种直接调用操作系统动态库的方法。但也需要安装C语言的客户端或者是类库。于是也放弃了这种方式。
最后选择了第二种方式。给项目安装了一个psycopg_binary依赖包。到此这场本人第一交用Python语言的连接PostgreSQL数据库的风波总算是过去了。