java密碼復雜度

A. java線程的作用什麼

線程同步我們可以在計算機上運行各種計算機軟體程序。每一個運行的程序可能包括多個獨立運行的線程（Thread）。 線程（Thread）是一份獨立運行的程序，有自己專用的運行棧。線程有可能和其他線程共享一些資源，比如，內存，文件，資料庫等。

當多個線程同時讀寫同一份共享資源的時候，可能會引起沖突。這時候，我們需要引入線程「同步」機制，即各位線程之間要有個先來後到，不能一窩蜂擠上去搶作一團。

同步這個詞是從英文synchronize（使同時發生）翻譯過來的。我也不明白為什麼要用這個很容易引起誤解的詞。既然大家都這么用，咱們也就只好這么將就。

線程同步的真實意思和字面意思恰好相反。線程同步的真實意思，其實是「排隊」：幾個線程之間要排隊，一個一個對共享資源進行操作，而不是同時進行操作。

因此，關於線程同步，需要牢牢記住的第一點是：線程同步就是線程排隊。同步就是排隊。線程同步的目的就是避免線程「同步」執行。這可真是個無聊的繞口令。

關於線程同步，需要牢牢記住的第二點是 「共享」這兩個字。只有共享資源的讀寫訪問才需要同步。如果不是共享資源，那麼就根本沒有同步的必要。

關於線程同步，需要牢牢記住的第三點是，只有「變數」才需要同步訪問。如果共享的資源是固定不變的，那麼就相當於「常量」，線程同時讀取常量也不需要同步。至少一個線程修改共享資源，這樣的情況下，線程之間就需要同步。

關於線程同步，需要牢牢記住的第四點是：多個線程訪問共享資源的代碼有可能是同一份代碼，也有可能是不同的代碼；無論是否執行同一份代碼，只要這些線程的代碼訪問同一份可變的共享資源，這些線程之間就需要同步。

為了加深理解，下面舉幾個例子
有兩個采購員，他們的工作內容是相同的，都是遵循如下的步驟：
（1）到市場上去，尋找並購買有潛力的樣品。
（2）回到公司，寫報告。
這兩個人的工作內容雖然一樣，他們都需要購買樣品，他們可能買到同樣種類的樣品，但是他們絕對不會購買到同一件樣品，他們之間沒有任何共享資源。所以，他們可以各自進行自己的工作，互不幹擾。這兩個采購員就相當於兩個線程；兩個采購員遵循相同的工作步驟，相當於這兩個線程執行同一段代碼。

下面給這兩個采購員增加一個工作步驟。采購員需要根據公司的「布告欄」上面公布的信息，安排自己的工作計劃。 這兩個采購員有可能同時走到布告欄的前面，同時觀看布告欄上的信息。這一點問題都沒有。因為布告欄是只讀的，這兩個采購員誰都不會去修改布告欄上寫的信息 下面增加一個角色。一個辦公室行政人員這個時候，也走到了布告欄前面，准備修改布告欄上的信息。

如果行政人員先到達布告欄，並且正在修改布告欄的內容。兩個采購員這個時候，恰好也到了。這兩個采購員就必須等待行政人員完成修改之後，才能觀看修改後的信息。

如果行政人員到達的時候，兩個采購員已經在觀看布告欄了。那麼行政人員需要等待兩個采購員把當前信息記錄下來之後，才能夠寫上新的信息。

上述這兩種情況，行政人員和采購員對布告欄的訪問就需要進行同步。因為其中一個線程（行政人員）修改了共享資源（布告欄）。而且我們可以看到，行政人員的工作流程和采購員的工作流程（執行代碼）完全不同，但是由於他們訪問了同一份可變共享資源（布告欄），所以他們之間需要同步。

同步鎖
前面講了為什麼要線程同步，下面我們就來看如何才能線程同步。
線程同步的基本實現思路還是比較容易理解的。我們可以給共享資源加一把鎖，這把鎖只有一把鑰匙。哪個線程獲取了這把鑰匙，才有權利訪問該共享資源。

生活中，我們也可能會遇到這樣的例子。一些超市的外面提供了一些自動儲物箱。每個儲物箱都有一把鎖，一把鑰匙。人們可以使用那些帶有鑰匙的儲物箱，把東西放到儲物箱裡面，把儲物箱鎖上，然後把鑰匙拿走。這樣，該儲物箱就被鎖住了，其他人不能再訪問這個儲物箱。（當然，真實的儲物箱鑰匙是可以被人拿走復制的，所以不要把貴重物品放在超市的儲物箱裡面。於是很多超市都採用了電子密碼鎖。）

線程同步鎖這個模型看起來很直觀。但是，還有一個嚴峻的問題沒有解決，這個同步鎖應該加在哪裡？ 當然是加在共享資源上了。反應快的讀者一定會搶先回答。

沒錯，如果可能，我們當然盡量把同步鎖加在共享資源上。一些比較完善的共享資源，比如，文件系統，資料庫系統等，自身都提供了比較完善的同步鎖機制。我們不用另外給這些資源加鎖，這些資源自己就有鎖。

但是，大部分情況下，我們在代碼中訪問的共享資源都是比較簡單的共享對象。這些對象裡面沒有地方讓我們加鎖。

讀者可能會提出建議：為什麼不在每一個對象內部都增加一個新的區域，專門用來加鎖呢？這種設計理論上當然也是可行的。問題在於，線程同步的情況並不是很普遍。如果因為這小概率事件，在所有對象內部都開辟一塊鎖空間，將會帶來極大的空間浪費。得不償失。

於是，現代的編程語言的設計思路都是把同步鎖加在代碼段上。確切的說，是把同步鎖加在「訪問共享資源的代碼段」上。這一點一定要記住，同步鎖是加在代碼段上的。

同步鎖加在代碼段上，就很好地解決了上述的空間浪費問題。但是卻增加了模型的復雜度，也增加了我們的理解難度。

B. JAVA中向mysql資料庫中添加信息，資料庫中顯示亂碼怎麼解決，資料庫是utf-8具體要怎麼做才能解決

1. 基礎知識

計算機中儲存的信息都是用二進制數表示的；而我們在屏幕上看到的英文、漢字等字元是二進制數轉換之後的結果。通俗的說，按照何種規則將字元存儲在計算機中，如'a'用什麼表示，稱為"編碼"；反之，將存儲在計算機中的二進制數解析顯示出來，稱為"解碼"，如同密碼學中的加密和解密。在解碼過程中，如果使用了錯誤的解碼規則，則導致'a'解析成'b'或者亂碼。

字元集（Charset）：是一個系統支持的所有抽象字元的集合。字元是各種文字和符號的總稱，包括各國家文字、標點符號、圖形符號、數字等。

字元編碼（Character Encoding）：是一套法則，使用該法則能夠對自然語言的字元的一個集合（如字母表或音節表），與其他東西的一個集合（如號碼或電脈沖）進行配對。即在符號集合與數字系統之間建立對應關系，它是信息處理的一項基本技術。通常人們用符號集合（一般情況下就是文字）來表達信息。而以計算機為基礎的信息處理系統則是利用元件（硬體）不同狀態的組合來存儲和處理信息的。元件不同狀態的組合能代表數字系統的數字，因此字元編碼就是將符號轉換為計算機可以接受的數字系統的數，稱為數字代碼。

2.常用字元集和字元編碼

常見字元集名稱：ASCII字元集、GB2312字元集、BIG5字元集、GB18030字元集、Unicode字元集等。計算機要准確的處理各種字元集文字，需要進行字元編碼，以便計算機能夠識別和存儲各種文字。

2.1. ASCII字元集&編碼

ASCII（AmericanStandardCode forInformationInterchange，美國信息交換標准代碼）是基於拉丁字母的一套電腦編碼系統。它主要用於顯示現代英語，而其擴展版本EASCII則可以勉強顯示其他西歐語言。它是現今最通用的單位元組編碼系統（但是有被Unicode追上的跡象），並等同於國際標准ISO/IEC 646。

ASCII字元集：主要包括控制字元（回車鍵、退格、換行鍵等）；可顯示字元（英文大小寫字元、阿拉伯數字和西文符號）。

ASCII編碼：將ASCII字元集轉換為計算機可以接受的數字系統的數的規則。使用7位（bits）表示一個字元，共128字元；但是7位編碼的字元集只能支持128個字元，為了表示更多的歐洲常用字元對ASCII進行了擴展，ASCII擴展字元集使用8位（bits）表示一個字元，共256字元。ASCII字元集映射到數字編碼規則如下圖所示：

圖1 ASCII編碼表

圖2 擴展ASCII編碼表

ASCII的最大缺點是只能顯示26個基本拉丁字母、阿拉伯數目字和英式標點符號，因此只能用於顯示現代美國英語（而且在處理英語當中的外來詞如naïve、café、élite等等時，所有重音符號都不得不去掉，即使這樣做會違反拼寫規則）。而EASCII雖然解決了部份西歐語言的顯示問題，但對更多其他語言依然無能為力。因此現在的蘋果電腦已經拋棄ASCII而轉用Unicode。

2.2. GBXXXX字元集&編碼

計算機發明之處及後面很長一段時間，只用應用於美國及西方一些發達國家，ASCII能夠很好滿足用戶的需求。但是當天朝也有了計算機之後，為了顯示中文，必須設計一套編碼規則用於將漢字轉換為計算機可以接受的數字系統的數。

天朝專家把那些127號之後的奇異符號們（即EASCII）取消掉，規定：一個小於127的字元的意義與原來相同，但兩個大於127的字元連在一起時，就表示一個漢字，前面的一個位元組（他稱之為高位元組）從0xA1用到 0xF7，後面一個位元組（低位元組）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼里，還把數學符號、羅馬希臘的 字母、日文的假名們都編進去了，連在ASCII里本來就有的數字、標點、字母都統統重新編了兩個位元組長的編碼，這就是常說的"全形"字元，而原來在127號以下的那些就叫"半形"字元了。

上述編碼規則就是GB2312。GB2312或GB2312-80是中國國家標准簡體中文字元集，全稱《信息交換用漢字編碼字元集·基本集》，又稱GB0，由中國國家標准總局發布，1981年5月1日實施。GB2312編碼通行於中國大陸；新加坡等地也採用此編碼。中國大陸幾乎所有的中文系統和國際化的軟體都支持GB2312。GB2312的出現，基本滿足了漢字的計算機處理需要，它所收錄的漢字已經覆蓋中國大陸99.75%的使用頻率。對於人名、古漢語等方面出現的罕用字，GB2312不能處理，這導致了後來GBK及GB 18030漢字字元集的出現。下圖是GB2312編碼的開始部分（由於其非常龐大，只列舉開始部分，具體可查看GB2312簡體中文編碼表）：

圖3 GB2312編碼表的開始部分

由於GB 2312-80隻收錄6763個漢字，有不少漢字，如部分在GB 2312-80推出以後才簡化的漢字（如"啰"），部分人名用字（如中國前總理朱鎔基的"鎔"字），台灣及香港使用的繁體字，日語及朝鮮語漢字等，並未有收錄在內。於是廠商微軟利用GB 2312-80未使用的編碼空間，收錄GB 13000.1-93全部字元制定了GBK編碼。根據微軟資料，GBK是對GB2312-80的擴展，也就是CP936字碼表 (Code Page 936)的擴展（之前CP936和GB 2312-80一模一樣），最早實現於Windows 95簡體中文版。雖然GBK收錄GB 13000.1-93的全部字元，但編碼方式並不相同。GBK自身並非國家標准，只是曾由國家技術監督局標准化司、電子工業部科技與質量監督司公布為"技術規范指導性文件"。原始GB13000一直未被業界採用，後續國家標准GB18030技術上兼容GBK而非GB13000。

GB 18030，全稱：國家標准GB 18030-2005《信息技術 中文編碼字元集》，是中華人民共和國現時最新的內碼字集，是GB 18030-2000《信息技術 信息交換用漢字編碼字元集 基本集的擴充》的修訂版。與GB2312-1980完全兼容，與GBK基本兼容，支持GB13000及Unicode的全部統一漢字，共收錄漢字70244個。GB 18030主要有以下特點：

與UTF-8相同，採用多位元組編碼，每個字可以由1個、2個或4個位元組組成。

編碼空間龐大，最多可定義161萬個字元。

支持中國國內少數民族的文字，不需要動用造字區。

漢字收錄范圍包含繁體漢字以及日韓漢字

圖4 GB18030編碼總體結構

本規格的初版使中華人民共和國信息產業部電子工業標准化研究所起草，由國家質量技術監督局於2000年3月17日發布。現行版本為國家質量監督檢驗總局和中國國家標准化管理委員會於2005年11月8日發布，2006年5月1日實施。此規格為在中國境內所有軟體產品支持的強制規格。

2.3. BIG5字元集&編碼

Big5，又稱為大五碼或五大碼，是使用繁體中文（正體中文）社區中最常用的電腦漢字字元集標准，共收錄13,060個漢字。中文碼分為內碼及交換碼兩類，Big5屬中文內碼，知名的中文交換碼有CCCII、CNS11643。Big5雖普及於台灣、香港與澳門等繁體中文通行區，但長期以來並非當地的國家標准，而只是業界標准。倚天中文系統、Windows等主要系統的字元集都是以Big5為基準，但廠商又各自增加不同的造字與造字區，派生成多種不同版本。2003年，Big5被收錄到CNS11643中文標准交換碼的附錄當中，取得了較正式的地位。這個最新版本被稱為Big5-2003。

Big5碼是一套雙位元組字元集，使用了雙八碼存儲方法，以兩個位元組來安放一個字。第一個位元組稱為"高位位元組"，第二個位元組稱為"低位位元組"。"高位位元組"使用了0x81-0xFE，"低位位元組"使用了0x40-0x7E，及0xA1-0xFE。在Big5的分區中：

0x8140-0xA0FE

保留給用戶自定義字元（造字區）

0xA140-0xA3BF

標點符號、希臘字母及特殊符號，包括在0xA259-0xA261，安放了九個計量用漢字：兙兛兞兝兡兣嗧瓩糎。

0xA3C0-0xA3FE

保留。此區沒有開放作造字區用。

0xA440-0xC67E

常用漢字，先按筆劃再按部首排序。

0xC6A1-0xC8FE

保留給用戶自定義字元（造字區）

0xC940-0xF9D5

次常用漢字，亦是先按筆劃再按部首排序。

0xF9D6-0xFEFE

保留給用戶自定義字元（造字區）

Unicode字元集&UTF編碼

3.偉大的創想Unicode

——不得不單獨說Unicode

像天朝一樣，當計算機傳到世界各個國家時，為了適合當地語言和字元，設計和實現類似GB232/GBK/GB18030/BIG5的編碼方案。這樣各搞一套，在本地使用沒有問題，一旦出現在網路中，由於不兼容，互相訪問就出現了亂碼現象。

為了解決這個問題，一個偉大的創想產生了——Unicode。Unicode編碼系統為表達任意語言的任意字元而設計。它使用4位元組的數字來表達每個字母、符號，或者表意文字(ideograph)。每個數字代表唯一的至少在某種語言中使用的符號。（並不是所有的數字都用上了，但是總數已經超過了65535，所以2個位元組的數字是不夠用的。）被幾種語言共用的字元通常使用相同的數字來編碼，除非存在一個在理的語源學(etymological)理由使不這樣做。不考慮這種情況的話，每個字元對應一個數字，每個數字對應一個字元。即不存在二義性。不再需要記錄"模式"了。U+0041總是代表'A'，即使這種語言沒有'A'這個字元。

在計算機科學領域中，Unicode（統一碼、萬國碼、單一碼、標准萬國碼）是業界的一種標准，它可以使電腦得以體現世界上數十種文字的系統。Unicode 是基於通用字元集（Universal Character Set）的標准來發展，並且同時也以書本的形式[1]對外發表。Unicode 還不斷在擴增， 每個新版本插入更多新的字元。直至目前為止的第六版，Unicode 就已經包含了超過十萬個字元（在2005年，Unicode 的第十萬個字元被採納且認可成為標准之一）、一組可用以作為視覺參考的代碼圖表、一套編碼方法與一組標准字元編碼、一套包含了上標字、下標字等字元特性的枚舉等。Unicode 組織（The Unicode Consortium）是由一個非營利性的機構所運作，並主導 Unicode 的後續發展，其目標在於：將既有的字元編碼方案以Unicode 編碼方案來加以取代，特別是既有的方案在多語環境下，皆僅有有限的空間以及不兼容的問題。

（可以這樣理解：Unicode是字元集，UTF-32/ UTF-16/ UTF-8是三種字元編碼方案。）

3.1.UCS & UNICODE

通用字元集（Universal Character Set，UCS）是由ISO制定的ISO 10646（或稱ISO/IEC 10646）標准所定義的標准字元集。歷史上存在兩個獨立的嘗試創立單一字元集的組織，即國際標准化組織（ISO）和多語言軟體製造商組成的統一碼聯盟。前者開發的 ISO/IEC 10646 項目，後者開發的統一碼項目。因此最初制定了不同的標准。

1991年前後，兩個項目的參與者都認識到，世界不需要兩個不兼容的字元集。於是，它們開始合並雙方的工作成果，並為創立一個單一編碼表而協同工作。從Unicode 2.0開始，Unicode採用了與ISO 10646-1相同的字型檔和字碼；ISO也承諾，ISO 10646將不會替超出U+10FFFF的UCS-4編碼賦值，以使得兩者保持一致。兩個項目仍都存在，並獨立地公布各自的標准。但統一碼聯盟和ISO/IEC JTC1/SC2都同意保持兩者標準的碼表兼容，並緊密地共同調整任何未來的擴展。在發布的時候，Unicode一般都會採用有關字碼最常見的字型，但ISO 10646一般都盡可能採用Century字型。

3.2.UTF-32

上述使用4位元組的數字來表達每個字母、符號，或者表意文字(ideograph)，每個數字代表唯一的至少在某種語言中使用的符號的編碼方案，稱為UTF-32。UTF-32又稱UCS-4是一種將Unicode字元編碼的協定，對每個字元都使用4位元組。就空間而言，是非常沒有效率的。

這種方法有其優點，最重要的一點就是可以在常數時間內定位字元串里的第N個字元，因為第N個字元從第4×Nth個位元組開始。雖然每一個碼位使用固定長定的位元組看似方便，它並不如其它Unicode編碼使用得廣泛。

3.3.UTF-16

盡管有Unicode字元非常多，但是實際上大多數人不會用到超過前65535個以外的字元。因此，就有了另外一種Unicode編碼方式，叫做UTF-16(因為16位 = 2位元組)。UTF-16將0–65535范圍內的字元編碼成2個位元組，如果真的需要表達那些很少使用的"星芒層(astral plane)"內超過這65535范圍的Unicode字元，則需要使用一些詭異的技巧來實現。UTF-16編碼最明顯的優點是它在空間效率上比UTF-32高兩倍，因為每個字元只需要2個位元組來存儲（除去65535范圍以外的），而不是UTF-32中的4個位元組。並且，如果我們假設某個字元串不包含任何星芒層中的字元，那麼我們依然可以在常數時間內找到其中的第N個字元，直到它不成立為止這總是一個不錯的推斷。其編碼方法是：

如果字元編碼U小於0x10000，也就是十進制的0到65535之內，則直接使用兩位元組表示；

如果字元編碼U大於0x10000，由於UNICODE編碼范圍最大為0x10FFFF，從0x10000到0x10FFFF之間 共有0xFFFFF個編碼，也就是需要20個bit就可以標示這些編碼。用U'表示從0-0xFFFFF之間的值，將其前 10 bit作為高位和16 bit的數值0xD800進行 邏輯or 操作，將後10 bit作為低位和0xDC00做 邏輯or 操作，這樣組成的 4個byte就構成了U的編碼。

對於UTF-32和UTF-16編碼方式還有一些其他不明顯的缺點。不同的計算機系統會以不同的順序保存位元組。這意味著字元U+4E2D在UTF-16編碼方式下可能被保存為4E 2D或者2D 4E，這取決於該系統使用的是大尾端(big-endian)還是小尾端(little-endian)。（對於UTF-32編碼方式，則有更多種可能的位元組排列。）只要文檔沒有離開你的計算機，它還是安全的——同一台電腦上的不同程序使用相同的位元組順序(byte order)。但是當我們需要在系統之間傳輸這個文檔的時候，也許在萬維網中，我們就需要一種方法來指示當前我們的位元組是怎樣存儲的。不然的話，接收文檔的計算機就無法知道這兩個位元組4E 2D表達的到底是U+4E2D還是U+2D4E。

為了解決這個問題，多位元組的Unicode編碼方式定義了一個"位元組順序標記(Byte Order Mark)"，它是一個特殊的非列印字元，你可以把它包含在文檔的開頭來指示你所使用的位元組順序。對於UTF-16，位元組順序標記是U+FEFF。如果收到一個以位元組FF FE開頭的UTF-16編碼的文檔，你就能確定它的位元組順序是單向的(one way)的了；如果它以FE FF開頭，則可以確定位元組順序反向了。

3.4.UTF-8

UTF-8（8-bit Unicode Transformation Format）是一種針對Unicode的可變長度字元編碼（定長碼），也是一種前綴碼。它可以用來表示Unicode標准中的任何字元，且其編碼中的第一個位元組仍與ASCII兼容，這使得原來處理ASCII字元的軟體無須或只須做少部份修改，即可繼續使用。因此，它逐漸成為電子郵件、網頁及其他存儲或傳送文字的應用中，優先採用的編碼。互聯網工程工作小組（IETF）要求所有互聯網協議都必須支持UTF-8編碼。

UTF-8使用一至四個位元組為每個字元編碼：

128個US-ASCII字元只需一個位元組編碼（Unicode范圍由U+0000至U+007F）。

帶有附加符號的拉丁文、希臘文、西里爾字母、亞美尼亞語、希伯來文、阿拉伯文、敘利亞文及它拿字母則需要二個位元組編碼（Unicode范圍由U+0080至U+07FF）。

其他基本多文種平面（BMP）中的字元（這包含了大部分常用字）使用三個位元組編碼。

其他極少使用的Unicode輔助平面的字元使用四位元組編碼。

在處理經常會用到的ASCII字元方面非常有效。在處理擴展的拉丁字元集方面也不比UTF-16差。對於中文字元來說，比UTF-32要好。同時，（在這一條上你得相信我，因為我不打算給你展示它的數學原理。）由位操作的天性使然，使用UTF-8不再存在位元組順序的問題了。一份以utf-8編碼的文檔在不同的計算機之間是一樣的比特流。

總體來說，在Unicode字元串中不可能由碼點數量決定顯示它所需要的長度，或者顯示字元串之後在文本緩沖區中游標應該放置的位置；組合字元、變寬字體、不可列印字元和從右至左的文字都是其歸因。所以盡管在UTF-8字元串中字元數量與碼點數量的關系比UTF-32更為復雜，在實際中很少會遇到有不同的情形。

優點

UTF-8是ASCII的一個超集。因為一個純ASCII字元串也是一個合法的UTF-8字元串，所以現存的ASCII文本不需要轉換。為傳統的擴展ASCII字元集設計的軟體通常可以不經修改或很少修改就能與UTF-8一起使用。

使用標準的面向位元組的排序常式對UTF-8排序將產生與基於Unicode代碼點排序相同的結果。（盡管這只有有限的有用性，因為在任何特定語言或文化下都不太可能有仍可接受的文字排列順序。）

UTF-8和UTF-16都是可擴展標記語言文檔的標准編碼。所有其它編碼都必須通過顯式或文本聲明來指定。

任何面向位元組的字元串搜索演算法都可以用於UTF-8的數據（只要輸入僅由完整的UTF-8字元組成）。但是，對於包含字元記數的正則表達式或其它結構必須小心。

UTF-8字元串可以由一個簡單的演算法可靠地識別出來。就是，一個字元串在任何其它編碼中表現為合法的UTF-8的可能性很低，並隨字元串長度增長而減小。舉例說，字元值C0,C1,F5至FF從來沒有出現。為了更好的可靠性，可以使用正則表達式來統計非法過長和替代值（可以查看W3 FAQ: Multilingual Forms上的驗證UTF-8字元串的正則表達式）。

缺點

因為每個字元使用不同數量的位元組編碼，所以尋找串中第N個字元是一個O(N)復雜度的操作 — 即，串越長，則需要更多的時間來定位特定的字元。同時，還需要位變換來把字元編碼成位元組，把位元組解碼成字元。

4.Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language

在HTTP中，與字元集和字元編碼相關的消息頭是Accept-Charset/Content-Type，另外主區區分Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language：

Accept-Charset：瀏覽器申明自己接收的字元集，這就是本文前面介紹的各種字元集和字元編碼，如gb2312，utf-8（通常我們說Charset包括了相應的字元編碼方案）；

Accept-Encoding：瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate），（注意：這不是隻字元編碼）；

Accept-Language：瀏覽器申明自己接收的語言。語言跟字元集的區別：中文是語言，中文有多種字元集，比如big5，gb2312，gbk等等；

Content-Type：WEB伺服器告訴瀏覽器自己響應的對象的類型和字元集。例如：Content-Type: text/html; charset='gb2312'

Content-Encoding：WEB伺服器表明自己使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip

Content-Language：WEB伺服器告訴瀏覽器自己響應的對象的語言。

資源來源於：http://blog.chinaunix.net/uid-22145625-id-3294658.html

C. andoid的socket測試為什麼出現這個錯誤：java.net.ConnectException: failed to connect to /192.168.0.8

andoid的socket測試出現這個錯誤：java.net.ConnectException: failed to connect to /192.168.0.8的原因是因為當時測試人次要比平時多，從而導致伺服器出現不穩定；

解決方式：重新換一個伺服器；

andoid的socket測試使得伺服器的硬體組成較為復雜，對於伺服器硬體的維護應由專業人員進行。在維護和保養存儲設備時，我們首先應當對其容量進行測試，看是否需要進行擴容等操作。存儲容量一定要能滿足任務的需求，並留有一定的冗餘量。

(3)java密碼復雜度擴展閱讀：

andoid的socket測試拆卸和更新伺服器設備時，務必讓設備處於斷電狀態並進行接地處理。即便是更換最簡單的部件，這些環節也不能省略。對於一些不熟悉的部件，要反復仔細的閱讀說明書和參照文件，在沒有十足把握的前提下切忌盲目拆解。

對伺服器的密碼進行更換，密碼應有專人管理。選用的密碼要有一定的專業性，一定的復雜度，最好是將數字和字母等結合起來，大小寫也要融合進去。在日常的檢查中，我們要做好登統計，關閉一些不太使用的埠；

定期對伺服器進行除塵處理。特別是伺服器這種高溫高速運行的設備，大量的積塵對設備造成的傷害往往是致命的。除塵工作要科學有序的進行，不能想當然，也不能蠻干。在除塵過程中特別注意對電源系統的保護。

D. java 密碼復雜度判斷

密碼就包括數字，字母，字元這三種，你可以判斷如果只有數字就為最簡單，然後再判斷有沒有字母，最後判斷有沒有字元，根據密碼中有這三者中的集中來做判斷定義幾個復雜程度

E. 編寫一個java程序可以計算圍棋復雜度

圍棋有幾種變化是一個老問題了，比較粗淺的說法是3的19乘19次方，意思就是棋盤上每個點有空、黑、白三種狀態，總共有19*19個點，所以得出這個結果。但實際上並沒有那麼多，因為在那麼多狀態中，有很大一部分是不可能出現的狀態，也就是盤面上有死棋的狀態。比如整個棋盤上布滿棋子的狀態都是不可能的，而這種狀態就有2的19*19次方之多。<?xml:namespaceprefix=ons="urn:schemas-microsoft-com:office:office"/>

程序員java進階最新視頻.zip" data_size="8.16M" data_filelogo="https://gss0.bdstatic.com//yun-file-logo/file-logo-6.png" data_number="1" data_sharelink="https://pan..com/s/1yXZ5G2GrL8htohYwNecdjA" data_code="exn4">

F. java密碼復雜度校驗

qaz，qwer這種都不能通過？這不算連續的吧，要實現這樣的你只能把連續的可能性列出來，比如[q,w,e,r,t,y,u,i,o,p]為一組，比如你的密碼包含wert四個字母，那你可以把這四個字母拆開，先使用w從數組中開始遍歷，發現w與數組中第二個元素相等，那麼再取密碼的第二個字母w與數組中的第三個元素比較，如果相等再比較下一個，滿足有三個字母對應上的就直接返回校驗不通過。
如果是要校驗0123456789和abcdefg這樣的連續的，你可以把密碼的拆分成char數組，數組每個元素轉成數值其實就是這個字元的ascii碼，然後比較相鄰的三個元素ascii碼是不是連續的就可以判斷出來，不過這種方法需要注意一點，比如'@'的ascii為64，'A'的ascii為65也是連續的，需要自己進行篩選。覺得這種方法麻煩的話也可以使用上面的方法把連續的都先列舉出來。
我只寫一下我的想法，僅供參考。

G. C語言的密碼檢測怎麼做

conio.h不是c標准頭文件，建議不要用這個頭文件。把這個頭文件刪掉。

將讀入密碼那行的函數改用gets

gets(input_pass);

另外為了避免bug，input_pass最好弄大一點。

H. java用md5密碼加密有必要嗎

有必要的，md5就是為了防止人偷窺，而當密碼很短的時候，利用暴力搜索也比較容易搜索到，只有密碼強度足夠的情況下才有意義，你想轉換也就沒那麼容易了。md5類hash演算法的設計初衷就是單向，即不可逆。