青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

關于Bash shell在不同locale下的”異常”表現之探討

                                      peakflys原創作品,轉載請注明原作者和源鏈接
   現有一個文本test.xml,內容大致如下:
         <Word content="㈠"/>
        <Word content="㈡"/>
        <Word content="㈢"/>
        <Word content="㈣"/>
        <Word content="㈤"/>
        <Word content="㈥"/>
        <Word content="㈦"/>
        <Word content="㈧"/>
        <Word content="㈨"/>
        <Word content="㈩"/>
        <Word content="㊣"/>
        <Word content="GM"/>
        <Word content="GM"/>
        <Word content="sex"/>
        <Word content="G M"/>
        <Word content="fuck"/>
        <Word content="shit"/>

文本中顯而易見含有重復行,假如讓你來去重的話,你可能會說so easy,直接手動去掉多出來的那項GM就行了。但是如果這個文本有上萬行,而且上下文內容沒有這么明顯的相似性歸類的話,又要怎么辦?

在windows下相信大家很容易寫出一個小程序來處理這樣的文本,而在linux下工作的人肯定馬上會想到諸如sort、uniq、awk等命令,這種問題一條指令就搞定了嘛:

         sort –u test.xml

但是結果卻大跌眼鏡,輸出如下:

        <Word content="㈡"/>
        <Word content="㈠"/>
        <Word content="GM"/>
        <Word content="sex"/>
        <Word content="fuck"/>

因為例子test.xml中內容只有十幾行,很明顯可以看出來去重后的結果不對!

      那么使用uniq 呢?
         sort test.xml  | uniq

輸出結果同上……

   那使用文本處理神器awk呢?
         awk '!a[$0]++' test.xml

輸出如下:
         <Word content="㈠"/>

        <Word content="㈡"/>
        <Word content="㈢"/>
        <Word content="㈣"/>
        <Word content="㈤"/>
        <Word content="㈥"/>
        <Word content="㈦"/>
        <Word content="㈧"/>
        <Word content="㈨"/>
        <Word content="㈩"/>
        <Word content="㊣"/>
        <Word content="GM"/>
        <Word content="sex"/>
        <Word content="G M"/>
        <Word content="fuck"/>
        <Word content="shit"/>

神器就是神器!這個結果才是我們需要的嘛。

但是sort和uniq為什么篩選出的結果有問題呢?

估計大家通過文章的標題早就知道原因了,廢話不多說,直接看一下sort 的manual吧。里面有這么一句:

     *** WARNING *** The locale specified by the environment affects sort order.  Set LC_ALL=C to get the traditional sort order that uses native byte values.

先看一下我本地的LANG設置:

LANG=en_US.UTF-8

LC_CTYPE="en_US.UTF-8"

LC_NUMERIC="en_US.UTF-8"

LC_TIME="en_US.UTF-8"

LC_COLLATE="en_US.UTF-8"

LC_MONETARY="en_US.UTF-8"

LC_MESSAGES="en_US.UTF-8"

LC_PAPER="en_US.UTF-8"

LC_NAME="en_US.UTF-8"

LC_ADDRESS="en_US.UTF-8"

LC_TELEPHONE="en_US.UTF-8"

LC_MEASUREMENT="en_US.UTF-8"

LC_IDENTIFICATION="en_US.UTF-8"

LC_ALL=

依照文檔中說明重新設置一下本地locale的環境變量:LANG=C

之后使用sort或者uniq命令輸出正確。

Linux下有不少命令的輸出是和本地的locale設置有關的,除sort和uniq外,還有ls等,在此不再擴展展開。

還如往常一樣,上面講述的僅僅是一個結果,以及淺層次的原因,為了對得起題目中的”探討”兩個字,咱們繼續細究一下sort的實現,以及發生這種情況的具體原因。

其實sort的實現代碼很精致也很高效,有興趣的同學可以自行察看,下面僅摘錄一些和本篇文章相關的代碼。

首先是一些初始化代碼:

     initialize_main (&argc, &argv);
     set_program_name (argv[0]);
     setlocale (LC_ALL, ""); //peakflys引manual注: If locale  is "", each part of the locale that should be modified is set according to the environment variables.
     bindtextdomain (PACKAGE, LOCALEDIR);
     textdomain (PACKAGE);
     initialize_exit_failure (SORT_FAILURE);
     hard_LC_COLLATE = hard_locale (LC_COLLATE);

setlocale上面已經注釋了,第二個參數為空字符時取本機的locale設置,hard_locale的實現代碼就不貼了,它主要是通過查找locale中LC_COLLATE有沒有"C"或者"POSIX"。

有的話置標記hard_LC_COLLATE為false,否則為true。這個標志位很重要,具體使用見下文。

下面給出sort實現的核心比較操作的代碼:

      static int
     compare (struct line const *a, struct line const *b)
     {
        int diff;
        size_t alen, blen;

        /* First try to compare on the specified keys (if any).
           The only two cases with no key at all are unadorned sort,
           and unadorned sort -r. */
        if (keylist)
        {
            diff = keycompare (a, b);
            if (diff || unique || stable)
              return diff;
        }
      
        /* If the keys all compare equal (or no keys were specified)
           fall through to the default comparison.  */
        alen = a->length - 1, blen = b->length - 1;
          
        if (alen == 0)
          diff = - NONZERO (blen);
        else if (blen == 0)
          diff = 1;
        else if (hard_LC_COLLATE)     //peakflys注:上文提到的這個標記位! 
        {
          /* Note xmemcoll0 is a performance enhancement as
            it will not unconditionally write '\0' after the
            passed in buffers, which was seen to give around
            a 3% increase in performance for short lines.  */
            diff = xmemcoll0 (a->text, alen + 1, b->text, blen + 1);
        }
        else if (! (diff = memcmp (a->text, b->text, MIN (alen, blen))))  //peakflys注:設置LANG=C后,程序邏輯在這里?
          diff = alen < blen ? -1 : alen != blen;
      
        return reverse ? -diff : diff;
   }

上面代碼注釋很清楚相信大家已經知道為什么設置LANG=C (linux系統中"C"和"POSIX"在locale意義上等價)后,sort操作就正常了。

那么為什么使用UTF-8的locale時會出問題呢?

那我們繼續看xmemcoll0相關的實現:

     int
     xmemcoll0 (char const *s1, size_t s1size, char const *s2, size_t s2size)
     {
        int diff = memcoll0 (s1, s1size, s2, s2size);
        int collation_errno = errno;
        if (collation_errno)
          collate_error (collation_errno, s1, s1size - 1, s2, s2size - 1); 
        return diff;
      }
      int
      memcoll0 (char const *s1, size_t s1size, char const *s2, size_t s2size)
      {
         if (s1size == s2size && memcmp (s1, s2, s1size) == 0)
         {   
            errno = 0;
            return 0;
         }   
        else
          return strcoll_loop (s1, s1size, s2, s2size);
      }
      static int 
      strcoll_loop (char const *s1, size_t s1size, char const *s2, size_t s2size)
      {     
        int diff;
    
        while (! (errno = 0, (diff = strcoll (s1, s2)) || errno))
        {
            /* strcoll found no difference, but perhaps it was fooled by NUL
               characters in the data.  Work around this problem by advancing
               past the NUL chars.  */
            size_t size1 = strlen (s1) + 1;
            size_t size2 = strlen (s2) + 1;
            s1 += size1;
            s2 += size2;
            s1size -= size1;
            s2size -= size2;

            if (s1size == 0) 
              return - (s2size != 0);
            if (s2size == 0)
              return 1;
          }   
  
        return diff;
      }

至此我們可以看到sort關于locale的比較實現最終是通過庫函數strcoll來實現的(礙于篇幅,這個glibc庫函數的實現代碼我就不貼了,感興趣的可以自行下載研究),這個函數通過調用__strcoll_l來根據不同locale定義的weights等信息來比較兩個字符串。
      其他的命令,諸如uniq、ls等的情況和sort命令大致一樣,大家可以自己down下GNU的coreutils來研究。

眼尖的同學可能會發現上面例子中文本就是大天朝下游戲臟詞庫中常見的一部分,而這些內容時常需要根據當前情況追加一些新的紀錄,所以如果沒有大天朝的奇葩制度和游戲玩家的“無窮智慧”也就沒有文中開場例子的使用場景。

講了那么多遍locale,可能有些人要問,什么是locale?
      其實locale就是根據計算機用戶所使用的語言,所在國家或者地區,以及當地的文化傳統所定義的一個軟件運行時的語言環境。狹隘的說,它規定了字符集,以及這種字符集具體的展示方式。 bash shell之所以很多命令同locale相關,也是基于不同地區、不同語言的用戶可以通過選擇各自的locale來達到定制化的效果。
      更具體的介紹就不在這里討論了,感興趣的朋友可以通過下面鏈接了解:

http://m.shnenglu.com/peakflys/articles/209773.html
                                                                                by peakflys 08:51:19 Tuesday, February 10, 2015

posted on 2015-02-10 09:10 peakflys 閱讀(1830) 評論(0)  編輯 收藏 引用 所屬分類: 操作系統雜談

<2012年12月>
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

導航

統計

公告

人不淡定的時候,就愛表現出來,敲代碼如此,偶爾的靈感亦如此……

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲国产天堂久久综合| 久久尤物视频| 黄色亚洲在线| 亚洲专区一区| 欧美在线观看视频在线| 国产精品一区二区三区乱码| 亚洲欧美日韩精品| 久久久久久久久久码影片| 国产真实精品久久二三区| 久久精品中文字幕免费mv| 欧美国产精品久久| 在线午夜精品自拍| 国产精品乱人伦中文| 性欧美大战久久久久久久久| 久久亚洲影院| 一本久道久久综合婷婷鲸鱼| 国产精品日韩精品| 久久亚洲影院| 一本大道久久a久久精品综合| 性一交一乱一区二区洋洋av| 尤妮丝一区二区裸体视频| 欧美xx69| av成人免费在线| 狼狼综合久久久久综合网 | 欧美成人一区二区在线| 夜夜嗨av一区二区三区免费区 | 亚洲区一区二| 国产精品国产成人国产三级| 国内精品久久久久国产盗摄免费观看完整版 | 一区二区三区免费看| 欧美日韩在线播放三区四区| 亚洲欧美另类国产| 亚洲高清123| 久久精品九九| 一区二区三区视频在线看| 亚洲第一二三四五区| 国产精品普通话对白| 欧美国产三级| 久久精品国产亚洲精品| 欧美在线免费播放| 亚洲视频1区| 亚洲成人资源| 欧美性大战xxxxx久久久| 欧美激情1区2区| 亚洲欧美激情一区| 亚洲精品免费在线观看| 日韩视频免费| 在线成人免费视频| 国产三级精品在线不卡| 国产精品h在线观看| 久久一区二区三区国产精品| 午夜精品亚洲| 亚洲在线免费观看| 欧美激情中文字幕乱码免费| 麻豆视频一区二区| 亚洲欧美视频一区| 亚洲一区二区三区在线视频| 亚洲激情电影在线| 欧美日韩国产经典色站一区二区三区| 一区二区三区四区蜜桃| 蜜桃av噜噜一区| 欧美在线黄色| 好吊妞**欧美| 欧美日韩免费观看一区二区三区 | 日韩一区二区福利| 欧美xxx成人| 亚洲欧美综合精品久久成人| 亚洲——在线| 欧美亚洲综合另类| 亚洲欧美伊人| 欧美一区二区三区免费视| 亚洲美女免费精品视频在线观看| 欧美日韩在线高清| 91久久精品一区二区别| 国产精品综合视频| 国产精品美女主播在线观看纯欲| 亚洲综合精品四区| 性欧美办公室18xxxxhd| 亚洲欧美在线视频观看| 欧美一区国产二区| 久久精品国产亚洲一区二区| 欧美一区二区性| 久久久www成人免费精品| 久久午夜视频| 久久亚洲春色中文字幕久久久| 午夜精品久久久久久久蜜桃app| 亚洲黄色三级| 亚洲一区高清| 伊人久久亚洲美女图片| 国产精品嫩草久久久久| 免费在线看一区| 亚洲图片在线观看| 午夜精品久久久久久久男人的天堂| 欧美mv日韩mv国产网站app| 亚洲国产国产亚洲一二三| 一本久道综合久久精品| 午夜精品久久久久久久男人的天堂 | 国产精品久久午夜夜伦鲁鲁| 国产午夜精品一区二区三区欧美| 国自产拍偷拍福利精品免费一| 亚洲精品久久视频| 亚洲欧美日韩一区二区| 欧美~级网站不卡| 一区二区三区欧美激情| 免费观看在线综合色| 国产日韩欧美中文| 亚洲天堂成人在线观看| 美女国产精品| 久久精品国产亚洲精品| 国产精品网红福利| 一本色道精品久久一区二区三区 | 久久免费国产| 一本大道久久a久久精二百| 欧美v日韩v国产v| 黄色亚洲大片免费在线观看| 亚洲欧美中文在线视频| 亚洲精选成人| 欧美大胆a视频| 亚洲国产99| 欧美成人中文| 久久精品国产精品| 国产一区二区在线观看免费| 你懂的一区二区| 欧美日精品一区视频| 好男人免费精品视频| 欧美在线播放| 亚洲欧美日韩精品| 国产丝袜美腿一区二区三区| 亚洲尤物影院| 亚洲一级黄色| 欧美午夜精品久久久久久孕妇| 一区二区久久久久| 日韩天堂在线视频| 国产精品毛片a∨一区二区三区| 亚洲私人影吧| 在线视频欧美日韩| 欧美性猛交xxxx乱大交退制版 | 国产精品日韩欧美一区二区| 亚洲综合丁香| 亚洲欧洲av一区二区| 国产欧美在线播放| 久久久精品免费视频| 久久超碰97人人做人人爱| 国产一区二区三区久久悠悠色av| 久久精品在线视频| 久久综合精品一区| 亚洲片在线资源| 日韩视频免费在线观看| 国产精品麻豆欧美日韩ww| 久久精品一区蜜桃臀影院 | 国产精品porn| 欧美一区二区三区四区在线 | 伊人久久亚洲热| 亚洲国产天堂久久综合网| 欧美性感一类影片在线播放| 久久精品日产第一区二区三区| 久久aⅴ国产紧身牛仔裤| 亚洲国产精品va在线看黑人 | 亚洲福利视频三区| 亚洲日本中文字幕区| 国产精品影片在线观看| 美女视频一区免费观看| 欧美日韩国产精品专区| 久久精品国产亚洲精品| 欧美区一区二| 久久一区中文字幕| 欧美日韩一区二区视频在线观看 | 国产亚洲欧美中文| 亚洲第一区中文99精品| 国产精品国产三级国产专播精品人 | 亚洲欧美激情一区二区| 亚洲第一福利在线观看| 久久久久国产精品一区三寸| 蜜臀a∨国产成人精品| 欧美三级电影一区| 欧美电影免费观看高清| 国产精品午夜国产小视频| 欧美高清视频一区二区三区在线观看 | 性欧美大战久久久久久久久| 久久亚洲不卡| 久久久久综合| 国产精品久久一卡二卡| 亚洲国产高清aⅴ视频| 黄色成人片子| 欧美亚洲视频一区二区| 亚洲视频在线免费观看| 久久午夜国产精品| 久久精品国产清高在天天线| 欧美日韩免费一区| 亚洲国产精品成人久久综合一区| 国产日韩欧美视频| 亚洲午夜影视影院在线观看| 日韩视频三区| 美女精品在线| 欧美日韩在线亚洲一区蜜芽| 久久久久国产精品一区三寸| 国产精品乱码妇女bbbb| 99视频在线观看一区三区| 日韩视频在线观看| 欧美电影免费观看高清|