Como os caracteres em senhas criptografadas podem ir do byte 00 até o byte FF (incluindo a aspa dupla ", byte 0x22, e a aspa simples ou plica ', byte 0x27) não há encoding que dê jeito. Sempre você vai ter algum problema.
O correto é codificar essa criptografia usando hexadecimal ou base-64.
Nunca deixe os bytes “expostos” assim em arquivos texto que você vai ter muitos problemas. Quando falo muitos, são muitos mesmo.
Thingol, então eu devo aplicar outra conversão sobre esta criptografia antes de inseri-lá no XML ??
Oque vc quis dizer sobre bytes expostos e seus problemas ??
Bom, como você disse que a senha é criptografada, o algoritmo que você usa (não importa qual) deve gerar uma seqüência de bytes aparentemente aleatória e cada byte (de 00 a FF) tem probabilidade igual de ocorrer.
O problema é que caracteres como aspa “”" ou apóstrofo “’” podem aparecer também - eles têm o mesmo direito à existência que o caracter “a” ou “ç”.
Então você teria um XML mal-formado de qualquer maneira - não importando o encoding que você usasse.
Mesmo você usando algo que substituísse “”" por " ou “’” por ’ não resolveria o seu problema.
Portanto é melhor evitar o seu problema codificando todos os bytes em hexadecimal. Por exemplo, “A” ficaria “41” e “ç” ficaria “E7”. É um pouco desajeitado porque você precisa ter uma rotina para converter e outra para desconverter, mas não é difícil escrever uma rotina dessas. Só tomar um pouco de cuidado com os bytes de 00 a 0F - não esquecer de pôr o zero à esquerda, senão você não saberia se você tem um caracter só (A = 41 ) ou dois (o byte 4 e o byte 1).
Um CDATA também não resolve - como a senha é aleatória, pode aparecer a seqüência de bytes “]]>” que termina um CDATA.
(A probabilidade é de 1/256 * 1/256 * 1/256, ou seja, 0,0000059604644775390625 %, mas não é zero.)