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

關于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 閱讀(1822) 評論(0)  編輯 收藏 引用 所屬分類: 操作系統雜談

<2015年2月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
1234567

導航

統計

公告

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

常用鏈接

留言簿(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>
            欧美女激情福利| 欧美激情亚洲综合一区| 一区二区三区我不卡| 国产九区一区在线| 国产日韩欧美日韩大片| 亚洲国产日韩欧美在线99| 亚洲一区国产视频| 欧美一区二区网站| 久久久精品国产免大香伊| 久久精品亚洲精品国产欧美kt∨| 久久综合九色综合久99| 亚洲精品激情| 亚洲在线观看视频网站| 久久久久国产精品一区三寸| 欧美成人dvd在线视频| 欧美另类变人与禽xxxxx| 国产老女人精品毛片久久| 亚洲国产精品电影| 亚洲一区二区三区四区五区午夜| 欧美在线999| 亚洲福利国产精品| 亚洲一区二区三区在线| 久久网站免费| 国产精品xnxxcom| 尤物九九久久国产精品的分类| 一区二区三区精品在线| 久久久久一区二区| 在线视频精品一区| 六月丁香综合| 国产精品久久777777毛茸茸| 在线观看91精品国产入口| 亚洲砖区区免费| 亚洲高清电影| 久久久精品一区| 国产精品极品美女粉嫩高清在线| 亚洲经典在线| 另类av导航| 亚洲欧美一区二区精品久久久| 欧美大片一区二区| 极品尤物久久久av免费看| 亚洲一区二区三| 欧美国产日韩亚洲一区| 欧美一区二区三区免费观看视频| 欧美精品一区二区三区久久久竹菊 | 久久久久看片| 亚洲一区二区三区免费观看| 欧美精品国产精品| 永久555www成人免费| 欧美制服丝袜第一页| 夜夜爽av福利精品导航 | 亚洲主播在线| 亚洲精品国产精品国自产观看| 久久久91精品| 精品电影在线观看| 久久久人成影片一区二区三区| 亚洲午夜久久久久久久久电影网| 欧美日韩国产综合视频在线观看| 亚洲综合欧美日韩| 欧美日韩精选| 亚洲精品欧美一区二区三区| 久久裸体视频| 久久精品国产第一区二区三区| 国产亚洲精久久久久久| 久久成人久久爱| 亚洲欧美在线aaa| 国产欧美精品| 久久免费视频这里只有精品| 久久av老司机精品网站导航| 国产综合婷婷| 欧美va天堂| 欧美xxx在线观看| 日韩午夜在线视频| 9色国产精品| 国产农村妇女精品一二区| 久久人91精品久久久久久不卡 | 欧美福利小视频| 99爱精品视频| 亚洲在线成人精品| 精品电影在线观看| 亚洲国产一区二区a毛片| 欧美日韩免费观看一区二区三区| 亚洲欧美日韩国产一区二区三区| 午夜精品久久久久久久99水蜜桃| 国产一区二区三区高清| 免费观看亚洲视频大全| 欧美激情亚洲国产| 欧美一区二区视频在线观看| 久久久久久久久久码影片| 一本色道88久久加勒比精品| 亚洲一区高清| 91久久国产综合久久蜜月精品 | 麻豆久久精品| 在线视频日韩| 久久精品99国产精品| 日韩视频中文| 久久国产精品第一页| 99国产精品99久久久久久粉嫩| 亚洲在线成人精品| 亚洲精品乱码久久久久久蜜桃91| 亚洲一区二区少妇| 亚洲国产日韩综合一区| 一区二区三区国产盗摄| 1000部精品久久久久久久久| 在线亚洲精品| 亚洲日本欧美在线| 午夜一区二区三视频在线观看 | 久久九九免费视频| 亚洲欧美国产精品专区久久| 久久人人爽人人爽爽久久| 亚洲综合精品一区二区| 欧美成人国产| 久久综合狠狠综合久久综合88| 国产精品v片在线观看不卡 | 99热免费精品| 国产一区二区三区精品久久久| 91久久精品国产91久久性色| 国产视频亚洲| 中文久久乱码一区二区| 亚洲精品在线视频| 久久精品免费| 久久国产一二区| 国产精品一区二区三区观看| 亚洲另类视频| 艳妇臀荡乳欲伦亚洲一区| 蜜桃av一区二区三区| 久久免费黄色| 狠狠爱www人成狠狠爱综合网| 欧美亚洲在线| 久久国产精品久久久久久久久久| 国产精品久久久久久妇女6080 | 亚洲国产视频一区| 久久激情综合| 久久亚洲综合色| 国产一区二区久久| 香蕉免费一区二区三区在线观看| 亚洲欧美日韩天堂一区二区| 欧美私人网站| 中文在线资源观看网站视频免费不卡| 国产精品99久久99久久久二8| 欧美视频国产精品| 亚洲素人在线| 欧美在线视频在线播放完整版免费观看| 国产精品美女在线观看| 亚洲一区亚洲| 久久深夜福利| 亚洲国产精品视频一区| 欧美精品久久久久久久久老牛影院| 91久久极品少妇xxxxⅹ软件| 一本大道久久精品懂色aⅴ| 欧美日韩中文字幕在线视频| 亚洲视频在线视频| 久久久久成人精品| 亚洲高清视频一区| 欧美日韩不卡一区| 亚洲嫩草精品久久| 美女精品在线| 亚洲深夜福利网站| 国产欧美一区二区精品忘忧草| 久久久精品国产一区二区三区| 欧美激情综合| 亚洲欧美久久久久一区二区三区| 国产亚洲成年网址在线观看| 久久裸体视频| 亚洲精品综合精品自拍| 欧美一区二区三区成人| 亚洲第一中文字幕在线观看| 欧美日韩一区二区三区| 欧美一区二区三区久久精品茉莉花| 欧美国产日韩一区二区在线观看| 一区二区三区欧美成人| 国产亚洲欧洲| 欧美日韩小视频| 欧美在线free| 亚洲美女在线一区| 久久久之久亚州精品露出| 99精品黄色片免费大全| 国产欧美日韩高清| 欧美日韩国产综合网| 亚洲欧洲偷拍精品| 久久久久在线| 一区二区三区欧美在线| 免费成人毛片| 亚洲综合日韩在线| 91久久久久久国产精品| 国产日韩精品在线观看| 欧美国产日韩一区二区| 久久精品国产77777蜜臀| 夜夜嗨av一区二区三区四区| 蜜臀va亚洲va欧美va天堂| 亚洲综合国产精品| 99精品久久久| 亚洲高清资源| 国模大胆一区二区三区| 国产精品露脸自拍| 欧美激情四色| 欧美阿v一级看视频| 久久久久久久尹人综合网亚洲| 午夜精品美女久久久久av福利| 99re66热这里只有精品4| 91久久久在线|