Существуют ли ограниченные шаблоны символов в Azure TableStorage RowKeys? Я не смог найти какие-либо документированные многочисленные запросы. Тем не менее, я получаю поведение, которое подразумевает такое при тестировании производительности.
У меня есть странное поведение с RowKeys, состоящее из случайных символов (тестовый драйвер предотвращает появление ограниченных символов (/\ #?) и блокирование одиночных кавычек в RowKey). В результате у меня есть RowKey, который будет вставлять штраф в таблицу, но не может быть запрошен (результат InvalidInput). Например:
RowKey: 9}5O0J=5Z,4,D,{!IKPE,~M]%54+9G0ZQ&G34!G+
Попытка запроса с помощью этого RowKwy (равенства) приведет к ошибке (как в нашем приложении, так и в Azure Storage Explorer и Cloud Storage Studio 2). Я взглянул на запрос, отправленный через Fiddler:
GET /foo()?$filter=RowKey%20eq%20'9%7D5O0J=5Z,4,D,%7B!IKPE,~M%5D%54+9G0ZQ&G34!G+' HTTP/1.1
Похоже, что% 54 в RowKey не экранируется в фильтре. Интересно, что я получаю подобное поведение для пакетных запросов к хранилищу таблиц с URI в пакетном XML, который включает этот RowKey. Я также видел подобное поведение для RowKeys со встроенными двойными кавычками, хотя я еще не изолировал этот шаблон.
Кто-нибудь может мне помочь в этом? Я могу легко ограничить появление дополнительных символов в RowKeys, но очень хотел бы знать "правила".
В полях PartitionKey и RowKey недопустимы следующие символы:
\)Для получения дополнительной информации обратитесь к следующей статье: http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx
public static readonly Regex DisallowedCharsInTableKeys = new Regex(@"[\\\\#%+/?\u0000-\u001F\u007F-\u009F]");
Обнаружение недопустимых разделов таблицы и строк:
bool invalidKey = DisallowedCharsInTableKeys.IsMatch(tableKey);
Санирование недействительного раздела или строки строки:
string sanitizedKey = DisallowedCharsInTableKeys.Replace(tableKey, disallowedCharReplacement);
На этом этапе вам также может потребоваться префикс дезинфицированного ключа (ключ раздела или строки строки) с хешем исходного ключа, чтобы избежать ложных коллизий разных недопустимых ключей с тем же самым дезинфицированным значением.
Не используйте string.GetHashCode(), хотя, поскольку он может создавать разные хэш-коды для одной и той же строки и не должен использоваться для идентификации уникальности и не должен сохраняться.
Я использую SHA256: https://msdn.microsoft.com/en-us/library/s02tk69a(v=vs.110).aspx
чтобы создать байтовый массив байтов недействительного ключа, преобразовать массив байтов в шестнадцатеричную строку и префикс для этого дезинфицированного ключа таблицы.
Также см. соответствующую документацию MSDN: https://msdn.microsoft.com/en-us/library/azure/dd179338.aspx
Связанный раздел по ссылке: Символы, запрещенные в ключевых полях
Следующие значения недопустимы для значений свойств PartitionKey и RowKey:
Символ прямой косой черты (/)
Символ обратной косой черты (\)
Знак знака числа (#)
Символ вопросительного знака (?)
Управляющие символы от U + 0000 до U + 001F, включая:
Символ горизонтальной вкладки (\ t)
Символ linefeed (\n)
Символ возврата каретки (\ r)
Управляющие символы от U + 007F до U + 009F
Обратите внимание, что в дополнение к указанным символам в статье MSDN я также добавил% char к шаблону, так как видел в нескольких местах, где люди упоминают, что это проблематично. Я думаю, что некоторые из них также зависят от языка и технологии, которую вы используете для доступа к хранилищу таблиц.
Если вы обнаружите дополнительные проблемные символы в вашем случае, вы можете добавить их к шаблону регулярных выражений, ничего больше не нужно изменять.
Я только узнал (трудный путь), что знак "+" разрешен, но невозможно запросить в PartitionKey.
Я обнаружил, что помимо символов, перечисленных в ответе Игорека, это также может вызвать проблемы (например, вставки не будут выполняться):
Протестировано с помощью Azure Node.js SDK.
В дополнение к вышесказанному вы также не можете использовать символ подчеркивания _ в начале ключа раздела, возвращается ошибка, когда ключ, начинающийся с подчеркивания, не является допустимым ключом раздела.