自己编写一个类，来覆盖ActionServlet中的RequestProcessor方法。大致的意思就是说当使用到RequestProcessor方法时，并不是使用ActionServlet中提供的方法，而是使用我们自己定义的方法（其实是废话！呵呵！），提供代码如下：

package tool;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.RequestProcessor;

public class MyRequestProcessor extends RequestProcessor {
	protected boolean processPreprocess(HttpServletRequest request,
			HttpServletResponse response) {
		try {
			request.setCharacterEncoding("UTF-8");
		} catch (Exception e) {
			System.out.println("set character failed！");
		}
		return true;
	}
}

很简单的几行代码。
还需要在struts-config.xml中设置一下。

这个配置的位置必须要放正确，使用过struts的人都知道的。放在之后，之前。否则是不正确的。
这样就可以实现从表单提交至actionForm的改成中文编码，而不会是乱码。

您可能也喜欢：

SSI(Struts,Spring,Ibatis)整合总结

详解Spring+Struts2整合步骤

Struts2 Action中获取Request Session Application的方法

Struts+hibernate实现分页

无觅

有效的对网站进行SEO优化是一件必要的事情，当然网站的架构也要随着时间的变化而变动，因为有些网页中继标记很可能已经被淘汰，如果不更新，很可能让网站获得一个不好的排名，结果可能会跟我们之前提到的Meta Keywords有一样的问题。那么我们该注意哪些网页标签呢？通常来讲，以title（标题）最为重要，再来就是description（描述），这两个影响了搜索引擎也影响了使用者的浏览判断依据。

不论是Yahoo、Google或者是Bing，绝大多数的搜索引擎都会在意title和description的属性，因为这两个元标记就是会最直接的呈现在搜索结果的页面之中，好的标题搭配好的描述，会直接影响搜索者要不要浏览这个网页的判断依据，如果要好的排名，那麽好的内容、好的标题、优化过的网站，会影响搜索引擎的排序结果。一般来讲，title标记影响了搜索结果标题，description直接影响搜索结果描述。

想要优化网站，让Google看得懂，那么别忘了根据Google在网站管理员说明中提到的资讯，将以下标记适当的加入网站，打造一个友善于Google搜索的网站。（参考资料：Google网站管理员工具说明-元标记）

title 网页标题

<title>网页标题</title>

相信这标籤应该是每一个网页都会加入的标记，如果没有加入，网页标题肯定是很奇怪的。通常会忽视网页标题的网页应该只有传统的Frontpage或是框架网页了。早期网页都是纯静态网页居多，大多数人都以网页可以看的方向制作网页，却往往忽略了这项关键因素。如果网页有缺title，别忘了补回去啊！

description 网页说明

<meta name=”description” content=”网页说明” />

如同前面所提到，网页的描述直接影响了搜索结果上的文字，基本上目前的Google、Bing（Yahoo）都有採计这一项标记，有效的引言可以吸引访客直接浏览你的网站。字数不宜过多，但是要精准命中。

Content-Type 网页编码

<meta http-equiv=”Content-Type” content=”….; charset=…” />

不论网站是否有好于Google或是哪个搜索引擎，这个标签一定要加入，如果不加入很容易让浏览器使用预设语系去判断网页，容易造成乱码问题。补充，乱码问题还可能是网页档桉没有正确地调整到UTF-8编码才造成的问题。

robots 元标记

<meta name=”robots” content=”…, …” />

<meta name=”googlebot” content=”…, …”/>

这个元标记主要是针对搜索引擎收录的一些规则，不过对于暴力搜索百度来讲应该是没有用的。对于正规的搜索引擎来讲，这些标记基本上都是被承认的。上面的「…」可以替换成以下标记。

1.noindex：阻止搜索引擎为网页建立索引。

2.nofollow：阻止 Googlebot 使用此网页上的连结。

3.nosnippet：阻止在搜索结果中显示某些文字片段。

4.noodp：阻止使用来自 ODP/DMOZ 的替代说明。

5.noarchive：阻止 Google 显示网页的快照链接。

6.unavailable_after：［date］：用来指定想要停止检索网页及建立网页索引的时间和日期。

4.noimageindex：用来指定不让 Google 图片搜索结果推荐您的网页。

用canonical标签取代noindex（排除网页重复）

在Google说明上提到，如果你要使用noindex标签来禁止网页搜索是可以的，但是如果要使用noindex来避免网页重複收录的问题是不建议的。那该怎么解决避免网页重复收录的问题呢？Google建议大家可以改用canonical标签进行处理，另外也可以调整搜索频率来避免重複搜索网站内容造成流量异常。

如果网站内容如果发生重复收录，Google表示若网站不是试图欺骗或者是操控搜索结果者，都不用担心Google对于网站的检索频率降低。但是，若网站内容因为重复而造成排名下降，又没有根据建议进行网站的修正，Google会自行选择搜索结果中显示的版本。所以大家要稍稍住一下这部分的问题咯！

notranslate 不要提供翻译

<meta name=”google” content=”notranslate” />

在Google搜索上，如果搜索结果出现了外国网页，大部分都会出现「翻译这个网页」的选项，点进去会自动帮你将内容翻译成您在使用的文字、语言，如果您不希望Gogole直接帮您网站提供这样的功能，可以在meta加入这个标签，就可以停用这样的功能了。平常我们搜索如果找自己网站可能不会发现这样的东西，主要是对外国人比较有用。

google-site-verification Google验证

<meta name=”google-site-verification” content=”…” />

这个验证的标记，主要是针对Google服务的验证，像是Google网站管理员、Google分析、Google应用服务等，都需要这个标记来验证网站是否属于您的。当然，验证的时候不定要是这样的标记，它也提供HTML档桉的验证，因为我觉得meta加入太多东西不太好，所以是采用HTML验证的。

refresh 网页导向

<meta http-equiv=”refresh” content=”…;url=…” />

这个标签在Google说明上说不一定支援每一种浏览器，不过这种标签最常使用来网页导向，在很久以前的网站导向文章中也有使用这方法，在换网址之前也有使用这种方式去导向网页，从根目录导向到网站子目录。但W3C并不建议这样的导向方式，因为容易造成混淆。还有一个问题就是有些刷SEO的网站会使用这种方式来处理，因此很容易被搜索引擎误判。建议采用301导向来解决网页导向问题。

您可能也喜欢：

HTML5本地存储方案介绍

HTML颜色代码表

Servlet的生命周期

青花瓷JAVA版，周杰伦告诉你怎么学Java

无觅

无法找到 Web 站点
HTTP 404- 无法找到文件
HTTP 405 – 资源被禁止
HTTP 406 – 无法接受
HTTP 407 – 要求代理身份验证
HTTP 410 – 永远不可用
HTTP 412 – 先决条件失败
HTTP 414 – 请求 – URI 太长

HTTP 500 – 内部服务器错误
HTTP 500.100 – 内部服务器错误 – ASP 错误
HTTP 500-11 服务器关闭
HTTP 500-12 应用程序重新启动
HTTP 500-13 – 服务器太忙
HTTP 500-14 – 应用程序无效
HTTP 500-15 – 不允许请求 global.asa
Error 501 – 未实现
HTTP 502 – 网关错误

用户试图通过 HTTP 或文件传输协议 (FTP) 访问一台正在运行 Internet 信息服务 (IIS) 的服务器上的内容时，IIS 返回一个表示该请求的状态的数字代码。该状态代码记录在 IIS 日志中，同时也可能在 Web 浏览器或 FTP 客户端显示。状态代码可以指明具体请求是否已成功，还可以揭示请求失败的确切原因。
日志文件的位置
在默认状态下，IIS 把它的日志文件放在 %WINDIRSystem32Logfiles 文件夹中。每个万维网 (WWW) 站点和 FTP 站点在该目录下都有一个单独的目录。在默认状态下，每天都会在这些目录下创建日志文件，并用日期给日志文件命名（例如，exYYMMDD.log）。
HTTP
1xx – 信息提示

这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。 100 – 继续。
101 – 切换协议。
2xx – 成功

这类状态代码表明服务器成功地接受了客户端请求。
200 – 确定。客户端请求已成功。
201 – 已创建。
202 – 已接受。
203 – 非权威性信息。
204 – 无内容。
205 – 重置内容。
206 – 部分内容。
3xx – 重定向

客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。
302 – 对象已移动。
304 – 未修改。
307 – 临时重定向。
4xx – 客户端错误

发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。 400 – 错误的请求。
401 – 访问被拒绝。IIS 定义了许多不同的
401 错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示：
401.1 – 登录失败。
401.2 – 服务器配置导致登录失败。
401.3 – 由于 ACL 对资源的限制而未获得授权。
401.4 – 筛选器授权失败。
401.5 – ISAPI/CGI 应用程序授权失败。
401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。

403 – 禁止访问：IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因：

403.1 – 执行访问被禁止。
403.2 – 读访问被禁止。
403.3 – 写访问被禁止。
403.4 – 要求 SSL。
403.5 – 要求 SSL 128。
403.6 – IP 地址被拒绝。
403.7 – 要求客户端证书。
403.8 – 站点访问被拒绝。
403.9 – 用户数过多。
403.10 – 配置无效。
403.11 – 密码更改。
403.12 – 拒绝访问映射表。
403.13 – 客户端证书被吊销。
403.14 – 拒绝目录列表。
403.15 – 超出客户端访问许可。
403.16 – 客户端证书不受信任或无效。
403.17 – 客户端证书已过期或尚未生效。
403.18 – 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
403.19 – 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
403.20 – Passport 登录失败。这个错误代码为 IIS 6.0 所专用。

404 – 未找到。 404.0 -（无） – 没有找到文件或目录。
404.1 – 无法在所请求的端口上访问 Web 站点。
404.2 – Web 服务扩展锁定策略阻止本请求。
404.3 – MIME 映射策略阻止本请求。

405 – 用来访问本页面的 HTTP 谓词不被允许（方法不被允许）
406 – 客户端浏览器不接受所请求页面的 MIME 类型。
407 – 要求进行代理身份验证。
412 – 前提条件失败。
413 – 请求实体太大。
414 – 请求 URI 太长。
415 – 不支持的媒体类型。
416 – 所请求的范围无法满足。
417 – 执行失败。
423 – 锁定的错误。
5xx – 服务器错误

服务器由于遇到错误而不能完成该请求。
500 – 内部服务器错误。
500.12 – 应用程序正忙于在 Web 服务器上重新启动。
500.13 – Web 服务器太忙。
500.15 – 不允许直接请求 Global.asa。
500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
500.100 – 内部 ASP 错误。

501 – 页眉值指定了未实现的配置。
502 – Web 服务器用作网关或代理服务器时收到了无效响应。
502.1 – CGI 应用程序超时。
502.2 – CGI 应用程序出错。application.

503 – 服务不可用。这个错误代码为 IIS 6.0 所专用。
504 – 网关超时。
505 – HTTP 版本不受支持。

常见的 HTTP 状态代码及其原因
200 – 成功。 此状态代码表示 IIS 已成功处理请求。
304 – 未修改。客户端请求的文档已在其缓存中，文档自缓存以来尚未被修改过。客户端使用文档的缓存副本，而不从服务器下载文档。
401.1 – 登录失败。 登录尝试不成功，可能因为用户名或密码无效。
401.3 – 由于 ACL 对资源的限制而未获得授权。 这表示存在 NTFS 权限问题。即使您对试图访问的文件具备相应的权限，也可能发生此错误。例如，如果 IUSR 帐户无权访问 C:WinntSystem32Inetsrv 目录，您会看到这个错误。 有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
187506 INFO: IIS 4.0 的基础 NTFS 权限
403.1 – 执行访问被禁止。 下面是导致此错误信息的两个常见原因： 您没有足够的执行许可。例如，如果试图访问的 ASP 页所在的目录权限设为“无”，或者，试图执行的 CGI 脚本所在的目录权限为“只允许脚本”，将出现此错误信息。若要修改执行权限，请在 Microsoft 管理控制台 (MMC) 中右击目录，然后依次单击属性和目录选项卡，确保为试图访问的内容设置适当的执行权限。
您没有将试图执行的文件类型的脚本映射设置为识别所使用的谓词（例如，GET 或 POST）。若要验证这一点，请在 MMC 中右击目录，依次单击属性、目录选项卡和配置，然后验证相应文件类型的脚本映射是否设置为允许所使用的谓词。

403.2 – 读访问被禁止。验证是否已将 IIS 设置为允许对目录进行读访问。另外，如果您正在使用默认文件，请验证该文件是否存在。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
247677 错误信息：403.2 Forbidden:Read Access Forbidden（403.2 禁止访问：读访问被禁止）
403.3 – 写访问被禁止。 验证 IIS 权限和 NTFS 权限是否已设置以便向该目录授予写访问权。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
248072 错误信息：403.3 Forbidden:Write Access Forbidden（403.3 禁止访问：写访问被禁止）
403.4 – 要求 SSL。禁用要求安全通道选项，或使用 HTTPS 代替 HTTP 来访问该页面。如果没有安装证书的 Web 站点出现此错误，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
224389 错误信息：HTTP 错误 403、403.4、403.5 禁止访问：要求 SSL
403.5 – 要求 SSL 128。禁用要求 128 位加密选项，或使用支持 128 位加密的浏览器以查看该页面。如果没有安装证书的 Web 站点出现此错误，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
224389 错误信息：HTTP 错误 403、403.4、403.5 禁止访问：要求 SSL
403.6 – IP 地址被拒绝。您已把您的服务器配置为拒绝访问您目前的 IP 地址。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
248043 错误信息：403.6 – Forbidden:IP Address Rejected（403.6 – 不可用：IP 地址被拒绝）
403.7 – 要求客户端证书。您已把您的服务器配置为要求客户端身份验证证书，但您未安装有效的客户端证书。有关其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
190004 错误 403.7 或“Connection to Server Could Not Be Established”（无法建立与服务器的连接）
186812 PRB：错误信息：403.7 Forbidden:Client Certificate Required（403.7 禁止访问：要求客户端证书）
403.8 – 站点访问被拒绝。您已为您用来访问服务器的域设置了域名限制。有关如何解决此问题的其他信息，请单击下面的文章编号，查看 Microsoft 知识库中相应的文章：
248032 错误信息：Forbidden:Site Access Denied 403.8（禁止访问：站点访问被拒绝 403.8）
403.9 – 用户数过多。与该服务器连接的用户数量超过了您设置的连接限制。有关如何更改此限制的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
248074 错误信息：Access Forbidden:Too Many Users Are Connected 403.9（禁止访问：连接的用户太多 403.9）
注意：Microsoft Windows 2000 Professional 和 Microsoft Windows XP Professional 自动设置了在 IIS 上最多 10 个连接的限制。您无法更改此限制。
403.12 – 拒绝访问映射表。 您要访问的页面要求提供客户端证书，但映射到您的客户端证书的用户 ID 已被拒绝访问该文件。有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
248075 错误信息：HTTP 403.12 – Access Forbidden:Mapper Denied Access（HTTP 403.12 – 禁止访问：映射表拒绝访问）
404 – 未找到。 发生此错误的原因是您试图访问的文件已被移走或删除。如果在安装 URLScan 工具之后，试图访问带有有限扩展名的文件，也会发生此错误。这种情况下，该请求的日志文件项中将出现“Rejected by URLScan”的字样。
500 – 内部服务器错误。 很多服务器端的错误都可能导致该错误信息。事件查看器日志包含更详细的错误原因。此外，您可以禁用友好 HTTP 错误信息以便收到详细的错误说明。 有关如何禁用友好 HTTP 错误信息的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
294807 如何在服务器端禁用 Internet Explorer 5 的“显示友好 HTTP 错误信息”功能
500.12 – 应用程序正在重新启动。 这表示您在 IIS 重新启动应用程序的过程中试图加载 ASP 页。刷新页面后，此信息即会消失。如果刷新页面后，此信息再次出现，可能是防病毒软件正在扫描 Global.asa 文件。有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
248013 错误信息：HTTP Error 500-12 Application Restarting（HTTP 错误 500-12 应用程序正在重新启动）
500-100.ASP – ASP 错误。 如果试图加载的 ASP 页中含有错误代码，将出现此错误信息。若要获得更确切的错误信息，请禁用友好 HTTP 错误信息。默认情况下，只会在默认 Web 站点上启用此错误信息。有关如何在非默认的 Web 站点上看到此错误信息的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
261200 显示 HTTP 500 错误信息，而不显示 500-100.asp 的 ASP 错误信息
502 – 网关错误。 如果试图运行的 CGI 脚本不返回有效的 HTTP 标头集，将出现此错误信息。

FTP
1xx – 肯定的初步答复

这些状态代码指示一项操作已经成功开始，但客户端希望在继续操作新命令前得到另一个答复。 110 重新启动标记答复。
120 服务已就绪，在 nnn 分钟后开始。
125 数据连接已打开，正在开始传输。
150 文件状态正常，准备打开数据连接。
2xx – 肯定的完成答复

一项操作已经成功完成。客户端可以执行新命令。 200 命令确定。
202 未执行命令，站点上的命令过多。
211 系统状态，或系统帮助答复。
212 目录状态。
213 文件状态。
214 帮助消息。
215 NAME 系统类型，其中，NAME 是 Assigned Numbers 文档中所列的正式系统名称。
220 服务就绪，可以执行新用户的请求。
221 服务关闭控制连接。如果适当，请注销。
225 数据连接打开，没有进行中的传输。
226 关闭数据连接。请求的文件操作已成功（例如，传输文件或放弃文件）。
227 进入被动模式 (h1,h2,h3,h4,p1,p2)。
230 用户已登录，继续进行。
250 请求的文件操作正确，已完成。
257 已创建“PATHNAME”。
3xx – 肯定的中间答复

该命令已成功，但服务器需要更多来自客户端的信息以完成对请求的处理。 331 用户名正确，需要密码。
332 需要登录帐户。
350 请求的文件操作正在等待进一步的信息。
4xx – 瞬态否定的完成答复

该命令不成功，但错误是暂时的。如果客户端重试命令，可能会执行成功。
421 服务不可用，正在关闭控制连接。如果服务确定它必须关闭，将向任何命令发送这一应答。
425 无法打开数据连接。
426 Connection closed; transfer aborted.
450 未执行请求的文件操作。文件不可用（例如，文件繁忙）。
451 请求的操作异常终止：正在处理本地错误。
452 未执行请求的操作。系统存储空间不够。
5xx – 永久性否定的完成答复

该命令不成功，错误是永久性的。如果客户端重试命令，将再次出现同样的错误。
500 语法错误，命令无法识别。这可能包括诸如命令行太长之类的错误。
501 在参数中有语法错误。
502 未执行命令。
503 错误的命令序列。
504 未执行该参数的命令。
530 未登录。
532 存储文件需要帐户。
550 未执行请求的操作。文件不可用（例如，未找到文件，没有访问权限）。
551 请求的操作异常终止：未知的页面类型。
552 请求的文件操作异常终止：超出存储分配（对于当前目录或数据集）。
553 未执行请求的操作。不允许的文件名。

常见的 FTP 状态代码及其原因
150 – FTP 使用两个端口：21 用于发送命令，20 用于发送数据。状态代码 150 表示服务器准备在端口 20 上打开新连接，发送一些数据。
226 – 命令在端口 20 上打开数据连接以执行操作，如传输文件。该操作成功完成，数据连接已关闭。
230 – 客户端发送正确的密码后，显示该状态代码。它表示用户已成功登录。
331 – 客户端发送用户名后，显示该状态代码。无论所提供的用户名是否为系统中的有效帐户，都将显示该状态代码。
426 – 命令打开数据连接以执行操作，但该操作已被取消，数据连接已关闭。
530 – 该状态代码表示用户无法登录，因为用户名和密码组合无效。如果使用某个用户帐户登录，可能键入错误的用户名或密码，也可能选择只允许匿名访问。如果使用匿名帐户登录，IIS 的配置可能拒绝匿名访问。
550 – 命令未被执行，因为指定的文件不可用。例如，要 GET 的文件并不存在，或试图将文件 PUT 到您没有写入权限的目录。

您可能也喜欢：

最新的Eclipse快捷键大全

SQL语句大全

System.getProperty()方法大全

PL/SQL Developer 连接远程Oracle数据库

无觅

　　软件的生命性

　　软件是有生命的，这可能是老调重弹了，但是因为它事关分层架构的原由，反复强调都不过分。

　　一个有生命的软件首先必须有一个灵活可扩展的基础架构，其次才是完整的功能。

　　目前很多人对软件的思想还是焦点落在后者：完整的功能，觉得一个软件功能越完整越好，其实关键还是架构的灵活性，就是前者，基础架构好，功能添加只是时间和工作量问题，但是如果架构不好，功能再完整，也不可能包括未来所有功能，软件是有生命的，在未来成长时，更多功能需要加入，但是因为基础架构不灵活不能方便加入，死路一条。

　　正因为普通人对软件存在短视误区，对功能追求高于基础架构，很多吃了亏的老程序员就此离开软件行业，带走宝贵的失败经验，新的盲目的年轻程序员还是使用老的思维往前冲。其实很多国外免费开源框架如ofbiz compiere和slide也存在这方面陷阱，貌似非常符合胃口，其实类似国内那些几百元的盗版软件，扩展性以及持续发展性严重不足。

　　那么选择现在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基础架构打好了呢？其实还不尽然，关键还是取决于你如何使用这些框架来搭建你的业务系统。

　　存储过程和复杂SQL语句的陷阱

　　首先谈谈存储过程使用的误区，使用存储过程架构的人以为可以解决性能问题，其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗方案就全部失效，请问你会使用这种短视方案吗？

　　为什么这样说呢？如果存储过程都封装了业务过程，那么运行负载都集中在数据库端，要中间J2EE应用服务器干什么？要中间服务器的分布式计算和集群能力做什么？只能回到过去集中式数据库主机时代。现在软件都是面向互联网的，不象过去那样局限在一个小局域网，多用户并发访问量都是无法确定和衡量，依靠一台数据库主机显然是不能够承受这样恶劣的用户访问环境的。(当然搞数据库集群也只是五十步和百步的区别)。

　　从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。打个比喻：你在火车站将水果和盘子两个对象委托保管处保管，过了两天来取时，你还要求保管处将水果去皮切成块，放在盘子里，做成水果盘给你，合理吗？

　　上面是谈过分依赖持久层的一个现象，还有一个正好相反现象，持久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的是数据表的影子(包括数据表的字段)，而不是业务对象。这样程序员应该多看看OO经典PoEAA.PoEAA 认为除了持久层，不应该在其他地方看到数据表或表字段名。

　　当然适量使用存储过程，使用数据库优点也是允许的。按照Evans DDD理论，可以将SQL语句和存储过程作为规则Specification一部分。

　　Hibernate等ORM问题

　　现在使用Hibernate人也不少，但是他们发现Hibernate性能缓慢，所以寻求解决方案，其实并不是 Hibernate性能缓慢，而是我们使用方式发生错误：

　　”最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3, 由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false,所以导致数据一加载很慢，而且查询一条数据更是非常的慢。”

　　Hibernate是一个基于对象模型持久化的技术，因此，关键是我们需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分层等有效办法处理关联。如果采取围绕数据表进行设计编程，加上表之间关系复杂(没有科学方法处理、侦察或减少这些关系)，必然导致 系统运行缓慢，其实同样问题也适用于当初对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model持久化，如果不首先设计Domain Model,而是设计数据表，和持久化工具设计目标背道而驰，能不出问题吗？关于这个问题N多年就在Jdon争论过。

　　这里同样延伸出另外一个问题：数据库设计问题，数据库是否需要在项目开始设计？

　　如果我们进行数据库设计，那么就产生了一系列问题：当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。

　　当然，也有脑力相当发达的人可以实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块(数据表和业务对象)相撞，必然产生地震，地震的结果是两败俱伤，软的一方吃亏，业务对象是代码，相当于数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。

　　领域建模解决了上述众多不协调问题，特别是ORM痛苦使用问题，关于 ORM/Hibernate使用还是那句老话：如果你不掌握领域建模方法，那么就不要用Hibernate,对于这个层次的你：也许No ORM 更是一个简单之道： No ORM: The simplest solution

　　Spring分层矛盾问题

　　Spring是以挑战EJB面貌出现，其本身拥有的强大组件定制功能是优点，但是存在实战的一些问题，Spring作为业务层框架，不支持业务层Session 功能。

　　具体举例如下：当我们实现购物车之类业务功能时，需要将购物场合保存到 Session中，由于业务层没有方便的Session支持，我们只得将购物车保存到 HttpSession,而HttpSession只有通过HttpRequest才能获得，再因为在Spring业务层容器中是无法访问到 HttpRequest这个对象的，所以，最后我们只能将”购物车保存到HttpSession”这个功能放在表现层中实现，而这个功能明显应该属于业务层功能，这就导致我们的Java项目层次混乱，维护性差。 违背了使用Spring和分层架构最初目的。

　　领域驱动设计DDD

　　现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的”Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。

　　我们现在很多人知道Java项目基本有三层：表现层 业务层和持久层，当我们执着于讨论各层框架如何选择之时，实际上我们真正的项目开发工作还没有开始，就是我们选定了某种框架的组合(如Struts+Spring+Hibernate或Struts+EJB或Struts+ JdonFramework)，我们还没有意识到业务层工作还需要大量工作，DDD提供了在业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为作业层、能力层、策略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式

　　当我们将精力花费在架构技术层面的讨论和研究上时，我们可能忘记以何种依据选择这些架构技术？选择标准是什么？领域驱动设计DDD 回答了这样的问题，DDD会告诉你如果一个框架不能协助你实现分层架构，那就抛弃它，同时，DDD也指出选择框架的考虑目的，使得你不会人云亦云，陷入复杂的技术细节迷雾中，迷失了架构选择的根本方向。

　　现在也有些人误以为DDD是一种新的理论，其实DDD和设计模式一样，不是一种新的理论，而是实战经验的总结，它将前人 使用面向模型设计的方法经验提炼出来，供后来者学习，以便迅速找到驾驭我们软件项目的根本之道。

您可能也喜欢：

Java中的性能优化

Java读取和写入文本文件内容

JAVA容器类解析

青花瓷JAVA版，周杰伦告诉你怎么学Java

无觅

D.1 基本方法
只有正确和完整地检测了程序后，再可着手解决性能方面的问题：
(1) 在现实环境中检测程序的性能。若符合要求，则目标达到。若不符合，则转到下一步。
(2) 寻找最致命的性能瓶颈。这也许要求一定的技巧，但所有努力都不会白费。如简单地猜测瓶颈所在，并试图进行优化，那么可能是白花时间。
(3) 运用本附录介绍的提速技术，然后返回步骤1。

为使努力不至白费，瓶颈的定位是至关重要的一环。Donald Knuth[9]曾改进过一个程序，那个程序把50％的时间都花在约4％的代码量上。在仅一个工作小时里，他修改了几行代码，使程序的执行速度倍增。此时，若将时间继续投入到剩余代码的修改上，那么只会得不偿失。Knuth在编程界有一句名言：“过早的优化是一切麻烦的根源”（Premature optimization is the root of all evil）。最明智的做法是抑制过早优化的冲动，因为那样做可能遗漏多种有用的编程技术，造成代码更难理解和操控，并需更大的精力进行维护。

D.2 寻找瓶颈
为找出最影响程序性能的瓶颈，可采取下述几种方法：

D.2.1 安插自己的测试代码
插入下述“显式”计时代码，对程序进行评测：

long start = System.currentTimeMillis();
// 要计时的运算代码放在这儿
long time = System.currentTimeMillis() – start;

利用System.out.println()，让一种不常用到的方法将累积时间打印到控制台窗口。由于一旦出错，编译器会将其忽略，所以可用一个“静态最终布尔值”（Static final boolean）打开或关闭计时，使代码能放心留在最终发行的程序里，这样任何时候都可以拿来应急。尽管还可以选用更复杂的评测手段，但若仅仅为了量度一个特定任务的执行时间，这无疑是最简便的方法。
System.currentTimeMillis()返回的时间以千分之一秒（1毫秒）为单位。然而，有些系统的时间精度低于1毫秒（如Windows PC），所以需要重复n次，再将总时间除以n，获得准确的时间。

D.2.2 JDK性能评测[2]
JDK配套提供了一个内建的评测程序，能跟踪花在每个例程上的时间，并将评测结果写入一个文件。不幸的是，JDK评测器并不稳定。它在JDK 1.1.1中能正常工作，但在后续版本中却非常不稳定。
为运行评测程序，请在调用Java解释器的未优化版本时加上-prof选项。例如：
java_g -prof myClass
或加上一个程序片（Applet）：
java_g -prof sun.applet.AppletViewer applet.html
理解评测程序的输出信息并不容易。事实上，在JDK 1.0中，它居然将方法名称截短为30字符。所以可能无法区分出某些方法。然而，若您用的平台确实能支持-prof选项，那么可试试Vladimir Bulatov的“HyperPorf”[3]或者Greg White的“ProfileViewer”来解释一下结果。

D.2.3 特殊工具
如果想随时跟上性能优化工具的潮流，最好的方法就是作一些Web站点的常客。比如由Jonathan Hardwick制作的“Tools for Optimizing Java”（Java优化工具）网站：

http://www.cs.cmu.edu/~jch/java/tools.html

D.2.4 性能评测的技巧
■由于评测时要用到系统时钟，所以当时不要运行其他任何进程或应用程序，以免影响测试结果。
■如对自己的程序进行了修改，并试图（至少在开发平台上）改善它的性能，那么在修改前后应分别测试一下代码的执行时间。
■尽量在完全一致的环境中进行每一次时间测试。
■如果可能，应设计一个不依赖任何用户输入的测试，避免用户的不同反应导致结果出现误差。

D.3 提速方法
现在，关键的性能瓶颈应已隔离出来。接下来，可对其应用两种类型的优化：常规手段以及依赖Java语言。

D.3.1 常规手段
通常，一个有效的提速方法是用更现实的方式重新定义程序。例如，在《Programming Pearls》（编程拾贝）一书中[14]，Bentley利用了一段小说数据描写，它可以生成速度非常快、而且非常精简的拼写检查器，从而介绍了Doug McIlroy对英语语言的表述。除此以外，与其他方法相比，更好的算法也许能带来更大的性能提升——特别是在数据集的尺寸越来越大的时候。欲了解这些常规手段的详情，请参考本附录末尾的“一般书籍”清单。

D.3.2 依赖语言的方法
为进行客观的分析，最好明确掌握各种运算的执行时间。这样一来，得到的结果可独立于当前使用的计算机——通过除以花在本地赋值上的时间，最后得到的就是“标准时间”。

运算 示例 标准时间

本地赋值 i=n; 1.0
实例赋值 this.i=n; 1.2
int增值 i++; 1.5
byte增值 b++; 2.0
short增值 s++; 2.0
float增值 f++; 2.0
double增值 d++; 2.0
空循环 while(true) n++; 2.0
三元表达式 (x<0) ?-x : x 2.2
算术调用 Math.abs(x); 2.5
数组赋值 a[0] = n; 2.7
long增值 l++; 3.5
方法调用 funct(); 5.9
throw或catch异常 try{ throw e; }或catch(e){} 320
同步方法调用 synchMehod(); 570
新建对象 new Object(); 980
新建数组 new int[10]; 3100

通过自己的系统（如我的Pentium 200 Pro，Netscape 3及JDK 1.1.5），这些相对时间向大家揭示出：新建对象和数组会造成最沉重的开销，同步会造成比较沉重的开销，而一次不同步的方法调用会造成适度的开销。参考资源[5]和[6]为大家总结了测量用程序片的Web地址，可到自己的机器上运行它们。

1. 常规修改
下面是加快Java程序关键部分执行速度的一些常规操作建议（注意对比修改前后的测试结果）。

将... 修改成... 理由

接口 抽象类（只需一个父时） 接口的多个继承会妨碍性能的优化
非本地或数组循环变量 本地循环变量 根据前表的耗时比较，一次实例整数赋值的时间是本地整数赋值时间的1.2倍，但数组赋值的时间是本地整数赋值的2.7倍
链接列表（固定尺寸） 保存丢弃的链接项目，或将列表替换成一个循环数组（大致知道尺寸） 每新建一个对象，都相当于本地赋值980次。参考“重复利用对象”（下一节）、Van Wyk[12] p.87以及Bentley[15] p.81
x/2（或2的任意次幂） X>>2（或2的任意次幂） 使用更快的硬件指令

D.3.3 特殊情况
■字串的开销：字串连接运算符+看似简单，但实际需要消耗大量系统资源。编译器可高效地连接字串，但变量字串却要求可观的处理器时间。例如，假设s和t是字串变量：
System.out.println(“heading” + s + “trailer” + t);
上述语句要求新建一个StringBuffer（字串缓冲），追加自变量，然后用toString()将结果转换回一个字串。因此，无论磁盘空间还是处理器时间，都会受到严重消耗。若准备追加多个字串，则可考虑直接使用一个字串缓冲——特别是能在一个循环里重复利用它的时候。通过在每次循环里禁止新建一个字串缓冲，可节省980单位的对象创建时间（如前所述）。利用substring()以及其他字串方法，可进一步地改善性能。如果可行，字符数组的速度甚至能够更快。也要注意由于同步的关系，所以StringTokenizer会造成较大的开销。
■同步：在JDK解释器中，调用同步方法通常会比调用不同步方法慢10倍。经JIT编译器处理后，这一性能上的差距提升到50到100倍（注意前表总结的时间显示出要慢97倍）。所以要尽可能避免使用同步方法——若不能避免，方法的同步也要比代码块的同步稍快一些。
■重复利用对象：要花很长的时间来新建一个对象（根据前表总结的时间，对象的新建时间是赋值时间的980倍，而新建一个小数组的时间是赋值时间的3100倍）。因此，最明智的做法是保存和更新老对象的字段，而不是创建一个新对象。例如，不要在自己的paint()方法中新建一个Font对象。相反，应将其声明成实例对象，再初始化一次。在这以后，可在paint()里需要的时候随时进行更新。参见Bentley编著的《编程拾贝》，p.81[15]。
■异常：只有在不正常的情况下，才应放弃异常处理模块。什么才叫“不正常”呢？这通常是指程序遇到了问题，而这一般是不愿见到的，所以性能不再成为优先考虑的目标。进行优化时，将小的“try-catch”块合并到一起。由于这些块将代码分割成小的、各自独立的片断，所以会妨碍编译器进行优化。另一方面，若过份热衷于删除异常处理模块，也可能造成代码健壮程度的下降。
■散列处理：首先，Java 1.0和1.1的标准“散列表”（Hashtable）类需要造型以及特别消耗系统资源的同步处理（570单位的赋值时间）。其次，早期的JDK库不能自动决定最佳的表格尺寸。最后，散列函数应针对实际使用项（Key）的特征设计。考虑到所有这些原因，我们可特别设计一个散列类，令其与特定的应用程序配合，从而改善常规散列表的性能。注意Java 1.2集合库的散列映射（HashMap）具有更大的灵活性，而且不会自动同步。
■方法内嵌：只有在方法属于final（最终）、private（专用）或static（静态）的情况下，Java编译器才能内嵌这个方法。而且某些情况下，还要求它绝对不可以有局部变量。若代码花大量时间调用一个不含上述任何属性的方法，那么请考虑为其编写一个“final”版本。
■I/O：应尽可能使用缓冲。否则，最终也许就是一次仅输入／输出一个字节的恶果。注意JDK 1.0的I/O类采用了大量同步措施，所以若使用象readFully()这样的一个“大批量”调用，然后由自己解释数据，就可获得更佳的性能。也要注意Java 1.1的“reader”和“writer”类已针对性能进行了优化。
■造型和实例：造型会耗去2到200个单位的赋值时间。开销更大的甚至要求上溯继承（遗传）结构。其他高代价的操作会损失和恢复更低层结构的能力。
■图形：利用剪切技术，减少在repaint()中的工作量；倍增缓冲区，提高接收速度；同时利用图形压缩技术，缩短下载时间。来自JavaWorld的“Java Applets”以及来自Sun的“Performing Animation”是两个很好的教程。请记着使用最贴切的命令。例如，为根据一系列点画一个多边形，和drawLine()相比，drawPolygon()的速度要快得多。如必须画一条单像素粗细的直线，drawLine(x,y,x,y)的速度比fillRect(x,y,1,1)快。
■使用API类：尽量使用来自Java API的类，因为它们本身已针对机器的性能进行了优化。这是用Java难于达到的。比如在复制任意长度的一个数组时，arraryCopy()比使用循环的速度快得多。
■替换API类：有些时候，API类提供了比我们希望更多的功能，相应的执行时间也会增加。因此，可定做特别的版本，让它做更少的事情，但可更快地运行。例如，假定一个应用程序需要一个容器来保存大量数组。为加快执行速度，可将原来的Vector（矢量）替换成更快的动态对象数组。

1. 其他建议
■将重复的常数计算移至关键循环之外——比如计算固定长度缓冲区的buffer.length。
■static final（静态最终）常数有助于编译器优化程序。
■实现固定长度的循环。
■使用javac的优化选项：-O。它通过内嵌static，final以及private方法，从而优化编译过的代码。注意类的长度可能会增加（只对JDK 1.1而言——更早的版本也许不能执行字节查证）。新型的“Just-in-time”（JIT）编译器会动态加速代码。
■尽可能地将计数减至0——这使用了一个特殊的JVM字节码。

您可能也喜欢：

Java编程语言程序的认识误区

JAVA容器类解析

用JAVA实现文件的ZIP压缩与解压

Java正则表达式

无觅

Servlet运行在Servlet容器中，其生命周期由容器来管理。Servlet的生命周期通过javax.servlet.Servlet接口中的init()、service()和destroy()方法来表示。

Servlet的生命周期包含了下面4个阶段：

（1）加载和实例化
Servlet容器负责加载和实例化Servlet。当Servlet容器启动时，或者在容器检测到需要这个Servlet来响应第一个请求时，创 建Servlet实例。当Servlet容器启动后，它必须要知道所需的Servlet类在什么位置，Servlet容器可以从本地文件系统、远程文件系 统或者其他的网络服务中通过类加载器加载Servlet类，成功加载后，容器创建Servlet的实例。因为容器是通过Java的反射API来创建 Servlet实例，调用的是Servlet的默认构造方法（即不带参数的构造方法），所以我们在编写Servlet类的时候，不应该提供带参数的构造方法。
（2）初始化
在Servlet实例化之后，容器将调用Servlet的init()方法初始化这个对象。初始化的目的是为了让Servlet对象在处理客户端请求前完成一些初始化的工作，如建立数据库的连接，获取配置信息等。对于每一个Servlet实例，init()方法只被调用一次。在初始化期间，Servlet实例可以使用容器为它准备的ServletConfig对象从Web应用程序的配置信息（在web.xml中配置）中获取初始化的参数信息。在初始化期间，如果发生错误，Servlet实例可以抛出ServletException异常或者UnavailableException异常来通知容器。ServletException异常用于指明一般的初始化失败，例如没有找到初始化参数；而UnavailableException异常 用于通知容器该Servlet实例不可用。例如，数据库服务器没有启动，数据库连接无法建立，Servlet就可以抛出 UnavailableException异常向容器指出它暂时或永久不可用。
（3）请求处理
Servlet容器调用Servlet的service()方法对请求进行处理。要注意的是，在service()方法调用之前，init()方法 必须成功执行。在service()方法中，Servlet实例通过ServletRequest对象得到客户端的相关信息和请求信息，在对请求进行处理后，调用ServletResponse对象的方法设置响应信息。在service()方法执行期间，如果发生错误，Servlet实例可以抛出 ServletException异常或者UnavailableException异常。如果UnavailableException异常指示了该实 例永久不可用，Servlet容器将调用实例的destroy()方法，释放该实例。此后对该实例的任何请求，都将收到容器发送的HTTP 404（请求的资源不可用）响应。如果UnavailableException异常指示了该实例暂时不可用，那么在暂时不可用的时间段内，对该实例的任 何请求，都将收到容器发送的HTTP 503（服务器暂时忙，不能处理请求）响应。
（4）服务终止
当容器检测到一个Servlet实例应该从服务中被移除的时候，容器就会调用实例的destroy()方法，以便让该实例可以释放它所使用的资源， 保存数据到持久存储设备中。当需要释放内存或者容器关闭时，容器就会调用Servlet实例的destroy()方法。在destroy()方法调用之 后，容器会释放这个Servlet实例，该实例随后会被Java的垃圾收集器所回收。如果再次需要这个Servlet处理请求，Servlet容器会创建 一个新的Servlet实例。

在整个Servlet的生命周期过程中，创建Servlet实例、调用实例的init()和destroy()方法都只进行一次，当初始化完成 后，Servlet容器会将该实例保存在内存中，通过调用它的service()方法，为接收到的请求服务。

二、Servlet运行原理和流程

1. Servlet运行原理
    ①. WebApplication的标准目录结构：
WEB-INF/classes

/lib

Web.xml

，也就是一个完整的web应用程序目录下，必须包含以上的目录结构。

Classes 文件夹下是项目中用到的类文件，均由JDK编译成了.class文件

Lib文件夹是我们项目中引用的jar包

Web.xml是整个web应用程序的配置文档。

了解了这些，我们再来看Tomcat的工作流程。

②. Tomcat解析URL
>a) 首先来看URL中包含的信息：”协议” + “端口号” + “路径(项目名称+文件路径)”

Tomcat启动后，监听我们的8080端口，当有Url请求发过来之后，解析出项目名称 abingtest，然后到webapps目录下搜索到该项目文件夹。

b) 项目文件找到后，开始寻找类文件。

这个时候Tomcat去Web.xml文件中寻找<servlet-mapping> 配置节中包含”servlet/FirstServlet”字符串，进而找到该类文件所在的位置。
③. Servelt中的doGet() 和 doPost() 方法
我们写的FirstServlet 继承了HttpServlet ，重写了HttpServlet中的doGet() 方法，HttpServlet中还有一个doPost()方法。这两个方法都是用来处理Http请求的。Servlet会根据我们提交表单的方法 （method=post/get）调用service方法来自动选择。
 

2、一个servlet运行流程图：

您可能也喜欢：

Servlet的生命周期

优化jsp速度的七种方法

J2EE中的13种技术规范

从DataSet导出Txt

无觅

Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。
URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作。GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。

2.GET是幂等的，POST是要修改更新的

通过上面概念的理解，我们很容易发现，GET是用于信息获取或查询的，这就意味着它是幂等的，POST可能会改变服务器上的资源请求。

这样一说有点抽象了，网上有一个我认为比较合理的例子就是新闻站点的例子：例子如下：get方式—新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是幂等的，因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看没有改变资源即可；post方式–读者对新闻发表自己的评论应该通过POST实现，因为在评论提交后站点的资源已经不同了，或者说资源被修改了。仔细考虑一下这个例子就能明白GET是幂等的而POST是要修改更新的了。

3.通过实例了解post和get的http请求过程

通过上面的分析，已经对GET和POST有所了解，也能感觉到他俩有着本质上的区别就是一个是拿来，一个是要更新修改。

下面就通过HTTPLOOK软件来看看他们是怎样进行HTPP请求的，它们到底是怎样进行传输的。

首先建立两个jsp页面用来测试：

第一个页面是post_get_jsp（代码如下）：

<%@ page language="java" contentType="text/html; charset=GB18030"
    pageEncoding="GB18030"%>











	

第二个页面是test.jsp（代码如下）：

<%@ page language="java" contentType="text/html; charset=GB18030"
    pageEncoding="GB18030"%>


<%
	String a=request.getParameter("text1");
	out.println(a);
%>







ddfdgdg

简单说一下http请求：

在HTTP请求中，第一行必须是一个请求行（request line），用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部（header）小节，用来说明服务器要使用的附加信息。在首部之后是一个空行，再此之后可以添加任意的其他数据。

开始测试post提交

http请求如下：

开始测试get提交

http请求如下：

4.POST与GET区别

①. GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。

②. 从上面的http请求中就能看出，GET提交是将请求的数据附加到URL之后，用？分割、参数用&连接。并且字符串已经被加密。而post的提交是放到了http包中。从这点看来GET请求的地址栏会改变，RUL附加上了请求的数据，而POST地址栏不会改变，UTL没有变化。更加深一层看GET的安全性不高，很容易暴露信息。

③. 另外虽然http协议没有对传输数据大小进行限制也没有对url长度进行限制，但是实际情况中浏览器对url进行限制，这样GET的传输数据大小随着URL长度被限制而受到限制。反观POST由于不是通过URL传值，所以没有限制。

您可能也喜欢：

could not get next sequence value

在Struts Action中获取来源IP的方法

request与response转向的区别

无觅

]]>

NLSSORT()，用来进行语言排序

拼音
SELECT * FROM TEAM ORDER BY NLSSORT(排序字段名,’NLS_SORT = SCHINESE_PINYIN_M’)
笔划
SELECT * FROM TEAM ORDER BY NLSSORT(排序字段名,’NLS_SORT = SCHINESE_STROKE_M’)
部首
SELECT * FROM TEAM ORDER BY NLSSORT(排序字段名,’NLS_SORT = SCHINESE_RADICAL_M’)
/*——增加：yl end–*/

列表一行汉字
WITH A AS
(SELECT ‘获取汉字拼音首字母’ W FROM DUAL)
SELECT SUBSTR(W, ROWNUM, 1) FROM A
CONNECT BY ROWNUM <= (SELECT LENGTH(W) FROM A);
返回结果
获
取
汉
字
拼
音
首
字
母

用汉字字符集对这个列表进行排序
WITH A AS
(SELECT '获取汉字拼音首字母' W FROM DUAL)
SELECT SUBSTR(W, ROWNUM, 1) FROM A
CONNECT BY ROWNUM <= (SELECT LENGTH(W) FROM A)
ORDER BY NLSSORT(SUBSTR(W, ROWNUM, 1), 'NLS_SORT=SCHINESE_PINYIN_M');
返回结果
汉
获
母
拼
取
首
音
字
字

那么根据这个原理，上面输入一个拼音A打头的字"澳"，后面输入一个B大头的字"吧"，找到每个音节的起止的汉字是哪个
WITH A AS
(
SELECT ROWNUM RN, CHR(ROWNUM) C FROM DUAL CONNECT BY LEVEL <= 65535
)
SELECT * FROM A WHERE LENGTHB(C) = 2
AND RN > 32768
AND NLSSORT(C, ‘NLS_SORT=SCHINESE_PINYIN_M’) > NLSSORT(‘澳’, ‘NLS_SORT=SCHINESE_PINYIN_M’)
AND NLSSORT(C, ‘NLS_SORT=SCHINESE_PINYIN_M’) < NLSSORT('吧', 'NLS_SORT=SCHINESE_PINYIN_M')
ORDER BY NLSSORT(C, 'NLS_SORT=SCHINESE_PINYIN_M');
根据返回的结果，就能看到，A的结束和B的开始的汉子分别是：“驁” “八”，依次类推可以找到其他的分界点，那么最后的函数就是如下：

CREATE OR REPLACE FUNCTION F_TRANS_PINYIN_CAPITAL(P_NAME IN VARCHAR2) RETURN VARCHAR2 AS
V_COMPARE VARCHAR2(100);
V_RETURN VARCHAR2(4000);

FUNCTION F_NLSSORT(P_WORD IN VARCHAR2) RETURN VARCHAR2 AS
BEGIN
RETURN NLSSORT(P_WORD, 'NLS_SORT=SCHINESE_PINYIN_M');
END;
BEGIN
FOR I IN 1..LENGTH(P_NAME) LOOP
V_COMPARE := F_NLSSORT(SUBSTR(P_NAME, I, 1));
IF V_COMPARE >= F_NLSSORT(‘ 吖 ‘) AND V_COMPARE <= F_NLSSORT('驁 ') THEN
V_RETURN := V_RETURN || 'a';
ELSIF V_COMPARE >= F_NLSSORT(‘八 ‘) AND V_COMPARE <= F_NLSSORT('簿 ') THEN
V_RETURN := V_RETURN || 'b';
ELSIF V_COMPARE >= F_NLSSORT(‘嚓 ‘) AND V_COMPARE <= F_NLSSORT('錯 ') THEN
V_RETURN := V_RETURN || 'c';
ELSIF V_COMPARE >= F_NLSSORT(‘咑 ‘) AND V_COMPARE <= F_NLSSORT('鵽 ') THEN
V_RETURN := V_RETURN || 'd';
ELSIF V_COMPARE >= F_NLSSORT(‘妸 ‘) AND V_COMPARE <= F_NLSSORT('樲 ') THEN
V_RETURN := V_RETURN || 'e';
ELSIF V_COMPARE >= F_NLSSORT(‘发 ‘) AND V_COMPARE <= F_NLSSORT('猤 ') THEN
V_RETURN := V_RETURN || 'f';
ELSIF V_COMPARE >= F_NLSSORT(‘旮 ‘) AND V_COMPARE <= F_NLSSORT('腂 ') THEN
V_RETURN := V_RETURN || 'g';
ELSIF V_COMPARE >= F_NLSSORT(‘妎 ‘) AND V_COMPARE <= F_NLSSORT('夻 ') THEN
V_RETURN := V_RETURN || 'h';
ELSIF V_COMPARE >= F_NLSSORT(‘丌 ‘) AND V_COMPARE <= F_NLSSORT('攈 ') THEN
V_RETURN := V_RETURN || 'j';
ELSIF V_COMPARE >= F_NLSSORT(‘咔 ‘) AND V_COMPARE <= F_NLSSORT('穒 ') THEN
V_RETURN := V_RETURN || 'k';
ELSIF V_COMPARE >= F_NLSSORT(‘垃 ‘) AND V_COMPARE <= F_NLSSORT('擽 ') THEN
V_RETURN := V_RETURN || 'l';
ELSIF V_COMPARE >= F_NLSSORT(‘嘸 ‘) AND V_COMPARE <= F_NLSSORT('椧 ') THEN
V_RETURN := V_RETURN || 'm';
ELSIF V_COMPARE >= F_NLSSORT(‘拏 ‘) AND V_COMPARE <= F_NLSSORT('瘧 ') THEN
V_RETURN := V_RETURN || 'n';
ELSIF V_COMPARE >= F_NLSSORT(‘筽 ‘) AND V_COMPARE <= F_NLSSORT('漚 ') THEN
V_RETURN := V_RETURN || 'o';
ELSIF V_COMPARE >= F_NLSSORT(‘妑 ‘) AND V_COMPARE <= F_NLSSORT('曝 ') THEN
V_RETURN := V_RETURN || 'p';
ELSIF V_COMPARE >= F_NLSSORT(‘七 ‘) AND V_COMPARE <= F_NLSSORT('裠 ') THEN
V_RETURN := V_RETURN || 'q';
ELSIF V_COMPARE >= F_NLSSORT(‘亽 ‘) AND V_COMPARE <= F_NLSSORT('鶸 ') THEN
V_RETURN := V_RETURN || 'r';
ELSIF V_COMPARE >= F_NLSSORT(‘仨 ‘) AND V_COMPARE <= F_NLSSORT('蜶 ') THEN
V_RETURN := V_RETURN || 's';
ELSIF V_COMPARE >= F_NLSSORT(‘侤 ‘) AND V_COMPARE <= F_NLSSORT('籜 ') THEN
V_RETURN := V_RETURN || 't';
ELSIF V_COMPARE >= F_NLSSORT(‘屲 ‘) AND V_COMPARE <= F_NLSSORT('鶩 ') THEN
V_RETURN := V_RETURN || 'w';
ELSIF V_COMPARE >= F_NLSSORT(‘夕 ‘) AND V_COMPARE <= F_NLSSORT('鑂 ') THEN
V_RETURN := V_RETURN || 'x';
ELSIF V_COMPARE >= F_NLSSORT(‘丫 ‘) AND V_COMPARE <= F_NLSSORT('韻 ') THEN
V_RETURN := V_RETURN || 'y';
ELSIF V_COMPARE >= F_NLSSORT(‘帀 ‘) AND V_COMPARE <= F_NLSSORT(‘咗 ‘) THEN
V_RETURN := V_RETURN || ‘z’;
END IF;
END LOOP;
RETURN V_RETURN;
END;

测试一下：
SELECT F_TRANS_PINYIN_CAPITAL(‘罗华’) FROM DUAL
返回 lh
使用的时候这样查询：
select name from users t1 where (t1.name = ? or F_TRANS_PINYIN_CAPITAL(t1.name) = ?)
如果里面的?参数传递的是“罗华”，就是查询用户名是罗华的人，如果传递的是lh的话，查询的就是拼音是lh的人

您可能也喜欢：

PL/SQL Developer 连接远程Oracle数据库

Oracle在Windows下的自动备份

从MySql到Oracle的迁移以及备份

彻底删除Windows上的Oracle产品

无觅

首先，它俩根本不是一个概念。

三层架构是一个分层式的软件体系架构设计，它可适用于任何一个项目。

MVC是一个设计模式，它是根据项目的具体需求来决定是否适用于该项目。

那么架构跟设计模式有什么区别呢？

我们从接手一个项目开始，首先，我们需要进行架构设计，一般我们采用的就是分层式的架构设计，即我们的三层架构。

然后，在确定了架构以后，我们再根据项目的具体需求去考虑是否需要应用一些设计模式，比如是否应用我们的MVC模式，抽象工厂模式等等。（在这里我们看出，MVC与三层架构不是一个等级的，而与抽象工厂等设计模式才是一路的）

最后，确定了模式以后，就是我们的一些具体的实现了。（当然一个项目不仅仅考虑这些问题，我只是为了说明两者的区别，将其他问题已省略）

其次，它俩划分的层次不同。

三层架构将整个项目划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

MVC即Model（模型），View（视图），Controller（控制）。

下面看一下他俩的区别与联系：

通过这个图我们可以知道，我们平常所说的V是UI，C是BLL，M是DAL的观点是错误的。

    而我们通常所见到的MVC一般也都是在应用三层架构的基础上，即将Model层再进行分层。而如果Model不再进行划分的话，那么使用MVC的意义也就不大了。

然后，它俩的目的着重点不同。

三层架构的目的着重点是“高内聚，低耦合”，即解耦。

MVC的目的则是实现Web系统的职能分工，即职责划分。

其实职责划分也是解耦，但是三层侧重的是整体的一个解耦，而MVC侧重的是web系统的解耦，即侧重jsp和Servlet的一个解耦。

最后，为何我们会将其混为一谈？

既然两者有这么多的不同，我们为什么还总是将其混淆呢，下面我列举了几个我们常常将其混为一谈的几个原因：

1.二者都是“三层”。

这个原因是最容易迷惑我们初学者的，一个是UI,BLL,DAL，一个是View，Controller，Model，不都是三层吗？

虽然都是“三层”（不一定是真的三层，还可以是多层），但是它们的划分的不一样。大家可从上面的图中看出不同。

2.MVC总是伴随着三层架构。

这个就是我在前面一再强调的，我们一般是在考虑使用（也可以不使用）了三层架构的基础上再根据具体需求决定是否需要使用MVC，于是我们常说的MVC中总是伴随着三层架构，所以大家总是会认为MVC就是三层架构，三层架构就是MVC，殊不知，它们二者是一起出现的。

3.都是在分层，即都是在解耦。

前面说它们目的的时候也说了，虽然它们的侧重点不同，但是它们的总体目的是一样的，都是为了解耦，对于初学者而言，是不知道这两个侧重点有何不同的。

大家往往对它们的联系知道很多，不然也不会混为一谈，但是对它们的区别却知道较少，希望我上面讲解的它们两者之间的区别可以让大家对它们有些了解，如有写的不妥的地方，请指教。

您可能也喜欢：

图解Spring 3.x MVC 整体流程

Spring MVC框架的高级配置

Div层中英文不自动换行的解决办法

java中的集合架构

无觅