Почему специальные символы изменяют ширину конечного / начального пробела в Gedit или medit?
Когда я вставляю специальный символ из Карты символов в Gedit или medit в Ubuntu 16.04, тогда пробел сразу после специального символа дисплей с «сжатым» межсимвольным интервалом.
Пример
-
После нескольких ведущих символов TABS я набираю:
A > B - Затем копирую и вставляю эту строку ниже, чтобы дублировать
- Если я теперь заменю напечатанный
>символ на⯈, вставив -
, я получу это:
Вы можете видеть, что пробелы после
⯈сжались / сжались. -
Если я удаляю символ
⯈, то пробелы возвращаются к нормальной ширине символа
Замечание о дополнительном поведении:
- Если я начну новую строку с «непробельного символа» и вставлю
⯈, то пробелы , ведущие , будут не затронуто -
Если я начну новую строку с пробелов и вставлю
⯈, то ведущие пробелы будут также ] пострадавших
Тесты
-
Обычные:
- поиск в Google
- Поиск в AskUbuntu
- Поиск в StackOverflow
-
Я использовал этот Unicode to Java string конвертер литералов и мои пробелы после
⯈все еще пробелы - ничего смешного там не происходит. -
Я позаботился о том, чтобы установить набор символов и размер шрифта в таблице символов так же, как мои настройки шрифта Gedit.
Это не должно иметь никакого значения - я знаю - но я сделал это ради проверки здравомыслия.
- Сохранение содержимого Gedit в правильно отформатированном HTML-файле и просмотр в Chrome:
Нормальное расстояние между символами - как и ожидалось - Копирование / вставка содержимого Gedit в пустой ячейка в LibreOffice Calc:
Интервал между символами нормальный - как и ожидалось
Это сводит меня с ума.
Есть какие-нибудь идеи относительно того, почему это происходит?
ОБНОВЛЕНИЕ
Я зарегистрировал сообщение об ошибке:
-
Ubuntu : панель запуска
-
GNOME
1 ответ
Это ошибка
Поддержка Gedit для более высоких символов Unicode не идеальна. Поймите, что то, что вы видите в gedit, не обязательно то, что вы получаете в другом приложении. Gedit - забавное и полезное маленькое приложение, но оно не идеальное.
Бьюсь об заклад, ошибка уже сообщается. Может быть, это один из них? https://bugzilla.gnome.org/buglist.cgi?quicksearch=product%3A%22gedit%22%20utf-8&list_id=272617
Я не вижу такого, который соответствует тому, что вы говорите. Возможно, вы можете сообщить о новой ошибке, выполнив следующие действия: https://wiki.gnome.org/Apps/Gedit/ReportingBugs
Если вы пишете код, попробуйте IntelliJ или другой более серьезный редактор. Даже Vim может сделать лучше. Я проверил, и ваш образец отлично работает в обоих случаях.
3-байтовый символ UTF-8
Вы используете 3-байтовый символ UTF-8:
e2af88
Я запустил xxd в созданном тестовом файле by gedit - Версия 3.22.1. xxd V1.10 27oct98 от Juergen Weigert также некорректно отображал символ, но cat (GNU coreutils) 8.26.
Итак, давайте пройдем кропотливый процесс перевода кодировки UTF-8 в символ Unicode, который он представляет.
Hx Binary
e2 1110 0010
af 1010 1111
88 1000 1000
Удалите элементы управления (каждый из которых заканчивается 0):
Ctr Actual bits Ctrl Meaning
1110 0010 1110 means: a three-byte character.
10 101111 10 means: continuation of character.
10 001000 10 means: continuation of character.
Конкатенация фактических битов:
0010101111001000
Преобразование обратно в шестнадцатеричное (не В этом примере показано / имеет значение, но если число битов не делится на 4 равномерно, необходимо создать группы по 4 бита, начиная с правой стороны, а затем дополнить нулями слева):
Hx Binary
2b 0010 1011
c8 1100 1000
Unicode Character
2bc8 - это «⯈» или «черный средний правый треугольник с центром» U + 2BC8. Таким образом, Gedit сохраняет правильный символ, просто не отображая пробелы вокруг него.
Похоже, что 2bc8 был добавлен в Unicode 7.0 в 2014 году: http://unicode.org/cldr/utility/character.jsp?a=2BC8
Возможно, gedit не делает ' t полностью поддерживает 7.0 еще? Или что пробелы иногда сжимаются около 3-байтовых символов UTF-8?