openSUSE Leap 15.2 Dolphin 文件名不按拼音排序

15.1 无此问题,15.2 貌似没按拼音排序,浏览文件时有点不习惯,需要安装哪个包?或者修改什么设置吗?

GNOME 没有这个问题。

没试过 gnome,难道和 KDE 有关系?

我一开始以为是你看错了,自己试了试还真有问题,,,,,,

从上到下分别是 Xfce thunar, GNOME nautilus, KDE dolphin 都不是拼音排序。

我猜测这个问题和那个文件管理器没有关系,是某个 LC_xxxx 的设置有关。因为我的主要语言一直设置为英语,直接就复现了。。。。

你可不可以从命令行复制一下 locale 的结果是啥?

从 YaST 的 sysconfig 里面把 RC_LC_COLLATE 或者你用其它方法改一下 LC_COLLATE,改成 zh_CN.utf8 就可以按中文的方式来排序了。


image
image

1赞

这个顺序原来从 glibc 开始就生效了,

所以在 unix/linux 下编写多语言的 C 程序应该用 strcoll()wcscoll()而不是 strcmp()。前者的输出会由于 LC_COLLATE 而改变。。。

https://man7.org/linux/man-pages/man3/strcoll.3.html
https://www.gnu.org/software/libc/manual/html_node/Collation-Functions.html

python

https://docs.python.org/3/library/locale.html#locale.strcoll

如果你想问 glibc 是怎么处理顺序的,他们是直接硬编码 2.5 万个汉字。。。

https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/zh_CN.UTF-8.in;hb=HEAD

cnqtd@localhost:~> locale
LANG=zh_CN.UTF-8
LC_CTYPE=zh_CN.UTF-8
LC_NUMERIC=zh_CN.UTF-8
LC_TIME=zh_CN.UTF-8
LC_COLLATE=zh_CN.UTF-8
LC_MONETARY=zh_CN.UTF-8
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT=zh_CN.UTF-8
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=

文件名排序
改与不改 LC 都是这排序,显然,咱肯定没办法记住 2.5W 汉字的编码

cat ~/.config/plasma-localerc

KDE 有时覆盖系统的那个 Locale,那个文件里面有什么内容?

还有通过命令行设定再启动 dolphin?

LC_COLLATE=zh_CN.UTF-8 ; dolphin

ls 命令的中文排序正常嘛?

ls 中文名排序正常
lc
命令行设定再启动,排序还是不正常

KDE 设置那里已经指定了简体中文
我先把系统设定为英文,再指定显示中文?

我搞错了,应该是

export LC_COLLATE=zh_CN.UTF-8 ; dolphin

中文拼音排序


中文按英语排序

风滚草上可以随便切。。。

既然 ls 命令的排序可以按照拼音来,说明整体的 LC_COLLATE 的设置没有问题,该有的软件也齐全。

那如果真的是 Dolphin 的 bug, 那用一个基于 GTK 的 文件管理器应该没有问题,比如说 nautilus, thunar, nemo 之类的,

如果基于 GTK 的也有问题,那么那个变量可能在中间的什么过程被覆盖掉了。

也许不是 Dolphin 的 bug,用 nautilus 也是这样。不过其他应用程序,比如用 audacious 等浏览文件时,中文文件排序是按拼音音序排列的


好吧,先忍忍。。。

@ 马大瞎子 Dolphin 的版本是多少?你的截图有问题…正常不应该是数字和英文排在前面,你的相当于是中英文混排。我现在的版本是 20.08.2,正确的排序是所有的中文按照拼音顺序排在最前面,然后字母和数字在拼音的后面再排一遍…


全中文文件名的目录里,排序也没按拼音音序

如果在其他应用程序里的文件 - 打开,浏览文件时,排序为先数字、再中文按音序排列、最后是字母按音序排列。就是说只在 Dolphin 和其他文件管理软件里没按拼音音序排列中文文件

@slbtty

strcoll() 这个解释只对了一部分,说说我对这个问题的分析:

Dolphin 依靠 kitemviews 提供排序,kitemviews 依靠的是 QListViews(github 上做一下 KDE/Dolphin 和 KDE/kitemviews 的源代码搜索,关键字 “Sort by”。)

看 “Compare Strings” 这个章节。Qt 使用 libicu 做 “locale-aware unicode sorting”,没有 linking icu 才会用 strcoll()。

也就是说我们可以用 c 写个测试小程序出来,两种输出,一种是 strcoll() 的输出,一种是 libicu 的输出…楼主自己比较一下就知道他是哪种了,然后再对应去看是不是 libicu 的问题。

1赞

@marguerite 我刚才在 15.2 里证实了一下,这个 bug 可以 100% 复现

设置好 LC_COLLATE 以后,ls 和 Nautilus 可以正确显示

影响的范围应该是所有的 KDE/Qt 程序,不只 dolphin, 基于 qt 的文件选择器也不遵守 LC_COLALTE 的设定,而且可能的影响范围不止中文。

不过风滚草里面已经不会有这个现象了,所以这个 bug 应该已经在新版修复了。


image

不过奇妙的是,我在修改了 LC_ALL 以后又可以正确地按照拼音来,

image

@ 马大瞎子 一个临时的解决方法是直接在 .bashrc 后面加上

export LC_ALL="zh_CN.utf8"

以前有人报过这个 bug

https://bugs.kde.org/show_bug.cgi?id=211531
https://bugreports.qt.io/browse/QTBUG-67661
https://bugreports.qt.io/browse/QTBUG-58621

另外 15.2 上的
qt5 -> 5.12.7
icu -> 65.1

现在用 Nautilus 可以按拼音排序了,邪门啊,昨天还试过不行的,啥都没改,刚才就正常了。这是大过年的闹小情绪?

有道理,不过我觉得 Dophin 应该是一板一眼地按照 model-view 的方法来编写的,kitemviews 应该只负责显示,对应的数据部分来自模型 model 应该是 kfileitemmodel

strcoll 和 qt 对应方法的实现,应该都是先实现一个通用的排序算法,然后这个排序算法需要一个自定义的比较的函数。(感觉和 go 里面的 sort.slice https://golang.org/pkg/sort/#Slice)。dolphin 应该也是差不多的操作。

kfileitemmodel 里面的 localeAwareLessThan 应该就是用来排序的那个比较函数。直接返回了的 lambda/匿名函数 m_collator.compare(c1, c2) < 0。那个 m_collator 实际上是更底层一点的 QCollator.

大概是这个样子,不过我觉得这些细节没什么用。结论都是 qt 有问题 :)