显示以下症状的示例命令：sed 's/./@/' <<<$'\xfc'失败，因为字节0xfc不是有效的UTF-8字符。
请注意，相比之下，* GNU * sed（Linux，但也可安装在macOS上）只是通过无效字节，而不报告错误。
如果你不介意失去对你的真实语言环境的支持，那么使用**formerly accepted answer是一个选择**（如果你在美国的系统上，你永远不需要处理外来字符，那可能是好的。）
但是，仅***************************************************************************************************************************************************************************************************************************************************

LC_ALL=C sed -i "" 's|"iphoneos-cross","llvm-gcc:-O3|"iphoneos-cross","clang:-Os|g' Configure

注意：重要的是C的 * effective * LC_CTYPE设置，所以LC_CTYPE=C sed ... * 通常 * 也可以工作，但是如果LC_ALL碰巧被设置（设置为C以外的值），它将覆盖单个LC_*-类别变量，如LC_CTYPE。因此，最可靠的方法是设置LC_ALL。
但是，（有效地）将LC_CTYPE设置为C会将字符串视为每个字节都是其自己的字符（* 不执行 * 基于编码规则的解释），不考虑OS X默认使用的-multibyte-on-demand-UTF-8编码，其中外来字符具有多字节编码。
简而言之：* * 将LC_CTYPE设置为C会导致shell和实用程序仅将基本英文字母识别为字母（7位ASCII范围内的字母），因此外来字符不会被视为字母**，从而导致大写/小写转换失败。
同样，如果您不需要 * 匹配 * 多字节编码的字符（如é），而只是想 * 传递这些字符 *，这可能是很好的。
如果这还不够，并且/或者您想要了解原始错误的原因（包括确定导致问题的输入字节）并按需执行编码转换，请阅读下面的。
问题是输入文件的编码与shell的不匹配。
更具体地说，输入文件包含以UTF-8无效的方式编码的字符（正如@Klas Lindbäck在评论中所说的那样）-这就是sed错误消息invalid byte sequence试图说的。
最有可能的是，您的输入文件使用单字节8位编码，例如ISO-8859-1，通常用于编码“西欧”语言。

• • 示例：**

重音字母à的Unicode代码点为0xE0（224）-与ISO-8859-1相同。然而，由于 * UTF-8 * 编码的性质，这个单个代码点表示为 * 2 * bytes-0xC3 0xA0，而试图传递 * 单个字节 * 0xE0在UTF-8下是 * 无效 * 的。
下面是问题的演示，使用字符串voilà编码为ISO-8859-1，à表示为 * one * byte（通过ANSI-C引用的bash字符串（$'...'）使用\x{e0}创建字节）：
请注意，sed命令实际上是一个no-op，它只是简单地传递输入，但我们需要它来引发错误：

# -> 'illegal byte sequence': byte 0xE0 is not a valid char.
sed 's/.*/&/' <<<$'voil\x{e0}'

要简单地*忽略 * 问题，可以使用上面的LCTYPE=C方法：

# No error, bytes are passed through ('á' will render as '?', though).
LC_CTYPE=C sed 's/.*/&/' <<<$'voil\x{e0}'

如果要确定输入的哪些部分导致问题，请尝试以下操作：

# Convert bytes in the 8-bit range (high bit set) to hex. representation.
  # -> 'voil\x{e0}'
iconv -f ASCII --byte-subst='\x{%02x}' <<<$'voil\x{e0}'

输出将以十六进制形式显示所有高位设置的字节（超过7位ASCII范围的字节）。（但是，请注意，这也包括正确编码的UTF-8多字节序列-需要更复杂的方法来专门识别无效的UTF-8字节。）

• • 按需进行编码转换**：

标准实用程序iconv可用于转换为（-t）和/或从（-f）编码;iconv -l列出了所有支持的。

• • 示例：**

将FROM ISO-8859-1转换为shell中有效的编码（基于LC_CTYPE，默认情况下基于UTF-8），以上面的示例为基础：

# Converts to UTF-8; output renders correctly as 'voilà'
sed 's/.*/&/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')"

请注意，此 * 转换允许您正确匹配外来字符 *：

# Correctly matches 'à' and replaces it with 'ü': -> 'voilü'
sed 's/à/ü/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')"

要在处理后将输入BACK转换为ISO-8859-1，只需将结果通过管道传输到另一个iconv命令：

sed 's/à/ü/' <<<"$(iconv -f ISO-8859-1 <<<$'voil\x{e0}')" | iconv -t ISO-8859-1

将以下行添加到~/.bash_profile或~/.zshrc文件中。

export LC_CTYPE=C 
export LANG=C

我的解决方法是使用Perl：

find . -type f -print0 | xargs -0 perl -pi -e 's/was/now/g'

您只需在 sed 命令. ex之前通过管道传输 iconv 命令，并输入file.txt：
iconv -f ISO-8859-1 -t UTF8-MAC file.txt|sed 's/something/àéèêçùû/g'|...

• -f* 选项是“from”代码集，-t选项是“to”代码集转换。

注意大小写，网页通常显示小写，如〈charset=iso-8859-1”/〉和 iconv 使用大写。您可以使用命令 iconv -l 在系统中列出 iconv 支持的代码集。

• UTF8-MAC* 是用于转换的现代OS Mac代码集。

mklement0's answer很棒，但我有一些小的调整。
在使用iconv时，显式指定bash的编码似乎是个好主意。（even though the unicode standard doesn't recommend it），因为there can be legitimate confusions between UTF-8 and ASCII without a byte-order mark。不幸的是，当您显式指定endianness时，iconv不会预先添加字节顺序标记（UTF-16BE或UTF-16LE），因此我们需要使用UTF-16，它使用特定于平台的字节序，然后使用file --mime-encoding来发现使用的真正字节序iconv。
（我把我所有的编码都大写，因为当你用iconv -l列出iconv支持的所有编码时，它们都是大写的。）

# Find out MY_FILE's encoding
# We'll convert back to this at the end
FILE_ENCODING="$( file --brief --mime-encoding MY_FILE )"
# Find out bash's encoding, with which we should encode
# MY_FILE so sed doesn't fail with 
# sed: RE error: illegal byte sequence
BASH_ENCODING="$( locale charmap | tr [:lower:] [:upper:] )"
# Convert to UTF-16 (unknown endianness) so iconv ensures
# we have a byte-order mark
iconv -f "$FILE_ENCODING" -t UTF-16 MY_FILE > MY_FILE.utf16_encoding
# Whether we're using UTF-16BE or UTF-16LE
UTF16_ENCODING="$( file --brief --mime-encoding MY_FILE.utf16_encoding )"
# Now we can use MY_FILE.bash_encoding with sed
iconv -f "$UTF16_ENCODING" -t "$BASH_ENCODING" MY_FILE.utf16_encoding > MY_FILE.bash_encoding
# sed!
sed 's/.*/&/' MY_FILE.bash_encoding > MY_FILE_SEDDED.bash_encoding
# now convert MY_FILE_SEDDED.bash_encoding back to its original encoding
iconv -f "$BASH_ENCODING" -t "$FILE_ENCODING" MY_FILE_SEDDED.bash_encoding > MY_FILE_SEDDED
# Now MY_FILE_SEDDED has been processed by sed, and is in the same encoding as MY_FILE

有人知道如何让sed打印非法字节序列的位置吗？或者有人知道非法字节序列是什么吗？

$ uname -a
Darwin Adams-iMac 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64

我通过使用 tr 来回答上述问题。
我有一个.csv文件是一个信用卡对帐单，我试图将其导入Gnucash。我在瑞士，所以我必须处理像Zürich这样的单词。怀疑Gnucash不喜欢数字字段中的“”，我决定简单地替换所有

; ;

与

;;

下面是：

$ head -3 Auswertungen.csv | tail -1 | sed -e 's/; ;/;;/g'
sed: RE error: illegal byte sequence

我用 od 来表达一些想法：注意这个 od -c 输出中间的374

$ head -3 Auswertungen.csv | tail -1 | od -c
0000000    1   6   8   7       9   6   1   9       7   1   2   2   ;   5
0000020    4   6   8       8   7   X   X       X   X   X   X       2   6
0000040    6   0   ;   M   Y       N   A   M   E       I   S   X   ;   1
0000060    4   .   0   2   .   2   0   1   9   ;   9   5   5   2       -
0000100        M   i   t   a   r   b   e   i   t   e   r   r   e   s   t
0000120                Z 374   r   i   c   h                            
0000140    C   H   E   ;   R   e   s   t   a   u   r   a   n   t   s   ,
0000160        B   a   r   s   ;   6   .   2   0   ;   C   H   F   ;    
0000200    ;   C   H   F   ;   6   .   2   0   ;       ;   1   5   .   0
0000220    2   .   2   0   1   9  \n                                    
0000227

然后我想我可以尝试说服 tr 用374来代替正确的字节码，所以我首先尝试了一些简单的方法，这不起作用，但有一个副作用，就是告诉我麻烦的字节在哪里：

$ head -3 Auswertungen.csv | tail -1 | tr . .  ; echo
tr: Illegal byte sequence
1687 9619 7122;5468 87XX XXXX 2660;MY NAME ISX;14.02.2019;9552 - Mitarbeiterrest   Z

您可以在374字符处看到 tr bails。
使用Perl似乎可以避免这个问题

$ head -3 Auswertungen.csv | tail -1 | perl -pne 's/; ;/;;/g'
1687 9619 7122;5468 87XX XXXX 2660;ADAM NEALIS;14.02.2019;9552 - Mitarbeiterrest   Z?rich       CHE;Restaurants, Bars;6.20;CHF;;CHF;6.20;;15.02.2019

我的解决方法一直是使用gnu sed。对我的目的来说工作得很好。

对我来说，这个问题的根源在于试图打开/编辑.DS_Store文件的命令。删除这些命令为我解决了这个问题。