Да, это не вина ColdFusion. Это общая проблема.
В основном это ошибка оригинальной спецификации CGI, которая указывает, что PATH_INFO должен быть% -одекодирован, таким образом, теряются исходные последовательности байтов %xx, которые позволили бы вам определить, какие реальные символы имели в виду.
И это отчасти ошибка IIS, потому что он всегда пытается прочитать отправленные %xx байты в части пути как кодировку UTF-8 в кодировке Unicode (если только путь не является допустимой последовательностью байтов UTF-8, в этом случае он сбрасывается для кодовой страницы Windows по умолчанию, но не дает возможности узнать, что это произошло). Сделав это, он помещает его в переменные окружения в виде строки Unicode (поскольку envvars - это Unicode под Windows).
Однако большинство основанных на байтах инструментов, использующих C stdio (и я предполагаю, что это применимо к ColdFusion, как это делается в Perl, Python 2, PHP и т. Д.), Затем пытаются прочитать переменные среды как байты, а MS Среда выполнения C снова кодирует содержимое Unicode, используя кодовую страницу Windows по умолчанию. Таким образом, любые символы, которые не помещаются в кодовую страницу по умолчанию, будут потеряны навсегда. Это будет включать ваши арабские символы при запуске на западной установке Windows.
Умный сценарий, имеющий прямой доступ к Win32 GetEnvironmentVariableW API, может вызывать это, чтобы получить переменную среды native-Unicode, которую они затем могут закодировать в UTF-8 или что-то еще, что они хотят, предполагая, что ввод был также UTF -8 (это то, что вы обычно хотели бы сегодня). Однако я не думаю, что CodeFusion предоставляет вам такой доступ, и в любом случае он работает только с IIS6 и выше; IIS5.x будет отбрасывать любые символы, отличные от кодовой страницы по умолчанию, прежде чем они достигнут переменных окружения.
В противном случае вам лучше всего переписать URL. Если слой выше CF может преобразовать это search.cfm/القاهرة в search.cfm/?q=القاهرة, то вы не столкнетесь с той же проблемой, поскольку переменная QUERY_STRING, в отличие от PATH_INFO, не указана для% -декодирования, поэтому %xx байты остаются там, где их может видеть инструмент на уровне CF.