utf8編譯時加u嗎
『壹』 我的文件格式是utf-8，內容也加了utf-8為什麼編譯的時候中文還是亂碼
代碼中的中文用unicode字元串 u'不能做除數'這種才行
『貳』 php正則表達式定界符之後加上一個小寫的u有什麼作用
你這里的u是小寫的吧。
u（PCRE_UTF8）
此修正符啟用了一個 PCRE 中與 Perl
不兼容的額外功能。模式字元串被當成 UTF-8。本修正符在 Unix 下自 PHP 4.1.0 起可用，在 win32 下自 PHP 4.2.3
起可用。自 PHP 4.3.5 起開始檢查模式的 UTF-8 合法性。
『叄』 python使用find_element_by_name()出現中文亂碼， 但是使用：# coding=utf-8 和中文前面加u無法解決
UTF-8默認在string前面加u的。
『肆』 utf8和unicode編碼究竟是什麼關系有何區別
什麼是 Unicode?
歷史上, 有兩個獨立的, 創立單一字元集的嘗試. 一個是國際標准化組織(ISO)的 ISO 10646 項目, 另一個是由(一開始大多是美國的)多語言軟體製造商組成的協會組織的 Unicode 項目. 幸運的是, 1991年前後, 兩個項目的參與者都認識到, 世界不需要兩個不同的單一字元集. 它們合並雙方的工作成果, 並為創立一個單一編碼表而協同工作. 兩個項目仍都存在並獨立地公布各自的標准, 但 Unicode 協會和 ISO/IEC JTC1/SC2 都同意保持 Unicode 和 ISO 10646 標準的碼表兼容, 並緊密地共同調整任何未來的擴展.
Unicode vs ISO 10646
Unicode 協會公布的 Unicode 標准 嚴密地包含了 ISO 10646-1 實現級別3的基本多語言面. 在兩個標准里所有的字元都在相同的位置並且有相同的名字.
Unicode 標准額外定義了許多與字元有關的語義符號學, 一般而言是對於實現高質量的印刷出版系統的更好的參考. Unicode 詳細說明了繪制某些語言(比如阿拉伯語)表達形式的演算法, 處理雙向文字(比如拉丁與希伯來文混合文字)的演算法和 排序與字元串比較 所需的演算法, 以及其他許多東西.
另一方面, ISO 10646 標准, 就象廣為人知的 ISO 8859 標准一樣, 只不過是一個簡單的字元集表. 它指定了一些與標准有關的術語, 定義了一些編碼的別名, 並包括了規范說明, 指定了怎樣使用 UCS 連接其他 ISO 標準的實現, 比如 ISO 6429 和 ISO 2022. 還有一些與 ISO 緊密相關的, 比如 ISO 14651 是關於 UCS 字元串排序的.
考慮到 Unicode 標准有一個易記的名字, 且在任何好的書店裡的 Addison-Wesley 里有, 只花費 ISO 版本的一小部分, 且包括更多的輔助信息, 因而它成為使用廣泛得多的參考也就不足為奇了. 然而, 一般認為, 用於列印 ISO 10646-1 標準的字體在某些方面的質量要高於用於列印 Unicode 2.0的. 專業字體設計者總是被建議說要兩個標准都實現, 但一些提供的樣例字形有顯著的區別. ISO 10646-1 標准同樣使用四種不同的風格變體來顯示表意文字如中文, 日文和韓文 (CJK), 而 Unicode 2.0 的表裡只有中文的變體. 這導致了普遍的認為 Unicode 對日本用戶來說是不可接收的傳說, 盡管是錯誤的.
UTF-8
首先 UCS 和 Unicode 只是分配整數給字元的編碼表. 現在存在好幾種將一串字元表示為一串位元組的方法. 最顯而易見的兩種方法是將 Unicode 文本存儲為 2 個 或 4 個位元組序列的串. 這兩種方法的正式名稱分別為 UCS-2 和 UCS-4. 除非另外指定, 否則大多數的位元組都是這樣的(Bigendian convention). 將一個 ASCII 或 Latin-1 的文件轉換成 UCS-2 只需簡單地在每個 ASCII 位元組前插入 0x00. 如果要轉換成 UCS-4, 則必須在每個 ASCII 位元組前插入三個 0x00.
在 Unix 下使用 UCS-2 (或 UCS-4) 會導致非常嚴重的問題. 用這些編碼的字元串會包含一些特殊的字元, 比如 '\0' 或 '/', 它們在 文件名和其他 C 庫函數參數里都有特別的含義. 另外, 大多數使用 ASCII 文件的 UNIX 下的工具, 如果不進行重大修改是無法讀取 16 位的字元的. 基於這些原因, 在文件名, 文本文件, 環境變數等地方, UCS-2 不適合作為 Unicode 的外部編碼.
在 ISO 10646-1 Annex R 和 RFC 2279 里定義的 UTF-8 編碼沒有這些問題. 它是在 Unix 風格的操作系統下使用 Unicode 的明顯的方法.
UTF-8 有一下特性:
UCS 字元 U+0000 到 U+007F (ASCII) 被編碼為位元組 0x00 到 0x7F (ASCII 兼容). 這意味著只包含 7 位 ASCII 字元的文件在 ASCII 和 UTF-8 兩種編碼方式下是一樣的.
所有 >U+007F 的 UCS 字元被編碼為一個多個位元組的串, 每個位元組都有標記位集. 因此, ASCII 位元組 (0x00-0x7F) 不可能作為任何其他字元的一部分.
表示非 ASCII 字元的多位元組串的第一個位元組總是在 0xC0 到 0xFD 的范圍里, 並指出這個字元包含多少個位元組. 多位元組串的其餘位元組都在 0x80 到 0xBF 范圍里. 這使得重新同步非常容易, 並使編碼無國界, 且很少受丟失位元組的影響.
可以編入所有可能的 231個 UCS 代碼
UTF-8 編碼字元理論上可以最多到 6 個位元組長, 然而 16 位 BMP 字元最多隻用到 3 位元組長.
Bigendian UCS-4 位元組串的排列順序是預定的.
位元組 0xFE 和 0xFF 在 UTF-8 編碼中從未用到.
下列位元組串用來表示一個字元. 用到哪個串取決於該字元在 Unicode 中的序號.
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
xxx 的位置由字元編碼數的二進製表示的位填入. 越靠右的 x 具有越少的特殊意義. 只用最短的那個足夠表達一個字元編碼數的多位元組串. 注意在多位元組串中, 第一個位元組的開頭"1"的數目就是整個串中位元組的數目.
例如: Unicode 字元 U+00A9 = 1010 1001 (版權符號) 在 UTF-8 里的編碼為:
11000010 10101001 = 0xC2 0xA9
而字元 U+2260 = 0010 0010 0110 0000 (不等於) 編碼為:
11100010 10001001 10100000 = 0xE2 0x89 0xA0
這種編碼的官方名字拼寫為 UTF-8, 其中 UTF 代表 UCS Transformation Format. 請勿在任何文檔中用其他名字 (比如 utf8 或 UTF_8) 來表示 UTF-8, 當然除非你指的是一個變數名而不是這種編碼本身.
『伍』 UTF-8，和Unicode是什麼關系 UTF-8的全稱又是什麼
UTF-8（8-bit Unicode Transformation Format）是一種針對Unicode的可變長度字元編碼，又稱萬國碼。由Ken Thompson於1992年創建。現在已經標准化為RFC 3629。UTF-8用1到6個位元組編碼Unicode字元。用在網頁上可以統一頁面顯示中文簡體繁體及其它語言（如英文，日文，韓文）。
在所有字元集中，最知名的可能要數被稱為ASCII的7位字元集了。它是美國標准信息交換代碼（American Standard Code for Information Interchange）的縮寫, 為美國英語通信所設計。它由128個字元組成，包括大小寫字母、數字0-9、標點符號、非列印字元（換行符、製表符等4個）以及控制字元（退格、響鈴等）組成。
但是，由於他是針對英語設計的，當處理帶有音調標號（形如漢語的拼音）的亞洲文字時就會出現問題。因此，創建出了一些包括255個字元的由ASCII擴展的字元集。其中有一種通常被稱為IBM字元集，它把值為128-255之間的字元用於畫圖和畫線，以及一些特殊的歐洲字元。另一種8位字元集是ISO 8859-1Latin 1，也簡稱為ISOLatin-1。它把位於128-255之間的字元用於拉丁字母表中特殊語言字元的編碼，也因此而得名。歐洲語言不是地球上的唯一語言，因此亞洲和非洲語言並不能被8位字元集所支持。僅漢語字母表（或pictograms）就有80000以上個字元。
但是把漢語、日語和越南語的一些相似的字元結合起來，在不同的語言里，使不同的字元代表不同的字，這樣只用2個位元組就可以編碼地球上幾乎所有地區的文字。因此，創建了UNICODE編碼。
它通過增加一個高位元組對ISO Latin-1字元集進行擴展，當這些高位元組位為0時，低位元組就是ISO Latin-1字元。UNICODE支持歐洲、非洲、中東、亞洲（包括統一標準的東亞象形漢字和韓國表音文字）。但是，UNICODE並沒有提供對諸如Braille,Cherokee, Ethiopic, Khmer, Mongolian, Hmong, Tai Lu, Tai Mau文字的支持。同時它也不支持如Ahom, Akkadian, Aramaic,BabylonianCuneiform, Balti, Brahmi, Etruscan, Hittite, Javanese, Numidian, Old Persian Cuneiform, Syrian之類的古老文字。
事實證明，對可以用ASCII表示的字元使用UNICODE並不高效，因為UNICODE比ASCII佔用大一倍的空間，而對ASCII來說高位元組的0對他毫無用處。為了解決這個問題，就出現了一些中間格式的字元集，他們被稱為通用轉換格式，即UTF（Unicode Transformation Format）。常見的UTF格式有：UTF-7, UTF-7.5, UTF-8,UTF-16, 以及UTF-32。
如果UNICODE字元由2個位元組表示，則編碼成UTF-8很可能需要3個位元組。而如果UNICODE字元由4個位元組表示，則編碼成UTF-8可能需要6個位元組。用4個或6個位元組去編碼一個UNICODE字元可能太多了，但很少會遇到那樣的UNICODE字元。
UTF-8編碼規則：如果只有一個位元組則其最高二進制位為0；如果是多位元組，其第一個位元組從最高位開始，連續的二進制位值為1的個數決定了其編碼的位元組數，其餘各位元組均以10開頭。
實際表示ASCII字元的UNICODE字元，將會編碼成1個位元組，並且UTF-8表示與ASCII字元表示是一樣的。所有其他的UNICODE字元轉化成UTF-8將需要至少2個位元組。每個位元組由一個換碼序列開始。第一個位元組由唯一的換碼序列，由n位連續的1加一位0組成, 首位元組連續的1的個數表示字元編碼所需的位元組數。
Unicode轉換為UTF-8時，可以將Unicode二進制從低位往高位取出二進制數字，每次取6位，如上述的二進制就可以分別取出為如下示例所示的格式，前面按格式填補，不足8位用0填補。
小結 :用通信理論的思路可以理解為:
unicode是信源編碼，對字元集數字化;
utf8是信道編碼，為更好的存儲和傳輸。
註：Unicode轉換為UTF-8需要的位元組數可以根據這個規則計算：如果Unicode小於0X80（Ascii字元），則轉換後為1個位元組。否則轉換後的位元組數為Unicode二進制位數減1再除以5。
參考:度女良
『陸』 到底utf-8和unicode是什麼關系
簡單來說：
Unicode 是「字元集」
UTF-8 是「編碼規則」
其中：
字元集：為每一個「字元」分配一個唯一的 ID（學名為碼位 / 碼點 / Code Point）
編碼規則：將「碼位」轉換為位元組序列的規則（編碼/解碼 可以理解為 加密/解密 的過程）
廣義的 Unicode 是一個標准，定義了一個字元集以及一系列的編碼規則，即 Unicode 字元集和 UTF-8、UTF-16、UTF-32 等等編碼……
Unicode 字元集為每一個字元分配一個碼位，例如「知」的碼位是 30693，記作 U+77E5（30693 的十六進制為 0x77E5）。
UTF-8 顧名思義，是一套以 8 位為一個編碼單位的可變長編碼。會將一個碼位編碼為 1 到 4 個位元組：
U+ 0000 ~ U+ 007F: 0XXXXXXX
U+ 0080 ~ U+ 07FF: 110XXXXX 10XXXXXX
U+ 0800 ~ U+ FFFF: 1110XXXX 10XXXXXX 10XXXXXX
U+10000 ~ U+1FFFF: 11110XXX 10XXXXXX 10XXXXXX 10XXXXXX
根據上表中的編碼規則，之前的「知」字的碼位 U+77E5 屬於第三行的范圍：
7 7 E 5
0111 0111 1110 0101 二進制的 77E5
--------------------------
0111 011111 100101 二進制的 77E5
1110XXXX 10XXXXXX 10XXXXXX 模版（上表第三行）
11100111 10011111 10100101 代入模版
E 7 9 F A 5
這就是將 U+77E5 按照 UTF-8 編碼為位元組序列 E79FA5 的過程。反之亦然。
『柒』 notepad++ python 源代碼中含有中文 utf8無bom編碼 無法編譯
print u'哈哈'
---------------------------------
Python 2 裡面默認所有字面上的字元串都用ASCII編碼，可以通過在字元串前面加一個『u』前綴的方式聲明Unicode字元串，這個『u』前綴告訴Python後面的字元串要編成Unicode字元串
-------------------------------------------------------------------------------------------------------------。
print 函數嚴重受IDE編碼環境的影響,本來 print u'哈哈'肯定能成功,因為u'哈哈'是unicode,
但是受ide的影響, print 強行把u'哈哈' 轉換成了 '哈哈' (字元類型),然後失敗了
---------------------------------------------------------------------------------------------
所以建議不要用notepad++這個ide
『捌』 python 中文字元串前為什麼加u
# -*- coding: UTF-8 -*- 這句是告訴python程序中的文本是utf-8編碼，讓python可以按照utf-8讀取程
中文前加u就是告訴python後面的是個unicode編碼，存儲時按unicode格式存儲。
『玖』 什麼是UTF-8編碼
UTF-8
一種字元集
介紹UTF-8編碼規則
首先 UCS 和 Unicode 只是分配整數給字元的編碼表. 現在存在好幾種將一串字元表示為一串位元組的方法. 最顯而易見的兩種方法是將 Unicode 文本存儲為 2 個 或 4 個位元組序列的串. 這兩種方法的正式名稱分別為 UCS-2 和 UCS-4. 除非另外指定, 否則大多數的位元組都是這樣的(Bigendian convention). 將一個 ASCII 或 Latin-1 的文件轉換成 UCS-2 只需簡單地在每個 ASCII 位元組前插入 0x00. 如果要轉換成 UCS-4, 則必須在每個 ASCII 位元組前插入三個 0x00.
在 Unix 下使用 UCS-2 (或 UCS-4) 會導致非常嚴重的問題. 用這些編碼的字元串會包含一些特殊的字元, 比如 '' 或 '/', 它們在 文件名和其他 C 庫函數參數里都有特別的含義. 另外, 大多數使用 ASCII 文件的 UNIX 下的工具, 如果不進行重大修改是無法讀取 16 位的字元的. 基於這些原因, 在文件名, 文本文件, 環境變數等地方, UCS-2 不適合作為 Unicode 的外部編碼.
在 ISO 10646-1 Annex R 和 RFC 2279 里定義的 UTF-8 編碼沒有這些問題. 它是在 Unix 風格的操作系統下使用 Unicode 的明顯的方法.
UTF-8 有一下特性:
UCS 字元 U+0000 到 U+007F (ASCII) 被編碼為位元組 0x00 到 0x7F (ASCII 兼容). 這意味著只包含 7 位 ASCII 字元的文件在 ASCII 和 UTF-8 兩種編碼方式下是一樣的.
所有 >U+007F 的 UCS 字元被編碼為一個多個位元組的串, 每個位元組都有標記位集. 因此, ASCII 位元組 (0x00-0x7F) 不可能作為任何其他字元的一部分.
表示非 ASCII 字元的多位元組串的第一個位元組總是在 0xC0 到 0xFD 的范圍里, 並指出這個字元包含多少個位元組. 多位元組串的其餘位元組都在 0x80 到 0xBF 范圍里. 這使得重新同步非常容易, 並使編碼無國界, 且很少受丟失位元組的影響.
可以編入所有可能的 231個 UCS 代碼
UTF-8 編碼字元理論上可以最多到 6 個位元組長, 然而 16 位 BMP 字元最多隻用到 3 位元組長.
Bigendian UCS-4 位元組串的排列順序是預定的.
位元組 0xFE 和 0xFF 在 UTF-8 編碼中從未用到.
下列位元組串用來表示一個字元. 用到哪個串取決於該字元在 Unicode 中的序號.
U-00000000 - U-0000007F:
0xxxxxxx
U-00000080 - U-000007FF:
110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF:
1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF:
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF:
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
xxx 的位置由字元編碼數的二進製表示的位填入. 越靠右的 x 具有越少的特殊意義. 只用最短的那個足夠表達一個字元編碼數的多位元組串. 注意在多位元組串中, 第一個位元組的開頭"1"的數目就是整個串中位元組的數目.
例如: Unicode 字元 U+00A9 = 1010 1001 (版權符號) 在 UTF-8 里的編碼為:
11000010 10101001 = 0xC2 0xA9
而字元 U+2260 = 0010 0010 0110 0000 (不等於) 編碼為:
11100010 10001001 10100000 = 0xE2 0x89 0xA0
這種編碼的官方名字拼寫為 UTF-8, 其中 UTF 代表 UCS Transformation Format. 請勿在任何文檔中用其他名字 (比如 utf8 或 UTF_8) 來表示 UTF-8, 當然除非你指的是一個變數名而不是這種編碼本身.
什麼編程語言支持 Unicode?
在大約 1993 年之後開發的大多數現代編程語言都有一個特別的數據類型, 叫做 Unicode/ISO 10646-1 字元. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.
ISO C 也詳細說明了處理多位元組編碼和寬字元 (wide characters) 的機制, 1994 年 9 月 Amendment 1 to ISO C 發表時又加入了更多. 這些機制主要是為各類東亞編碼而設計的, 它們比處理 UCS 所需的要健壯得多. UTF-8 是 ISO C 標准調用多位元組字元串的編碼的一個例子, wchar_t 類型可以用來存放 Unicode 字元
『拾』 python怎麼設置utf8編碼格式
python2.7里的話代碼前加上coding:utf-8，中文前加上u
如：
#coding:utf-8
text=u'中文'
printtext
#這里的text就是utf-8編碼