風は吹いてるか?

这是ultralight卡

看起来代码里面对pn532做了配置自动保存，但是acr122u没存，可能就每次用122都要搜索半天设备 我在win7下速度正常，或许和win10扫描操作不同有关？没深入研究过libnfc，不知道具体为什么

要命。小米11如果设置为其他机型文字，就会被自动替换成“m2011k2c”（关键是还tmd小写的，难看死了）

 文件例

> 在程序本身不做出改变的前提下，建议阁下使用如下替代解决方案： 使用Unicode符号\u2571(制表正斜杠), 即 "╱" , 代替 "/" 使用Unicode符号\u2044(分数正斜杠), 即 " ⁄ " , 代替 “/” 使用Unicode符号\u2215(除法正斜杠), 即 " ∕ " , 代替 "/" 由于我的个人音乐库全部使用这一份副本，而且购买的数字正版也是以“/”（半角ASCII斜杠）进行分割。贸然更改这个斜杠不仅不利于美观，也可能引起不可确定的问题。

> 是flac的原因，windows资源管理器无法（不会）分割flac的多艺术家 > > ~更新：可能是要设置flac多艺术家应当使用分号分割而不是"/"~ > > 我的想法是把一首歌的艺术家作为一个整体出现在媒体库艺术家列表不进行主动拆分 但是如过其中的一个艺术家也有单曲则也把这首多艺术家的也添加进去 > > 例如22/7不会主动分割为22和7，但是如果存在其他艺术家为22的歌曲则 左侧列表里有 22；22/7 且都含有这首歌 这显然是一个针对特例的做法，实际上并不存在22和22/7的歌曲存在关联的可能性。又或者说，如果曲库出现了一首歌的艺术家字符串是`NMB46/22/7`，又各自有`22/7`和`NMB46/AKB48`这样的艺术家字符串，程序会产生怎样的结果？（本处不作任何关于这三个团的推测和期望，仅仅是用于举例） 并且不如添加白名单（PowerAmp的做法，默认添加了“AC/DC”和“+/-”）简单。 但是如果近期的迭代中能够修复该问题，我很乐意看到PotPlayer的继任者出现在我的电脑上。期待作者的更新！

> 关于举例，按我上述做法程序会正常工作，这个方案代价是 可能会有识别不出的（会和其他艺术家组合出现），不会有不存在的 就是说假设真的同时存在“22/7”与“22”并不会导致“7”单独出现 > > 关于白名单，由于没有用过不太清楚，这里说的是一个程序全局的字符串列表吗？ 如果是的话，这也是一个针对特例的处理，是在赌下述情况不会出现 比如对“22/7”设置不拆分并且真的存在艺术家“22”与“7”就会出问题，只是可能性很低 > > 我觉得全局白名单的方案更好一些 你这么说的话，我仔细想了下，确实都有各自的弊端。不过如果自动识别的那个方案是可行的话，用户应该会很乐于接受不需要自己动手设置白名单的体验。（大概代价是写算法费点脑细胞+扫描慢一点？） 目前能想到的就是出现假设某人下载的歌曲全都是`NMB46/AKB48`这样的字符串的话，会看见有一个`NMB46/AKB48`，并且找不到`AKB48`这个艺术家，可能会懵逼，而意识不到这是没有自动拆分。~~不过厨到只听联合演唱的用户可能要么以为是常年联合演唱要么就是死忠粉吧~~ ~~肥秋也真是的，公式文件居然用的都是ASCII的半角斜杠，直接坑死一片。~~ ~~包括我的自动根据metainfo重命名文件都翻车了（“./22/7 - 理解者.flac”，中间那个斜杠被认为是路径了）~~ ******** 期待尽快添加这个feature

Risky function.

miui上没有跟随，是因为非类原生？

您倒是把标题改了啊