Oi Chiappa. Mais uma vez, obrigado por sua resposta.

Os Charset que estou usando, conforme meu ultimo e-mail:

NLS_CHARACTERSET               WE8ISO8859P1
NLS_NCHAR_CHARACTERSET         AL16UTF16


Depois de algum trabalho ontem eu percebi que o problema está na hora de
copiar o arquivo txt que irá alimentar minha tabela externa do windows para
o linux.

O desenvolvedor estava enviando pelos utilitários scp e psftp, no entanto,
em ambos os casos, ao ser copiado para o linux, o arquivo foi quebrado
(Caracteres se perderam).

Logando via ssh no servidor linux, e criando um arquivo com o utilitário
VI, colando o texto do arquivo, funcionou perfeitamente.


Eu realmente não tenho muita experiência em trabalhar com caracteres
diferentes do que usamos habitualmente, portanto, estou um pouco perdido.


as Var de ambiente do meu Linux são:

oragwp01@lxdwprddb01>env | grep NLS
NLS_SORT=BINARY
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
NLS_DATE_LANGUAGE=AMERICAN
NLS_NUMERIC_CHARACTER=.,
ORA_NLS33=/oracle/GWP01/home/server/10.2.0/ocommon/nls/admin/data
NLS_DATE_FORMAT=DD-MON-RR


Seria necessário setar essas mesmas variáveis no ambiente windows do qual
estou acessando via sftp para transferencia do arquivo?



*O que não funcionou:*

Enviar o arquivo via PSFTP ou SCP.
  *Ao dar um cat os caracteres se perdem. Ao ler o arquivo com VI é
possível ver os caracteres em chines normalmente.


*O que funcionou:*

Criar um novo arquivo diretamente no servidor linux através de ssh, usando
o VI e colando o texto do arquivo lá.
  *Tanto ao dar cat quanto ao ler o arquivo com VI os caracteres chineses
funcionam.
  *A tabela externa carregou o conteúdo do arquivo perfeitamente, exibindo
os caracteres em chinês ao fazermos select nela.




Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 23 de setembro de 2014 18:19, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
>   Sorry, mas não é só uma questão de "variáveis" : além disso, outro ponto
> aí é que o database possui um conjunto de caracteres próprio instalado, que
> é usado para a exibição : Óbvio ululante que se o conjunto de caracters
> (characterset) em uso não conter todos os caracteres chineses que vc
> precisa, vc VAI ter perda/conversão de caracter aí, né não ???
>    Os dois conjuntos de caracter que o database Oracle pode ter são o
> principal (o NLS_CHARACTERSET, que é usado para as string VARCHAR e CHAR) e
> o conjunto NCHAR (o NLS_NCHAR_CHARACTERSET), que é usado para as strings de
> datatype NCHAR : como estão esses dois no seu database ?? Vc os vê
> consultando a nls_database_parameters ... A questão aqui é que, como
> Sabemos, os alfabetos asiáticos possuem mais de 255 caracteres possíveis,
> então só um byte não dá pra representar tudo, vc TEM que estar usando um
> conjunto de caracteres que use mais de um byte para representar cada
> caracter, normalmente adota-se o UNICODE, cfrme
> https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10250420313043
> mostra - outros são possíveis (cfrme
> http://en.wikipedia.org/wiki/Chinese_character_encoding), mas a tendência
> é mesmo UNICODE.. Um dos dois charactersets TEM que ser multibyte, seja o
> default (se vc usar char/varchar) seja o nchar, se vc usar colunas NCHAR....
>     Isso ok, aí é setar o Sistema Operacional, instalando as fontes de
> exibição necessárias e fazendo os ajustes de linguagem necessários, ajustar
> o teu software de terminal se tem algum em uso (a maioria deles, como o
> putty, possui opção de conjunto de caracteres a utilizar), e só DEPOIS
> disso setar as variáveis NLS : imagino que a mais importante vai ser a de
> characterset apontando para a versão de UNICODE que vc esteja usando...
>
>  []s
>
>    Chiappa
>  
>
  • [oracle_br] Ajuda... Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
    • [oracle_br] ... jlchia...@yahoo.com.br [oracle_br]
      • Re: [ora... Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
        • Re: ... ederson200...@yahoo.com.br [oracle_br]
          • ... Evandro Giachetto evandrogiache...@gmail.com [oracle_br]

Responder a