Проблема кодирования Coldfusion/Lucee при использовании EncodeForHTML

Возникла проблема при использовании EncodeForHTML для определенных символов (в данном случае эмодзи)

Текст в данном случае: ⌛️a????b????c???? ???????????? ???? ????????‍♀️????????‍♀️????????‍♀️ ????

Теперь, если я просто прямой вывод

<cfoutput>#txt#</cfoutput>

Он отображается правильно, без проблем, но если я сначала использую EncodeForHTML

<cfoutput>#EncodeForHTML(txt)#</cfoutput>

Я понимаю это ⌛️a��b��c�� ������ �� ����‍♀️����‍♀️����‍♀️ ��

Я также проверил его с помощью EncodeForXML и esapiEncode, чтобы быть уверенным; все дают мне тот же результат. Я проверил, что настройки кодирования в Lucee - UTF-8, и тег метакодировки также установлен в UTF-8. Я не могу найти документацию по поводу: EncodeForHTML, в которой говорится, вносит ли он какие-либо изменения в кодировку символов, требует ли кодировка символов чего-то определенного или есть ли у него какие-либо известные проблемы с смайликами или определенными кодовыми точками.

Я ценю любую помощь или разъяснения, которые кто-либо может предоставить.

Редактировать: Спасибо всем. Хотел бы я принять несколько ответов.


person Jacob FW    schedule 03.07.2020    source источник
comment
В трекере Adobe есть активная ошибка, связанная с устаревшей версией библиотеки esapi-java-legacy. Вы можете прокомментировать там или поднять еще один со своей проблемой: tracker.adobe.com /#/представление/CF-4205004   -  person Bernhard Döbler    schedule 04.07.2020


Ответы (3)


От меня требовалось дезинфицировать смайлики, чтобы обеспечить перекрестную совместимость стороннего контента с внешними сервисами. Некоторый контент содержал эмодзи и вызывал проблемы с экспортом/импортом. Я написал оболочку ColdFusion для emoji-java для идентификации, очистки и преобразования смайликов.

https://github.com/JamoCA/cf-emoji-java

Например, функция parseToAliases() заменяет все юникоды эмодзи, найденные в строке. по своим псевдонимам.

emojijava = new emojijava();
emojijava.parseToAliases('I like ????');   // I like :pizza:

Для кодирования вы можете использовать либо parseToHtmlDecimal(), либо parseToHtmlHexadecimal() перед использованием EncodeForHTML().

emojijava = new emojijava();
test = emojijava.parseToHtmlDecimal('I like ????');   // I &#10084;️ &#127829;
EncodeForHTML(test);
person James Moberg    schedule 03.07.2020

На момент написания этой статьи последней версией ColdFusion было обновление 9 2018 года.

В свою очередь, он использует ESAPI 2.1.1.

В последних примечаниях к выпуску не упоминаются Emoji,

https://github.com/ESAPI/esapi-java-legacy/tree/develop/documentation

Но они упоминают в запросе на вытягивание 413

Устранение неспособности ESAPI обрабатывать кодовые точки, отличные от BMP.

Это датируется 2017 годом

https://github.com/ESAPI/esapi-java-legacy/pull/ 413


Поэтому, основываясь на всей этой информации, я бы рекомендовал выполнить оба следующих действия.

  1. Попробуйте использовать ESAPI напрямую. Так это было сделано до того, как ESAPI был добавлен в CF. Эта проблема может существовать или не существовать в ESAPI.

  2. Подайте заявку в Adobe, чтобы обновить эту библиотеку.

person James A Mohler    schedule 03.07.2020

Да, в ESAPI 2.2.0.0 решена проблема неправильного кодирования символов, отличных от BMP (см. https://github.com/ESAPI/esapi-java-legacy/issues/300) в рамках PR #413, о котором Джеймс упоминал выше.

Но я только что сегодня утром загрузил выпуск ESAPI 2.2.1.0-RC1 (кандидат на выпуск 1) в Maven Central и надеюсь выпустить официальный выпуск 2.2.1.0 к следующим выходным, поэтому, если вы собираетесь подать заявку в Adobe на исправить это с помощью обновленной версии ESAPI, я бы подождал еще неделю, а затем сказал им обновить до 2.2.1.0.

person Kevin W. Wall    schedule 06.07.2020
comment
Github по-прежнему говорит, что 2.2.0.0 является последней версией, хотя есть тег 2.2.1.0 github.com/ESAPI/esapi-java-legacy/releases - person Bernhard Döbler; 23.07.2020
comment
Виноват; Я забыл этот шаг. Там сейчас. github.com/ESAPI/esapi-java-legacy/ релизы/тег/esapi-2.2.1.0 - person Kevin W. Wall; 24.07.2020