raku 可以避免这种 Malformed UTF-8 错误吗？
Can raku avoid this Malformed UTF-8 error?
当我 运行 这个 raku 脚本...
my $proc = run( 'tree', '--du', :out);
$proc.out.slurp(:close).say;
我在 MacOS 上遇到这个错误...
Malformed UTF-8 near bytes ef b9 5c
... 而不是像这样的 tree zsh 输出，这正是我想要的...
.
├── 00158825_20210222_0844.csv
├── 1970-Article\ Text-1971-1-2-20210118.docx
├── 1976-Article\ Text-1985-1-2-20210127.docx
├── 2042-Article\ Text-2074-1-10-20210208.pdf
├── 2045-Article\ Text-2076-1-10-20210208.pdf
├── 6.\ Guarantor\ Form\ (A).pdf
试过slurp(:close, enc=>'utf8-c8')，还是一样的错误
我也试过了...
shell( "tree --du >> .temp.txt" );
my @lines = open(".temp.txt").lines;
dd @lines;
...错误是一样的。
打开 .temp.txt 揭示了这个...
.
â<94><9c>â<94><80>â<94><80> [ 1016739] True
â<94><9c>â<94><80>â<94><80> [ 9459042241] dir-name
â<94><82>Â Â â<94><9c>â<94><80>â<94><80> [ 188142] Business
â<94><82>Â Â â<94><82>Â Â â<94><9c>â<94><80>â<94><80> [ 9117] KeyDates.xlsx
â<94><82>Â Â â<94><82>Â Â â<94><9c>â<94><80>â<94><80> [ 13807] MondayNotes.docx
文件-我给这个...
.temp.txt: text/plain; charset=unknown-8bit
有什么建议吗？
[这是 Catalina 10.15.17，终端编码 Unicode(UTF-8)
欢迎使用™ v2020.10。
实施 ™ 编程语言 v6.d。
基于 MoarVM 版本 2020.10。]
更新 我删除了这个 nanswer，因为 Brad 的出色回答和 Valle Lukas 的评论点似乎让它变得毫无意义。然后@p6steve 确认 Brad 的回答和 Valle Lukas 的解决方案对他们都有效，因此更有理由将其删除。但为时已晚！我的 nanswer 中的一个错误误导了 @p6steve，他在跟进 SO 中犯了类似的错误。我们有过失。为了赎罪，我现在永久删除并留下我可耻的过去。
这是一个 nanswer。不知道Mac，但喜欢调查，我要说的不在评论里。
更新下面的'find .'应该是'find', '.'。参见 run doc。
你得到了什么？：
say .out.lines given run 'find .', :out
如果find .有效，问题大概是tree。
如果 find . 不起作用，那么尝试一些非常简单的方法，它内置于 MacOS 中，确实应该起作用。如果它不起作用，那么问题就不是 tree，而是更基本的问题。
Malformed UTF-8 near bytes ef b9 5c
这意味着 Raku 需要 UTF-8 但输入不是 UTF-8。
将消息从计算机语言翻译成英语：
The supposedly English string "[Linux] xshell远程登陆CentOS时中文乱码解决_Cindy的博客 ..." is Malformed near 远程登.
换句话说，tree 命令没有生成 UTF-8。
(因此使用 utf8-c8 几乎肯定在第一个实例中是无用的。它的目的是作弊。当文本要么 almost 都是 UTF-8除了少数流氓字节，你不会费心去整理输入，或者当你别无选择只能接受输入但仍然想得过且过。但在这种情况下你肯定应该要么追根究底解决问题，要么找到 tree 的替代方法。)
Terminal encoding Unicode(UTF-8)
A google for "Terminal encoding Unicode(UTF-8)" 仅产生 7 个匹配项。 None 似乎与“终端编码 Unicode(UTF-8)”完全匹配。在我看来，除了一个，其他都像…… ef b9 5c 在 Rakudo 看来。 :)
如果你copy/pasted那个字符串，你是从哪里复制的？
如果你自己写了那个字符串，为什么你这么确定 MacOS 真的 是 编码 tree 的输出为 UTF -8 当 运行 通过内核（不是 shell）你写的是？
run 不使用 shell.
The current doc claims shell uses /bin/sh -c on MacOS.
这个输出是什么？：
readlink -e $(which sh)
输出是zsh?
如果是 sh -c 应该使用它。
如果不是，那可能是问题所在。
当使用 shell 时，必须确保传递的字符串被适当地引用和转义。当你尝试这些时你会得到什么？：
say .out.lines given shell "'find .'", :out;
say .out.lines given shell "'tree --du'", :out;
tree 究竟在调用什么？它是 zsh 中的 shell 别名吗？如果它是二进制文件，您从哪里安装它以及如何配置它，尤其是在影响 zsh 的编码处理方面？
您的 codepage/locale 似乎不是 Utf8。 （或者 tree 忽略代码页并使用不同的内容。）
快……得到一些东西，从中得到任何东西；就是使用8位的单字节编码。
run( 'tree', '--du', :out, :enc<latin1> );
用utf8看解码哪里开始出错一般就够了
也就是说，让我们看看您的预期输出和文件输出。
say '├──'.encode; # utf8:0x<E2 94 9C E2 94 80 E2 94 80>
在你的文件中你有
â<94><9c>â<94><80>â<94><80> [ 1016739] True
等等……
say 'â'.encode('latin1'); # Blob[uint8]:0x<E2>
<E2><94><9c><E2><94><80><E2><94><80>
<E2 94 9c E2 94 80 E2 94 80>
utf8:0x<E2 94 9C E2 94 80 E2 94 80>
是的，它们看起来非常相似。
因为它们完全相同。
所以它似乎在某种程度上产生了预期的输出。
这似乎证实了 tree 和您的代码之间存在编码问题。这表明 codepage/locale 设置错误。
您还没有真正提供足够的信息来弄清楚哪里出了问题。
您应该在二进制模式下使用 run 来为我们提供准确的输出。
say run('echo', 'hello', :out, :bin).out.slurp;
# Buf[uint8]:0x<68 65 6C 6C 6F 0A>
你也没有说 <9c> 是否在文件中作为四个文本字符字面意思，或者它是否是你用来打开文件将二进制数据转换为文本的任何功能。
如果所有的示例数据都是同一件事就好了。
稍微相关的说明…
由于 tree 给出了文件名，而 文件名不是 Unicode，因此在这里使用 utf8-c8 是合适的。
（用户名和密码通常也是如此。）
这是我在计算机上 运行 的一些代码，希望能说明原因。
say dir(:test(/^ r.+sum.+ $/)).map: *.relative.encode('utf8-c8').decode
# (résumé résumé résumé résumé)
dir(:test(/^ r.+sum.+ $/)).map: *.relative.encode('utf8-c8').say
# Blob[uint8]:0x<72 65 CC 81 73 75 6D 65 CC 81>
# Blob[uint8]:0x<72 C3 A9 73 75 6D 65 CC 81>
# Blob[uint8]:0x<72 C3 A9 73 75 6D C3 A9>
# Blob[uint8]:0x<72 65 CC 81 73 75 6D C3 A9>
say 'é'.NFC;
# NFC:0x<00e9>
say 'é'.NFD
# NFD:0x<0065 0301>
sub to-Utf8 ( Uni:D $_ ){
.map: *.chr.encode
}
say to-Utf8 'é'.NFC
# (utf8:0x<C3 A9>)
say to-Utf8 'é'.NFD
# (utf8:0x<65> utf8:0x<CC 81>)
因此 é 要么被编码为一个组合代码点 <C3 A9> 要么被编码为两个分解代码点 <65> <CC 81>.
我真的为了这个目的创建了4个“同名”文件吗？
是的。是的，我做到了。
当我 运行 这个 raku 脚本...
my $proc = run( 'tree', '--du', :out);
$proc.out.slurp(:close).say;
我在 MacOS 上遇到这个错误...
Malformed UTF-8 near bytes ef b9 5c
... 而不是像这样的 tree zsh 输出，这正是我想要的...
.
├── 00158825_20210222_0844.csv
├── 1970-Article\ Text-1971-1-2-20210118.docx
├── 1976-Article\ Text-1985-1-2-20210127.docx
├── 2042-Article\ Text-2074-1-10-20210208.pdf
├── 2045-Article\ Text-2076-1-10-20210208.pdf
├── 6.\ Guarantor\ Form\ (A).pdf
试过slurp(:close, enc=>'utf8-c8')，还是一样的错误
我也试过了...
shell( "tree --du >> .temp.txt" );
my @lines = open(".temp.txt").lines;
dd @lines;
...错误是一样的。
打开 .temp.txt 揭示了这个...
.
â<94><9c>â<94><80>â<94><80> [ 1016739] True
â<94><9c>â<94><80>â<94><80> [ 9459042241] dir-name
â<94><82>Â Â â<94><9c>â<94><80>â<94><80> [ 188142] Business
â<94><82>Â Â â<94><82>Â Â â<94><9c>â<94><80>â<94><80> [ 9117] KeyDates.xlsx
â<94><82>Â Â â<94><82>Â Â â<94><9c>â<94><80>â<94><80> [ 13807] MondayNotes.docx
文件-我给这个...
.temp.txt: text/plain; charset=unknown-8bit
有什么建议吗？
[这是 Catalina 10.15.17，终端编码 Unicode(UTF-8) 欢迎使用™ v2020.10。 实施 ™ 编程语言 v6.d。 基于 MoarVM 版本 2020.10。]
更新 我删除了这个 nanswer，因为 Brad 的出色回答和 Valle Lukas 的评论点似乎让它变得毫无意义。然后@p6steve 确认 Brad 的回答和 Valle Lukas 的解决方案对他们都有效，因此更有理由将其删除。但为时已晚！我的 nanswer 中的一个错误误导了 @p6steve，他在跟进 SO 中犯了类似的错误。我们有过失。为了赎罪，我现在永久删除并留下我可耻的过去。
这是一个 nanswer。不知道Mac，但喜欢调查，我要说的不在评论里。
更新下面的'find .'应该是'find', '.'。参见 run doc。
你得到了什么？：
say .out.lines given run 'find .', :out
如果find .有效，问题大概是tree。
如果 find . 不起作用，那么尝试一些非常简单的方法，它内置于 MacOS 中，确实应该起作用。如果它不起作用，那么问题就不是 tree，而是更基本的问题。
Malformed UTF-8 near bytes ef b9 5c
这意味着 Raku 需要 UTF-8 但输入不是 UTF-8。
将消息从计算机语言翻译成英语：
The supposedly English string "[Linux] xshell远程登陆CentOS时中文乱码解决_Cindy的博客 ..." is Malformed near
远程登.
换句话说，tree 命令没有生成 UTF-8。
(因此使用 utf8-c8 几乎肯定在第一个实例中是无用的。它的目的是作弊。当文本要么 almost 都是 UTF-8除了少数流氓字节，你不会费心去整理输入，或者当你别无选择只能接受输入但仍然想得过且过。但在这种情况下你肯定应该要么追根究底解决问题，要么找到 tree 的替代方法。)
Terminal encoding Unicode(UTF-8)
A google for "Terminal encoding Unicode(UTF-8)" 仅产生 7 个匹配项。 None 似乎与“终端编码 Unicode(UTF-8)”完全匹配。在我看来，除了一个，其他都像…… ef b9 5c 在 Rakudo 看来。 :)
如果你copy/pasted那个字符串，你是从哪里复制的？
如果你自己写了那个字符串，为什么你这么确定 MacOS 真的 是 编码 tree 的输出为 UTF -8 当 运行 通过内核（不是 shell）你写的是？
run 不使用 shell.
The current doc claims shell uses /bin/sh -c on MacOS.
这个输出是什么？：
readlink -e $(which sh)
输出是zsh?
如果是 sh -c 应该使用它。
如果不是，那可能是问题所在。
当使用 shell 时，必须确保传递的字符串被适当地引用和转义。当你尝试这些时你会得到什么？：
say .out.lines given shell "'find .'", :out;
say .out.lines given shell "'tree --du'", :out;
tree 究竟在调用什么？它是 zsh 中的 shell 别名吗？如果它是二进制文件，您从哪里安装它以及如何配置它，尤其是在影响 zsh 的编码处理方面？
您的 codepage/locale 似乎不是 Utf8。 （或者 tree 忽略代码页并使用不同的内容。）
快……得到一些东西，从中得到任何东西；就是使用8位的单字节编码。
run( 'tree', '--du', :out, :enc<latin1> );
用utf8看解码哪里开始出错一般就够了
也就是说，让我们看看您的预期输出和文件输出。
say '├──'.encode; # utf8:0x<E2 94 9C E2 94 80 E2 94 80>
在你的文件中你有
â<94><9c>â<94><80>â<94><80> [ 1016739] True
等等……
say 'â'.encode('latin1'); # Blob[uint8]:0x<E2>
<E2><94><9c><E2><94><80><E2><94><80>
<E2 94 9c E2 94 80 E2 94 80>
utf8:0x<E2 94 9C E2 94 80 E2 94 80>
是的，它们看起来非常相似。
因为它们完全相同。
所以它似乎在某种程度上产生了预期的输出。
这似乎证实了 tree 和您的代码之间存在编码问题。这表明 codepage/locale 设置错误。
您还没有真正提供足够的信息来弄清楚哪里出了问题。
您应该在二进制模式下使用 run 来为我们提供准确的输出。
say run('echo', 'hello', :out, :bin).out.slurp;
# Buf[uint8]:0x<68 65 6C 6C 6F 0A>
你也没有说 <9c> 是否在文件中作为四个文本字符字面意思，或者它是否是你用来打开文件将二进制数据转换为文本的任何功能。
如果所有的示例数据都是同一件事就好了。
稍微相关的说明…
由于 tree 给出了文件名，而 文件名不是 Unicode，因此在这里使用 utf8-c8 是合适的。
（用户名和密码通常也是如此。）
这是我在计算机上 运行 的一些代码，希望能说明原因。
say dir(:test(/^ r.+sum.+ $/)).map: *.relative.encode('utf8-c8').decode
# (résumé résumé résumé résumé)
dir(:test(/^ r.+sum.+ $/)).map: *.relative.encode('utf8-c8').say
# Blob[uint8]:0x<72 65 CC 81 73 75 6D 65 CC 81>
# Blob[uint8]:0x<72 C3 A9 73 75 6D 65 CC 81>
# Blob[uint8]:0x<72 C3 A9 73 75 6D C3 A9>
# Blob[uint8]:0x<72 65 CC 81 73 75 6D C3 A9>
say 'é'.NFC;
# NFC:0x<00e9>
say 'é'.NFD
# NFD:0x<0065 0301>
sub to-Utf8 ( Uni:D $_ ){
.map: *.chr.encode
}
say to-Utf8 'é'.NFC
# (utf8:0x<C3 A9>)
say to-Utf8 'é'.NFD
# (utf8:0x<65> utf8:0x<CC 81>)
因此 é 要么被编码为一个组合代码点 <C3 A9> 要么被编码为两个分解代码点 <65> <CC 81>.
我真的为了这个目的创建了4个“同名”文件吗？
是的。是的，我做到了。