About Encodings 1.1/ru

From Aviberry API

К содержанию
Возникли вопросы?

---

Рассмотрим подробнее метод API startConversion. Все сказанное далее не является проблемой, если имена файлов содержат только символы латиницы. Но, если в именах используются национальные символы, то требуемый результат может быть и не получен, т.е. не удастся создать конвертацию.

Рассмотрим для примера обработку source_url, т.е. обработку имени файла-источника. Как уже было сказано при описании метода, имя файла-источника должно быть оформлено соответственно стандарту, т.е. все спецсимволы должны быть "percent-encoded". Cервис после получения этого параметра выполнит обратное преобразование и получит "стандартное" имя файла-источника, которое и будет использовать в дальнейшей работе.

Например, дальнейшей работой является определение того, что файл-источник существует на самом деле. Для этого будет использовано уже это новое, преобразованное имя. Но, вполне может статься, что имя файла-источника в файловой системе сервера, на котором он хранится, находится в другой кодировке, чем переданное имя. Тогда, используя полученное имя, сервис не сможет определить наличие файла даже существующего на самом деле.

С помощью пары соответствующих параметров source_url_encoding и source_filename_encoding для файла-источника можно точно сказать сервису, что "переданное методу имя фала-источника сейчас в кодировке source_url_encoding, но для того, чтобы получить доступ к файлу в файловой системе сервера, на котором он хранится, нам нужно имя файла-источника в кодировке source_filename_encoding (актуальной кодировке)". Т.е. возможно задать некое "правило" преобразования переданного имени файла-источника, и сервис выполнит это преобразование.

Рассмотрим конкретный пример. Допустим, на некоем FTP сервере ftp.example.com, в его корне, находится файл пример.flv (русские символы в названии), созданный изначально в Windows. Верным URL этого файла для передачи сервису является ftp://ftp.example.com/%EF%F0%E8%EC%E5%F0.flv. Допустим, что есть HTML форма, на которой пользователь может сам вводить имя файла и некий пользователь указывает этот самый файл. Пользователь - это не компьютер - и он вместо ftp://ftp.example.com/%EF%F0%E8%EC%E5%F0.flv может набрать просто ftp://ftp.example.com/пример.flv и будет прав :-). И если кодировка страницы с формой UTF-8, то URL файла полученного с формы примет вид ftp://ftp.example.com/%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80.flv. Если данный URL передать в качестве файла-источника при создании конвертации, то сервис вернет ошибку, что такого файла не существует, т.к. на самом деле в файловой системе сервера лежит именно файл %EF%F0%E8%EC%E5%F0.flv. Для успешного создания конвертации необходимо пользователю API или самому перекодировать полученное из формы имя файла в актуальную кодировку для указания этого нового конвертированного имени при создании конвертации, или же при создании конвертации, не меняя само имя, задать то самое "правило" преобразования имени файла, которое для рассматриваемого примера заключается в том, что нужно установить дополнительные параметры source_url_encoding в UTF-8, а source_filename_encoding в Windows-1251, и сервис сам сделает необходимые преобразования.

Заданное "правило" преобразования имени файла-источника срабатывает только если пара параметров source_url_encoding и source_filename_encoding установлена в различные значения. При одинаковых значениях, никакого преобразования не выполняется, т.е. данные параметры игнорируются, а сервисом используется имя файла-источника именно в том виде, в каком ему передано. Данное поведение является поведением по умолчанию, т.к. оба параметра по умолчанию установлены в UTF-8.

Для файла-результата все аналогично сказанному для файла-источника. Список поддерживаемых кодировок представлен в приложении.

Таким образом, основное правило при передаче имени файла-источника или имени файла-результата, содержащего национальные символы: "percent-encoded" должно быть имя файла в актуальной кодировке для файловой системы, на которой данный файл хранится. Если по какой-то причине это не так, то пользователь API или сам должен получить имя файла в актуальной кодировке и передать уже его, или должен использовать описанные здесь соответствующие параметры метода startConversion для того, чтобы указать сервису правило получения имени файла в актуальной кодировке из переданного имени.

Поддерживаемые кодировки

---

К содержанию
Возникли вопросы?