我有JSON文件注释了注释，我在使用.进行操作之前将其删除。我刚刚遇到一个有趣的问题，其中我收到了带注释注释的JSON文件，其中包含一些富文本引号字符（hex 93和hex 94）。我现有的sed dot % echo -e '# \x93text\x94\n{"a":1}' | od -c
0000000 # 223 t e x t 224 \n { " a " : 1 }
0000020 \n
0000021
%
字符与这些字符不匹配。这是一个演示：
首先，输入：
% echo -e '# \x93text\x94\n{"a":1}' | sed 's/^\s*#.*//' | od -c
0000000 223 t e x t 224 \n { " a " : 1 } \n
0000017
%
这是变换：
LC_ALL=C请注意，sed表达式中的点字符与hex 93字符不匹配。但是，如果我加入% echo -e '# \x93text\x94\n{"a":1}' | LC_ALL=C sed 's/^\s*#.*//' | od -c
0000000 \n { " a " : 1 } \n
0000011
%
：
% echo -e '# \x93text\x94\n{"a":1}' | sed '/^\s*#.*/d' | od -c
0000000 { " a " : 1 } \n
0000010
然后sed表达式中的点字符与十六进制93和十六进制94字符匹配。 sed文档部分Locale Considerations说的是括号表达式，但上面的行为似乎证明了这个问题发生在其他地方。
值得注意的是，删除而非替换并未显示此问题：
LC_ALL=C鉴于我正在对带注释的JSON文件进行操作，我认为将LC_ALL=C添加到sed语句的解决方案是合理的。
所以，我的问题：使用sed在进行非特定于语言环境的applicationDidBecomeActive转换时我总是想要使用的东西（适用于带注释的JSON）文件）？如果没有，有哪些替代方案可以避免我上面提到的问题？
我的环境：
答案 0 :(得分：0)
C语言环境是一种特殊的语言环境，意味着它是最简单的语言环境。您还可以说，虽然其他语言环境适用于人类，但C语言环境适用于计算机。 在C语言环境中，字符是单字节，字符集是ASCII
在某些系统上，与POSIX语言环境有所不同，例如，未定义非ASCII字符的排序顺序。
所以LC_ALL = C是考虑非第8位字符的安全方法。
见comparaison
使用LC，sed计数作为角色的一部分
echo -e '# \x93text\x94\n{"a":1}' | LC_ALL=C sed 's/[^[:alnum:]]/[HERE:&] /g' | od -c
0000000 [ H E R E : # ] [ H E R E :
0000020 ] [ H E R E : 223 ] t e x t [
0000040 H E R E : 224 ] \n [ H E R E : {
0000060 ] [ H E R E : " ] a [ H E R
0000100 E : " ] [ H E R E : : ] 1 [
0000120 H E R E : } ] \n
没有LC，sed不计入要考虑的字符的一部分（[[:alnum:]]和[^[:alnum:]]不要看第8位字符
echo -e '# \x93text\x94\n{"a":1}' | sed 's/[[:alnum:]]/[HERE:&] /g' | od -c
0000000 # 223 [ H E R E : t ] [ H E R
0000020 E : e ] [ H E R E : x ] [ H
0000040 E R E : t ] 224 \n { " [ H E R E
0000060 : a ] " : [ H E R E : 1 ] }
0000100 \n
echo -e '# \x93text\x94\n{"a":1}' | sed 's/[^[:alnum:]]/[HERE:&] /g' | od -c
0000000 [ H E R E : # ] [ H E R E :
0000020 ] 223 t e x t 224 \n [ H E R E : {
0000040 ] [ H E R E : " ] a [ H E R
0000060 E : " ] [ H E R E : : ] 1 [
0000100 H E R E : } ] \n