错误如下:

解决方法:
在“解决方案资源管理器”中点击项目右键,选择“编辑项目文件”

手动添加内容:
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.3" />
完成。如果编译出错,关闭项目并重新打开项目再试。
Orbi 型号命名规则:
套装:RBK
主体:RBR
分身:RBS、RBW 等
套装对比:
CPU | 高通 IPQ4019 四核 717MHz | 四核 710MHz | ||||
ROM | 128MB | - | - | - | - | - |
内存 RAM | 256MB DDR3 | 512MB | ||||
闪存 Flash | - | 256MB | 4GB | |||
包装内容 | 2 个(不分子母) | 1 个 RBR10 1 个 RBS10 | 1 个 RBR20 1 个 RBS20 | 1 个 RBR40 1 个 RBW30 插墙式 | 1 个 RBR40 1 个 RBS40 | 1 个 RBR50 1 个 RBS50 |
速度 | AC1300 双频段 1300Mbps 电力线 1000M 有线 | AC1200 双频段 2.4GHz 300Mbps+5GHz 866Mbps | 三频段 AC2200 本体 AC2200 分身 (866回程+866+400Mbps) | 三频段 AC3000 本体 AC3000 分身 (1733回程+866+400Mbps) | ||
本体端口 | 每个主机 3 个 WAN/LAN 自适应以太网端口 | 1 WAN & 1 LAN | 1 WAN & 1 LAN | 1 WAN & 3 LAN | 1 WAN & 3 LAN & 1 USB 2.0 | |
分身端口 | - | 2 LAN | - | 4 LAN | 4 LAN & 1 USB 2.0 | |
天线 | 4根 | 6根 | ||||
以太网回程 | 支持 | 支持 | ||||
Daisy Chain Topology 菊花链 | 支持 | |||||
Beamforming 波束成形 | 支持 | |||||
MU-MIMO | 支持 | |||||
802.11k/v 快速漫游 | 支持 | |||||
802.11r 快速漫游 | 不支持 | |||||
802.11ax(Wi-Fi 6) | 不支持 | |||||
AP 模式 | 不支持 | 支持 | ||||
关闭 WiFi 双频合一 | 原厂不支持,小米和 RBK50 可通过修改实现,分离后有线回程可能会失效 | |||||
IPv6 | 支持 | |||||
带机量 | 248 | |||||
覆盖范围 | - | 418 平方米 | 250 平方米 | 200 平方米 | 250 平方米 | 350 平方米 |
官网价 | 229.99 美元 | - | - | - | - | |
京东自营 | ||||||
京东旗舰店 | - | |||||
天猫旗舰店 | - | |||||
其它天猫店 | 969 苏宁易购 | - | RBK30:1288 | RBK40:1699 | - | |
优势 | 管理功能丰富。 配合米家APP 设置小米智能家居设备入网时,无需手动输入密码,入网更便捷。 网口盲插,不分子母。后续再扩展两个分身时可直接购买套装充当两个分身,相对于 Orbi 购买两个分身要节省成本。 | 三频。 性能稳定。 大内存 | ||||
分体价格:
本体 RBR20:599
本体 RBR40:999
本体 RBR50:999 活动
分身 RBS20:699
分身 RBW30 插墙:999
分身 RBS40:1099
分身 RBS50:1449
分身 RBS50Y 室外:未知
价格采自2019年8月
主体/分身 匹配:
分身 RBS20 可作为 RBR20, RBR40 or RBR50 的卫星
分身 RBW30 可作为 RBR40 or RBR50 的卫星
分身 RBS40 可作为 RBR40 or RBR50 的卫星
分身 RBS50 可作为 RBR50 的卫星
分身 RBS50Y 可作为 RBR50 or RBR40 or SRR60 的卫星

RBK13 = 1个 RBR10 + 2个 RBS10
RBK20 = 1个 RBR20 + 1个 RBS20
RBK23 = 1个 RBR20 + 2个 RBS20
RBK30 = 1个 RBR40 + 1个 RBW30
RBK33 = 1个 RBR40 + 2个 RBW30
RBK40 = 1个 RBR40 + 1个 RBS40
RBK43 = 1个 RBR40 + 2个 RBS20
RBK44 = 1个 RBR40 + 3个 RBS20
RBK50 = 1个 RBR50 + 1个 RBS50
RBK53 = 1个 RBR50 + 2个 RBS50
扩展阅读:Mesh 路由器有线回程布线方案
完整操作步骤如下:
安装 NuGet 包:
Microsoft.AspNet.Web.Optimization打开
Views目录(如果是应用于区域,则为区域的Views目录)中的 web.config,在<namespaces />节点中添加<add namespace="System.Web.Optimization" />在
App_Start目录中创建类文件BundleConfig.cs,更改其命名空间为应用程序的默认命名空间(即移除.App_Start),创建方法:public static void RegisterBundles(BundleCollection bundles) { bundles.Add(new StyleBundle("~/虚拟路径(不能有点)").Include("~/CSS文件路径")); bundles.Add(new ScriptBundle("~/虚拟路径(不能有点)").Include("~/JS文件路径")); }虚拟路径应避免与页面访问路径相同。Include 可包含多个文件,效果是合并输出,注意引用的顺序。
打开
Global.asax,在Application_Start()事件中添加代码BundleTable.EnableOptimizations = true; // 该设置使在开发模式中实现压缩代码,不设置则仅在发布后压缩代码 BundleConfig.RegisterBundles(BundleTable.Bundles);视图页面中引用样式表或脚本
@Styles.Render("~/CSS虚拟路径") @Scripts.Render("~/JS虚拟路径")使用 Render 的好处是,ASP.NET 会自动给引用地址加上参数,可在更改脚本或样式表内容后更改这些参数使浏览器缓存立即失效。
如果你的项目中已经安装并使用 Bundle,那么只需要参考第 4 步,将 BundleTable 的 EnableOptimixations 设为 true。
以下是一些常见异常的解决方法:
The name 'Styles' does not exist in the current context
The name 'Scripts' does not exist in the current context
解决:参步骤 2。
引用的样式表或脚本不存在(报 404 错误)
解决:步骤 3 中的虚拟路径不规范。
传统的 LIKE 模糊查询(前置百分号)无法利用索引,特别是多个关键词 OR,或在多个字段中 LIKE,更是效率低下。本文研究对文章进行分词以提高检索的准确度和查询效率。
根据自己的编程语言选择一款合适的中文分词组件,我在 ASP.NET 平台下选择了 jieba.NET。
设想的步骤:
分别对文章标题、标签、正文进行分词,保存到一张分词表上。该表把“文章 ID”和“词语”设为联合主键,用 3 个字段记录该词语分别在标题、标签、正文中出现的次数,另外还可以按需要添加文章分类 ID、文章创建时间等字段。
当用户输入关键词进行检索时,先将关键词分词,在分词表中用 in 语法查询到所有相关的记录;
使用 group by 语法对查询结果按文章 ID 分组;
关键在排序上,理想的排序是:
a. 先按搜索关键词中不同词语的出现量排序,即:若搜索关键词分词后是 3 个词语,那么全部包含这 3 个词的文章优先,只匹配其中 2 个词语的其次;
b. 再按搜索关键词在文中累计出现的次数排序(考虑权重),即:我们先假定标题和标签的分词权重为 5(意思是一个分词在标题中出现 1 次相当于在正文中出现 5 次),那么累加每个分词在标题、标签、正文的权重次数,得分高的优先;
c. 再进一步考虑文章的发布时间,即将文章的发布时间距离最早一篇文章的发布时间(或一个较早的固定日期)相隔的天数,乘以一个系数加入到权重中,这个系数按不同文章分类(场景)不同,比如新闻类的大一点,情感类的小一点)。乘以系数时一篇文章只加权一次,不要加权到每个分词。
d. 根据需求还可以加入文章热度(阅读数)的权重。
根据上述逻辑对一个有 18 万篇文章的内容管理系统进行改造,循环所有文章进行分词统计,得到一张包含 5 千万条记录的分词表(系统中部分文章只有标题、标签和外链,没有正文,否则更多)。
由于查询中包含 in、group by、count、sum、运算等,再若分类是无级限的,即文章分类 ID 也是 in 查询,然后分页,即使创建索引,效率也只能呵呵了。
简化:
不对正文进行分词;
不按权重进行排序;
那么分词表的记录数降到 250 万条,同样用 in 查询分词,先按搜索关键词中不同词语的出现量排序,再按发布时间排序,分页后获得一页的文章 ID 集合,再去文章表中 in 获取详细信息(注意保持一页中的排序)。
添加相关索引后,查询一个包含 3 个分词的关键词仅需十几毫秒。因为 in 的内容比较离散,所以索引的利用率比较高。
本文讲述使用网页开发适用于宴会、活动、年会现场 LED 大屏幕显示抽奖、抢楼、游戏、视频等互动界面,通过在浏览器中打开后 F11 全屏投影到大银幕上。
设计思路:
为了保证最佳的显示效果,设计稿的尺寸按大屏幕的“宽高比”来做(本文以4米*3米的大银幕为例,设计稿以800*600像素为例)。
由于电脑的视频输出分辨率很有可能与大银幕的宽高比不同,那么我们全屏投影后会界面会有变形,但是投影设备接收到电脑视频信号后再全屏显示到大银幕时,界面又会变回正常。
按设计稿的尺寸开发网页,并使用 CSS3 的 scale 实现整体伸缩,目的是自适应窗口尺寸来全屏显示内容,无留白、无裁切。整体拉伸的要求是文字、图片、背景、间距、iframe 等所有元素以统一的比例拉伸,无错位。
网页上通过 JS 设置一些快捷键来实现页面展示内容的切换。
若投影设备功能有限或操作员水平有限等原因导致无法顺利设置输入输出分辨率时,网页可设置 x 轴和 y 轴两个方向的伸缩系数、定位偏移量等,更灵活地实现完美投影需求。
开发要点:
网页尺寸按设计稿来定(以 800x600 为例)。
使用 CSS3 的 transform 的 scale 来实现缩放,以电脑显示器分辨率 1920x1080,宽放大 1920/800 倍,高放大 1080/600 倍,即可将设计稿全屏展示到电脑显示器上。为了更灵活,我们使用窗口大小来代替显示器分辨率,这样不管怎么改变窗口大小或者全屏,设计稿都能完整地显示在窗口上。
在页面初始化和窗口尺寸变化时重新调整设置上述比例。
代码参考:
这是一篇可能解决困扰了 .NET 程序猿多年的文章!
首先,使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序,直接选用了 MVC 模板。
直接发布项目,默认的设置如下图:

对于小型项目,按默认设置发布基本可满足正常运行,首次运行打开第一个页面基本在 5~6 秒(视服务器配置),其它页面的首次打开也基本在 1~2 秒完成,非首次瞬间打开。
一旦项目功能变得复杂,文件增多,会导致发布后首次运行打开第一个页面 30 秒以上,其它页面的首次打开 10 秒左右,非首次瞬间打开。
这是因为项目在发布时没有进行预编译,而是在用户访问网页时动态编译,一旦应用程序池回收,或项目文件改动,都会重新编译,再次经历缓慢的“第一次”,这是不能忍的。
于是咱们来研究一下“预编译”。
在发布页面勾选“在发布期间预编译”,这时发布会在“输出”窗口显示正在执行编译命令(编译时间会比较长):

该选项对发布后的文件结构和内容影响不大,因此对首次执行效率的提升也不大,重要的在后面。
在“高级预编译设置”窗口中:

我们针对预编译选项和合并选项分别做测试。
不勾选“允许更新预编译站点”,会致 bin 目录中生成许多 .compiled 文件,而所有 .cshtml 文件的内容都是:
这是预编译工具生成的标记文件,不应删除!
如果是 Web From 网站,.aspx/.ashx 等文件内容同上。
尝试打开网站页面,你会发现,除了项目启动后的第一个页面仍然需要 1~2 秒(无 EF),其余每个页面的首次都是瞬间打开的(EF 的首次慢不在本文讨论范围)。这让我对预编译有一种相见恨晚的感觉!
这里偷偷地告诉你,把 Views 目录删掉也不影响网页正常打开哦~为什么不让删,咱也不敢问,咱也不敢删。
目的达到了,有一些后遗症需要解决,比如 bin 目录内杂乱无章。
选“不合并。为每个页面和控件创建单独的程序集”,结果是 bin 多出许多 App_Web_*.dll 文件。
选“将所有输出合并到单个程序集”,填写程序集名称。这时会发现“输出”窗口执行了命令:

如果程序集名称跟已有名称冲突,会发生错误:
合并程序集时出错: ILMerge.Merge: The target assembly '******' lists itself as an external reference.
查看 bin 目录,.compiled 文件还在,但 App_Web_*.dll 合并成了一个程序集。FTP 的“不合并”也是把所有 App_Web_*.dll 上传一遍,所以不存在相对于“合并”的增量发布优势。
是不是勾了“视为库组件删除(AppCode.compiled 文件)”.compiled 文件就会不见?意外之外,情理之中,bin 没有什么变化。
继续选择“将各个文件夹输出合并到其自己的程序集”,呃,bin 中文件数不降反增。
最后选择“将所有页和控件输出合并到单个程序集”,同样程序集名称不能冲突。结局令人失望,bin 中仍然一大堆 .compiled 和 App_Web_*.dll。
整理成表格:
| 1 | 允许更新预编译站点 aspnet_compiler.exe -v / -p \Source -u \TempBuildDir 重复发布后 bin 目录文件数:不会增多(页面不进行预编译) |
| 2 | 不允许更新预编译站点,不合并 aspnet_compiler.exe -v / -p \Source \TempBuildDir 重复发布后 bin 目录文件数:.compiled 不会增多,App_Web_*.dll 增多 |
| 3 | 不允许更新预编译站点,不合并。为每个页面和控件创建单独的程序集 aspnet_compiler.exe -v / -p \Source -c -fixednames \TempBuildDir 重复发布后 bin 目录文件数:不会增多(编译后的文件名固定,FTP 方式的部分 App_Web_*.dll 文件可能实现增量上传) |
| 4 | 不允许更新预编译站点,将所有输出合并到单个程序集,不勾选“视为库组件” aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数:不会增多(.compiled 固定名称,App_Web_*.dll 合并为一个) |
| 5 | 不允许更新预编译站点,将所有输出合并到单个程序集,勾选“视为库组件” aspnet_compiler.exe -v / -p \Source \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a -r 重复发布后 bin 目录文件数:不会增多(.compiled 固定名称,App_Web_*.dll 合并为一个) |
| 6 | 不允许更新预编译站点,将每个文件夹输出合并到其自己的程序集,前缀 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -prefix 前缀 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数:.compiled 不会增多,App_Web_*.dll 增多 |
| 7 | 不允许更新预编译站点,将所有页和控件输出合并到单个程序集 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -w 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数:.compiled 不会增多,App_Web_*.dll 增多 |
bin 目录下,页面的程序集文件(App_Web_*.dll)增多的原因是编译后的文件名不固定,发布到会导致残留许多无用的程序集文件。
相比较,如果第 3 种能实现 FTP 稳定的增量上传的话是比较完美的(还有一个缺点是:如果页面有删除,目标 bin 内对应该页面的 .compiled 和 .dll 不会删除,这跟“允许更新预编译站点”是一个情况),那么第 4 种 或第 5 种也是不错的选择(同样有缺点:执行合并比较慢)。
测试一个有 300 个页面的项目,compiler 用时约 2 分钟,merge 用时约 5 分钟,发布用时约 4 分钟。
这里有个槽点,执行预编译和合并是佛系的,CPU 和磁盘使用率永远保持在最低水平。
所以如果是要经常修改的项目,那么建议选择“不合并”的第 3 种发布方式:

“视为库组件(删除 AppCode.compiled 文件)”:移除主代码程序集(App_Code 文件夹中的代码)的 .compiled 文件。 如果应用程序包含对主代码程序集的显式类型引用,则不要使用此选项。
补充:
不允许更新预编译站点发布后,因为前端页面没有内容,因此无法单独修改发布(单独发布一个页面后,在访问时不会生效!),只能全站发布,耗时较长;bin 目录有变动将导致使用 InProc 方式存储的 Session 丢失。
预编译的另一个优点是可以检查 .aspx / .cshtml 页面 C# 部分的错误(特别是命名空间和路径引用)。
改为预编译发布后,可以将服务器上残留的 .master / .ascx / .asax 删除,但不能删除 .aspx / .ashx /.config 等。
VS 发布到 FTP 经常会遗漏一些页面文件,不合并时会遗漏独立文件,合并后也会遗漏合并后的 .dll 的文件,合并的好处就是方便检查是否完全上传发布。
慎选“在发布前删除所有现有文件”!一旦勾选发布,世界就清静了,所有网友上传的图片附件以及网站运行产生的其它文件,消失得无影无踪。不管发布到文件系统还是发布到 FTP 都一样。当然,如果是先发布到文件系统,再通过 FileZilla 等 FTP 软件上传到服务器的,建议勾选此项。
.NET Core 应用程序部署:https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index
由于上传文件时 bin 目录文件较多,理论上 bin 目录内的文件有任何改动都会重启应用池,而且 VS 是单线程上传的,导致期间网站访问缓慢,服务器 CPU 升高,我的做法是:发布到文件系统,再使用专用 FTP 工具上传,上传用时约半分钟(如果大小不同或源文件较新则覆盖文件)。还嫌慢?那就打包上传,解压覆盖。
关于本文研究对象的官方解释:高级预编译设置对话框
出现“未能加载文件或程序集“***”或它的某一个依赖项。试图加载格式不正确的程序。”的问题时,先用改用 Debug 方式发布会报详细错误,一般是 .aspx 等客户端页面有 C# 语法问题,注意提示报错的是 /obj/ 目录下的克隆文件,应更改原文件。排除错误后关闭所有页面,再使用 Release 方式发布。
2025年9月补充:因预编译发布后生成的文件时间都是系统最新时间,通过 FTP 上传到服务器时都会覆盖文件,可能导致杀毒软件进程 MsMpEng.exe 占用 CPU 过高。尝试选择不进行预编译,即取消“发布期间预编译”前的勾,这样发布的的文件时间都是文件本身的最后修改时间,重复发布不会更新这个时间,而且 bin 目录中也不会出现大量编译后的文件。这样通过 FTP 上传时只要设置“大小不同且文件较新则覆盖”就不会重复上传文件了,杀毒软件的工作量就能大大减少。缺点就是本文开头说的,每个页面的第一次打开会比较慢,而是非常慢。所以仍然需要勾选“发布期间预编译”,同时勾上“允许更新预编译站点”,这样 bin 目录中不会发现很多文件(合并不合并都一样),打开每个页面的第一次耗时也能在接受范围内。
前提:
若需获取用户 unionid,则小程序必须已绑定到微信开放平台。
小程序调用 wx.login(),将 code 发送到开发者服务器
开发者服务器请求微信接口 code2Session,获得 session_key、openid,有机会获得 unionid(参 UnionID 机制说明)。因此无需任何用户授权即可获取 openid
访问须要已获取用户信息的页面时,可通过小程序端使用 button + getUserInfo 的方式请求用户授权
访问须要已获取手机号码的页面时,可通过小程序端使用 button + getPhoneNumber 的方式请求用户授权
code2session、getUserInfo、getPhoneNumber 等接口返回数据存入数据库 dt_weapp_user
服务端的任何接口均返回口令状态包(含自定义会话口令等信息),小程序端应保存于 storage
请求 getUserInfo 后应判断 detail.errMsg 是否为 getUserInfo:ok,请求 getPhoneNumber 后应判断 detail.errMsg 是否为 getPhoneNumber:ok
授权窗口的弹出情况参此文
口令状态包是用来传递到客户端用来标识用户唯一凭证的,包含字段:会话口令(自定义用户凭证)、会话口令有效时间(秒)、是否已获取 unionid 或昵称(视业务需求)、是否已获取手机号码、uid(可选),以及其他用来标识业务身份字段。服务端可根据会话口令从数据库中获取该用户的所有已知信息。
一般情况下,当已获取手机号码时,uid 必有值,否则,uid 必为空。因此 uid 不是必须传递到客户端的。
通过 code2Session 获得的 session_key、以及 openid、unionid、手机号码等机密信息不允许包含在口令状态包中并缓存在客户端,客户端需要用到手机号码时单独调用接口获取。
若业务不要求以手机号码作为用户唯一标识,那么口令状态包中不需要包含是否已获取手机号码,仅 uid 即可。在客户端访问须要业务用户登录的页面时,也仅判断 uid 有值即可。
流程图:

为更好地适应 2017.7.19 发布的《小程序内用户帐号登录规范调整和优化建议》,开发者服务器提供的所有业务逻辑接口的返回值中都应包含口令状态包,约定有以下相关的返回值和处理动作(返回值按个人喜好来定):
| 口令状态 | 接口返回 | ASP.NET Web API 语句 | 处理动作 |
| access_token 空或失效 | 401 状态码 | return Unauthorized(); | login() + code2Session,获取 openid,生成 access_token |
| access_token 有效,但未获取 uniond 或用户信息 | 401 状态码,http 头 WWW-Authenticate 中标注 getUserInfo | return Unauthorized(new AuthenticationHeaderValue("getUserInfo")); | getUserInfo() |
| access_token 有效,但未获取手机号码(即未找到业务用户) | 401 状态码,http 头 WWW-Authenticate 中标注 getPhoneNumber | return Unauthorized(new AuthenticationHeaderValue("getPhoneNumber")); | getPhoneNumber() |
WWW-Authenticate 有大小写的问题,千万别入坑,参:https://xoyozo.net/Blog/Details/header-www-authenticate
返回内容是根据业务逻辑在服务端决定的,客户端在处理每个接口返回值时对返回内容作相应的处理即可。
spacedesk 是一款非常强大的虚拟投影软件,可以将其它电脑、苹果设备(iPhone、iPad)、安卓手机甚至 HTML5 浏览器作为第二屏幕。本文以一台笔记本的屏幕作为另一台笔记本的扩展记录安装配置过程。
主笔记本安装 spacedesk DRIVER
扩展笔记本安装 spacedesk VIEWER
为了保证屏幕最佳的显示效果,我们希望两台笔记本最终的显示分辨率与物理分辨率一致。
我的主笔记本分辨率 1920x1080,扩展笔记本分辨率 1366x768
主笔记本
首先在扩展笔记本中打开 spacedesk VIEWER,连接主笔记本。
在主笔记本,桌面右键“显示设置”,分别针对 1 和 2 显示器设置分辨率:


当然还可以在上上图中的“重新排列显示器”中拖动来实现屏幕内容的显示位置。
扩展笔记本
打开 spacedesk VIEWER,在菜单的 Settings 中选择 Resolutions 可设置显示分辨率:


选择 Compression Quality 可设置显示质量:

压缩(Compression)如果选择 Off,那得看你的电脑能否吃得消,否则显示效果会更卡。我的配置是压缩选择 On,颜色深度选择低,快速,质量 100,帧率选择 60 FPS:

这样比默认设置的显示效果要好很多。
如果有条件用有线连接的话,尽量不要用无线连接,能减少不少延时。
当使用在线编辑器编辑一篇文章(或从 Word 复制)后,会得到包含 HTML 标签的字符串内容,可以直接将它输出到页面上而不需要进行 HTML 编码。
但是,当我们需要改变图片大小时,我们发现有些图片的尺寸是直接使用 style 属性固定的,除了用 JS 进行后期处理,我们可以在服务端对 <img /> 进行修正。
这个场景会在小程序开发的时候遇到。
我们可以在客户端用 JS 进行处理,也可以在服务端用类似的方法处理(使用正则表达式)。参此文
这里使用 HtmlAgilityPack 通过递归节点来处理:
/// <summary>
/// 给所有指定节点添加样式
/// </summary>
/// <param name="html"></param>
/// <param name="tag">节点名称(小写),如:img</param>
/// <param name="styles">要添加的样式,如:max-width:100%;</param>
/// <returns></returns>
public static string AddStyleToHtmlNode(string html, string tag, string styles)
{
HtmlDocument doc = new HtmlDocument();
doc.LoadHtml(html);
for (var i = 0; i < doc.DocumentNode.ChildNodes.Count; i++)
{
doc.DocumentNode.ChildNodes[i] = AddStyleToHtmlNode(doc.DocumentNode.ChildNodes[i], tag, styles);
}
return doc.DocumentNode.OuterHtml;
}
private static HtmlNode AddStyleToHtmlNode(HtmlNode node, string tag, string styles)
{
if (node.Name == tag)
{
var style = node.GetAttributeValue("style", null);
node.SetAttributeValue("style", ((string.IsNullOrWhiteSpace(style) ? "" : style.Trim() + ";") + styles).Replace(";;", ";"));
}
for (var i = 0; i < node.ChildNodes.Count; i++)
{
node.ChildNodes[i] = AddStyleToHtmlNode(node.ChildNodes[i], tag, styles);
}
return node;
}直接调用:
Content = zStringHTML_190126.AddStyleToHtmlNode(Content, "img", "max-width:100%;height:auto;");当使用在线编辑器编辑一篇文章(或从 Word 复制)后,会得到包含 HTML 标签的字符串内容,可以直接将它输出到页面上而不需要进行 HTML 编码。
但是,当我们需要改变图片大小时,我们发现有些图片的尺寸是直接使用 style 属性固定的,除了用 JS 进行后期处理,我们可以在服务端对 <img /> 进行修正。
这个场景会在小程序开发的时候遇到。
网上一般使用正则表达式直接将 <img 替换成 <img style="max-width: 100%; height: auto;" ,缺点是如果该 <img /> 本身就带有 style 属性,那么会出现一个标签两个 style,很多情况导致这两个样式同时失效,所以我们应针对有 style 和无 style 分别处理。
// 把 <img src="a.jpg" style="display: block;" /> 替换成 <img src="a.jpg" style="display: block;;max-width:100%;height:auto;" />
Content = Content.replace(/(\<img\s+[^>]*style\s*\=\s*['"][^'"]*)(['"])/gi, '$1;max-width:100%;height:auto;$2');
// 把 <img src="b.jpg" /> 替换成 <img src="b.jpg" style="max-width:100%;height:auto;" />
Content = Content.replace(/(\<img\s+((?!style).)+?)(\/?>)/gi, '$1 style="max-width:100%;height:auto;" $3');复制以上代码时,半角空格可能会变成全角空格,请注意修正。
当有 style 时,我们将 max-width: 100%; height: auto;追加在原样式之后,以重写原样式。这里没有直接判断原样式是否以 ; 结尾,而是直接追加 ;,这并不会影响实现展示效果。
在判断没有 style 用到正则表达式的“断言”,参:https://blog.csdn.net/xuyangxinlei/article/details/81359366