當前位置:首頁 » 網頁前端 » javaweb解決方案
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

javaweb解決方案

發布時間: 2022-09-20 02:59:57

① javaEE和javaweb的區別

javaweb是特製原sun公司出的一套以servlet規范的web層規范,是java在web方面的開發.圍繞此規范的web伺服器有tomcat,jetty,jboss等,我們可以使用sun公司提供的servlet規范結合實現了servlet規范的這些web伺服器做java網站,這就是javaweb。
Java EE是sun公司(2009年4月20日甲骨文將其收購)推出的企業級應用程序版本。這個版本以前稱為 J2EE。能夠幫助我們開發和部署可移植、健壯、可伸縮且安全的伺服器端 Java應用程序。Java EE 是在 Java SE 的基礎上構建的,它提供Web 服務、組件模型、管理和通信 API,可以用來實現企業級的面向服務體系結構.javaEE是企業級應用開發平台,主要是圍繞企業軟體的開發提出來的一整套業務和技術解決方案,比如EJB和Spring體系平台,主要是解決軟體開發過程中的數據持久化,事務機制,業務服務等。
其實這兩者只是一個平台和一個模式的關系。就相當於電腦和操作系統。可以是筆記本電腦,可以用windows操作系統;也可以是台式機,用linux操作系統一個道理。但是呢,java web一般情況都用的是j2ee這個平台。

② 如何解決JavaWeb亂碼問題

request-line中的URL部分必須以application/x-www-form-urlencoded方式編碼。編碼時使用的字元集是當前網頁在瀏覽器上顯示時所使用的字元集。

JDK中專門有兩個類處理application/x-www-form-urlencoded類型的數據,它們是URLEncoder及URLDecoder。當網頁上的數據需要手動進行URLEncoding處理時,可使用URLEncoder類完成編碼工作。需要手動進行URLEncoding處理的位置包括:

  • 鏈接(<a></a>)中的href標簽屬性;

  • 以POST方式提交的表單(<form></form>)中的action標簽屬性。

  • 例如,網頁上不應該產生這樣的鏈接:

    [xhtml]view plain

  • <!--不正確的寫法-->

  • <ahref="/hello/checkUser.html?opt=中文>使用者身份驗證"</a>

  • 正確的寫法是:

    [xhtml]view plain

  • <!--使用UTF-8字元集進行URLEncoding的結果-->

  • <ahref="/hello/checkUser.html?opt=%E4%B8%AD%E6%96%87">使用者身份驗證</a>

  • 為此,方案之一可以在JSP網頁上使用腳本化語言進行URLEncoding處理。如:

    [xhtml]view plain

  • <%@pageimport="java.net.URLEncoder"%>

  • <ahref="/hello/checkUser.html?opt=<%=URLEncoder.encode("中文","UTF-8")%>">使用者身份驗證</a>

  • request-body的編碼處理

    request-body只有在POST提交的方式下才會產生。request-body的編碼方式由表單的enctype標簽屬性指定,同request-line一樣,編碼request-body時使用的字元集也是當前網頁在瀏覽器上顯示時所使用的字元集。request-body的編碼過程由客戶端瀏覽器自動完成,不需要額外的編程處理。

    伺服器的處理

    相對於用戶端,伺服器端在接收到HTTP請求時提供了兩種處理請求數據的方式:自動處理與不處理。
    伺服器一般會自動處理application/x-www-form-urlencoded類型的數據(包括request-line及request-body中的數據),就servlet(Servlet類或JSP網頁)而言,可以通過request對象的getParameter()或getParameterValues()取得這些數據。對於除此以外的其它MIME類型的數據,HTTP伺服器則是將處理的過程直接交到了與HTTP請求相對應的servlet(Servlet類或JSP網頁)身上。
    例如用戶端有以下表單被提交:

    [xhtml]view plain

  • <formaction="checkUser.html?opt=xxx"method="POST">

  • <inputtype="text"name="username"value="yyy"/>

  • <inputtype="text"name="username"value="zzz"/>

  • <inupttype="submit"value="submit"/>

  • </form>

  • 表單提交時經伺服器端自動處理後與checkUser.html相對應的servlet(Servlet類或JSP網頁)可以通過下面的方式取得數據:

    [java]view plain

  • Stringopt=request.getParameter("opt");

  • String[]users=request.getParameterValues("username");

  • 默認情況下,伺服器對於接收到的application/x-www-form-urlencoded類型數據進行字元集為ISO-8859-1的URLDecoding處理,經過處理之後的字元串內碼為ISO-8859-1。對於沒有附加任何設置的HTTP伺服器而言,我們的servlet在取得數據之後必須進行相應的解碼處理,生成內碼為UTF-16(unicode)的字元串。
    例如對於用戶端請求數據中以UTF-8字元集進行URLEncoding的數據,servlet需要進行如下方式的解碼:

    [java]view plain

  • Stringopt=request.getParameter("opt");

  • if(opt!=null&&!"".equals(opt)){

  • opt=newString(opt.getBytes("ISO-8859-1"),"UTF-8");

  • }

  • 為了避免這種額外的編碼/解碼處理,也就是說讓伺服器了解到用戶端在URLEncoding時所使用的字元集,從而直接進行相應字元集的URLDecoding處理,不同的HTTP伺服器提供了不同的解決方案。
    以Tomcat為例,Tomcat自動解碼request-line的處理方式由Tomcat的配置文件server.xml指定。在server.xml中的Connector標簽中提供了URIEncoding標簽屬性,只要為其指定解碼用的字元集,Tomcat就會自動解碼request-line中經過application/x-www-form-urlencoded編碼處理的數據。例如:

    <Connector connectionTimeout="40000" port="8080" protocol="HTTP/1.1"
    URIEncoding="UTF-8" redirectPort="8443"/>

    Tomcat自動解碼request-body的處理方式是設置request的characterEncoding值。如:

    request.setCharacterEncoding("UTF-8");

    但是這一操作必須提前在filter中完成,在servlet中使用此方法已經不起作用了。filter的例子如下:

    [java]view plain

  • importjava.io.IOException;

  • importjavax.servlet.Filter;

  • importjavax.servlet.FilterChain;

  • importjavax.servlet.FilterConfig;

  • importjavax.servlet.ServletException;

  • importjavax.servlet.ServletRequest;

  • importjavax.servlet.ServletResponse;

  • {

  • privateStringencoding;

  • publicCharacterEncodingFilter(){

  • encoding=null;

  • }

  • publicvoiddestroy(){

  • encoding=null;

  • }

  • publicvoiddoFilter(ServletRequestrequest,ServletResponseresponse,

  • FilterChainchain)throwsIOException,ServletException{

  • request.setCharacterEncoding(encoding);

  • chain.doFilter(request,response);

  • }

  • publicvoidinit(FilterConfigfilterConfig)throwsServletException{

  • encoding=filterConfig.getInitParameter("encoding");

  • if(encoding==null||"".equals(encoding)){

  • encoding="UTF-8";

  • }

  • }

  • }

  • 我們可以在web.xml使用這個filter。web.xml的相應配置如下:

    [xhtml]view plain

  • <filter>

  • <filter-name>CharacterEncodingFilter</filter-name>

  • <filter-class>

  • CharacterEncodingFilter

  • </filter-class>

  • <init-param>

  • <param-name>encoding</param-name>

  • <param-value>UTF-8</param-value>

  • </init-param>

  • </filter>

  • <filter-mapping>

  • <filter-name>CharacterEncodingFilter</filter-name>

  • <url-pattern>/*</url-pattern>

  • </filter-mapping>

  • 通過上述兩種方式的預處理,在servlet中取出的數據可以不必進行ISO-8859-1解碼而直接使用。

    字元集的選擇

    在處理application/x-www-form-urlencoded類型的數據過程中,需要注意的另一個問題是字元集的選擇問題。如上所述,不論是request-line還是request-body,其URLEncoding所使用的字元集都是當前網頁在瀏覽器上顯示時所使用的字元集。而這個信息又是HTTP伺服器端生成HTML網頁時,在HTTP響應中提供的。
    當HTTP伺服器接收到一個HTTP請求時,伺服器總是需要向用戶端發送一個HTTP響應。HTTP響應數據與HTTP請求數據格式相同,同樣由以下幾個部分組成:

    <response-line>
    <headers>
    <CRLF>
    [<response-body><CRLF>]

    下面描述的是請求一個HTML網頁數據時伺服器的響應信息:

    HTTP/1.1 200 OK
    Server: Apache-Coyote/1.1
    Content-Type: text/html;charset=UTF-8
    Content-Length: 265
    Date: Thu, 17 Dec 2009 05:20:36 GMT

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>test</title>
    </head>
    <body>
    <h1>Hello World</h1>
    </body>
    </html>
    [End]

    其中headers的Content-Type指定了數據流的數據格式以及顯示用的字元集。這一指標可以通過以下幾種方式指定:
    1. HTML網頁
    在HTML網頁的<head></head>中存在多個<meta/>標簽,其中可以設置Content-Type。例如:

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

    2. JSP網頁
    JSP網頁中,除了<meta/>標簽之外,還需要在JSP網頁頭部設置如下代碼:

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

    3. Servlet類
    如果要在Servlet類中通過response向用戶端傳送HTML數據,需要在傳送前指定Content-Type。代碼如下:

    response.setContentType("text/html;charset=UTF-8");

    通過上述三種方式,可以確保響應數據傳送到用戶端瀏覽器時,瀏覽器使用正確解碼方式和字元集顯示其內容。

    結束語

    總之,Content-Type是聯系用戶端與伺服器端的紐帶,通過這一指標,雙方得以對相關的數據進行正確的編碼與解碼。只要了解了Content-Type的作用以及使用方法,亂碼問題就會迎刃而解。

③ 如何在 Web 瀏覽器中啟用 Java

請按照以下說明通過您的 Web 瀏覽器啟用 Java:

適用於 Windows 的瀏覽器
Internet Explorer
單擊工具,然後單擊 Internet 選項
選擇安全選項卡,選擇自定義級別按鈕
向下滾動到 Java 小應用程序腳本
確保選中啟用單選按鈕
單擊確定保存您的首選設置
Chrome
單擊扳手圖標,然後選擇選項。
依次選擇高級選項和隱私內容設置。
將顯示「內容設置」面板。
在插件部分,選擇禁用單獨插件鏈接以檢查是否已啟用 Java
單擊啟用鏈接(如果顯示「禁用」鏈接,則已啟用 Java)
注意:此外,您也可通過在瀏覽器地址欄中 鍵入「about:plugins」 來訪問「插件」設置。

適用於 Windows 和 Mac OS X 的瀏覽器
Firefox
啟動 Mozilla Firefox 瀏覽器,如果該瀏覽器正在運行,則重新啟動它。
在瀏覽器頂部,選擇 Firefox 按鈕(或 Windows XP 中的工具菜單),然後選擇附加組件
此時將打開「附加組件管理器」選項卡。
在「附加組件管理器」選項卡中,選擇插件
單擊 Java (TM) 平台插件以將其選定
單擊啟用按鈕(如果按鈕顯示為禁用,則 Java 已啟用)
Safari
啟動 Safari 瀏覽器
單擊「Safari」並選擇首選項
單擊安全選項卡
選中(選擇)啟用 Java 復選框
關閉「Safari 首選項」窗口
Opera 4.x 及更高版本
適用於 Windows 的 Opera 不使用 Java,但是 Opera Web 瀏覽器中已嵌入了 Java。
適用於其他平台的 Opera 可支持 Java。請參見 Opera 平台文檔。
有關詳細信息,請參見以下 Opera 支持文檔:
Opera 中的 Java 軟體支持
搶首贊
評論
分享
舉報

河南新華電腦學院
2021-10-26 · 專注互聯網IT教育,電腦培訓院校
關注
啟動Mozilla Firefox 瀏覽器,如果該瀏覽器正在運行,則重新啟動它。
在瀏覽器頂部,選擇Firefox按鈕(或 Windows XP 中的工具菜單)...
在「附加組件管理器」選項卡中,選擇插件
單擊Java (TM) 平台插件以將其選定

④ web伺服器的缺陷是什麼java是怎麼樣解決這個缺陷的

Web伺服器的缺陷是什麼?Java是怎麼樣解決這個缺陷的?因為web伺服器是被設計用來向客戶端提供HTTP服務的,它只能向客戶端提供靜態的網頁內容,不能創建動態伺服器端內容。java解決方案servlet和web容器對請求和響應的處理如下:1.客戶端向web伺服器發起一個HTTP請求;2.HTTP請求被WEB伺服器接受,如果請求是靜態頁面,則由web伺服器負責處理,如果請求是javaweb主件,則交給Web容器。Web容器可以在主機的同一個進程、不同的行程或其他的web伺服器主機的進程中啟動。3.web容器根據Servlet的配置文件確定調用具體的Servlet類,並把request對象、response對象傳給它。4.Servlet通過request對象知道客戶端的使用者是誰,客戶的請求信息是什麼和其他的一些信息。Servlet處理完請求後吧要返回的信息放入response對象返回到客戶端。5.一旦Servlet完成請求的處理,web容器就會刷新response。並把控制權返回給web伺服器。

⑤ 基於web的報表開發的JAVA有什麼好的解決方案

基於JAVA報表開發的方案有多種,簡單的說一下:
第一種是自己編碼來做報表,這種解決方案成本高、技術要求高,效率底,但是可以完全掌控
第二種是用開源的報表工具,這種解決方案技術要求一般,有隱形成本,無服務,效率中等。
第三種是用商業的報表工具,這種解決方案效率高,技術要求底,有服務。成本的高低要看您所選擇的廠家,推薦皕傑報表

⑥ javaweb防止表單重復提交的幾種解決方案

1.js方法解決:關於js方法解決就是說通過js動態控制提交按鈕不能多次點擊,或者多次點擊不起作用。

方案一:通過設立標識使表單不能重復提交:

要強調的是,利用session方法解決表單重復問題是十分完美的,基本上可以應對各種重復提交問題。

但!是不是之前在客戶端防止表單重復提交的種種方法就不使用了呢?

答案是否定的,我們需要多種方法混合使用才能達到最好的效果,也許有人會問,不是說session方法基本可以應對各種重復提交問題了嗎?

這里我們所說的達到最好效果指的是,給用戶更好地體驗,例如用戶點擊了提交按鈕,這時將按鈕變為不可用的,用以告訴用戶你已經提交內容了,不可重復提交。還有如果無論什麼情況都用session防止表單重復提交問題,反而無形的增加了伺服器端的負擔。

⑦ Java Web 亂碼 求解決方案

以下提到的地方,你都做一下檢查,這是平時總結的,但願對你有幫助

最基本的亂碼問題
這個亂碼問題是最簡單的亂碼問題。一般新會出現。就是頁面編碼不一致導致的亂碼。
Html代碼:
<%@ page language="java" pageEncoding="UTF-8"%>? <%@ page contentType="text/html;charset=iso8859-1"%>? <html>? <head>? <title>中文問題</title>? <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">? </head>? </head>? <body>? JSP中文編碼問題解決方法詳解? </body>? </html>?

三個地方的編碼
第一個地方的編碼格式為jsp文件的存儲格式。Ecljpse會根據這個編碼格式保存文件。並編譯jsp文件,包括裡面的漢字。
第二處編碼為解碼格式。因為存為UTF-8的文件被解碼為iso8859-1,這樣如有中文肯定出亂碼。也就是必須一致。而第二處所在的這一行,可以沒有。預設也是使用iso8859-1的編碼格式。所以如果沒有這一行的話,「我是個好人」也會出現亂碼。必須一致才可以。
第三處編碼為控制瀏覽器的解碼方式。如果前面的解碼都一致並且無誤的話,這個編碼格式沒有關系。有的網頁出現亂碼,就是因為瀏覽器不能確定使用哪種編碼格式。因為頁面有時候會嵌入頁面,導致瀏覽器混淆了編碼格式。出現了亂碼。
表單使用Post方式提交後接收到的亂碼問題
這個問題也是一個常見的問題。這個亂碼也是tomcat的內部編碼格式iso8859-1在搗亂,也就是說post提交時,如果沒有設置提交的編碼格式,則會以iso8859-1方式進行提交,接受的jsp卻以utf-8的方式接受。導致亂碼。既然這樣的原因,下面有幾種解決方式,並比較。
a. 接受參數時進行編碼轉換

String str = new String(request.getParameter("something").getBytes("ISO-8859-1"),"utf-8") ;

這樣的話,每一個參數都必須這樣進行轉碼。很麻煩。但確實可以拿到漢字。
b. 在請求頁面上開始處,執行請求的編碼代碼

request.setCharacterEncoding("UTF-8")

把提交內容的字元集設為UTF-8。這樣的話,接受此參數的頁面就不必在轉碼了。直接使用

String str = request.getParameter("something");
即可得到漢字參數。但每頁都需要執行這句話。這個方法也就對post提交的有效果,對於get提交和上傳文件時的enctype="multipart/form-data"是無效的。稍後下面單獨對這個兩個的亂碼情況再進行說明。
c. 為了避免每頁都要寫request.setCharacterEncoding("UTF-8"),建議使用過濾器對所有jsp進行編碼處理。這個網上有很多例子。請大家自己查閱。
表單get提交方式的亂碼處理方式
如果使用get方式提交中文,接受參數的頁面也會出現亂碼,這個亂碼的原因也是tomcat的內部編碼格式iso8859-1導致。Tomcat會以get的預設編碼方式iso8859-1對漢字進行編碼,編碼後追加到url,導致接受頁面得到的參數為亂碼/、。
解決辦法:
a. 使用上例中的第一種方式,對接受到的字元進行解碼,再轉碼。
b. Get走的是url提交,而在進入url之前已經進行了iso8859-1的編碼處理。要想影響這個編碼則需要在server.xml的Connector節點增加useBodyEncodingForURI="true"屬性配置,即可控制tomcat對get方式的漢字編碼方式,上面這個屬性控制get提交也是用request.setCharacterEncoding("UTF-8")所設置的編碼格式進行編碼。所以自動編碼為utf-8,接受頁面正常接受就可以了。但我認為真正的編碼過程是,tomcat又要根據

<Connector port="8080"maxThreads="150" minSpareThreads="25" maxSpareThreads="75"enableLookups="false" redirectPort="8443" acceptCount="100"debug="0" connectionTimeout="20000" useBodyEncodingForURI="true"disableUploadTimeout="true" URIEncoding=」UTF-8」/>

裡面所設置的URIEncoding=」UTF-8」再進行一次編碼,但是由於已經編碼為utf-8,再編碼也不會有變化了。如果是從url獲取編碼,接受頁面則是根據URIEncoding=」UTF-8」來進行解碼的。
上傳文件時的亂碼解決
上傳文件時,form表單設置的都是enctype="multipart/form-data"。這種方式以流方式提交文件。如果使用apach的上傳組件,會發現有很多亂碼想像。這是因為apach的先期commons-fileupload.jar有bug,取出漢字後進行解碼,因為這種方式提交,編碼又自動使用的是tomcat預設編碼格式iso-8859-1。但出現的亂碼問題是:句號,逗號,等特殊符號變成了亂碼,漢字如果數量為奇數,則會出現亂碼,偶數則解析正常。
解決方式:
下載commons-fileupload-1.1.1.jar 這個版本的jar已經解決了這些bug。但是取出內容時仍然需要對取出的字元進行從iso8859-1到utf-8轉碼。已經能得到正常所有漢字以及字元。
Java代碼關於url請求,接受參數的亂碼
url的編碼格式,取決於上面所說的URIEncoding=」UTF-8」。如果設定了這個編碼格式,則意味著所有到url的漢字參數,都必須進行編碼才可以。否則得到的漢字參數值都是亂碼,例如一個鏈接:

Response.sendDerect(「/a.jsp?name=玫瑰妮子」);
而在a.jsp裡面直接使用 String name = request.getParameter("name");

得到的就是亂碼。因為規定了必須是utf-8才可以,所以,這個轉向應該這樣寫:

Response.sendDerect(「/a.jsp?name=URLEncode.encode(「玫瑰妮子」,」utf-8」);才可以。
如果不設置這個參數URIEncoding=」UTF-8」,會怎麼樣呢? 不設置則就使用了預設的編碼格式iso8859-1。問題又出來了,第一就是參數值的個數如果是奇數個數,則就可以正常解析,如果使偶數個數,得到最後字元就是亂碼。還有就是如果最後一個字元如果是英文,則就能正常解析,但中文的標點符號仍出現亂碼。權宜之計,如果您的參數中沒有中文標點符號,則可以在參數值最後加一個英文符號來解決亂碼問題,得到參數後再去掉這個最後面的符號。也可以湊或使用。
腳本代碼關於url請求,接受到的參數亂碼
腳本中也會進行頁面轉向的控制,也會涉及到附帶參數,並在接受頁面解析這個參數的情況。如果這個漢字參數不進行URIEncoding=」UTF-8」所指定的編碼處理,則接受頁面接受到的漢字也是亂碼。腳本處理編碼比較麻煩,必須有相應的編碼腳本對應文件,然後調用腳本中的方法對漢字進行編碼即可。
關於jsp在MyEclipse中打開的亂碼問題
對於一個已經存在的項目,Jsp文件的存儲格式可能是utf-8。如果新安裝的eclipse,則預設打開使用的編碼格式都是iso8859-1。所以導致jsp裡面的漢字出現亂碼。這個亂碼比較容易解決,直接到eclipse3.1的偏好設置裡面找到general-〉edidor,設置為您的文件打開編碼為utf-8即可。Eclipse會自動重新以新的編碼格式打開。漢字即可正常顯示。
關於html頁面在eclipse中打開出現亂碼情況
由於大部分頁面都是由dreamweaver製作,其存儲格式跟eclipse的識別有差別導致。一般這種情況,在eclipse中新建一個jsp,直接從dreamweaver復制頁面內容粘貼到jsp即可。

⑧ java web工程裡面中文亂碼了

如果是用的tomact做容器,打開server.xml,看一下是否編碼設置正確。如下URIEncoding的值:

<Connectorport="8080"protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"URIEncoding="UTF-8"/>

⑨ javaweb項目,欄位經常變動,有什麼好的解決方案嗎

我能想到的也是做動態欄位,再弄一個表。等著看看誰有好想法

⑩ java web 登錄次數限制,該如何解決

java web 登錄次數限制 一個用戶登錄系統,如果他一分鍾之內連續登錄 3 次,就讓他在 15 分鍾之內無法再登錄, ------解決方案-------------------------------------------------------- 將用戶的每次登錄都記入登錄日誌表 每次登錄的時候,去查最近15 分鍾內,是否存在連續3 次登錄發生在一分鍾之內的 ------解決方案-------------------------------------------------------- 呵呵,好方法啊.但這樣會不會資料庫伺服器很累啊 ------解決方案--------------------------------------------------------引用: 將用戶的每次登錄都記入登錄日誌表 每次登錄的時候,去查最近15 分鍾內,是否存在連續3 次登錄發生在一分鍾之內的 這是個方法. 不過總查資料庫應該是有些不妥的.! 不過暫時還想不到更好的辦法.! 再去想想 ------解決方案-------------------------------------------------------- 如果以後不需要日誌查詢和審計,可以使用緩存而不是資料庫,把每次登陸的信息(登陸名、 時間) 這些放入緩存。然後每次登陸時查詢緩存就可以了。 ------解決方案-------------------------------------------------------- ------解決方案-------------------------------------------------------- 如果你不想用資料庫的形式的話,用session 存下試試。 先聲明下,我沒用過: 在用戶登錄時候,如果成功不記錄session,如果登錄不成功,記錄下session +1; 到第三次,就不讓登錄了。session 的有效期設置為15 分鍾。.setMaxInactiveInterval(15