tsrs: 在 ENX 项目里试用 Rust 版 TypeScript 类型检查器

起因 先是在微信公众号上看到一篇介绍 tsrs 的文章,又读了 Cloudflare 的公告 Porting TypeScript to Rust。tsrs 在 Oxc 项目下孵化,Oxc 属于尤雨溪的 VoidZero。我一直关注尤雨溪的动向,早年也用过 Vue,对他团队出的东西比较信任,所以想在自己的项目 ENX 上试一下。 ENX 有两个 TypeScript 前端:enx-ui(Next.js)和 enx-chrome(Chrome 扩展,Vite 构建)。两边现在都用 TypeScript 6.0.3。 tsrs 是什么 把 TypeScript 7 的 Go 版编译器(tsgo)逐个函数移植到 Rust,命令行用法和 tsc 一样,许可证是 Apache-2.0。 由 Owner.com 的 Max Schwenk 发起,Cloudflare 和 VoidZero 参与,和 TypeScript 团队有合作。它不是 fork,语言方向仍由 TypeScript 团队决定。 对齐的是 TypeScript 7.1 开发版(microsoft/TypeScript@b85298b6a81f)。官方一致性测试的 13,462 条错误基线通过了 13,458 条,作者说剩下 4 条是测试工具本身的问题。 Cloudflare 的数据:同样数量的检查线程下,tsrs 比 TypeScript 7.0 快最多 8 倍,内存少约 70%。 仓库 2026-10-01 才建,到我试的时候已经发到 0.18.0。仓库不接受 PR。不支持 --init 和 --showConfig,没有 Intel Mac 二进制,Windows 包还没发布。 试用过程 为了不动项目依赖,我把 tsrs 装在一个临时目录里,再用它的二进制去检查两个前端: ...

Created 21216-10-21 · Updated 21216-10-21 · 2 min · 263 words · -

Long Polling and HTTP Keep-Alive: 长轮询与连接复用

客户端想"一有新消息就知道",但只能由客户端主动发请求(比如它在内网里,服务端连不进来),常用的办法是长轮询。这篇记录长轮询怎么工作,以及它底下的 HTTP 连接复用(keep-alive)是怎么回事。起因是给 homelab 配 GitHub Actions 自托管 runner 时,想弄清楚 runner 在内网里是怎么及时拿到任务的。 短轮询和长轮询 短轮询:客户端每隔固定时间问一次"有没有新消息",服务端立刻回答,有就给,没有就回空。 间隔设短了,大部分请求都是空跑,浪费流量和服务端资源 间隔设长了,消息要等到下一次轮询才能拿到,延迟最多一个间隔 长轮询:客户端发出请求后,服务端先不回答,把请求挂住: 挂住期间来了消息,立刻在这个请求上返回 一直没有消息,等到约定的时间(比如 50 秒)返回一个空响应 客户端收到响应(不管有没有消息)后马上发下一个请求 client server |---- GET /messages (wait up to 50s) ---->| | | no message yet, hold the request | | ... 12s later a message arrives |<--------- 200 [message] ----------------| |---- GET /messages (wait up to 50s) ---->| sent again immediately | | nothing for 50s |<--------- 200 [] (empty) ---------------| |---- GET /messages (wait up to 50s) ---->| 所以长轮询几乎任何时候都有一个请求挂在服务端,消息一到就能送出去,延迟接近实时;没有消息时每 50 秒才一个请求,空跑也很少。消息在两次请求之间到达也不会丢:服务端先把它放进队列,下一个请求一到就取走。 ...

Created 20206-10-20 · Updated 20206-10-20 · 2 min · 310 words · -

WCAG: Web 内容无障碍指南

WCAG 全称 Web Content Accessibility Guidelines,中文一般译作「Web 内容无障碍指南」,是 W3C 发布的一套规范,规定网页要做到什么程度,才能让视力、听力、行动或认知有障碍的人也能正常使用。这里的「障碍」范围比想象中宽:色弱、老花、在强光下看手机、手腕受伤只能用键盘,都算在内。 我第一次认真对照它,是给自己的项目调灰色辅助文字的颜色:原来的灰字在白底上对比度 4.7:1,刚好过线;在浅灰背景上只有 4.3:1,没过线。下面是我整理的要点。 版本 版本 发布时间 说明 WCAG 2.0 2008-12 后来被采纳为国际标准 ISO/IEC 40500:2012 WCAG 2.1 2018-06 在 2.0 上增加移动端、低视力、认知相关的条款 WCAG 2.2 2023-10 再增加 9 条(如焦点不能被遮挡、点击目标最小尺寸),删除了过时的 4.1.1 Parsing WCAG 3.0 草案 打算换一套评分模型,还没定稿,不能拿来做合规依据 2.x 各版本向后兼容:满足 2.2 就自动满足 2.1 和 2.0。现在各国法规引用最多的是 2.1 AA,新项目直接按 2.2 AA 做就行。 四个原则:POUR 所有条款归在四个原则下: Perceivable(可感知):信息要能被感知到。图片有替代文字,视频有字幕,文字和背景有足够对比度,不能只靠颜色传达信息。 Operable(可操作):界面要能被操作。所有功能都能用键盘完成,焦点位置看得见,不设置让人来不及反应的时间限制。 Understandable(可理解):内容和操作方式要能看懂。页面声明语言,表单出错时说明错在哪、怎么改,同样的控件在不同页面行为一致。 Robust(健壮):能被各种浏览器和辅助技术(如读屏软件)正确解析。主要靠语义化 HTML 和正确使用 ARIA。 三个等级:A、AA、AAA 每条「成功标准」(success criterion)都标了等级: A:最低要求,做不到会让一部分人完全用不了。例如 2.1.1 键盘可操作。 AA:通行的合规目标,法规和公司规范基本都要求到这一级。例如 1.4.3 文字对比度 4.5:1。 AAA:最高要求,W3C 自己也说不建议把整站 AAA 作为目标,因为有些内容做不到。例如 1.4.6 文字对比度 7:1。 说「符合 WCAG 2.2 AA」,意思是 A 级和 AA 级的条款全部满足。 ...

Created 15156-10-15 · Updated 15156-10-15 · 2 min · 389 words · -

Turbopack

Turbopack 是 Vercel 开发的 JavaScript/TypeScript 打包工具(bundler),用 Rust 编写,定位是 Webpack 的继任者。它目前主要通过 Next.js 使用:从 Next.js 16 开始,next dev 和 next build 默认都用 Turbopack。 打包工具做什么 浏览器不能直接运行一个现代前端项目的源码:TypeScript 和 JSX 要编译成 JavaScript,import 了上百个 npm 包的模块图要合并、拆分成若干个文件,CSS、图片要处理,生产环境还要压缩、去掉没用到的代码(tree shaking)。打包工具做的就是这件事:从入口文件出发,沿着 import 建出完整的模块图,再按规则输出浏览器和 Node.js 能直接加载的文件。 Next.js 这类同时有服务端和客户端代码的框架,还要求打包工具同时产出两套结果:服务端渲染用的代码,和发给浏览器的代码。 常见的打包工具: 工具 实现语言 说明 Webpack JS 2012 年起的事实标准,插件和 loader 生态最大 Rollup JS 偏库打包,Vite 的生产构建原先基于它 esbuild Go 速度快,常被其他工具当作底层编译器 Vite JS 开发模式基于浏览器原生 ESM,正在把底层换成 Rust 实现 Turbopack Rust Vercel 出品,与 Next.js 绑定 背景 Webpack 统治前端工程化十余年,但它用 JavaScript 实现,项目一大,冷启动和热更新都慢。Vercel 在 2022 年随 Next.js 13 发布了 Turbopack 的 alpha 版。Webpack 的原作者 Tobias Koppers 是 Turbopack 的核心作者之一。 ...

Created 10106-06-10 · Updated 12126-10-12 · 2 min · 378 words · -

Chrome Side Panel 侧边栏

Side Panel 是什么 Chrome 窗口右侧可以展开的一栏,和当前网页并排显示。Google 的说法是「a new companion surface that allows users to use tools alongside the content they are browsing」:一个伴随页面的界面,让用户一边看网页一边用工具。 它分两层: 浏览器自带的侧边栏:书签、阅读清单等 Chrome 自己的功能。 扩展的侧边栏:扩展通过 Side Panel API(chrome.sidePanel)在这一栏里显示自己的页面。 时间线 时间 版本 变化 2022-03 Chrome 99 稳定版出现侧边栏,内容是书签和阅读清单(9to5Google 报道;Google 自己的博客写的是 2022 年 5 月加入) 2023-05 Chrome 114 扩展可用 Side Panel API,只支持 Manifest V3,需要 sidePanel 权限 2023-08 Chrome 116 新增 sidePanel.open(),可以由扩展主动打开,但必须在用户操作(点击、快捷键、右键菜单等)里调用 为什么要有 Side Panel API API 出现之前,扩展想做侧边栏,只能用 content script 往每个网页里注入一个 <div>。Google 在发布 API 时给的理由: ...

Created 12126-10-12 · Updated 12126-10-12 · 1 min · 131 words · -

OWL

OWL OWL Web本体语言指南 W3C推荐标准 2004年02月10日 摘要 目前这种结构的万维网,很像一本地图做得很差的地理书,我们对于Web中可以使用的文档和服务的了解,都是基于关键字搜索的, 同时还需要灵活地使用文档的链接和使用模式。如果没有强有力的工具的支持,这么大规模的数据是很难管理的,为了能够给Web绘制出更为详实的地图,计算代理需要对于网络上可用资源的内容和能力做一个机器能够读得懂的描述。这些描述是人类能够读得懂的信息的扩展。 OWL,这种本体描述语言,可以用来描述Web文档和应用中内在的类和关系。 这篇文章解释了OWL语言的使用: 通过定义类以及类的属性来形式化某个领域; 定义个体并说明它们之间的属性; 在OWL语言的形式化语义允许的层次上,对类和个体进行推理。 本文的各章节间是按照类、属性、个体的集合的定义给出来的,从最简单的概念开始,逐渐过渡到更为复杂的概念。 本文档的状态 本文档已被W3C成员及其他相关方面审阅,并已被W3C总监 (W3C Director) 批准为W3C推荐标准 (W3C Recommendation) 。W3C制定推荐标准的任务是使之受到关注,并促使其被广泛应用。这将增强Web的功能性与互操作性。 本文档是W3C关于Web本体语言OWL的推荐标准的六个部分之一。 它已经被Web 本体工作小组(小组章程) 作为W3C语义Web行动 (行动声明) 的一部分于2004年2月10日发布。 本文档的早期版本中所描述的关于OWL的设计已被广泛评阅,并已满足工作小组的技术需求。工作小组充分考虑所有收到的意见,并做了必要的修改。本文档自从候选推荐标准版本以来的所有修改都在文后的变更日志中。 欢迎通过public-webont-comments@w3.org (历史存档)提出您的意见,也可以通过www-rdf-logic@w3.org (mailto:www-rdf-logic@w3.org)(历史存档) 参与相关技术的讨论。 可以访问到有关实现的一个列表。 W3C维护着一个与这些工作相关的专利声明的目录。 这节描述了本文档在发布时的状态。其他文档可能替代这文档。一份当前W3C的最新出版物的目录和这个技术报告的最新版本可以在 W3C技术报告索引http://www.w3.org/TR/ 上找到。 目录 引言 1.1. OWL的种类 1.2. 本文档的结构 本体的结构 2.1. 命名空间 2.2. 本体头部 2.3. 数据集成与隐私 基本元素 (Basic Elements) 3.1. 简单的类和个体 3.1.1. 简单的具名类 3.1.2. 个体 3.1.3. 使用方面的考虑 3.2. 简单属性 3.2.1. 定义属性 (Defining Properties) 3.2.2. 属性和数据类型 ...

Created 22226-09-22 · Updated 9096-10-09 · 9 min · 1736 words · -

HTML5 中 div section article 的区别

HTML5 中 div section article 的区别 div HTML Spec: “The div element has no special meaning at all.” 这个标签是我们见得最多、用得最多的一个标签。本身没有任何语义,用作布局以及样式化或脚本的钩子(hook)。 section HTML Spec: “The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.” 与 div 的无语义相对,简单地说 section 就是带有语义的 div 了,但是千万不要觉得真得这么简单。section 表示一段专题性的内容,一般会带有标题。看到这里,我们也许会想到,那么一篇博客文章,或者一条单独的评论岂不是正好可以用 section 吗?接着看: “Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the elemen.” ...

Created 19196-02-19 · Updated 9096-10-09 · 3 min · 539 words · -

CSS 垂直居中

css垂直居中 单行内容的居中 只考虑单行是最简单的,无论是否给容器固定高度,只要给容器设置 line-height 和 height,并使两值相等,再加上 over-flow: hidden 就可以了 [css] .middle-demo-1{ height: 4em; line-height: 4em; overflow: hidden; } [/css] 优点: 同时支持块级和内联极元素 支持所有浏览器 缺点: 只能显示一行 IE 中不支持 <img> 等的居中 要注意的是: 使用相对高度定义你的 height 和 line-height 不想毁了你的布局的话,overflow: hidden 一定要加上。 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告:代码/配置放入代码块,正文中的尖括号占位符改为行内代码;文件重命名为 css-vertical-center.md;title 改为「CSS 垂直居中」;url 改为 css-vertical-center;旧 url 加入 aliases 正文中的 HTML/XML 片段被当作原始 HTML 丢弃;文件名/URL/标题按规范调整

Created 25256-02-25 · Updated 9096-10-09 · 1 min · 60 words · -

两个 Tomcat 同时运行时修改 Tomcat 端口

当装了两个tomcat后,修改tomcat端口 http://zfsn.iteye.com/blog/669901 修改Tomcat的端口号: 在默认情况下,tomcat的端口是8080,如果出现8080端口号冲突,用如下方法可以修改Tomcat的端口号: 首先: 在Tomcat的根 (安装) 目录下,有一个conf文件夹,双击进入conf文件夹,在里面找到Server.xml文件,打开该文件。 其次: 在文件中找到如下文本: <Connector port="8080" protocol="HTTP/1.1" maxThreads="150" connectionTimeout="20000" redirectPort="8443" /> 也有可能是这样的: <Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true" /> 等等; 最后: 将 port="8080" 改为其它的就可以了。如 port="8081" 等。保存 server.xml 文件,重新启动 Tomcat 服务器,Tomcat 就可以使用 8081 端口了。 注意,有的时候要使用两个 tomcat,那么就需要修改其中的一个的端口号才能使得两个同时工作。 修改了上面的以后,还要修改两处: 将 <Connector port="8009" enableLookups="false" redirectPort="8443" debug="0" protocol="AJP/1.3" /> 的 8009 改为其它的端口。 继续将 <Server port="8005" shutdown="SHUTDOWN" debug="0"> 的 8005 改为其它的端口。 经过以上 3 个修改,应该就可以了。 8443 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告:代码/配置放入代码块,正文中的尖括号占位符改为行内代码;文件重命名为 tomcat-port.md;title 改为「两个 Tomcat 同时运行时修改 Tomcat 端口」;url 改为 tomcat-port;旧 url 加入 aliases 正文中的 HTML/XML 片段被当作原始 HTML 丢弃;文件名/URL/标题按规范调整

Created 13136-05-13 · Updated 9096-10-09 · 1 min · 97 words · -

Tomcat Port 8009 与 AJP13 协议

Tomcat Port 8009 与AJP13协议 由于tomcat的html和图片解析功能相对其他服务器如apche等较弱,所以,一般都是集成起来使用,只有jsp和servlet服务交由tomcat处理,而tomcat和其他服务器的集成,就是通过ajp协议来完成的。 AJP13(Apache JServ Protocol version 1.3)是定向包协议。因为性能原因,使用二进制格式来传输可读性文本。WEB服务器通过TCP连接和SERVLET容器连接。为了减少进程生成 socket的花费,WEB服务器和SERVLET容器之间尝试保持持久性的TCP连接,对多个请求/回复循环重用一个连接。一旦连接分配给一个特定的请 求,在请求处理循环结束之前不会在分配。换句话说,在连接上,请求不是多元的。这个是连接两端的编码变得容易,虽然这导致在一时刻会有很多连接。 一旦WEB服务器打开了一个到SERVLET容器的连接,连接处于下面的状态: ◆ 空闲 这个连接上没有处理的请求。 ◆ 已分派 连接正在处理特定的请求。 一旦一个连接被分配给一个特定的请求,在连接上发送的基本请求信息是高度压缩的。在这点,SERVLET容器大概准备开始处理请求,当它处理的时候,它能发回下面的信息给WEB服务器: ◆ SEND_HEADERS 发送一组头到浏览器。 ◆ SEND_BODY_CHUNK 发送一块主体数据到浏览器。 ◆ GET_BODY_CHUNK 从请求获得下一个数据如果还没有全部传输完,如果请求内容的包长度非常大或者长度不确定,这是非常必要的。例如上载文件。注意这和HTTP的块传输没有关联。 ◆ END_RESPONSE 结束请求处理循环。 Tomcat服务器通过Connector连接器组件与客户程序建立连接,Connector组件负责接收客户的请求,以及把Tomcat服务器的响应结果发送给客户。默认情况下,Tomcat在server.xml中配置了两种连接器: <!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 --> <Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true" /> <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 --> <Connector port="8009" enableLookups="false" redirectPort="8443" debug="0" protocol="AJP/1.3" /> 第一个连接器监听8080端口,负责建立HTTP连接。在通过浏览器访问Tomcat服务器的Web应用时,使用的就是这个连接器。 第二个连接器监听8009端口,负责和其他的HTTP服务器建立连接。在把Tomcat与其他HTTP服务器集成时,就需要用到这个连接器。 Web客户1直接访问Tomcat服务器上的JSP组件,他访问的URL为http://localhost:8080 /index.jsp。Web客户2通过HTTP服务器访问Tomcat服务器上的JSP组件。假定HTTP服务器使用的HTTP端口为默认的80端口, 那么Web客户2访问的URL为http://localhost:80/index.jsp 或者 http://localhost/index.jsp。 摘自: http://hikin.iteye.com/blog/555682 2.http://bbs.163jsp.com/posts/list/472.html http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告:代码/配置放入代码块,正文中的尖括号占位符改为行内代码;文件重命名为 tomcat-ajp13.md;title 改为「Tomcat Port 8009 与 AJP13 协议」;url 改为 tomcat-ajp13;旧 url 加入 aliases 正文中的 HTML/XML 片段被当作原始 HTML 丢弃;文件名/URL/标题按规范调整

Created 13136-05-13 · Updated 9096-10-09 · 1 min · 113 words · -

tomcat server.xml

tomcat server.xml http://www.importnew.com/26156.html Tomcat隶属于Apache基金会,是开源的轻量级Web应用服务器,使用非常广泛。server.xml是Tomcat中最重要的配置文件,server.xml的每一个元素都对应了Tomcat中的一个组件;通过对xml文件中元素的配置,可以实现对Tomcat中各个组件的控制。因此,学习server.xml文件的配置,对于了解和使用Tomcat至关重要。 本文将通过实例,介绍server.xml中各个组件的配置,并详细说明Tomcat各个核心组件的作用以及各个组件之间的相互关系。 说明: 由于server.xml文件中元素与Tomcat中组件的对应关系,后文中为了描述方便,“元素"和"组件"的使用不严格区分。 一、一个server.xml配置实例 server.xml位于$TOMCAT_HOME/conf目录下;下面是一个server.xml实例。后文中将结合该实例讲解server.xml中,各个元素的含义和作用;在阅读后续章节过程中,可以对照该xml文档便于理解。 <Server port="8005" shutdown="SHUTDOWN"> <GlobalNamingResources> <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> </GlobalNamingResources> <Service name="Catalina"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> <Engine name="Catalina" defaultHost="localhost"> <Realm className="org.apache.catalina.realm.LockOutRealm"> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> </Realm> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b" /> </Host> </Engine> </Service> </Server> 二、server.xml文档的元素分类和整体结构 整体结构 server.xml的整体结构如下: <Server> <Service> <Connector /> <Connector /> <Engine> <Host> <Context /><!-- 现在常常使用自动部署,不推荐配置Context元素,Context小节有详细说明 --> </Host> </Engine> </Service> </Server> 该结构中只给出了Tomcat的核心组件,除了核心组件外,Tomcat还有一些其他组件,下面介绍一下组件的分类。 元素分类 server.xml文件中的元素可以分为以下4类: (1) 顶层元素: <Server>和<Service> <Server>元素是整个配置文件的根元素,<Service>元素则代表一个Engine元素以及一组与之相连的Connector元素。 (2) 连接器: <Connector> <Connector>代表了外部客户端发送请求到特定Service的接口;同时也是外部客户端从特定Service接收响应的接口。 (3) 容器: <Engine><Host><Context> ...

Created 2026-06-02 · Updated 9096-10-09 · 3 min · 536 words · -

Java web 乱码

Java web 乱码 http://www.jb51.net/web/12714.html (一) get提交 1.首先说下客户端 (浏览器) 的form表单用get方法是如何将数据编码后提交给服务器端的吧。 对于get方法来说,都是把数据串联在请求的url后面作为参数,如: http://localhost:8080/servlet?msg=abc (很常见的一个乱码问题就要出现了,如果url中出现中文或其它特殊字符的话,如: http://localhost:8080 /servlet?msg=杭州,服务器端容易得到乱码) ,url拼接完成后,浏览器会对url进行URL encode,然后发送给服务器,URL encode的过程就是把部分url做为字符,按照某种编码方式 (如: utf-8,gbk等) 编码成二进制的字节码,然后每个字节用一个包含3个字符的字符串 “%xy” 表示,其中xy为该字节的两位十六进制表示形式。我这里说的可能不清楚,具体介绍可以看下java.net.URLEncoder。了解了 URL encode的过程,我们能看到2个很重要的问题,第一: 需要URL encode的字符一般都是非ASCII的字符 (笼统的讲) ,再通俗的讲就是除了英文字母以外的文字 (如: 中文,日文等) 都要进行URL encode,所以对于我们来说,都是英文字母的url不会出现服务器得到乱码问题,出现乱码都是url里面带了中文或特殊字符造成的;第二: URL encode到底按照那种编码方式对字符编码?这里就是浏览器的事情了,而且不同的浏览器有不同的做法,中文版的浏览器一般会默认的使用GBK,通过设置浏览器也可以使用UTF-8,可能不同的用户就有不同的浏览器设置,也就造成不同的编码方式,所以很多网站的做法都是先把url里面的中文或特殊字符用 javascript做URL encode,然后再拼接url提交数据,也就是替浏览器做了URL encode,好处就是网站可以统一get方法提交数据的编码方式。 完成了URL encode,那么现在的url就成了ASCII范围内的字符了,然后以iso-8859-1的编码方式转换成二进制随着请求头一起发送出去。这里想多说几句的是,对于get方法来说,没有请求实体,含有数据的url都在请求头里面,之所以用URL encode,我个人觉的原因是: 对于请求头来说最终都是要用iso-8859-1编码方式编码成二进制的101010…..的纯数据在互联网上传送,如果直接将含有中文等特殊字符做iso-8859-1编码会丢失信息,所以先做URL encode是有必要的。 2。服务器端 (tomcat) 是如何将数据获取到进行解码的。 第一步是先把数据用iso-8859-1进行解码,对于get方法来说,tomcat获取数据的是ASCII范围内的请求头字符,其中的请求url里面带有参数数据,如果参数中有中文等特殊字符,那么目前还是URL encode后的%XY状态,先停下,我们先说下开发人员一般获取数据的过程。通常大家都是request.getParameter(“name”)获取参数数据,我们在request对象获得的数据都是经过解码过的,而解码过程中程序里是无法指定,这里要说下,有很多新手说用 request.setCharacterEncoding(“字符集”)可以指定解码方式,其实是不可以的,看servlet的官方API说明有对此方法的解释: Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader().可以看出对于get方法他是无能为力的。那么到底用什么编码方式解码数据的呢,这是tomcat的事情了,默认缺省用的是 iso-8859-1,这样我们就能找到为什么get请求带中文参数为什么在服务器端得到乱码了,原因是在客户端一般都是用UTF-8或GBK对数据 URL encode,这里用iso-8859-1方式URL decoder显然不行,在程序里我们可以直接 ...

Created 3036-06-03 · Updated 9096-10-09 · 1 min · 151 words · -

从 HTTP GET 和 POST 的区别说起

从 HTTP GET 和 POST 的区别说起 HTTP 定义了与服务器交互的不同方法,最基本的方法是 GET 和 POST. 面试时得到的回答大多是: POST 是安全的,因为被提交的数据看不到,或者被加密的,其它的还有 GET 的时候中文出现乱码 (在地址栏里) ,数据最大长度限制等等。 说 POST 比 GET 安全肯定是错的,POST 跟 GET 都是明文传输,用httpfox等插件,或者像WireShark 等类似工具就能观察到。 POST 和 GET 的差别其实是很大的。语义上,GET 是获取指定URL上的资源,是读操作,重要的一点是不论对某个资源 GET 多少次,它的状态是不会改变的, 在这个意义上,我们说 GET 是安全的 (不是被密码学或者数据保护意义上的安全) 。因为 GET 是安全的,所以 GET 返回的内容可以被浏览器, Cache 服务器缓存起来 (其中还有很多细节,但不影响这里的讨论) 。 而 POST 的语意是对指定资源"追加/添加"数据,所以是不安全的,每次提交的 POST,参与的代码都会认为这个操作会修改操作对象资源的状态, 于是,浏览器在你按下 F5 的时候会跳出确认框,缓存服务器不会缓存 POST 请求返回内容。 很遗憾到目前为止没有应聘者能够提到这一点。我猜测这背后的原因大概有两个,一是也许大多数人往往 (我也一样) 满足于只要完成任务就好,不管用哪个, 表单提交了,数据处理了,内容显示或者重新定向到另外一个页面,就算完成了一个任务,从任务表里划掉,结束。 而且对大部分项目(OA, CRM, MIS)的大部分情况下,用哪个似乎都可以。 同时,在被商业机构在媒体和书籍上宣传兜售的 WS-* 概念和使用集成开发环境提供的"方便"的代码生成工具后,“了解"到所有 Web 服务调用都是通过 POST, 更潜意识里确定了 POST 和 GET 是一样的,而且 GET 能做的,POST 都能做,POST 简直就是 GET++ 嘛。 自然,能用 POST 就用 POST,不必在乎两者的差别了。 ...

Created 3036-06-03 · Updated 9096-10-09 · 4 min · 790 words · -

MIME

MIME 媒体类型, 用途互联网邮件扩展 (MIME,Multipurpose Internet Mail Extensions) 是一个互联网标准, 它扩展了电子邮件标准,使其能够支持非ASCII字符、二进制格式附件等多种格式的邮件消息。HTTP协议中也使用了MIME的框架。MIME是通过标准化电子邮件报文的头部的附加域 (fields) 而实现的;这些头部的附加域,描述新的报文类型的内容和组织形式。 内容类型 (Content-Type) ,这个头部领域用于指定消息的类型。一般以下面的形式出现。 type有下面的形式。 Text: 用于标准化地表示的文本信息,文本消息可以是多种字符集和或者多种格式的; Multipart: 用于连接消息体的多个部分构成一个消息,这些部分可以是不同类型的数据; Application: 用于传输应用程序数据或者二进制数据; Message: 用于包装一个E-mail消息; Image: 用于传输静态图片数据; Audio: 用于传输音频或者音声数据; Video: 用于传输动态影像数据,可以是与音频编辑在一起的视频数据格式。 subtype 用于指定 type 的详细形式。 text/plain (纯文本) text/html (HTML文档) application/xhtml+xml (XHTML文档) image/gif (GIF图像) image/jpeg (JPEG图像) 【PHP中为: image/pjpeg】 image/png (PNG图像) 【PHP中为: image/x-png】 video/mpeg (MPEG动画) application/octet-stream (任意的二进制数据) application/pdf (PDF文档) application/msword (Microsoft Word文件) message/rfc822 (RFC 822形式) multipart/alternative (HTML邮件的HTML形式和纯文本形式,相同内容使用不同形式表示) application/x-www-form-urlencoded (使用HTTP的POST方法提交的表单) multipart/form-data (同上,但主要用于表单提交时伴随文件上传的场合) parameter可以用来指定附加的信息,更多情况下是用于指定text/plain和text/htm等的文字编码方式的charset参数。MIME根据type制定了默认的subtype,当客户端不能确定消息的subtype的情况下,消息被看作默认的subtype进行处理。Text默认是text/plain,Application默认是application/octet-stream而Multipart默认情况下被看作multipart/mixed。 内容传输编码 内容传输编码 (Content-Transfer-Encoding) ,这个区域使指定ASCII以外的字符编码方式成为可能。形式如下: ...

Created 3036-06-03 · Updated 9096-10-09 · 2 min · 263 words · -

web.xml

web.xml web.xml template servlet 2.5 <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> web.xml 3.0: http://www.wiloon.com/?p=3484 <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1" metadata-complete="false"> <display-name>Servlet 3.x Demo</display-name> <description>A demo for servlet 3.x</description> <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>com.wiloon.test.servlet.HelloWorld</servlet-class> </servlet> <servlet-mapping> <servlet-name>HelloWorld</servlet-name> <url-pattern>/servlet/HelloWorld</url-pattern> </servlet-mapping> </web-app> web.xml是传统的部署描述文件。 servlet 3.x 中web.xml 变为可选配置. ...

Created 10106-06-10 · Updated 9096-10-09 · 6 min · 1226 words · -

web.xml mime-mapping

web.xml – mime-mapping 关联文件与MIME类型 服务器一般都具有一种让Web站点管理员将文件扩展名与媒体相关联的方法。例如,将会自动给予名为mom.jpg的文件一个image/jpeg的MIME 类型。但是,假如你的Web应用具有几个不寻常的文件,你希望保证它们在发送到客户机时分配为某种MIME类型。mime-mapping元素 (具有 extension和mime-type子元素) 可提供这种保证。例如,下面的代码指示服务器将application/x-fubar的MIME类型分配给所有以.foo结尾的文件。 <mime-mapping> <extension>foo</extension> <mime-type>application/x-fubar</mime-type> </mime-mapping> 或许,你的Web应用希望重载 (override) 标准的映射。例如,下面的代码将告诉服务器在发送到客户机时指定.ps文件作为纯文本 (text/plain) 而不是作为PostScript (application/postscript) 。 <mime-mapping> <extension>ps</extension> <mime-type>application/postscript</mime-type> </mime-mapping> TOMCAT在默认情况下下载.rar的文件是把文件当作text打开,以至于IE打开RAR文件为乱码,如果遇到这种情况时不必认为是浏览器的问题,大多数浏览器应该不会死皮赖脸地把二进制文件当作文本打开,一般都是服务器给什么浏览器就开什么.解决方法: 打开conf/web.xml,加入下面的代码. <mime-mapping> <extension>doc</extension> <mime-type>application/msword</mime-type> </mime-mapping> <mime-mapping> <extension>xls</extension> <mime-type>application/msexcel</mime-type> </mime-mapping> <mime-mapping> <extension>pdf</extension> <mime-type>application/pdf</mime-type> </mime-mapping> <mime-mapping> <extension>zip</extension> <mime-type>application/zip</mime-type> </mime-mapping> <mime-mapping> <extension>rar</extension> <mime-type>application/rar</mime-type> </mime-mapping> <mime-mapping> <extension>txt</extension> <mime-type>application/txt</mime-type> </mime-mapping> <mime-mapping> <extension>chm</extension> <mime-type>application/mshelp</mime-type> </mime-mapping> <mime-mapping> <extension>mp3</extension> <mime-type>audio/x-mpeg</mime-type> </mime-mapping> 重启TOMCAT,清除IE缓存,再打开RAR的文件时就可以正常下载了. 常见的MIME类型 超文本标记语言文本 .htm,.html text/html 普通文本 .txt text/plain RTF文本 .rtf application/rtf GIF图形 .gif image/gif ...

Created 10106-06-10 · Updated 9096-10-09 · 1 min · 115 words · -

servlet3.0

servlet3.0 http://www.ibm.com/developerworks/cn/java/j-lo-servlet30/ Servlet 3.0 作为 Java EE 6 规范体系中一员,随着 Java EE 6 规范一起发布。该版本在前一版本 (Servlet 2.5) 的基础上提供了若干新特性用于简化 Web 应用的开发和部署。其中有几项特性的引入让开发者感到非常兴奋,同时也获得了 Java 社区的一片赞誉之声: 异步处理支持: 有了该特性,Servlet 线程不再需要一直阻塞,直到业务处理完毕才能再输出响应,最后才结束该 Servlet 线程。在接收到请求之后,Servlet 线程可以将耗时的操作委派给另一个线程来完成,自己在不生成响应的情况下返回至容器。针对业务处理较耗时的情况,这将大大减少服务器资源的占用,并且提高并发处理速度。 新增的注解支持: 该版本新增了若干注解,用于简化 Servlet、过滤器 (Filter) 和监听器 (Listener) 的声明,这使得 web.xml 部署描述文件从该版本开始不再是必选的了。 可插性支持: 熟悉 Struts2 的开发者一定会对其通过插件的方式与包括 Spring 在内的各种常用框架的整合特性记忆犹新。将相应的插件封装成 JAR 包并放在类路径下,Struts2 运行时便能自动加载这些插件。现在 Servlet 3.0 提供了类似的特性,开发者可以通过插件的方式很方便的扩充已有 Web 应用的功能,而不需要修改原有的应用。 新增的注解支持 Servlet 3.0 的部署描述文件 web.xml 的顶层标签 <web-app> 有一个 metadata-complete 属性,该属性指定当前的部署描述文件是否是完全的。如果设置为 true,则容器在部署时将只依赖部署描述文件,忽略所有的注解 (同时也会跳过 web-fragment.xml 的扫描,亦即禁用可插性支持,具体请看后文关于 可插性支持的讲解) ;如果不配置该属性,或者将其设置为 false,则表示启用注解支持 (和可插性支持) 。 @WebServlet @WebServlet 用于将一个类声明为 Servlet,该注解将会在部署时被容器处理,容器将根据具体的属性配置将相应的类部署为 Servlet。该注解具有下表给出的一些常用属性 (以下所有属性均为可选属性,但是 vlaue 或者 urlPatterns 通常是必需的,且二者不能共存,如果同时指定,通常是忽略 value 的取值) : ...

Created 10106-06-10 · Updated 9096-10-09 · 2 min · 405 words · -

context-param 与 init-param

‘context-param&init-param’ <context-param>的作用: web.xml的配置中<context-param>配置作用 1. 启动一个WEB项目的时候,容器(如:Tomcat)会去读它的配置文件web.xml.读两个节点: </listener> 和 <context-param></context-param> 2.紧接着,容器创建一个ServletContext(上下文),这个WEB项目所有部分都将共享这个上下文. 3.容器将<context-param></context-param>转化为键值对,并交给ServletContext. 4.容器创建</listener>中的类实例,即创建监听. 5.在监听中会有contextInitialized(ServletContextEvent args)初始化方法,在这个方法中获得ServletContext = ServletContextEvent.getServletContext(); context-param的值 = ServletContext.getInitParameter(“context-param的键”); 6.得到这个context-param的值之后,你就可以做一些操作了.注意,这个时候你的WEB项目还没有完全启动完成.这个动作会比所有的Servlet都要早. 换句话说,这个时候,你对<context-param>中的键值做的操作,将在你的WEB项目完全启动之前被执行. 7.举例.你可能想在项目启动之前就打开数据库. 那么这里就可以在<context-param>中设置数据库的连接方式,在监听类中初始化数据库的连接. 8.这个监听是自己写的一个类,除了初始化方法,它还有销毁方法.用于关闭应用前释放资源.比如说数据库连接的关闭. web.xml里面可以定义两种参数: (1)application范围内的参数,存放在servletcontext中,在web.xml中配置如下: <context-param> <param-name>context/param</param-name> <param-value>avalible during application</param-value> </context-param> <context-param> <param-name>cpn</param-name> <param-value>cpv</param-value> </context-param> (2)servlet范围内的参数,只能在servlet的init()方法中取得,在web.xml中配置如下: <servlet> <servlet-name>MainServlet</servlet-name> <servlet-class>com.wes.controller.MainServlet</servlet-class> <init-param> <param-name>param1</param-name> <param-value>avalible in servlet init()</param-value> </init-param> <load-on-startup>0</load-on-startup> </servlet> 在servlet中可以通过代码分别取用: package com.wes.controller; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; public class MainServlet extends HttpServlet { public MainServlet() { super(); } public void init() throws ServletException { System.out.println("下面的两个参数param1是在servlet中存放的"); System.out.println(this.getInitParameter("param1")); System.out.println("下面的参数是存放在servletcontext中的"); System.out.println(getServletContext().getInitParameter("context/param")); } } 第一种参数在servlet里面可以通过getServletContext().getInitParameter(“context/param”)得到 ...

Created 10106-06-10 · Updated 9096-10-09 · 1 min · 101 words · -

Servlet Filter

Servlet Filter @Servlet里的过滤器的主要作用 1,判断用户是否登录。 2,网络聊天系统或论坛,功能是过滤非法文字 3,统一解决编码 @Servlet3.0之前怎么创建一个过滤器 1,生成一个普通的class类,实现Filter接口(javax.servlet.Filter)。 2,重写接口里面的三个方法: init,doFilter,destroy。 其中的doFilter方法的第一个参数为ServletRequest对象。此对象给过滤器提供了对进入的信息 (包括表单数据、cookie和HTTP请求头) 的完全访问。第二个参数为ServletResponse,通常在简单的过滤器中忽略此参数。最后一个参数为FilterChain,此参数用来调用servlet或JSP页。 3,然后在web.xml配置过滤器。 具体例子:1.首先写一个权限过滤filter类,实现Filter接口 import javax.servlet.Filter; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.FilterChain; import java.io.IOException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpSession; import javax.servlet.http.HttpServletResponse; public class RightFilter implements Filter { public void init(FilterConfig filterConfig) throws ServletException { } public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; //如果处理HTTP请求,并且需要访问诸如getHeader或getCookies等在ServletRequest中无法得到的方法 //就要把此request对象构造成HttpServletRequest HttpServletResponse res = (HttpServletResponse) response; HttpSession session = req.getSession(true); //从session里取的用户名信息 String username = (String) session.getAttribute("username"); //判断如果没有取到用户信息,就跳转到登陆页面 if (username == null || "".equals(username)) { //跳转到登陆页面 res.sendRedirect("http://"+req.getHeader("Host")+"/login.jsp"); } else { //已经登陆,继续此次请求 chain.doFilter(request,response); //调用FilterChain对象的doFilter方法 //Filter接口的doFilter方法取一个FilterChain对象作为它的一个参数 //在调用此对象的doFilter方法时,激活下一个相关的过滤器 //如果没有另一个过滤器与servlet或JSP页面关联,则servlet或JSP页面被激活 } } public void destroy() { } } 2.然后在web.xml里配置需要登陆权限验证的JSP文件: ...

Created 10106-06-10 · Updated 9096-10-09 · 5 min · 1056 words · -

web service

web service http://www.cnblogs.com/hanlsheng/archive/2011/01/20/1940367.html 第一章 设计一个简单的web service接口 本章主要内容: 你将学会如何设计一个简单的web service接口 穿越网络提供跨平台操作 假设你想为大众或者业务伙伴提供一种这样的服务: 他们向你发送两个字符串,你把两个字符串进行连接,然后返回给他们。当然在现实世界中,你将提供一些更有用更复杂的服务。 此服务有几个必须满足的需求: 首先,用户可以使用不同的语言( 比如Java,C# 等)以及不同的平台( Windows,Linux等)。你提供的服务对于不同的语言和平台必须是可以访问的。第二,用户可以通过网络对你的服务进行访问。而且必须能够穿越防火墙。 给定了以上需求,最佳的解决方案是提供一个所谓的"web service"。比如,你可以在主机( www.ttdev.com)上提供可访问的web service( 通过/SimpleService 访问,见下图),所以URL全称是: http: www.ttdev.com/SimpleService. 这被称为web service的"endpoint"( 终端,端点)。web service 可以支持一个或者多个操作。在这个例子中,一个操作被命名为"concat": 然而,你希望为你的每一个web service 操作提供全球唯一标识,这样别人也可以拥有名称为"concat"的操作。如何实现呢?很简单,你可以在名称"concat"前面声明一个"namespace"( 命名空间,比如http: ttdev.com/ss). namespace( 命名空间)的作用同java 中包的作用非常类似,只是表示形式不用而已,包的表示形式为 com.ttdev.foo。全球唯一标识是由namespace和操作名称组成的。Operation(操作)的名称,比如"concat"被称为local name( 本地名称)。全球唯一标识被称为QName( qualified name)。 你可能想知道命名空间(如http: ttdev.com/ss)有什么含义。答案是:没有什么特别的含义。即使这个命名空间是一个URL,但不意味着你能通过浏览器进行访问会获得一个可访问页面。对你来说唯一重要的一点是,这个标识是全球唯一的。因为我已经注册了这个域名ttdev.com,所以它一定是全球唯一的。 值得注意的一点是, namespace (命名空间)与endpoint(终端,端点)是完全不同的概念。endpoint是真实的服务提供地点,而namespace仅仅是一个唯一标识符号。我可以轻易的把服务部署在另外的服务器上,这样web service将会有不同的 endpoint,但是 web service的操作唯一标识( 命名空间+本地名称)可以保持不变。 2.RPC 类型的web service 你的concat 操作将包含两个参数。一个名称为"s1"为string 类型。另一个名称为"s2"同样是string类型。返回值同样是一个string类型: 然而,上图中的string 类型是什么含义呢?是Java的 string类型吗?不是,因为它必须是语言中立的。幸运的是,XML schema spec 定义了一些基本的数据类型,其中包括string类型。每一个数据类型都有一个QName 作为其id。比如: 所以操作的接口可以如下表示: ...

Created 17176-06-17 · Updated 9096-10-09 · 2 min · 327 words · -