System.Xml Namespace

Classes

Interfaces

Enumerações

Delegados

Comentários

Padrões com suporte

O System.Xml namespace dá suporte a esses padrões:

• XML 1.0, incluindo suporte a DTD
• Namespaces XML, no nível do fluxo e do DOM
• Esquemas XML
• Expressões XPath
• Transformações XSLT
• Núcleo de Nível 1 do DOM
• Núcleo de Nível 2 do DOM

Consulte a seção Diferenças das especificações do W3C para dois casos em que as classes XML diferem das recomendações do W3C.

Processando XML de forma assíncrona

O System.Xml.XmlReader e System.Xml.XmlWriter as classes incluem uma série de métodos assíncronos que se baseiam no modelo de programação assíncrona. Esses métodos podem ser identificados pela cadeia de caracteres "Async" no final de seus nomes. Com esses métodos, você pode escrever um código assíncrono semelhante ao código síncrono e migrar seu código síncrono existente para código assíncrono facilmente.

• Use os métodos assíncronos em aplicativos em que há latência significativa de fluxo de rede. Evite usar as APIs assíncronas para operações de leitura/gravação de fluxo de arquivos local ou fluxo de arquivos local. O fluxo XmlTextReaderde entrada também deve dar XmlTextWriter suporte a operações assíncronas. Caso contrário, os threads ainda serão bloqueados por operações de E/S.

• Não recomendamos misturar chamadas de função síncronas e assíncronas, pois você pode esquecer de usar a await palavra-chave ou usar uma API síncrona em que uma assíncrona é necessária.

• Não defina o XmlReaderSettings.Async sinalizador ou XmlWriterSettings.Async o sinalizador para true se você não pretender usar um método assíncrono.

• Se você esquecer de especificar a await palavra-chave ao chamar um método assíncrono, os resultados serão não determinísticos: você pode receber o resultado esperado ou uma exceção.

• Quando um XmlReader objeto está lendo um nó de texto grande, ele pode armazenar em cache apenas um valor de texto parcial e retornar o nó de texto, portanto, a recuperação da XmlReader.Value propriedade pode ser bloqueada por uma operação de E/S. Use o XmlReader.GetValueAsync método para obter o valor de texto no modo assíncrono ou use o XmlReader.ReadValueChunkAsync método para ler um bloco de texto grande em partes.

• Ao usar um XmlWriter objeto, chame o XmlWriter.FlushAsync método antes de chamar XmlWriter.Close para evitar bloquear uma operação de E/S.

Diferenças das especificações do W3C

Em dois casos que envolvem restrições em componentes de esquema de grupo de modelos, o System.Xml namespace difere das recomendações do W3C.

Consistência em declarações de elemento:

Em alguns casos, quando grupos de substituição são usados, a System.Xml implementação não atende à "Restrição de Componente de Esquema: Declarações de Elemento Consistentes", que é descrita na seção Restrições em Componentes de Esquema de Grupo de Modelos da especificação W3C.

Por exemplo, o esquema a seguir inclui elementos que têm o mesmo nome, mas tipos diferentes no mesmo modelo de conteúdo e grupos de substituição são usados. Isso deve causar um erro, mas System.Xml compila e valida o esquema sem erros.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

   <xs:element name="e1" type="t1"/>
   <xs:complexType name="t1"/>

   <xs:element name="e2" type="t2" substitutionGroup="e1"/>
      <xs:complexType name="t2">
         <xs:complexContent>
            <xs:extension base="t1">
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1"/>
         <xs:element name="e2" type="xs:int"/>
      </xs:sequence>
   </xs:complexType>
</xs:schema>

Neste esquema, o tipo t3 contém uma sequência de elementos. Devido à substituição, a referência ao elemento e1 da sequência pode resultar no elemento e1 do tipo t1 ou no elemento e2 do tipo t2. O último caso resultaria em uma sequência de dois e2 elementos, em que um é do tipo t2 e o outro é do tipo xs:int.

Atribuição de partícula exclusiva:

Nas seguintes condições, a System.Xml implementação não atende à "Restrição de Componente de Esquema: Atribuição de Partícula Exclusiva", que é descrita na seção Restrições em Componentes de Esquema de Grupo de Modelos da especificação W3C.

• Um dos elementos no grupo faz referência a outro elemento.
• O elemento referenciado é um elemento principal de um grupo de substituição.
• O grupo de substituição contém um elemento que tem o mesmo nome de um dos elementos no grupo.
• A cardinalidade do elemento que faz referência ao elemento de cabeçalho do grupo de substituição e ao elemento com o mesmo nome de um elemento de grupo de substituição não é fixa (minOccurs < maxOccurs).
• A definição do elemento que faz referência ao grupo de substituição precede a definição do elemento com o mesmo nome de um elemento de grupo de substituição.

Por exemplo, no esquema abaixo, o modelo de conteúdo é ambíguo e deve causar um erro de compilação, mas System.Xml compila o esquema sem erros.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

  <xs:element name="e1" type="xs:int"/>
  <xs:element name="e2" type="xs:int" substitutionGroup="e1"/>

  <xs:complexType name="t3">
    <xs:sequence>
      <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
      <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="e3" type="t3"/>
</xs:schema>

Se você tentar validar o seguinte XML em relação ao esquema acima, a validação falhará com a seguinte mensagem: "O elemento 'e3' tem elemento filho 'e2' inválido" e uma exceção XmlSchemaValidationException será gerada.

<e3>
  <e2>1</e2>
  <e2>2</e2>
</e3>

Para contornar esse problema, você pode trocar declarações de elemento no documento XSD. Por exemplo:

<xs:sequence>
  <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
  <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
</xs:sequence>

torna-se o seguinte:

<xs:sequence>
  <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
  <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
</xs:sequence>

Este é outro exemplo do mesmo problema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
   <xs:element name="e1" type="xs:string"/>
   <xs:element name="e2" type="xs:string" substitutionGroup="e1"/>

   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
         <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
      </xs:sequence>
   </xs:complexType>
   <xs:element name="e3" type="t3"/>
</xs:schema>

Se você tentar validar o seguinte XML em relação ao esquema acima, a validação falhará com a seguinte exceção: "Exceção sem tratamento: System.Xml.Schema.XmlSchemaValidationException: o elemento 'e2' el é inválido - o valor 'abc' é inválido de acordo com seu tipo 'http://www.w3.org/2001/XMLSchema:int' de dados - a cadeia de caracteres 'abc' não é um valor Int32 válido."

<e3><e2>abc</e2></e3>

Considerações de segurança

Os tipos e membros no System.Xml namespace dependem do sistema de segurança do .NET. As seções a seguir discutem problemas de segurança específicos das tecnologias XML.

Observe também que quando você usa os System.Xml tipos e membros, se o XML contiver dados que têm possíveis implicações de privacidade, você precisará implementar seu aplicativo de uma maneira que respeite a privacidade dos usuários finais.

Acesso externo

Várias tecnologias XML têm a capacidade de recuperar outros documentos durante o processamento. Por exemplo, uma DTD (definição de tipo de documento) pode residir no documento que está sendo analisado. O DTD também pode residir em um documento externo referenciado pelo documento que está sendo analisado. As tecnologias XSD (linguagem de definição de esquema XML) e XSLT também têm a capacidade de incluir informações de outros arquivos. Esses recursos externos podem apresentar algumas preocupações de segurança. Por exemplo, você vai querer garantir que seu aplicativo recupere arquivos somente de sites confiáveis e que o arquivo que ele recupera não contenha dados mal-intencionados.

A XmlUrlResolver classe é usada para carregar documentos XML e resolver recursos externos, como entidades, DTDs ou esquemas, e importar ou incluir diretivas.

Você pode substituir essa classe e especificar o XmlResolver objeto a ser usado. Use a XmlSecureResolver classe se precisar abrir um recurso que você não controla ou que não seja confiável. O XmlSecureResolver encapsula um XmlResolver e permite restringir os recursos aos quais o subjacente XmlResolver tem acesso.

Negação de serviço

Os cenários a seguir são considerados menos vulneráveis a ataques de negação de serviço porque as System.Xml classes fornecem um meio de proteção contra esses ataques.

• Analisando dados XML de texto.

• Analisando dados XML binários se os dados XML binários foram gerados pelo Microsoft SQL Server.

• Gravando documentos XML e fragmentos de fontes de dados para o sistema de arquivos, fluxos, um TextWriterou um StringBuilder.

• Carregando documentos no objeto DOM (Document Object Model) se você estiver usando um XmlReader objeto e XmlReaderSettings.DtdProcessing definido como DtdProcessing.Prohibit.

• Navegando no objeto DOM.

Os cenários a seguir não serão recomendados se você estiver preocupado com ataques de negação de serviço ou se estiver trabalhando em um ambiente não confiável.

• Processamento de DTD.

• Processamento de esquema. Isso inclui adicionar um esquema não confiável à coleção de esquemas, compilar um esquema não confiável e validar usando um esquema não confiável.

• Processamento XSLT.

• Analisando qualquer fluxo arbitrário de dados XML binários fornecidos pelo usuário.

• Operações do DOM, como consulta, edição, movimentação de subárvores entre documentos e salvamento de objetos DOM.

Se você estiver preocupado com problemas de negação de serviço ou se estiver lidando com fontes não confiáveis, não habilite o processamento de DTD. Isso é desabilitado por padrão em XmlReader objetos que o XmlReader.Create método cria.

Se você tiver o processamento de DTD habilitado, poderá usar a XmlSecureResolver classe para restringir os recursos que podem XmlReader ser acessados. Você também pode projetar seu aplicativo para que o processamento XML seja de memória e tempo restritos. Por exemplo, você pode configurar limites de tempo limite em seu aplicativo ASP.NET.

Considerações de processamento

Como documentos XML podem incluir referências a outros arquivos, é difícil determinar quanto poder de processamento é necessário para analisar um documento XML. Por exemplo, documentos XML podem incluir um DTD. Se o DTD contiver entidades aninhadas ou modelos de conteúdo complexos, poderá levar um tempo excessivo para analisar o documento.

Ao usar XmlReader, você pode limitar o tamanho do documento que pode ser analisado definindo a XmlReaderSettings.MaxCharactersInDocument propriedade. Você pode limitar o número de caracteres resultantes da expansão de entidades definindo a XmlReaderSettings.MaxCharactersFromEntities propriedade. Consulte os tópicos de referência apropriados para obter exemplos de como definir essas propriedades.

As tecnologias XSD e XSLT têm recursos adicionais que podem afetar o desempenho do processamento. Por exemplo, é possível construir um esquema XML que requer uma quantidade substancial de tempo para processar quando avaliado em um documento relativamente pequeno. Também é possível inserir blocos de script em uma folha de estilos XSLT. Ambos os casos representam uma ameaça à segurança potencial para seu aplicativo.

Ao criar um aplicativo que usa a XslCompiledTransform classe, você deve estar ciente dos seguintes itens e suas implicações:

• O script XSLT está desabilitado por padrão. O script XSLT só deve ser habilitado se você precisar de suporte de script e estiver trabalhando em um ambiente totalmente confiável.

• A função XSLT document() está desabilitada por padrão. Se você habilitar a document() função, restrinja os recursos que podem ser acessados passando um XmlSecureResolver objeto para o XslCompiledTransform.Transform método.

• Os objetos de extensão são habilitados por padrão. Se um XsltArgumentList objeto que contém objetos de extensão for passado para o XslCompiledTransform.Transform método, os objetos de extensão serão usados.

• As folhas de estilo XSLT podem incluir referências a outros arquivos e blocos de script inseridos. Um usuário mal-intencionado pode explorar isso fornecendo dados ou folhas de estilo que, quando executadas, podem fazer com que seu sistema seja processado até que o computador seja executado com poucos recursos.

• Aplicativos XSLT executados em um ambiente de confiança misturada podem resultar em falsificação de folha de estilos. Por exemplo, um usuário mal-intencionado pode carregar um objeto com uma folha de estilos prejudicial e entregá-lo a outro usuário que, posteriormente, chama o XslCompiledTransform.Transform método e executa a transformação.

Esses problemas de segurança podem ser atenuados por não habilitar o script ou a document() função, a menos que a folha de estilos venha de uma fonte confiável e por não aceitar XslCompiledTransform objetos, folhas de estilo XSLT ou dados de origem XML de uma fonte não confiável.

Manuseio de exceção

As exceções geradas por componentes de nível inferior podem divulgar informações de caminho que você não deseja expor ao aplicativo. Seus aplicativos devem capturar exceções e processá-las adequadamente.

Confira também

• System.Xml.Xsl
• System.Xml.Schema
• System.Xml.Linq
• Documentos e dados XML