Literais de String Mvsql¶

O padrão SQL define dois tipos de sequência de caracteres, cada um com sua própria sintaxe literal.

• ANSI
• Nacional

As cadeias de caracteres ANSI representam conjuntos de caracteres ASCII e outros conjuntos de caracteres de byte único, como EBCDIC no DB2/i.

Cadeias de caracteres nacionais representam conjuntos de caracteres multibyte, como Unicode.

O padrão SQL define uma sintaxe literal separada para cada tipo de string de caractere. A sintaxe para uma literal de string ANSI é:

'Aristotle''s quotes'

Observe que aspas simples incorporadas dentro do literal de string são escapadas dobrando as aspas simples.

A sintaxe para um literal de string nacional é:

N'Aristotle''s quotes'

mvSQL suporta a sintaxe SQL Standard para literais de string de caracteres ANSI e National.

Suporte ao Fornecedor¶

A menos que documentado de outra forma, os literais de string de caracteres ANSI e National são mapeados diretamente para o equivalente do fornecedor nativo.

MySQL¶

O MySQL não define uma sintaxe separada para literais de string de caracteres ANSI e National. No MySQL, o literal de string é assumido como codificado usando o conjunto de caracteres da conexão. Isso significa que a codificação pode variar com base nas configurações de conexão. Se a conexão usar uma codificação ANSI (como a codificação latin1 padrão), todas as strings serão assumidas como ANSI.

O MySQL suporta introdutores de conjunto de caracteres. O "introdutor" é um prefixo adicionado ao início do valor literal da string. O prefixo indica o conjunto de caracteres da string. App Builder usa introdutores de conjunto de caracteres para garantir que dados Unicode possam ser codificados em literais de string, independentemente das configurações de conexão. Por outro lado, se a conexão usar o conjunto de caracteres UTF-8, o introdutor de conjunto de caracteres garante que dados ASCII sejam passados para o servidor como ASCII, evitando conversões problemáticas.

Na prática, isso significa que um literal de string de caracteres ANSI mvSQL será traduzido para:

_latin1'Aristotle''s quotes'

Um literal de string de caracteres mvSQL National será traduzido para a sintaxe do MySQL como:

_utf8'Aristotle''s quotes'

O MySQL não define tipos de dados de armazenamento separados para tipos de caracteres ANSI e National. Em vez disso, todos os tipos de string são armazenados em um tipo de dados comum. O conjunto de caracteres determina como os dados são armazenados. App Builder mapeia colunas de caracteres MySQL com um conjunto de caracteres Unicode (utf8) para o tipo de string de caracteres National correspondente e neutro em relação ao fornecedor (por exemplo, NCHAR ou NVARCHAR).

DB2/i¶

Assim como o MySQL, o DB2/i não tem tipos de dados separados para strings de caracteres ANSI e National. Em vez disso, o CCSID determina a codificação. O CCSID é um inteiro não assinado de 16 bits. É similar em natureza ao LCID do Windows.

Assim como no MySQL, App Builder inspeciona o CCSID para mapear corretamente de um tipo de caractere DB2/i (por exemplo, VARCHAR) para an App Builder, tipo de dados neutro de fornecedor (por exemplo, NVARCHAR). Os seguintes CCSIDs serão mapeados para o tipo de dados NVARCHAR:

• 1200 - UTF-16
• 1208 - UTF-8
• 13488 - UCS-2

Por outro lado, ao criar colunas com um tipo de dados de caractere nacional, App Builder define explicitamente o CCSID. Especificamente, App Builder define o CCSID como 1208 (UTF-8).

Por fim, o DB2/i não precisa ter uma sintaxe separada para strings de caracteres ANSI e National. Portanto, a mesma sintaxe é usada para ambas.

Fontes de Dados Não RDBMS¶

Literais de string nacionais mvSQL não são suportados para fontes de dados não RDBMS, como REST e Salesforce, etc.

Leitura Adicional¶

https://learn.microsoft.com/en-us/sql/relational-databases/collations/collation-and-unicode-support https://docs.microsoft.com/en-us/sql/t-sql/data-types/constants-transact-sql https://dev.mysql.com/doc/refman/8.0/en/charset-introducer.html