Есть ли у нас список неподдерживаемых символов для имен файлов Azure blob?

Я загружаю в blob файлы с разными специальными символами. Он не загружается. Я обнаружил, что есть некоторые ограничения на именование файлов лазурного. Поэтому мне нужен список неподдерживаемых символов Юникода для имен файлов BLOB-объектов или способ узнать, поддерживается ли символ в имени файла BLOB-объектов Azure или нет.

Я сослался на нижеприведенный документ по этому поводу. Они не предоставили никакого конкретного списка или способа его найти. https://docs.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-shares--directories--files--and-metadata

Мне нужна точная проверка правильности имени файла, происходящая в лезвии загружаемого файла на лазурном BLOB-объекте


azure azure-files c# filenames azure-storage-blobs
person Dinesh Kumar    schedule 21.02.2019    source источник
comment
что вы имеете в виду, он довольно подробно описывает возможности?   -  person 4c74356b41    schedule 21.02.2019
comment
Кроме того, они упоминают некоторые символы ASCII или Unicode, такие как управляющие символы (от 0x00 до 0x1F, \ u0081 и т. Д.) ETC означает, что есть еще несколько символов. Я пишу инструмент, который обнаружит неподдерживаемый символ имени файла. Поэтому мне потребовался полный набор неподдерживаемых символов или полный набор поддерживаемых символов.   -  person Dinesh Kumar    schedule 21.02.2019
comment
о, я понимаю, что вы имеете в виду, почти все, за исключением [a-zA-Z0-9-], хотя у меня нет исчерпывающего списка.   -  person 4c74356b41    schedule 21.02.2019
comment
Нам также необходимо включить поддерживаемые специальные символы. Да, но есть некоторые другие языковые символы, которые не поддерживаются.   -  person Dinesh Kumar    schedule 21.02.2019

Ответы (2)


arrow_upward
2
arrow_downward

Я не думаю, что Microsoft Docs очень точно указаны.

Имя большого двоичного объекта должно соответствовать следующим правилам именования:

  • Имя большого двоичного объекта может содержать любую комбинацию символов.
  • Имя большого двоичного объекта должно состоять не менее чем из одного символа и не может превышать 1024 символа для больших двоичных объектов в хранилище Azure.
  • Имена BLOB-объектов чувствительны к регистру.
  • Зарезервированные символы URL-адреса должны быть правильно экранированы.
  • Количество сегментов пути, составляющих имя большого двоичного объекта, не может превышать 254. Сегмент пути - это строка между последовательными символами-разделителями (например, косая черта '/'), которая соответствует имени виртуального каталога.

В своих тестах я обнаружил, что у вас не может быть этих символов в имени Azure Blob.

  • Управляющие символы 0x00-0x1F
  • Удалить 0x7F
  • Обратная косая черта '\' - Azure преобразует ее в прямую косую черту '/'.
  • Имена, оканчивающиеся точкой "."

Я использовал пакет SDK Azure Blob go для выполнения этих тестов, так что это возможно, некоторые из этих ограничений связаны с этим.

person Nick Craig-Wood    schedule 21.09.2019

arrow_upward
0
arrow_downward

Вот правильный документ: https://docs.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs-and-metadata#blob-names

Имя большого двоичного объекта должно соответствовать следующим правилам именования:

Примечание. Избегайте имен больших двоичных объектов, которые заканчиваются точкой (.), Косой чертой (/), а также последовательностью или комбинацией этих двух.

Служба BLOB-объектов основана на простой схеме хранения, а не на иерархической схеме. Однако вы можете указать символ или разделитель строк в имени большого двоичного объекта, чтобы создать виртуальную иерархию. Например, в следующем списке показаны действительные и уникальные имена больших двоичных объектов. Обратите внимание, что строка может быть действительной как имя большого двоичного объекта, так и имя виртуального каталога в одном контейнере:

  • /a

  • /a.txt

  • /a/b

  • /a/b.txt

Вы можете воспользоваться символом разделителя при перечислении больших двоичных объектов.

Примечание: doc, упомянутый в вашем вопросе, предназначен для хранилища файлов Azure, а не для хранилища BLOB-объектов Azure, поэтому это неверный вариант.

person Zhaoxing Lu    schedule 22.02.2019
comment
Вы правы с документом. Но все же это не коснулось моего вопроса. Считайте имя файла "test.␍ 簴 ꊨ 簷". Мы не можем скопировать этот файл на лазурный портал из-за неподдерживаемого символа. Поэтому мне нужно найти либо все допустимые символы, либо неподдерживаемые символы для капель. Моя проблема такая же, как упомянутая в этой ссылке social.msdn.microsoft.com/Forums/azure/en-US/ - person Dinesh Kumar; 22.02.2019
comment
@DineshKumar из этой ссылки ясно, что ограничение основано на стандарте URI. RFC 1738 дополнительно упоминается. Любое имя файла, которое было бы незаконным как часть URI, предположительно также незаконно как blobname. - person Svend; 01.03.2019
comment
@Svend Похоже, что так не работает. Он не принимает символы вроде '\ u007f', которые поддерживаются в ntfs, а также некоторые другие специальные символы также не поддерживаются. - person Dinesh Kumar; 01.03.2019
comment
@DineshKumar То, что NTFS обрабатывает, не имеет значения. \u007f - управляющий символ удаления. Из RFC 1738, упомянутого в ваших ссылках, я нахожу следующее: URLs are written only with the graphic printable characters of the US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded - person Svend; 01.03.2019
comment
@Svend Не могли бы вы поделиться ссылкой на документ, о котором говорилось в RFC 1738. Мне будет полезно его проанализировать. - person Dinesh Kumar; 08.03.2019
comment
Мне это кажется противоречивым. он говорит, что зарезервированные символы URL-адреса должны быть правильно экранированы, а затем говорит, что /a/b.txt является допустимым именем большого двоичного объекта, когда согласно tools.ietf.org/html/rfc3986#section-2.2, / - зарезервированный символ - person Andy; 13.05.2020
comment
Еще я обнаружил, что вы должны кодировать пробел как% 20. если вы закодируете его как + (что будет делать большинство кодировщиков URL) или оставите его как пробел, вы получите + обратно при вызове ListBlobs - person Andy; 14.05.2020