車用鋰電池的關鍵材料──鈷在需求增溫、供給短缺的帶動下，年初迄今報價已狂飆135%，但認為鈷價可能漲到外太空的避險基金和投機客要小心了，因為剛果的礦脈2018年將開出大量產能，屆時供需景況驟變、原本飛龍在天的鈷價恐墜回地球。

英國金融時報14日報導，全球最大鈷生產商嘉能可（Glencore Plc）位於剛果共和國的加丹加（Katanga）礦場，在花費4.3億美元整治機台後，明年就可上線產鈷，預計市場將因此增加最多22,000公噸的供應量。目前鈷的全球年產量約在100,000公噸左右。

高盛分析師指出，加丹加礦場重新上線，將明顯改變供需狀態、終結短缺，預計鈷的供給量到了2019年底，都能充分滿足需求。

鈷是銅和鎳的副產品。原物料價格於2015年底慘崩之際，數個銅礦和鎳礦都被迫縮減產能，而嘉能可也在市況最為嚴峻的時候決定暫時封閉加丹加礦場。巴西礦商Votorantim Metais則跟著在2016年初暫停了鎳、鈷的生產線。

不過，中國預定要在2020年讓500萬輛電動車上路，特斯拉（Tesla Motors）首款平價電動車接單接到手軟，卻讓車用電池的需求水漲船高。根據倫敦原物料顧問機構CRU分析師Edward Spencer的數據，高級鈷的報價已拉高至每磅27美元。

看準這個趨勢，業界開始有消息傳出，括瑞士專門關注採礦業的創投機構Pala Investments，以及中國大型原物料基金上海混沌投資（Shanghai Chaos Investment）在內的六家機構，因看好電動車業者的需求，至今已囤積了約6,000公噸的鈷，價值多達2.8億美元，相當於去年全球總產量的17%。（註：混沌投資的控股股東是被稱為「中國索羅斯」的葛衛東。）（）

路透社2月14日報導，根據電池用鈷鹽製造商eCobalt Solutions的預估，到了2020年，75%的鋰電池都將含有鈷，因為鈷能增加電動車每一次充電的里程數。

 

不過，由於98%的鈷都是銅、鎳礦的副產品，因此投資人很難買到純粹的鈷。歐洲一名交易員透露，私募股權基金業者雖然考慮過倫敦金屬交易所（LME）的鈷合約，但流動性卻不足，難以滿足投資機構的龐大需求。因此，許多基金公司決定直接囤積鈷、靜待價格上漲，設定的目標價則是每磅25美元，甚至更多。

（本文內容由授權使用。圖片出處：Wikipedia）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

靜態文件(css,js,html等類型文件)通常位於 web根目錄下，而ASP.Net Core框架默認內容根目錄下的wwwroot文件夾為web根目錄。這裏簡單解釋下內容根目錄：實際就是指包含可執行程序exe,程序集dll，配置文件json,xml等的文件目錄.

1.訪問web根目錄靜態文件

正常情況下，靜態文件是無法直接訪問的，需要我們添加如下靜態文件的中間件，這是框架內置自帶的。

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseStaticFiles(); 
}

然後我們就可通過web根目錄的相關路徑訪問靜態文件。例如，Web 應用程序項目模板包含 wwwroot 文件夾中的多個文件夾 ：

• wwwroot
  • css
  • images
  • js

然後就可以通過如下格式的URL:https://localhost:5001/images/123.jpg 來訪問靜態文件。

2.訪問web根目錄之外的靜態文件

有些時候，可能有些靜態文件我們並不是放在web根目錄下面的。例如如下一個目錄層次結構，其中要提供的靜態文件位於 Web 根目錄之外：

• wwwroot
  • css
  • images
  • js
• Content
  
  • images
    • img.jpg

如果通過URL:https://localhost:5001/Content/images/img.jpg是無法訪問的，這個時候我們就需要額外的指定靜態文件路徑：

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
           //wwroot目錄下靜態文件
 app.UseStaticFiles(); //wwwroot之外的靜態文件 app.UseStaticFiles(new StaticFileOptions { //指定實際物理路徑 FileProvider = new PhysicalFileProvider(Path.Combine(Directory.GetCurrentDirectory(), @"Content/images")), //設置URL請求的文件路徑 RequestPath = new Microsoft.AspNetCore.Http.PathString("/MyStaticFiles") }); }

然後就可以通過如下格式的URL:https://localhost:5001/MyStaticFiles/img.jpg 來訪問靜態文件。

3.提供默認文件

UseDefaultFiles中間件用於啟用默認文件的功能，例如我們打開一個網站只輸入網站地址，就會自動跳出網站首頁。這裏的網站首頁實際就相當於一個默認文件。

ASP.Net Core為我們簡化了默認文件的搜索功能，我們只需要添加中間件即可。

public void Configure(IApplicationBuilder app)
{
    app.UseDefaultFiles();
    app.UseStaticFiles();
}

要提供默認文件，必須在 UseStaticFiles 前調用 UseDefaultFiles。 UseDefaultFiles 實際上用於重寫 URL，不提供文件。 通過 UseStaticFiles 啟用靜態文件中間件來提供文件。

 UseDefaultFiles 默認支持以下幾種類型文件：

• default.htm
• default.html
• index.htm
• index.html

當然，框架也支持自定義默認文件，感興趣的同學可以研究一下。

例如如下一個目錄層次結構：

• wwwroot
  • Index.html
  • css
  • images
  • js

• 通過URL:https://localhost:5001/訪問時，會自動跳轉到並打開Index.html頁面

4.啟用目錄瀏覽功能

出於安全考慮，目錄瀏覽默認處於禁用狀態，需通過添加UseDirectoryBrowser中間件的方式開啟。

public void Configure(IApplicationBuilder app)
{
    //默認文件
 app.UseDefaultFiles(); //靜態文件  app.UseStaticFiles(); //目錄瀏覽  app.UseDirectoryBrowser(); }

另外，需要註冊目錄瀏覽的服務

public void ConfigureServices(IServiceCollection services)
{
    services.AddDirectoryBrowser();
}

例如如下一個目錄層次結構：

   wwwroot

• 123.jpg
• 234.jpg

通過URL:https://localhost:5001/訪問時，由於wwwroot根目錄下不存在默認文件，所以會打開文件目錄。

 

 5.UseFileServer

UseFileServer 結合了 UseStaticFiles、UseDefaultFiles 和 UseDirectoryBrowser（可選）的功能。

例如以下目錄層次結構：

• wwwroot
  • 123.jpg
  • 234.jpg
    
• Content
  • images
    • 234.jpg

以下代碼啟用靜態文件、默認文件和及 MyStaticFiles 的目錄瀏覽：

public void Configure(IApplicationBuilder app)
{
    //靜態文件
    app.UseStaticFiles(); 

    app.UseFileServer(new FileServerOptions { FileProvider = new PhysicalFileProvider( Path.Combine(Directory.GetCurrentDirectory(), "Content")), RequestPath = "/MyStaticFiles",
 //啟用目錄 EnableDirectoryBrowsing = true }); }

EnableDirectoryBrowsing 屬性值為 true 時必須註冊服務 AddDirectoryBrowser：

public void ConfigureServices(IServiceCollection services)
{
    services.AddDirectoryBrowser();
}

 

通過URL:https://localhost:5001/MyStaticFiles/訪問時，由於目錄下不存在默認文件，所以會打開文件目錄。

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

說明：設計模式系列文章是讀劉偉所著《設計模式的藝術之道(軟件開發人員內功修鍊之道)》一書的閱讀筆記。個人感覺這本書講的不錯，有興趣推薦讀一讀。詳細內容也可以看看此書作者的博客https://blog.csdn.net/LoveLion/article/details/17517213

模式概述

樹形結構在軟件中隨處可見，例如操作系統中的目錄結構、應用軟件中的菜單、辦公系統中的公司組織結構等等，如何運用面向對象的方式來處理這種樹形結構是組合模式需要解決的問題。組合模式通過一種巧妙的設計方案使得用戶可以一致性地處理整個樹形結構或者樹形結構的一部分，也可以一致性地處理樹形結構中的恭弘=叶 恭弘子節點（不包含子節點的節點）和容器節點（包含子節點的節點）。

模式定義

組合模式(Composite Pattern)：組合多個對象形成樹形結構以表示具有“整體—部分”關係的層次結構。組合模式對單個對象（即恭弘=叶 恭弘子對象）和組合對象（即容器對象）的使用具有一致性，組合模式又可以稱為“整體—部分”(Part-Whole)模式，它是一種對象結構型模式。

模式結構圖

組合模式結構圖如下所示：

在組合模式結構圖中包含如下幾個角色：

• Component（抽象構件）：它可以是接口或抽象類，為恭弘=叶 恭弘子構件和容器構件對象聲明接口，在該角色中可以包含所有子類共有行為的聲明和實現。在抽象構件中定義了訪問及管理它的子構件的方法，如增加子構件、刪除子構件、獲取子構件等。

• Leaf（恭弘=叶 恭弘子構件）：它在組合結構中表示恭弘=叶 恭弘子節點對象，恭弘=叶 恭弘子節點沒有子節點，它實現了在抽象構件中定義的行為。對於那些訪問及管理子構件的方法，可以通過異常等方式進行處理。

• Composite（容器構件）：它在組合結構中表示容器節點對象，容器節點包含子節點，其子節點可以是恭弘=叶 恭弘子節點，也可以是容器節點，它提供一個集合用於存儲子節點，實現了在抽象構件中定義的行為，包括那些訪問及管理子構件的方法，在其業務方法中可以遞歸調用其子節點的業務方法。

組合模式的關鍵是定義了一個抽象構件類，它既可以代表恭弘=叶 恭弘子，又可以代表容器，而客戶端針對該抽象構件類進行編程，無須知道它到底表示的是恭弘=叶 恭弘子還是容器，可以對其進行統一處理。同時容器對象與抽象構件類之間還建立一個聚合關聯關係，在容器對象中既可以包含恭弘=叶 恭弘子，也可以包含容器，以此實現遞歸組合，形成一個樹形結構。

模式偽代碼

對於客戶端而言，一般針對抽象構件編程，而無須關心其具體子類是容器構件還是恭弘=叶 恭弘子構件。抽象構建類典型代碼如下：

public abstract class Component {
    public abstract void add(Component c); //增加成員

    public abstract void remove(Component c); //刪除成員

    public abstract Component getChild(int i); //獲取成員

    public abstract void operation();  //業務方法
}

如果繼承抽象構件的是恭弘=叶 恭弘子構件，則其典型代碼如下所示：

public class Leaf extends Component {
    @Override
    public void add(Component c) {
        //異常處理或錯誤提示 
    }

    @Override
    public void remove(Component c) {
        //異常處理或錯誤提示 
    }

    @Override
    public Component getChild(int i) {
        //異常處理或錯誤提示 
        return null;
    }

    @Override
    public void operation() {
        //恭弘=叶 恭弘子構件具體業務方法的實現
    }
}

如果繼承抽象構件的是容器構件，則其典型代碼如下所示:

public class Composite extends Component {

    private List<Component> list = new ArrayList<>();

    @Override
    public void add(Component c) {
        list.add(c);
    }

    @Override
    public void remove(Component c) {
        list.remove(c);
    }

    @Override
    public Component getChild(int i) {
        return (Component) list.get(i);
    }

    @Override
    public void operation() {
        //容器構件具體業務方法的實現
        //遞歸調用成員構件的業務方法
        for (Object obj : list) {
            ((Component) obj).operation();
        }
    }
}

客戶端對抽象構件類進行編程

public class Client {
    public static void main(String[] args) {
        Component component;
        component = new Leaf();
        //component = new Composite();

        // 無須知道到底是恭弘=叶 恭弘子還是容器
        // 可以對其進行統一處理
        component.operation();
    }
}

模式簡化

透明組合模式

透明組合模式中，抽象構件Component中聲明了所有用於管理成員對象的方法，包括add()、remove()以及getChild()等方法，這樣做的好處是確保所有的構件類都有相同的接口。在客戶端看來，恭弘=叶 恭弘子對象與容器對象所提供的方法是一致的，客戶端可以相同地對待所有的對象。透明組合模式也是組合模式的標準形式。

透明組合模式的完整結構圖如下：

也可以將恭弘=叶 恭弘子構件的add()、remove()等方法的實現代碼移至Component中，由Component提供統一的默認實現，這樣子類就不必強制去實現管理子Component。代碼如下所示：

public abstract class Component {
    public void add(Component c) {
        throw new RuntimeException("不支持的操作");
    }

    public void remove(Component c) {
        throw new RuntimeException("不支持的操作");
    }

    public Component getChild(int i) {
        throw new RuntimeException("不支持的操作");
    }

    public abstract void operation();  //業務方法
}

透明組合模式的缺點是不夠安全，因為恭弘=叶 恭弘子對象和容器對象在本質上是有區別的。恭弘=叶 恭弘子對象不可能有下一個層次的對象，即不可能包含成員對象，因此為其提供add()、remove()以及getChild()等方法是沒有意義的，這在編譯階段不會出錯，但在運行階段如果調用這些方法可能會出錯（如果沒有提供相應的錯誤處理代碼）。

安全組合模式

安全組合模式中，在抽象構件Component中沒有聲明任何用於管理成員對象的方法，而是在Composite類中聲明並實現這些方法。

安全組合模式的完整結構圖如下：

此時Component就應該這樣定義了

public abstract class Component {
    // 業務方法
    public abstract void operation();
}

安全組合模式的缺點是不夠透明，因為恭弘=叶 恭弘子構件和容器構件具有不同的方法，且容器構件中那些用於管理成員對象的方法沒有在抽象構件類中定義，因此客戶端不能完全針對抽象編程，必須有區別地對待恭弘=叶 恭弘子構件和容器構件。在實際應用中，安全組合模式的使用頻率也非常高，在Java AWT中使用的組合模式就是安全組合模式。

模式應用

模式在JDK中的應用

Java SE中的AWT和Swing包的設計就基於組合模式，在這些界麵包中為用戶提供了大量的容器構件（如Container）和成員構件（如Checkbox、Button和TextComponent等），其結構如下圖所示

Component類是抽象構件，Checkbox、Button和TextComponent是恭弘=叶 恭弘子構件，而Container是容器構件，在AWT中包含的恭弘=叶 恭弘子構件還有很多。在一個容器構件中可以包含恭弘=叶 恭弘子構件，也可以繼續包含容器構件，這些恭弘=叶 恭弘子構件和容器構件一起組成了複雜的GUI界面。除此以外，在XML解析、組織結構樹處理、文件系統設計等領域，組合模式都得到了廣泛應用。

模式在開源項目中的應用

Spring中org.springframework.web.method.support.HandlerMethodArgumentResolver使用了安全組合模式。提取關鍵代碼如下：

public interface HandlerMethodArgumentResolver {
    
    boolean supportsParameter(MethodParameter parameter);

    Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
                           NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception;

}

再看下它的一個實現類org.springframework.web.method.support.HandlerMethodArgumentResolverComposite

public class HandlerMethodArgumentResolverComposite implements HandlerMethodArgumentResolver {


    private final List<HandlerMethodArgumentResolver> argumentResolvers = new LinkedList<>();

    /**
     * Add the given {@link HandlerMethodArgumentResolver}.
     */
    public HandlerMethodArgumentResolverComposite addResolver(HandlerMethodArgumentResolver resolver) {
        this.argumentResolvers.add(resolver);
        return this;
    }

    /**
     * Add the given {@link HandlerMethodArgumentResolver HandlerMethodArgumentResolvers}.
     */
    public HandlerMethodArgumentResolverComposite addResolvers(
            @Nullable HandlerMethodArgumentResolver... resolvers) {

        if (resolvers != null) {
            Collections.addAll(this.argumentResolvers, resolvers);
        }
        return this;
    }

    /**
     * Clear the list of configured resolvers.
     */
    public void clear() {
        this.argumentResolvers.clear();
    }


    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        return getArgumentResolver(parameter) != null;
    }


    @Override
    public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
                                  NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {

        HandlerMethodArgumentResolver resolver = getArgumentResolver(parameter);
        if (resolver == null) {
            throw new IllegalArgumentException("Unsupported parameter type [" +
                    parameter.getParameterType().getName() + "]. supportsParameter should be called first.");
        }
        return resolver.resolveArgument(parameter, mavContainer, webRequest, binderFactory);
    }
}

模式總結

主要優點

1. 組合模式可以清楚地定義分層次的複雜對象，表示對象的全部或部分層次，它讓客戶端忽略了層次的差異，方便對整個層次結構進行控制。

2. 客戶端可以一致地使用一個組合結構或其中單個對象，不必關心處理的是單個對象還是整個組合結構，簡化了客戶端代碼。

3. 組合模式為樹形結構的面向對象實現提供了一種靈活的解決方案，通過恭弘=叶 恭弘子對象和容器對象的遞歸組合，可以形成複雜的樹形結構，但對樹形結構的控制卻非常簡單。

適用場景

(1) 在具有整體和部分的層次結構中，希望通過一種方式忽略整體與部分的差異，客戶端可以一致地對待它們。

(2) 在一個使用面向對象語言開發的系統中需要處理一個樹形結構。

(3) 在一個系統中能夠分離出恭弘=叶 恭弘子對象和容器對象，而且它們的類型不固定，需要增加一些新的類型。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

最近有個小夥伴在群里問美團數據怎麼獲取，而且她只要火鍋數據，她在上海，只要求抓上海美團火鍋的數據，而且要求也不高，只要100條，想做個簡單的分析，相關的字段如下圖所示。

乍一看，這個問題還真的是蠻難的，畢竟美團也不是那麼好抓，什麼驗證碼，模擬登陸等一大堆拂面而來，嚇得小夥伴都倒地了。

通過F12查看，抓包，分析URL，找規律，等等操作。

不過白慌，今天小編給大家介紹一個小技巧，另闢蹊徑去搞定美團的數據，這裏需要用到抓包工具Fiddler。講道理，之前我開始接觸網絡爬蟲的時候也沒有聽過這個東東，後來就慢慢知道了，而且它真的蠻實用的，建議大家都能學會用它。這個工具專門用於抓包，而且其安裝包也非常小，如下圖所示。

接下來，我們開始進行抓取信息。

1、在Fiddler的左側找到meituan網站的鏈接，如下圖所示。鏈接的左邊返回的response（響應）的文件類型，可以看到是JSON文件，爾後雙擊這一行鏈接。

2、此時在右側會显示下圖的界面，點擊黃色區域內的那串英文“Responsebody is encoded. Click to decode.”意思是response是加密的，點擊此處進行解碼，對返回的網頁進行解碼。

3、此時會彈出下圖所示的界面，在WebView中可以看到返回的數據，與網頁中的內容對應一致。

4、不過美團網限制一頁最多显示32條火鍋信息，如下圖所示。

5、如果我想獲取100條信息的話，那得前後找4頁，才能夠滿足要求。有沒有辦法讓其一次性多显示一些數據呢？答案是可以的，操作方法如下。

在左側找到對應的美團網鏈接，然後點擊右鍵一次選擇CopyàJustUrl，如下圖所示。

7、將得到的URL放到瀏覽器中去進行訪問，如下圖所示。可以看到limit=32，即代表可以獲取到32條相關的火鍋信息，並且返回的內容和Fiddler抓包工具返回的信息是一致的。

8、此時，我們直接在瀏覽器中將limit=32這個參數改為limit=100，也就是說將32更改為100，讓其一次性返回100條火鍋數據，天助我也，竟然可以一次性訪問到，如下圖所示。就這樣，輕輕鬆松的拿到了一百條數據。

9、接下來，可以將瀏覽器返回的數據進行Ctrl+A全部選中，放到一個本地文件中去，存為txt格式，在sublime中打開，如下圖所示。

10、其實乍一看覺得很亂，其實它就是一個JSON文件，剩下的工作就是對這個JSON文件做字符串的提取，寫個代碼，提取我們的目標信息，包括店門、星級、評論數、關鍵詞、地址、人均消費等，如下圖所示。

11、運行程序之後，我們會得到一個txt文件，列與列之間以製表符分開，如下圖所示。

12、在txt文件中看上去很是費勁，將其導入到Excel文件中去，就清晰多了，如下圖所示。接下來就可以很方便的對數據做分析什麼的了。

13、至此，抓取美團火鍋數據的簡易方法就介紹到這裏了，希望小夥伴們都可以學會，以後抓取類似的數據就不用找他人幫你寫程序啦~~

14、關於本文涉及的部分代碼，小編已經上傳到github了，後台回復【美團火鍋】四個字即可獲取。

看完本文有收穫？請轉發分享給更多的人

IT共享之家

入群請在微信後台回復【入群】

想學習更多Python網絡爬蟲與數據挖掘知識，可前往專業網站：http://pdcfighting.com/

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

一、類註釋

1、打開設置面板：file -> setting -> Editor -> file and code Templates

選擇其中的inclues選項卡，並選擇File header，如圖。不要選擇Files選項卡再設置Class，這樣比較麻煩，而且這樣設置以後沒新建一個類都要自己寫一次Date。

2、在右邊編輯面板插入自己想要的註釋即可。其中${}是變量，需要在變量基本都在編輯款下面的Description，往下拉即可看到。

/*
* @Classname ${NAME}
*
* @Date ${DATE}
*
* @userName
*/

3、新建一個類，看是否自動加了註釋

 

二、方法註釋

1、打開設置面板：file -> setting -> Editor -> Live Templates

 

 2、新建一個Template Group…，命名隨意，假設為bokeyuan，然後選擇該組，點擊新建一個模板Live Template

 

3、名稱建議設為*，文本框輸入自己想要設置的註釋格式，右下角要選擇enter（原本是tab）。

 

 4、留意註釋格式，其中參數要直接寫變量$param$，開頭只有一個*號。寫好之後點擊上圖框中的edit variables

 

其中返回值return使用系統自帶的，下拉可以找到methodReturnType()

 

 

 5、自定義多行參數註釋

IDEA自帶的參數函數methodParameters()產出的註釋格式是這樣的：

/**
      * 
      * @param [a,b,c]
      * @return void
      * @throws 
      */

我們可能需要的是多行參數註釋：

/**
      * 
      * @param a
      * @param b
      * @param c
      * @return void
      * @throws 
      */

這個時候就要使用裏面的groovyScript()函數來自定義格式：

groovyScript("def result=''; def params=\"${_1}\".replaceAll('[\\\\[|\\\\]|\\\\s]', '').split(',').toList(); for(i = 0; i < params.size(); i++) {if(i == 0) result += '* @param ' + params[i] + ' ' + ((i < params.size() - 1) ? '\\n' : '');else result+='  * @param ' + params[i] + ' ' + ((i < params.size() - 1) ? '\\n' : '')}; return result", methodParameters())

直接複製在Expression裏面即可。

 

6、選擇語言，點擊Define勾選Java

 

 

有其他問題可以評論問我哦

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

美國聯邦政府為了推廣電動車，給予電動車買主每人7,500美元（約台幣23萬）的補助，問題是此一補助即將到期，美國電動市或許有崩盤危機。

Barron’s Next 9日報導，汽車銷售暨資訊網站Edmunds悲觀預測（見此），補助終結將摧毀美國電動車車市。當局規定，車商的前20萬名客戶，可以獲得補助，如今特斯拉（Tesla）已售出將近10萬輛電動車，估計明年優惠就會結束。

特斯拉平價車款「Model 3」定價3.5萬美元，扣掉7,500美元補貼之後，買家等於只要付2.75萬美元，差距極為明顯。特斯拉想打入大眾車市，必須對上2萬美元的汽油車和油電混合車，少了優惠之後，兩者價差更為懸殊。

以美國喬治亞州為例，該州取消購買電動車的5,000美元稅務優惠之後，買氣急凍。有稅務優惠時，喬治亞州佔全美電動車銷售的17%；取消之後，銷售比重驟降至2%。Edmunds據此推論，補助結束後，電動車市將崩盤。Edmunds報告指出，高檔電動車較不受稅務優惠影響，但是一般買家會在意補貼。補助終結後，電動車廠必須大砍售價，才能維持買氣。

Edmunds斷言電動車會陷入困境，其他專家不以為然。

The Christian Science Monitor報導，分析師批評Edmunds報告只看稅務優惠，忽略大局。Bloomberg New Energy Finance分析師Salim Morsy說，儘管Model 3較為平價，但是仍不算主流車款，不至於需要稅務優惠才能存活。他認為Model 3是入門款的豪華車，與BMW 3系列或賓士C系列同等級，價格超過多數美國民眾能夠負擔的範圍，因此就算補助結束，買氣或許不受影響。

（本文內容由授權使用。圖片出處：Tesla）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

看好電動車潛力，台中建商與台達電子合作，於新完工大樓採用台達電的電動車充電解決方案，設置兩座通用型快速充電站，充電30分鐘即可上路。

通用型充電站指Tesla之外的電動車皆適用，Tesla則要使用超級充電站（Supercharger），目前僅有台北花博公園有設置Tesla的超級充電站。

2017年1月，台達協助BMW台灣總代理汎德於台北市20處停車場建置40座電動車充電座；4月時又再次為汎德於台北101大樓建置直流和交流充電器。

（首圖來源：public domain CC0）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

應用層協議

應用層協議 (application-layer protocol) 定義了運行在不同端系統上的應用程序進程如何相互傳遞報文，特別是應用層協議定義了:

• 交換的報文類型，例如請求報文和響應報文
• 各種報文類型的語法，如報文中的各個字段及這些字段是如何描述的
• 字段的語義，即這些字段中包含的信息的含義
• 一個進程何時以及如何發送報文，對報文進行響應的規則。

  在本文中主要是講5種重要的應用: Web 、文件傳輸、电子郵件、目錄服務和P2P，我們首先討論 Web應用，不僅因為它是極為流行的應用，而且因為它的應用層協議 HTTP 相對比較簡單並且易於理解。討論完 Web ，我們簡要地討論FTP，因為它與 HTTP 形成了很好的對照 我們接下來討論电子郵件應用，這是因特網上最早的招人喜愛的應用程序。說电子郵件比 Web更複雜，是因為它使用了多個而不是一個應用層協議。在电子郵件之後，我們討論DNS它為因特網提供目錄服務，大多數用戶不直接與 DNS 打交道，而是通過其他的應用(包括Web 、文件傳輸和电子郵件)間接使用它，DNS 很好地說明了一種核心的網絡功能(網絡名字到網絡地址的轉換)是怎樣在因特網的應用層實現的。

HTTP概況

  Web 的應用層協議是超文本傳輸協議 (HyperText Transfer Protocol , HTTP) ，它是Web的核心，HTTP 由兩個程序實現:一個客戶程序和一個服務器程序。客戶程序和服務器程序運行在不同的端系統中，通過交換HTTP報文進行會話。 HTTP 定義了這些報文的結構以及客戶和服務器進行報文交換的方式。HTTP使用TCP作為它的支撐運輸協議(而不是在 UDP 上運行)。HTTP 客戶首先發起一個與服務器的TCP連接，一旦連接建立，該瀏覽器和服務器進程就可以通過套接字接口訪問TCP。

注意：服務器向客戶發送被請求的文件，而不存儲任何關於該客戶的狀態信息，假如某個特定的客戶在短短的幾秒鐘內兩次請求同一個對象，服務器並不會因為剛剛為該客戶提供了該對象就不再做出反應，而是重新發送該對象，就像服務器已經完全忘記不久之前所做過的事一樣，因為 HTTP 服務器並不保存關於客戶的任何信息，所以我們說HTTP是一個無狀態協議 (stateless protocol)

非持續連接和持續連接

  在許多因特網應用程序中，客戶和服務器在一個相當長的時間範圍內通信，其中客戶發出一系列請求並且服務器對每個請求進行響應 依據應用程序以及該應用程序的使用方式，這一系列請求可以以規則的間隔周期性地或者間斷性地一個接一個發出。當這種客戶-服務器的交互是經TCP進行的，應用程序的研製者就需要做一個重要決定，即每個請求/響應對是經一個單獨的 TCP 連接發送，還是所有的請求及其響應經相同的TCP連接發送呢?採用前一種方法，該應用程序被稱為使用非持續連接( non- persistent connection) ;採用后一種方法，該應用程序被稱為使用持續連接( persistent connection)。儘管 HTTP在其默認方式下使用持續連接， HTTP 客戶和服務器也能配置成使用非持續連接。

  非持續連接有一些缺點：首先，必須為每一個請求的對象建立和維護一個全新的連接。對於每個這樣的連接，在客戶和服務器巾都要分配 TCP 的緩衝區和保持 TCP 變量。這給 Web 服務器帶來了嚴重的負擔，因為一台 Web 服務器可能同時服務於數以百計不同的客戶的請求。第二，每一個對象經受兩倍 RTT 的交付時延，即一個RTT 用於創建 TCP ，另一個 RTT 用於請求和接收一個對象。在採用持續連接的情況下，服務器在發送響應后保持該 TCP 連接打開。在相同的客戶與服務器之間的後續請求和響應報文能夠通過相同的連接進行傳送

HTTP報文格式

1. 請求報文

      GET /somedir/page.html HTTP/l.l
      Host: www.someschool.edu
      Connection: close
      User-agent: Mozilla/5.0
      Accept-language: fr

  我們看到該報文由5行組成，每行由一個回車和換行符結束。最後一行后再附加一個回車換行。雖然這個特定的報文僅有5行，但一個請求報文能夠具有更多的行或者至少為一行。HTTP 請求報文的第一行叫做請求行 (request line) ，其後繼的行叫做首部行( headerline)。請求行有3個字段:方法字段、URL字段和HTTP版本字段。方法宇段可以取幾種不同的值，包括 GET、POST、HEAD、PUT和DELETE。絕大部分的 HTTP 請求報文使用GET方法，當瀏覽器請求一個對象時，使用 GET 方法，在 URL 字段帶有請求對象的標識。在本例中，該瀏覽器正在請求對象/somedirl page. html 其版本字段是自解釋的;在本例中，瀏覽器實現的是 HTTP/ l. 版本。

  現在我們看看本例的首部行：首部行 Host: www. someschool. edu 指明了對象所在的主機。你也許認為該首部行是不必要的，因為在該主機中已經有一條 TCP 連接存在了，但是，該首部行提供的信息是 Web 代理高速緩存所要求的，通過包含 Connection: close 首部行，該瀏覽器告訴服務器不希望麻煩地使用持續連接，它要求服務器在發送完被請求的對象后就關閉這條連接。User- agent: 首部行用來指明用戶代理，即向服務器發送請求的瀏覽器的類型。這裏瀏覽器類型是 Mozilla/5. 0，即Firefox 瀏覽器，這個首部行是有用的，因為服務器可以有效地為不同類型的用戶代理，實際發送相同對象的不同版本 (每個版本都由相同的URL尋址)。最後Accept-language：首部行表示用戶想得到該對象的法語版本(如果服務器中有這樣的對象的話)；否則，服務器應當發送它的默認版本 Accept -language：首部行僅是 HTTP 中可用的眾多內容協商首部之一。

  HEAD方法類似於GET方法，當服務器收到使用HEAD方法的請求時，將會用一個HTTP報文進行響應，但是並不返回請求對象，應用程序開發者常用HEAD方法進行調試，跟蹤PUT方法常與Web發行工具聯合使用，它允許用戶上傳對象到指定的 Web 服務器上指定的路徑(目錄)。PUT方法也被那些需要向 Web 服務器上傳對象的應用程序使用。DELETE 方法允許用戶或者應用程序刪除 Web 服務器上的對象

1. HTTP響應報文
   下面我們提供了一條典型的HTTP響應報文 該響應報文可以是對剛剛討論的例子中請求報文的響應：

HTTP/ 1. 1 200 OK
Connection: close 
Date: Tue , 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue , 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html 

(data data data data data ...) 

  我們仔細看一下這個響應報文 它有三個部分：一個初始狀態行 (sLatus line) ，6個首部行 (header 1ine) ，然後是實體體 (enLity body) 實體體部分是報文的主要部分，即它包含了所請求的對象本身(表示為 dala dala data data …）。 狀態行有3個字段:協議版本字段、狀態碼和相應狀態信息。在這個例子中，狀態行指示服務器正在使用 HTTP/l.1，並且一切正常(即服務器已經找到並正在發送所請求的對象)。

  我們現在來看看首部行。服務器用 Connection: close 首部行告訴客戶，發送完報文後將關閉該 TCP 連接。Date: 首部行指示服務器產生併發送該響應報文的日期和時間。值得一提的是，這個時間不是指對象創建或者最後修改的時間；而是服務器從它的文件系統中檢索到該對象，插入到響應報文，併發送該響應報文的時間。Server: 首部行指示該報文是由一台 Apache Web 服務器產生的，它類似於 HTTP 請求報文中的 User- agent 首部行。Last- Modified: 首部行指示了對象創建或者最後修改的日期和時間。Lasl-Modified: 首部行對既可能在本地客戶也可能在網絡緩存服務器上的對象緩存來說非常重要。下面將會介紹緩存服務器(也叫代理服務器)。Content- Length: 首部行指示了被發送對象中的字節數；Conlent- Type: 首部行指示了實體體中的對象是 HTML 文本 (該對象類型應該正式地由 Conlent- Type: 首部行而不是用文件擴展名來指示。

Web 緩存

  Web緩存器 (Web cache)也叫代理服務器 (proxy server)，它是能夠代表初始 Web 服務器來滿足 HTTP 請求的網絡實體。Web 緩存器有自己的磁盤存儲空間，並在存儲空間中保存最近請求過的對象的副本 如圖 2-11 所示，可以配置用戶的瀏覽器，使得用戶的所有 HTTP請求首先指向 Web 緩存器。一旦某瀏覽器被配置，每個對某對象的瀏覽器請求首先被定向到該 Web 緩存器。舉例來說，假設瀏覽器正在請求對象 http://www.someschool. edu/ campus.giI.將會發生如下情況:

• 瀏覽器建立一個到Web緩存器的TCP連接，並向 Web 緩存器中的對象發送一個HTTP請求
• Web 緩存器進行檢查，看看本地是否存儲了該對象副本 如果有， Web 緩存器就向客戶瀏覽器用 HTTP 響應報文返回該對象
• 如果 Web 緩存器中沒有該對象，它就打開一個與該對象的初始服務器(如www. someschool. edu)，TCP 連接 Web 緩存器則在這個緩存器到服務器的TCP連接上發送一個對該對象的 HTTP 請求，在收到該請求后，初始服務器向該 Web緩存器發送具有該對象的 HTTP響應
• 當 Web 緩存器接收到該對象時，它在本地存儲空間存儲一份副本，並向客戶的瀏覽器用盯TP 響應報文發送該副本(通過現有的客戶瀏覽器和 Web 緩存器之間的TCP連接)

DHCP協議

  DHCP(Dynamic Host Configuration Protocol: 動態主機設置協議，DHCP是一個局域網協議，DHCP是應用UDP協議的應用層協議。使用UDP協議工作，主要有兩個用途：給內部網絡或網絡服務供應商自動分配IP地址，給用戶或者內部網絡管理員作為對所有計算機作中央管理的手段。
對於一個 臨時設備，是如何知道自己的IP地址的？
  DHCP服務器監聽默認端口：67，主機使用UDP協議廣播DHCP發現報文，DHCP服務器發出DHCP提供報文，主機向DHCP服務器發出DHCP請求報文，DHCP服務器回應並提供IP地址。

HTTPS

  由於HTTP是明文傳輸的，則HTTPS(Secure)是安全的HTTP協議，默認端口為443，http(s): //<主機>:<端口>/<路徑>

• A、B是擁有一定數學關係的一組秘鑰
  • 私鑰：私鑰自己使用，不對外公開
  • 公鑰：公鑰給大家使用，對外公開

    使用公鑰加密，使用私鑰解密。

• 数字證書是可信任組織頒發給特定對象的認證

證書格式、版本號

證書序列號

簽名算法

有效期

對象名稱

對象公開秘鑰

…

• SSL(Secure Sockets Layer: 安全套接層)
  • 數據安全和數據完整
  • 對傳輸層數據進行加密後傳輸

HTTPS 原理

1. 客戶端將它所支持的算法列表和一個用作產生密鑰的隨機數發送給服務器 ；
2. 服務器從算法列表中選擇一種加密算法，並將它和一份包含服務器公用密鑰的證書發送給客戶端；該證書還包含了用於認證目的的服務器標識，服務器同時還提供了一個用作產生密鑰的隨機數；
3. 客戶端對服務器的證書進行驗證（有關驗證證書，可以參考数字簽名），並抽取服務器的公用密鑰；然後，再產生一個稱作 pre_master_secret 的隨機密碼串，並使用服務器的公用密鑰對其進行加密（參考非對稱加 / 解密），並將加密后的信息發送給服務器 ；
4. 客戶端與服務器端根據 pre_master_secret 以及客戶端與服務器的隨機數值獨立計算出加密和 MAC密鑰（參考 DH密鑰交換算法）；
5. 客戶端將所有握手消息的 MAC 值發送給服務器；
6. 服務器將所有握手消息的 MAC 值發送給客戶端

文件傳輸協議：FTP

  在一個典型的FTP會話中，用戶坐在一台主機(本地主機)前面，向一台遠程主機傳輸(或接收來自遠程主機的)文件 為使用戶能訪問它的遠程賬戶，用戶必須提供一個用戶標識和口令 在提供了這種授權信息后，用戶就能從本地文件系統向遠程主機文件系統傳送文件，反之亦然 如圖 2-14 所示，用戶通過一個FTP用戶代理與FTP交互。該用戶首先提供遠程主機的主機名，使本地主機的FTP客戶進程建立一個到遠程主機FTP服務器進程的 TCP 連接。該用戶接着提供用戶標識和口令，作為 FTP 命令的一部分在該 TCP連接上傳送。一旦該服務器向該用戶授權，用戶可以將存放在本地文件系統中的一個或者多個文件複製到遠程文件系統(反之亦然)。

  HTTP和FTP 都是文件傳輸協議，並且有很多共同的特點，例如，它們都運行在 TCP上，然而，這兩個應用層協議也有一些重要的區別 其中最顯著的就是FTP 使用了兩個并行的 TCP 連接來傳輸文件，一個是控制連接 (control connection) ，一個是數據連接( data connection) 。控制連接用於在兩主機之間傳輸控制信息，如用戶標識、口令、改變遠程目錄的命令以及”存放 (put) “和”獲取 (get)”文件的命令。數據連接用於實際發送一個文件，因為FTP協議使用一個獨立的控制連接，所以我們也稱FTP的控制信息是帶外(out-of-band)傳送的。如你所知，HTTP協議是在傳輸文件的同一個 TCP 連接中發送請求和響應首部行的 因此，HTTP也可以說是帶內 (in-band) 發送控制信息的。FTP協議的控制連接和數據連接如圖二 15 所示：

  當用戶主機與遠程主機開始一個FTP會話時，FTP的客戶(用戶)端首先在服務器21號端口與服務器(遠程主機)端發起一個用於控制的 TCP 連接。FTP的客戶端也通過該控制連接發送用戶的標識和口令，發送改變遠程目錄的命令，當FTP的服務器端從該連接上收到一個文件傳輸的命令后(無論是向還是來自遠程主機) ，就發起一個到客戶端的 TCP 數據連接 FTP 在該數據連接上準確地傳送一個文件，然後關閉該連接。在同一個會話期間，如果用戶還需要傳輸另一個文件，FTP則打開另一個數據連接，因而對FTP傳輸而言，控制連接貫穿了整個用戶會話期間，但是對會話中的每一次文件傳輸都需要建立一個新的數據連接(即數據連接是非持續的)。

  FTP服務器必須在整個會話期間保留用戶的狀態(state) 特別是，服務器必須把特定的用戶賬戶與控制連接聯繫起來，隨着用戶在遠程目錄樹上徘徊，服務器必須追蹤用戶在遠程目錄樹上的當前位置，對每個進行中的用戶會話的狀態信息進行追蹤，大大限制了FTP同時維持的會話總數。而另一方面，前面講過 HTTP 是無狀態的，即它不必對任何用戶狀態進行追蹤。

因特網中的电子郵件

  圖2-16 給出了因特網电子郵件系統的總體情況，從該圖中我們可以看到它有3個主要組成部分: 用戶代理( user agenl) 、郵件服務器 (mail server) 簡單郵件傳輸協議(Simple Mai] Transfer Prolocol , SMTP) 。

SMTP 是因特網电子郵件中主要的應用層協議，它使用 TCP 可靠數據傳輸服務，從發送方的郵件服務器向接收方的郵件服務器發送郵件，像大多數應用層協議一樣， SMTP有兩個部分:運行在發送方郵件服務器的客戶端和運行在接收方郵件服務器的服務器端，每台郵件服務器上既運行 SMTP 的客戶端也運行 SMTP 的服務器端 。當一個郵件服務器向其他郵件服務器發送郵件時，它就表現為 SMTP 的客戶;當郵件服務器從其他郵件服務器上接收郵件時，它就表現為SMTP的服務器。目前有一些流行的郵件訪問協議，包括第三版的郵局協議 (POSl OfficeProtocol-Version 3 , POP3)、因特網郵件訪問協議 (Intemet Mail Access Protocol , IMAP)以及 HTTP。

總結：應用層為操作系統或網絡應用程序提供訪問網絡服務的接口。數據傳輸基本單位為報文；包含的主要協議：FTP（文件傳送協議）、Telnet（遠程登錄協議）、DNS（域名解析協議）、SMTP（郵件傳送協議），POP3協議（郵局協議），HTTP協議（Hyper Text Transfer Protocol）。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!