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, nível de fluxo e DOM

• Esquemas XML

• Expressões XPath

• Transformações XSLT

• Núcleo de Nível 1 do DOM

• Núcleo do DOM Nível 2

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

Namespaces relacionados

O .NET também fornece outros namespaces para operações relacionadas a XML. Para obter uma lista, descrições e links, consulte System.Xml Namespaces.

Processando XML de forma assíncrona

As System.Xml.XmlReader classes e System.Xml.XmlWriter incluem vários métodos assíncronos baseados 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 código assíncrono semelhante ao seu código síncrono e migrar facilmente seu código síncrono existente para código assíncrono.

• 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 o fluxo de memória ou operações de leitura/gravação do fluxo de arquivos local. O fluxo de entrada, XmlTextReadere XmlTextWriter também devem dar 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 o 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 como true se você não pretende usar um método assíncrono.

• Se você esquecer de especificar o 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 satisfaz a "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 a substituição, a referência ao elemento e1 a sequência pode resultar no elemento e1 de tipo t1 ou elemento e2 de 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:

Sob as 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 referencia 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 que 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 que 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 que um elemento de grupo de substituição.

Por exemplo, no esquema abaixo do modelo de conteúdo é ambíguo e deve causar um erro de compilação, mas System.Xml criar 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 o elemento filho 'e2' inválido" e uma exceção XmlSchemaValidationException será gerada.

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

Para solucionar 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>

se torna isso:

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

Aqui está 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 sobre segurança

Os tipos e membros no System.Xml namespace dependem do sistema de segurança .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 contém dados que têm possíveis implicações de privacidade, você precisa implementar seu aplicativo de uma maneira que respeite a privacidade dos usuários finais.

Acesso externo

Várias tecnologias XML tem a capacidade de recuperar outros documentos durante o processamento. Por exemplo, um Document type definition (DTD) pode residir no documento que está sendo analisada. O DTD também pode viver em um documento externa que é referenciado pelo documento que está sendo analisada. O idioma da definição de esquema XML (XSD) e tecnologias XSLT também têm a capacidade para incluir informações de outros arquivos. Esses recursos externos podem apresentar algumas preocupações de segurança. Por exemplo, você deseja garantir que seu aplicativo recupere arquivos somente de sites confiáveis e que o arquivo recuperado não contenha dados mal-intencionados.

A XmlUrlResolver classe é usada para carregar documentos XML e para resolve 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 classe de XmlSecureResolver se você precisa abrir um recurso que você não controle, ou que é não confiável. XmlSecureResolver envolve XmlResolver e permite que você restringir os recursos a que XmlResolver subjacente tem acesso.

Negação de serviço

Os seguintes cenários são considerados menos vulneráveis a ataques de negação de serviço como as classes de System.Xml fornecem um meio da proteção de como ataques.

• Dados XML de texto de análise.

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

• Escrevendo documentos XML e fragmentos de fontes de dados para o sistema de arquivos, para fluxos, a TextWriter, ou a StringBuilder.

• Documentos de carregamento em Document Object Model (DOM) objeto se você estiver usando um objeto e XmlReader de XmlReaderSettings.DtdProcessing definidos como DtdProcessing.Prohibit.

• Navegando no objeto DOM.

Os seguintes cenários não são recomendados se você estiver preocupado sobre ataques de negação de serviço, ou se você estiver trabalhando em um ambiente não confiável.

• Processamento de DTD.

• Processamento de esquema. Isso inclui adicionar um esquema não confiável a coleção do esquema, criar um esquema não confiável, e validar-lo usando um esquema não confiável.

• Processamento de XSLT.

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

• Operações DOM como subpropriedades árvores consulte, editar, em movimento entre documentos, e salvar 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 o XmlReader pode acessar. 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 sobre processamento

Porque os documentos XML podem incluir referências a outros arquivos, é difícil determinar quanto poder de processamento é necessária para analisar um documento XML. Por exemplo, documentos XML podem incluir um DTD. Se o DTD contém entidades aninhadas ou modelos de conteúdo complexos, poderia levar uma quantidade excessiva de tempo para analisar o documento.

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

As tecnologias XSD e XSLT têm recursos adicionais que podem afetar o desempenho de processamento. Por exemplo, é possível criar um esquema XML que requer um montante considerável de tempo de processamento quando avaliada sobre um documento relativamente pequeno. Também é possível inserir blocos de script em uma folha de estilos XSLT. Ambos os casos representam uma possível ameaça à segurança 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 é desativado por padrão. O script XSLT deverá ser habilitado somente se você precisar de suporte a script e estiver trabalhando em um ambiente totalmente confiável.

• A função XSLT document() é desativada por padrão. Se você ativar a função de document() , restringir os recursos que podem ser acessados passando um objeto de XmlSecureResolver para o método de XslCompiledTransform.Transform .

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

• As folhas de estilos XSLT podem incluir referências a outros arquivos e blocos de script inseridos. Um usuário mal-intencionado pode explorar isto fornecendo o com dados ou folhas de estilos que, quando executados, podem fazer com que seu sistema processa até o computador executam baixo em recursos.

• Aplicativos XSLT executados em um ambiente de confiança mista 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 fora a outro usuário que subseqüentemente chama o método de XslCompiledTransform.Transform e executa a transformação.

Essas questões de segurança podem ser abrandadas não ativando scripts ou função de document() a menos que a folha de estilos vem de uma fonte não confiável, e retornando objetos de XslCompiledTransform , dados de folhas de estilos XSLT, ou de código-fonte XML de uma fonte não confiável.

Tratamento de exceções

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