Символы Unicode в относительной ссылке iTextSharp - PullRequest
Новая
       8

Символы Unicode в относительной ссылке iTextSharp

0 голосов
/ 12 ноября 2018

Я пытаюсь создать относительную ссылку в файле PDF, созданном с помощью iTextSharp

, все хорошо работает с буквами ASCII, но если я добавлю другие символы Юникода в путь, они просто пропускаются

Это прекрасно работает: 

Chunk chunk = new Chunk(text, font);
chunk.SetAnchor("./Attachments/1.jpg");

Это создает неправильную ссылку (ссылка создается следующим образом: //1.jpg, Вложения - часть отсутствует): 

Chunk chunk = new Chunk(text, font);
chunk.SetAnchor("./Вложения/1.jpg");

Есть ли способ создать правильную ссылку с символами Unicode?Спасибо

1 Ответ

0 голосов
/ 14 ноября 2018

Используя Chunk.SetAnchor в iText 5, вы эффективно генерируете URI Action . Параметр URI указан как

URI Строка ASCII (Обязательно) Унифицированный идентификатор ресурса для разрешения, закодированный в 7-битном ASCII.

(ISO 32000-1, таблица 206 - Дополнительные записи, относящиеся к действию URI)

Таким образом, можно считать нормальным, что не-ASCII символы, такие как ваши кириллические, не принимаются Chunk.SetAnchor. (Однако это не нормально, что они просто отбрасываются; если метод не принимает свои входные данные, он должен выдать исключение.)

Но это ни в коем случае не означает, что вы не можете ссылаться на файл в пути, который использует некоторые не-ASCII символы. Вместо этого вы можете использовать тот факт, что путь считается URI: это, в частности, означает, что вы можете применить схему кодирования URL для специальных символов!

Таким образом, просто замените 

chunk.SetAnchor("./Вложения/1.jpg");

от 

chunk.SetAnchor(WebUtility.UrlEncode("./Вложения/1.jpg"));

и ваша ссылка снова работает! (По крайней мере, так было в моих тестах.)

PS: в .Net у вас действительно есть большой выбор классов для кодирования URL, ср. например этот ответ . WebUtility.UrlEncode работал для меня в данном случае, но в зависимости от вашего варианта использования один из других может быть более подходящим.

PPS: Ситуация немного меняется в новой спецификации PDF:

URI Строка ASCII (Обязательно) Унифицированный идентификатор ресурса для разрешения, закодированный в UTF8.

(ISO 32000-2, таблица 210 - Дополнительные записи, относящиеся к действию URI)

(Я думаю, что «ASCII» в столбце type является ошибкой спецификации, а к UTF8 в столбце value следует относиться серьезно.)

Но iText 5 не поддерживает PDF 2.0 и, следовательно, не поддерживает здесь кодировку UTF8. Вероятно, стоит протестировать с iText 7, который заявляет о поддержке PDF 2.0 ...

...