我在使用 DiscoTOC 的自动生成目录功能时，似乎遇到了一个潜在问题：
在使用除英语以外的语言（例如中文）的各种级别标题时，自动生成目录中的 data-d-toc ID 似乎只捕获标题中的数字和英文字母。这种情况很容易导致生成相同的 ID，进而导致右侧滚动条中的链接不正确。
在上图中，如果标题中的序号都为 5，则生成的 data-d-toc ID 将都为 toc-h2-5。因此，这将导致两个不同的链接错误地指向同一部分。
但是，通过将序号修改为 1.5 和 2.5，data-d-toc ID 将不同（toc-h2-15 和 toc-h2-25），从而确保链接准确且合适。
为了确保滚动条内链接的准确性，建议将标题保留为英文吗？
此外，对于中文等语言，最可行的解决方案是否包括在标题中加入多级序号（例如 3.5、3.6.5、4.2.5.6）？
参考：
这个问题我之前已经发现提出过了，还顺便fork了一份
I have already mentioned this issue, and forked a copy
https://meta.discourse.org/t/discotoc-automatic-table-of-contents/111143/399?u=lhc_fl
不过我这个虽然能用但是不完美，主要是懒得改了
However, although it’s working, it is not perfect, but I am too lazy to change the code.
Obviously a better solution is to use base64 to generate data-d-toc and add a unique identifier to prevent possible duplicate titles
我暂时无权对公司的论坛做出这样的改动，但还是感谢你的回复！
I currently do not have the authority to make such changes to my company’s forum, but I do appreciate your response!
另外，我还想问，官方是否有考虑过在后续DiscoTOC插件的正式版中，加入这一功能对其他语言的支持呢？
Furthermore, I’d like to ask if the official team has considered incorporating support for other non-latin languages regarding this auto-generated table of contents in future DiscoTOC component releases? @Lilly @awesomerobot
再次感谢各位！
Once more, thank you, everyone!
In truth, they have taken into consideration non-Latin languages, utilizing the slugify(h.textContent) method. I suspect that this slugify function was developed in accordance with the forum’s slug generation method. When it is not in ‘encode’ mode, issues tend to arise, although I have not personally tested this hypothesis.
In previous instances when we used the official version of the theme component our forum’s slug generation method was set to ‘none’, which gave rise to similar problems. May I therefore suggest that you attempt altering the setting to ‘encode’?
其实他们考虑了non-latin language ，用到了slugify(h.textContent) ，我怀疑这个slugify函数是根据论坛的 slug generation method 生成的，当它不是 encode 的时候就会出问题，但我没试过。
之前用官方版插件时，我们论坛的 slug generation method 设置的是 none 就会出现和你一样的问题。要不你试试改成 encode 。
另外考虑到官方对组件的修复速度……隔壁有个组件我去年提的问题到现在都没下文，我建议你申请一下用我fork的版本得了
试着改了下这个设置，但前面说到的问题依然存在，data-d-toc ID还是只能读取数字和字母，还是会有重复的目录ID。我感觉问题的关键不在这里？
我问下我领导吧，感谢解答~
I made an attempt to modify this setting, but the issues mentioned earlier still persist. The data-d-toc ID can only read numbers and letters, and there are still instances of duplicated table of contents IDs. I guess the crux lies elsewhere?
更新：今天更新了代码。后缀现在由索引生成：
此改进解决了非拉丁字符或相同标题名称生成相同锚点的问题
const suffix = `${slugify(h.textContent)}-${post?.post_number}-${index}`