Estou tentando decodificar html contendo entidades html.
Eu tentei dbms_xmlgen.convert
e , utl_i18n.unescape_reference
mas os resultados são menos do que satisfatórios.
SET ESCAPE ON;
SELECT
'dbms_xmlgen.convert' AS method,
dbms_xmlgen.convert('\♥', 1) AS hearts,
dbms_xmlgen.convert('\&', 1) AS amp_ent,
dbms_xmlgen.convert('\&', 1) AS amp_dec,
dbms_xmlgen.convert('\&', 1) AS amp_hex,
dbms_xmlgen.convert('\激\光', 1) AS chinese_laser
FROM dual
UNION ALL
SELECT
'utl_i18n.unescape_reference',
utl_i18n.unescape_reference('\♥'),
utl_i18n.unescape_reference('\&'),
utl_i18n.unescape_reference('\&'),
utl_i18n.unescape_reference('\&'),
utl_i18n.unescape_reference('\激\光')
FROM dual;
Os resultados que obtenho são:
METHOD HEARTS AMP_ENT AMP_DEC AMP_HEX CHINESE_LASER
----------------------------------------------------------------------------------------------
dbms_xmlgen.convert ♥ & & & 激光
utl_i18n.unescape_reference ¿ & & & ¿¿
Meu problema real envolve caracteres chineses, processados por um programa Java para criar relatórios em PDF. Não tenho acesso fácil ao código Java, mas tenho controle sobre a consulta utilizada pelo programa.
Um exemplo de caracteres chineses que uso para teste é 激光, que o Google Tradutor me diz que significa 'laser' e que recebo codificado como 激光
. Estes não são decodificados corretamente, como pode ser visto no exemplo acima.
Percebo que na segunda linha, os pontos de interrogação invertidos parecem indicar que as entidades foram convertidas, mas não podem ser exibidas corretamente. Porém, é o próprio Oracle fazendo isso, ou o cliente (tentei tanto no SQL+ quanto no Toad)? Quando eu conecto utl_i18n.unescape_reference
a consulta usada pelo programa Java, ela funciona para entidades como ±
(±), mas, novamente, não para os caracteres chineses.
Como posso ter todas as entidades devidamente decodificadas?
- Devo usar outra função? (Estes foram recomendados em algum lugar na Internet ).
- Devo alterar algumas configurações? (Configurações relevantes mostradas abaixo).
Informação relevante
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
SQL*Plus: Release 10.1.0.5.0
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CHARACTERSET WE8MSWIN1252
NLS_NCHAR_CHARACTERSET AL16UTF16
Os caracteres chineses são decodificados corretamente com
utl_i18n.unescape_reference
. Na verdade, eles simplesmente não são exibidos corretamente no resultado da consulta, o que pode não oferecer suporte a esses caracteres especiais.Você pode confirmar isso com este SQL Fiddle .
É o cliente que é responsável por exibir os caracteres de forma adequada. Se o cliente não puder exibir um caractere, ele pode mostrar um ponto de interrogação de cabeça para baixo, outra coisa ou simplesmente lixo.
Então, agora, a verdadeira questão é onde você deseja exibir essa string...
Você mencionou que experimentou o SQL*Plus e o Toad; qual é o sistema operacional do seu cliente, Windows? Unix? Consulte NLS_OS_CHARSET Variável de ambiente que é uma variável de ambiente definida em seu cliente para um valor que seu cliente entenda e suporte. Se você estiver no Unix, invoque o
comando e veja para qual LANG ou LC_ALL está definido; você pode precisar definir
exportar NLS_OS_CHARSET=UTF-8
ou semelhante.
Você pode listar os locais disponíveis no Unix com