首页 文章 精选 留言 我的

精选列表

搜索[高性能全文搜索引擎],共10007篇文章
优秀的个人博客,低调大师

微语 0.7.8 发布,支持全文+向量混合检索

企业级多租户团队协作工具,免费开源8件套:企业IM、在线客服、企业知识库/帮助文档、客户之声、工单系统、AI对话、工作流、项目管理。 语言 English 中文 介绍 企业IM 局域网即时通讯 企业成员管理 聊天记录监控 ... 全渠道客服 多渠道接入 人工客服 客服Agent智能体,对接自有数据,自动执行操作 ... 知识库 对接大模型 自定义知识库 Function Calling Mcp ... 工单系统 工单管理 工单SLA管理 工单统计和报表 ... AI Agent Ollama/DeepSeek/ZhipuAI/... 智能体 工作流 ... 客户之声 意见反馈 服务投诉 问卷调查 ... 项目看板 待办todo卡片 日报/周报 统计 ... 工作流 自定义表单 自定义流程 工单流程可视化 ... OpenManus 浏览器自动化执行 视频会议 集成jitsi 社交群组 类似 Discord ... 多租户 多租户管理 租户隔离 租户统计 ... Docker 快速开始 方法一:克隆项目并启动docker compose容器,需要另行安装ollama,默认使用 qwen3:0.6b 模型 git clone https://gitee.com/270580156/weiyu.git && cd weiyu/deploy/docker && docker compose -p weiyu -f docker-compose.yaml up -d 因项目默认使用ollama qwen3:0.6b模型,所以需要提前拉取模型。配置文件中可以配置其他模型,如deepseek-r1等 # 对话Chat模型 ollama pull qwen3:0.6b # 嵌入Embedding模型 ollama pull bge-m3:latest # 重新排序Rerank模型 ollama pull linux6200/bge-reranker-v2-m3:latest # 或者从 huggingface 下载模型 # ollama pull hf.co/<username>/<model-repository> 方法二:使用 docker compose ollama,默认安装ollama,默认使用 qwen3:0.6b 模型 git clone https://gitee.com/270580156/weiyu.git && cd weiyu/deploy/docker && docker compose -p weiyu -f docker-compose-ollama.yaml up -d docker 拉取ollama模型。配置文件中可以配置其他模型,如deepseek-r1等 # 对话模型 docker exec ollama-bytedesk ollama pull qwen3:0.6b # 嵌入模型 docker exec ollama-bytedesk ollama pull bge-m3:latest # 重新排序Rerank模型 docker exec ollama-bytedesk ollama pull linux6200/bge-reranker-v2-m3:latest # 或者从 huggingface 下载模型 # docker exec ollama-bytedesk ollama pull hf.co/<username>/<model-repository> 停止容器 docker compose -p weiyu -f docker-compose.yaml stop 修改配置,否则上传图片、文件和知识库无法正常显示 修改docker-compose.yaml文件 或docker-compose-ollama.yaml文件,修改以下配置项: # 请将服务器127.0.0.1替换为你的服务器ip BYTEDESK_UPLOAD_URL: http://127.0.0.1:9003 BYTEDESK_KBASE_API_URL: http://127.0.0.1:9003 方法三:宝塔面板 宝塔面板部署 方法四:源码启动 源码启动 演示 本地预览 # 请将127.0.0.1替换为你的服务器ip http://127.0.0.1:9003/ # 开放端口:9003, 9885 默认用户名: admin@email.com 默认密码: admin 架构图 架构图 开源客户端 桌面客户端 移动客户端 开源Demo + SDK Project Description Forks Stars iOS iOS Android Android Flutter Flutter UniApp Uniapp Web Vue/React/Angular/Next.js/JQuery/... Wordpress Wordpress Woocommerce woocommerce Magento Magento Prestashop Prestashop Shopify Shopify Opencart Opencart Laravel Laravel Django Django 链接 下载 文档 技术栈 springboot-3.x for 后端 react for web前端 flutter for 移动客户端(ios&android) electron for 桌面客户端(windows&mac&linux) 联系 微语技术支持群: 服务号 订阅号

优秀的个人博客,低调大师

P++ 的想法: 常见问题( 全文翻译 )

关键字 PHP, PPlusPlus, FAQ, Zeev Suraski, internals@ P++ 的想法: 常见问题 原文:https://wiki.php.net/pplusplus/faq 时间: 2019 年 8 月 9 日 作者: Zeev Suraski, zeev@php.net 这是一份对在 internals@译注1上提出的想法的常见问题澄清,它试图解决许多在随后讨论中被反复提出的问题。 注:P++ 是一个临时代码命名,未来可能会变化。 这到底是怎么回事? 试图将冗长的邮件内容浓缩为几点: PHP 世界有两个大的阵营。第一个大致喜欢 PHP 的动态性,带有强烈的 BC译注2偏见,并特别强调简单性,另一个更喜欢减掉包袱,拥有更高级、更复杂功能的更严格的语言。 这里没有“对”或“错”。这两种流派都有效,并具有非常坚定的追随者。然而,创建一种同时迎合这两个阵营的语言则是一项挑战,这也是 internals@ 上争论的一贯的原因。 该提议是创建一种新的 PHP 方言(代码名 P++),与 PHP 并存,但不受语言背后的历史哲学约束。换句话说,这种新方言本质上可能更加严格,它可能会更加大胆地消除向后兼容,并删除被认为是“包袱”的元素(例如短标签),并添加更复杂的特性,尤其是那些非常适合严格类型化的语言的,而无需为 PHP 方言引入相同的复杂性。 这不是 PHP 代码分支。代码库将是同一个,在该代码库上工作的开发人员是相同的。绝大多数代码都是相同的。只有两种方言之间的特定差异点才会有不同的实现。它有点类似于 PHP 7 中的 strict_types 所做的,只是在更大的范围内。 我们真的要做的就是因为有些人不能放弃短标签吗? 这与短标签无关,“弃用短标签 RFC译注3”不是这个想法的主要动力。这个提案的目标是更有野心,它是为 PHP 提供一个清晰的愿景,并希望通过向两个阵营提供他们想要的东西来最终解决两方的紧张关系。 为什么要分叉 PHP? 这不是分叉。 代码库将完全相同,它将由相同的人开发版本。二进制文件将完全相同,如果你安装 PHP,你也将安装 P++,反之亦然。相同的二进制将运行 PHP,P++ 或组合 PHP/P++ 的应用程序。 虽然目前还不清楚如何将一个文件“标记”为 P++ 文件,但它可能是文件顶部的某种特殊标记,例如: <?p++?> <?php 'Hello, world!'; ?> 此外,我们可能会找到将整个命名空间标记为 P++ 的方法,因此,框架不必将每个单独的文件明确标记为 P++。 这意味着我们的开发工作量增加了一倍,而internals@ 的贡献者已经很低(low)了。 我们如何处理? 值得庆幸的是,这并不意味着是那样(工作量增加了一倍)。绝大多数代码将在 PHP 模式和 P++ 模式之间共享——包括源代码和运行时。 无论运行的文件是 PHP 还是 P++文件,数据结构、关键子系统、扩展、Web服务器接口、OPcache 以及其他所有代码都将是完全相同的代码。唯一的额外开发开销会是 PHP 和 P++ 之间的差异部分。 确实,这意味着我们必须维护某些代码片段的两个版本,并且我们在各个地方都会有一些 if() 语句,因为与 PHP 相比,P++ 可能会有额外的检查。 但是,如果我们要转向更严格的 PHP 版本,这些元素无论如何都必须引入。此外,即使是严格阵营中的人,也不建议我们在没有提供迁移途径的情况下转向未来严格版本——实际上,这种方法所涉及的努力和几乎任何其他的方法都是相似的。 当我们转向更严格的 PHP 8/9时, 为什么不只是开发一个永久维护的 PHP 7.4 长期维护版? 这种方法存在许多问题。 即使我们忽视这样一个事实,即这会让庞大的动态偏好阵营悬而未决——没有任何特性或性能更新,从开发工作的角度来看,这是不切实际的。 这与这个提议不同,事实上,这确实意味着事实上的分叉。 我需要在 PHP 和 P++ 之间做出选择吗? 是,也不是。 如上所述,当你安装一个,你就有了另一个,所以就应用而言,你可以在一台服务器上运行这两种方言。 然而,实际上,项目和个人通常可能选择并标准化其中一个,类似于严格类型的情况。 我能在同一个应用程序中混合使用 PHP 和 P++ 吗? 是的。 虽然我们需要确定精确的机制,但代码是 PHP 还是 P++ 的指定将在文件级别,而不是在请求级别。 单个执行(请求)可以加载许多不同的文件,这些文件可以来自两种方言。PHP文件中的代码将表现为 PHP 语义——而来自 P++ 文件的代码将表现为 P++ 语义。 这也是,与 strict_types 类似。 虽然这开始听起来可能听很尴尬,但可能会有非常实用的用例。例如,PHP 应用程序使用的只含 P++ 的框架,反之亦然。 对于那些熟悉 C 和 C++ 的人来说,这有点类似。 这是否意味着 PHP 将不再发展? 所有新功能都会用于 P++ 吗? 不,这只是意味着它会以不同的方式发展。 严格性和类型相关的功能可能只适用于 P++,并且只能在 P++ 文件中使用。向后兼容偏差将保留在 PHP 中(这并不意味着向后兼容永不会被打破,只是每个这样的案例必须有良好的投资回报案例)。 但是,与此无关的功能,例如引擎的性能改进(如 JIT ),扩展的开发,或新的异步相关的功能,PHP 和 P++ 都可以使用。 这个方法有什么好处? 这种方法有很多好处。 首先,它为 internals@ 的两个阵营提供了一个很好的解决方案。 那些喜欢 PHP 动态特性的人可以保留它,而那些喜欢更严格类型语言的人也可以获得它,而不受任何 PHP 限制。 而替代方案是零和游戏,一个阵营的胜利是另一个的失败,反之亦然。 除了设计一个好的技术解决方案(使我们能够以最少的努力支持整个受众)之外,还可以终结近年来 internals@ 上争论的关键根源。 最后,虽然本文档的大多数读者可能是技术人员,但应该注意的是,启动 P++ 将从一个新的基点译注4不计过去重新开始,可能具有巨大的定位和品牌优势。未使用 PHP 的公司、开发经理和个人开发者更有可能注意到 P++ 的推出,而不是 PHP 8.0 或 PHP 9.0 的推出。 我们不是冒着分裂用户群的风险吗? 在某种程度上,我们是。但这不是这一想法的缺陷, 而是现实已经存在的表现。 如上所述,那里有很多人喜欢 PHP 的动态本质,并且谨慎地看待尝试使其越来越多地面向类型。 与此同时,还有另外一群看着 PHP 的人,自己在想:“为什么它变得如此缓慢,以至于我最终要放弃这动态的废材(原文:dynamicnonsense)?” 这里没有对或错。这两种观点都有效。当我们研究在这两个相互矛盾的观点之间架起桥梁的可能的解决方案时,没有太多可用的方案: 坚持使用动态PHP。这将不会被更严格语言的支持者所接受。 向严格的PHP发展。动态语言的支持者不会接受这一点。 分叉代码库。无论如何完成,都是所有参与者的净损失选项。 这样做没有技术优势,即使我们想要(我们不想要),我们也没有足够的贡献者去做。 提出一些创意解决方案,以满足双方观众的需求。 这就是该提案试图做的。它在保持项目本身统一的同时,也确保两种方言之间的永久互操作性。这虽然会有一定程度的碎片化,但它仍然是满足每个人的主要需求的最小可能。 这与 Nikita译注5版本的想法有何不同? 这两个想法之间有许多相似之处,但也存在一些实质性差异。 请注意,这是基于对版本方法的有限理解,因此部分可能缺乏,不准确或不正确。 在这个提议中,有一个明确的目标是保持当前动态类型的 PHP,作为一个长期的,完全支持的,平等的对等方言。 发版本的方法将当前行为视为“遗留”。 这意味着它可能会被劝止(使用),然后在某些时候弃用和删除。 推出策略完全不同。 P++ 提案旨在首先关注兼容性破坏元素,例如严格的操作、类型转换逻辑的更改、数组索引处理、需要变量声明等等,并且旨在在 P++ 的第一期提供它们。这样做的目的是允许新项目/框架重新开始,而不需知道在引入更多兼容性更改时,他们可能不得不在一两年内进行重大改写。 版本化提案似乎没有这样的目标,而是旨在逐步添加/更改 PHP 中的元素。 与推出方式相关,版本化方法不允许只有两种方言,而是任何数量的方言。我们可能有 PHP2020 方言,以及 PHP2022 方言和 PHP2027 方言。 如果我们全部保留它们,实际上这可能会增加我们的维护复杂性。 该提议还提到了 PHP 与 P++(保守与积极)的不同打破向后兼容策略,而版本化方案可能根本不会涉及该主题。 版本提案与此提案的定位/营销方面并不完全相同。 重要的是,要注意这两个想法不一定是相互排斥的。 我们可以介绍 P++ 并使用版本进行改进,特别是当证明很难将所有重要的变化都放到 P++ 的第一期中。 有哪些挑战? 在我们能运行第一个 P++ 应用程序之前,不乏挑战。 我们需要获得支持。这意味着,两派的人都需要放弃让 PHP 完全动态或完全类型化的梦想,而忽略那些与他们想法不同的人。这似乎是一个非常重大的挑战。 为获得成功,P++ 第一个版本应该处理来自 PHP 的所有,或至少大多数兼容性破坏的更改,以便切换(可能相当痛苦)的开发人员不必在未来重新审核/彻底重构他们的代码。一些人表示担心,由于我们的开发人员能力有限,他们可能过于乐观,无法在一期发布。一旦我们对列表的内容有了更好的了解,我们就必须对此进行评估。 请注意,这并不意味着我们需要在第一个期中实现我们可能对 P++ 提出的所有想法,只是我们应该优先考虑会触发大量最终用户代码重写的元素,并尝试在我们的第一版之前处理它们。 当然,最具挑战性的——我们需要为这种新方言找到一个合理的名字。 pplusplus/faq.txt· 最后修改: zeev 于 2019/08/09 21:44 译注 internals@:PHP 内部开发人员邮件列表。这里涉及 PHP 的开发机制,当内部讨论成熟后,会公开在externals,通常用来提交 RFC 和发布版本通知。 BC:即 Backward Compatibility,向后兼容,也叫向下兼容,兼容过去的版本,即升级的软件要考虑旧版本的兼容性,比如,Office 2019 的 Word 默认使用 .docx 文件格式,但也可以打开 Office 2017/2013/2010,甚至是 2003 的 .doc 格式。相对的概念叫做 FC,即 Forward Compatibility,向前兼容,也叫向上兼容,即升级的软件会考虑对未来的兼容性。这在软件中通常为一个确定的接口和约定,未来依然遵循,即可实现向前兼容。 RFC:即 Request for Comments,语言特性的加入,以及标准化变更管理的方法,通常加入新特性时,会为新特性提交 RFC 并给出例子,变更委员会评估通过后,语言会合入实现的源码,并入新版本。 新的基点:a clean slate,美国习语,即不计过去新的开始。 Nikita:一位 internals@ 上的发言者,提议在版本中加入特性。顺便提一句,美剧《Nikita》值得一看。 (本文翻译为笔者原创,限于水平有限,如翻译中有不妥的地方请回复留言,如转载请注明出处:IT桃花岛) 相关文章 PHP 联席架构师辞职,原来他想做 P++…

优秀的个人博客,低调大师

Python-网页转义字符及正则全文匹配

前言 大部分情况下,通过request去请求网页,response.text返回来的都是正常值,但是有一些反爬虫比较严重的网站(比如知乎)就不会是这样。知乎会返回转义字符,例如: header = { "User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0", "HOST":"www.zhihu.com", "Referer":"https://www.zhihu.com/signup?next=%2F", } def rget(): response = session.get("https://www.zhihu.com/signup?next=%2F", headers=header) target_str = response.text print(target_str) rget() 在给知乎的登录页面发请求后,打印返回结果(内容太多,只返回一小部分): &quot;token&quot;:{&quot;xsrf&quot;:&quot;9b6c6406-db1b-45fa-8626-296c037cfc00&quot;,&quot;xUDID&quot;:&quot;ANBsasFlAg2PTgaqB1CHBtsWMijmJ20s89E=&quot;},&quot;account&quot;:{&quot;lockLevel&quot;:{} 发现有很多字符是转义的,登录需要用到的xsrf字段也在这里面,这样做正则匹配就很麻烦。 解决的办法是将html进行转义: import html target_str = html.unescape(response.text) 就能够得到正常的返回信息了: "token":{"xsrf":"9febf0fd-7c47-4695-93b6-f670e518d920","xUDID":"ACDsF5lmAg2PTi2GMwQTl0Cwh88G51BOgzc="}, 正则匹配 匹配xsrf的值 (为了方便测试,只将一小部分值提取出来做匹配): tokens = '"token":{"xsrf":"9febf0fd-7c47-4695-93b6-f670e518d920","xUDID":"ACDsF5lmAg2PTi2GMwQTl0Cwh88G51BOgzc="},:' matchs = re.search(r'xsrf[:"\w-]+', tokens) if matchs: print(matchs.group(0)) else: print("未匹配") 得到输出结果为: xsrf":"9febf0fd-7c47-4695-93b6-f670e518d920" 然后再借用replace将引号替换,然后用split将值用冒号分开: import re tokens = '"token":{"xsrf":"9febf0fd-7c47-4695-93b6-f670e518d920","xUDID":"ACDsF5lmAg2PTi2GMwQTl0Cwh88G51BOgzc="},:' matchs = re.search(r'xsrf[:"\w-]+', tokens) nstr = matchs.group(0).replace("\"", "").split(":") finall = nstr[1] print(finall) 就得到了我需要的xsrf: 9febf0fd-7c47-4695-93b6-f670e518d920 xUDID的提取也是如此,这两个值在知乎登录的时候是需要携带的,所以要提取: import re tokens = '"token":{"xsrf":"9febf0fd-7c47-4695-93b6-f670e518d920","xUDID":"ACDsF5lmAg2PTi2GMwQTl0Cwh88G51BOgzc="},:' matchs = re.search(r'xUDID[:"\w-]+=', tokens) nstr = matchs.group(0).replace("\"", "").split(":") finall = nstr[1] print(finall) ACDsF5lmAg2PTi2GMwQTl0Cwh88G51BOgzc= re正则匹配html的坑 上面的正则可以匹配到字符串了,如果正常登录的话要将请求返回的内容文本进行匹配的,也就是匹配response.text,代码是否就是 matchs = re.search(r'xUDID[:"\w-]+=', response.text) 坑就在这里! re默认匹配的是单行字符串,而response.text的返回值虽然是一个html页面的构成,但是它是分行的,第一行是html头<! DOCUMENT html>不是我想要的整个文本进行匹配。 re是支持整个文本匹配的,需要在正则代码加上参数re.DOTALL即可: matchs = re.search(r'xUDID[:"\w-]+=', response.text, re.DOTALL) 就可以对整个返回的文本进行匹配了

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册