При тестировании по этой строке:

“… so that’s that… ”

Следующее должно, но не совпадать с открывающей кавычкой и после многоточия и пробела:

sed "s/\([“‘\"']…\) /\1/g"

Однако это правильно соответствует второму многоточию и следующему пробелу и закрывающей кавычке:

sed "s/… \([”’\"'.!?]\)/…\1/g"

Если я разделю первый на части, он будет работать нормально:

sed -e "s/\(“…\) /\1/g" \
-e "s/\(‘…\) /\1/g" \
-e "s/\(\"…\) /\1/g" \
-e "s/\('…\) /\1/g"

Так почему же он не работает, когда он сгруппирован вместе? Особенно, когда он отлично работает с закрывающими кавычками.

1 ответ1

1

Какую версию sed вы используете? Я считаю, что GNU sed должен поддерживать символы Unicode, и ваш пример работает для меня в Linux (Ubuntu, со средой UTF-8).

Если вы используете версию sed, которая не поддерживает Unicode, ваша группа символов будет повреждена, потому что она соответствует только одному байту. Если ваша командная строка использует кодировку UTF-8, когда вы говорите sed, не поддерживающий Unicode, на самом деле видит три байта, \xE2 , \x80 и \x9C . Это поднимет вашу группу персонажей, которая будет соответствовать только одному из этих байтов за раз. Различные другие конструкции тоже потерпят неудачу, например. a”? это буква 'a', затем два байта, за которыми следует необязательный третий байт, поэтому само по себе a не будет соответствовать выражению, хотя выглядит так, как должно.

(Вы можете также рассмотреть возможность замены символа многоточия на три периода. Многоточие - это символ совместимости в Юникоде; обычно считается более современным выписывать точки и позволять шрифту заботиться о наборе текста.)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .