Início / dba / Perguntas / 266763
Accepted
Lennart - Slava Ukraini
Asked: 2020-05-09 04:59:53 +0800 CST

clp acrescenta bytes à saída

  • 772

Estou migrando vários bancos de dados para UTF-8 e acabei de descobrir fenômenos que não conhecia. Ao selecionar dados para o terminal, bytes adicionais são adicionados à saída. Exemplo:

~]$ x=$(db2 -x "values 'a'")
~]$ echo "${x}b"
a b

Um espaço adicional após um

~]$ x=$(db2 -x "values 'aa'")
echo "${x}b"
aa  b

Dois espaços adicionais após aa

Não parece importar quantos bytes um caractere ocupa em utf8:

~]$ x=$(db2 -x "values '?'")
~]$ echo "${x}b"
? b

Um espaço adicional após g-clave

~]$ x=$(db2 -x "values '??'")
~]$ echo "${x}b"
??  b

Dois espaços adicionais após a clave de sol

db cfg:

Database territory                                      = SE
Database code page                                      = 1208
Database code set                                       = UTF8
Database country/region code                            = 46
Database collating sequence                             = SYSTEM_819_SE

O terminal tem codificação UTF8 (tentei terminador e gnome-terminal), e antes de conectar ao banco de dados eu fiz:

export LC_CTYPE=sv_SE.utf8

O acima é, obviamente, apenas exemplos bobos, mas eu tenho uma boa quantidade de testes em scripts semelhantes a esse:

dbtype=`db2 -x "values nya.get_db_type()"`
if [ "${dbtype}" = "N" ]; then
    ...

onde eu preciso mudar o teste de uma forma ou de outra.

Alguma ideia sobre uma configuração que eliminaria os bytes extras?

~]$ uname -a
Linux nya-ladok3-release 3.10.0-1062.9.1.el7.x86_64 #1 SMP Mon Dec 2 08:31:54 EST 2019 x86_64 x86_64 x86_64 GNU/Linux
~]$ db2level
DB21085I  This instance or install (instance name, where applicable: 
"db2inst1") uses "64" bits and DB2 code release "SQL11050" with level 
identifier "0601010F".
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", 
and Fix Pack "0".
Product is installed at "/opt/ibm/db2/V11.5".
db2 db2-luw

1 respostas

  1. Best Answer

    Esta é a explicação que recebi do suporte da IBM, não testei eu mesmo, mas parece razoável. A solução alternativa sugerida funcionará para todas as situações em que posso pensar agora:

    Os espaços extras preenchidos no CLP são o comportamento esperado. Isso ocorre porque existem alguns caracteres de vários bytes que ocupam mais de 1 espaço físico. Veja abaixo exemplo que demonstra o mesmo:

    Diga, U+FF2D LETRAS MAIÚSCULAS EM LATIM M

    $ db2 "select a, hex(a) from table(values('A' || u&'\FF2D' || 'B'),('A B')) t(a)"
A   2     
----- ----------
AＭB 41EFBCAD42 —> Here wide-M is taking more space than a normal multi/single byte character. 
A B  41204220202 record(s) selected.

    Se você estiver usando muitas funções como get_db_type() em seus scripts, poderá alterar o valor de retorno dessas funções para modificá-lo para OCTETS:

    Algo como o seguinte:

    CREATE OR REPLACE FUNCTION get_db_type()
RETURNS VARCHAR(1 OCTETS)
DETERMINISTIC NO EXTERNAL ACTION CONTAINS SQL
BEGIN ATOMIC
    RETURN 'N';

END @

    Vou deixar a solução atual como está abaixo:

    Se nada mais aparecer, provavelmente farei algo como:

    x=$(db2 -x "values ('??')")
x="${x%"${x##*[![:space:]]}"}"
echo ${x}b
??b

    A princípio, imaginei:

    x=$(db2 -x "values ('??')" | xargs echo)

    faria, mas o pipe introduz um subshell, então:

    echo ${x}b
SQL1024N A database connection does not exist. SQLSTATE=08003b

    não funciona.

    • 0

relate perguntas