今天发现在 .NET Framework 和 .NET 9 中使用 System.Uri.EscapeDataString() 方法对字符串进行编码，会产生不同的结果。
譬如“(”符号，前者视其为非保留字符，不进行转义，后者视为保留字符，转义为“%28”。
原因是 .NET Framework 4.8 主要遵循 RFC 2396，而 .NET 9 遵循 RFC 3986。
在跨平台签名验证场景中，对 URL 编码的一致性要求极高，任何细微差别都会导致签名校验失败。
以下是以 RFC 3986 标准为核心、优先使用各平台内置的高一致性方案。
对于 .NET 9，直接使用 Uri.EscapeDataString()。
string encodedData = System.Uri.EscapeDataString(dataToEncode);对于 .NET Framework，以下是一个遵循 RFC 3986 严格标准的自定义编码方法示例。
static string Rfc3986EscapeDataString(string input)
{
// 定义 RFC 3986 中明确的未保留字符集（不编码）
var unreservedChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";
var result = new StringBuilder();
byte[] data = Encoding.UTF8.GetBytes(input); // 统一转换为 UTF-8 字节
foreach (byte b in data)
{
char currentChar = (char)b;
// 如果是未保留字符，直接输出
if (unreservedChars.IndexOf(currentChar) != -1)
{
result.Append(currentChar);
}
else
{
// 否则，进行百分号编码（%XX，大写）
result.Append('%').Append(b.ToString("X2"));
}
}
return result.ToString();
}对于 PHP，直接使用内置的 rawurlencode() 函数。这个函数的设计初衷就是严格遵循 RFC 3986 标准。
$encoded_data = rawurlencode($data_to_encode);对于 JavaScript，encodeURIComponent 函数严格遵循 RFC 3986 标准。
let encodedData = encodeURIComponent(dataToEncode);重要提示：无论使用哪种语言，务必在编码前明确指定字符串使用 UTF-8 编码。编码不一致是导致乱码和签名失败最常见的原因之一 。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
原因有很多，其中一种就是缺少主键。
一般地，应选择尺寸小于显存的大模型版本，且适当冗余。
譬如，显存 8GB，选择尺寸为 5.2GB 的 deepseek-r1:8b。
这样，整个大模型都能被完整地读取到显存中。
若选择 9.0GB 的 deepseek-r1:14b 则显存不足，Ollama 会自动调用系统内存和 CPU 来协同工作，导致推理速度显著下降。
显卡的算力影响生成的速度，模型的参数决定生成的质量。
另外经实测，在 /api/generate 接口的 format 参数中设置返回的 JSON 格式，会缩短生成时间，降低生成质量，可能的原因是强制格式限制了词汇选择空间。
今天遇到一个向基于 .NET Framework 框架开发的 Web 网站 POST 数据响应 405 Method Not Allowed 的问题。
服务端接口地址是 https://***/api/abc/Default.aspx，
若请求 https://***/api/abc/Default.aspx 或 https://***/api/abc/ 则正常 ，
若请求 https://***/api/abc 就会出现这个问题。
原因可能是服务器可能返回 301 重定向到 https://***/api/abc/Default.aspx，
导致最终接口接受到的请求方法不是 POST 。
早前记录过在 CentOS 中部署 ASP.NET Core 网站，现在宝塔面板已经直接支持创建 .NET 网站了，再次记录一下。
本文环境：VS2022、.NET 9、宝塔面板v11。
一、在 VS 中创建一个 .NET 9 网站，项目名称例：WebApplication1
发布选项：
关于“生成单个文件”选项，若勾选，发布后的项目启动文件不带后缀名（.dll），尝试在宝塔面板 v11.0.0 中无法顺利启动。
二、在 Linux 服务器上创建目录：/www/wwwroot/WebApplication1/
将发布后的文件上传到这个目录上，最终的文件结构如下：
三、进入宝塔面板，在 网站-Net项目 中安装 .Net环境管理，这里以 9.0.201 为例：
四、添加项目
项目名称：随意
运行路径：项目所在目录，本例中为：
/www/wwwroot/WebApplication1启动命令：使用 dotnet 命令，dotnet 命令可以不使用全路径（/www/server/dotnet/9.0.201/dotnet），第一个参数是项目启动文件，--urls 是反向代理的服务器和端口。服务器名可以是*也可以是localhost。例：
dotnet WebApplication1.dll --urls=http://*:5000项目端口：与启动命令中的端口号一致
开机启动：一般会勾选
启动用户：尽量用 www，最小权限原则。
正常情况下，网站已启动，如果未启动，检查配置，根据报错内容排查问题。
五、配置网站
添加域名、SSL 证书等。
友情提示：
网站版本更新重新发布后，需要手动重启网站才能生效，习惯于发布到 IIS（会自动生效）的同学要特别注意。
新手尽量以空项目或默认项目来部署，避免因特殊原因导致一系列其它问题。
nginx 反向代理并不会转发所有 Header，需要手动配置。
IIS 中使用 HttpPlatformHandler 模块部署 python web 项目时遇到 502.3 网关错误：
HTTP 错误 502.3 - Bad Gateway
There was a connection error while trying to route the request.
最可能的原因:
CGI 应用程序没有返回一组有效的 HTTP 错误。
由于父网关中出现错误，充当代理或网关的服务器无法处理该请求。
可尝试的操作:
使用 DebugDiag 排查 CGI 应用程序。
确定此错误是否由代理或网关引起。
详细错误信息:
模块 httpPlatformHandler
通知 ExecuteRequestHandler
处理程序 httpplatformhandler
错误代码 见下方表格
详细信息:
当 CGI 应用程序未返回一组有效的 HTTP 头，或者代理或网关无法将请求发送至父网关时，便会出现此错误。您可能需要获取一个网络跟踪，或者与代理服务器管理员联系(如果不是 CGI 的问题)。
| 错误代码 | 可能的错误原因 |
|---|---|
| 0x8007053d | 未安装相关组件库，建议执行命令：pip install -r requirements.txt |
| 0x80070005 | 若显示配置错误“由于权限不足而无法读取配置文件”则是应用代码目录未配置相应用户的读取权限； 访问受限，请正确配置 IIS 中的网站凭据、应用程序池标识、项目目录“读取”、解释器目录“读取和执行”权限等 |
| 0x80072ee2 | 执行超时，一般发生在批量读写的时候 |
| 0x8007042b | |
| 任何错误 | 查看日志文件。 可能的错误原因：
|
| 字段 | MySQL 中的类型和精度 | MySQL 中占用字节 | 原因说明 |
| 股票价格 | DECIMAL(10,2) | 5 | 股票价格四舍五入保留两位小数，避免浮点型精度丢失。 即使最贵的股票价格并没有超过 9999.99 元，但考虑到复权价和扩展性，建议用更大的类型。 |
| 基金价格 | 基金价格四舍五入保留三位小数，避免浮点型精度丢失。 | ||
| 精确的成交金额（元）、成交量（手） | BIGINT UNSIGNED | 8 | 取值范围 0 到 1844,6744,0737,0955,1615（即一千多个亿亿）。 2024年A股总成交金额为257万亿元。 |
| 不精确的成交金额、成交量 | float | 4 | 取值范围足够大，有效数字约为6-7位。 |
| 交易日 | DATE | 3 | 包括年、月、日 |
| 交易时间 | DATETIME | 8 | 精确到分钟 |
| 6位股票代码 | CHAR(6) | 6 | 6个半角字符占6个字节 |
| 股票名称 | VARCHAR(10) | utf-8 的一个汉字占3个字节 |
通常，我们在更新一条数据库记录时，EF 先取出这一条记录：
var log = DbContext.MyTable.Find(id);然后赋值字段并保存：
log.Result = "OK";
DbContext.SaveChanges();这样就会产生两次数据库查询。
我们尝试用 Attach 方法。
先创建一个仅包含主键的对象：
var log = new MyTable { Id = id };将对象附加到上下文：
DbContext.MyTable.Attach(log);然后更新需要更新的字段：
log.Result = "OK";
DbContext.SaveChanges();这样，能在保留其它字段值的前提下，减少一次数据库查询。
但是需要注意的是：
当某非 null 字段需要恢复默认值时，EF 会忽略这个更改。（可能会因 EF 版本等原因有不同的结论）
举个例子：
某记录有个 int 型字段 a，在数据库中这个记录的 a 的值为 1，但 C# 中 int 型的默认值为 0，所以当 Attach 附加这个对象后，如果重新设置 log.a 为 0，那么保存后 a 的值仍为 1。
还有一种写法，利用 ExecuteUpdate 方法：
var affectedRows = DbContext.MyTable
.Where(c => c.Id == id)
.ExecuteUpdate(setters => setters
.SetProperty(c => c.Result, "OK")
);返回匹配的行数。
这种写法不会遇到“恢复为默认值不生效”的问题，推荐使用。