HMG - Unicode x ANSI

Mensagem por **Itamar M. Lins Jr.** » 15 Abr 2021 12:57

Olá!
Mesma coisa ADO que só funciona no Windows.
E por ai vai...
Tem os padrões abertos e outros que as empresas privadas adotam e expandem, entre aspas "", mas só vão obter tais benefícios se usarem os produtos delas.

Saudações,
Itamar M. Lins Jr.

Mensagem por **JoséQuintas** » 15 Abr 2021 13:04

UTF-8 é a representação do unicode.
Dá a impressão de que UTF-8 não existe no computador, é só uma forma humana de representar os caracteres unicode.

E realmente, unicode é de 20 anos atrás, e do jeito que demora, talvez quando finalmente virar padrão pode mudar de novo kkkkk

Se unicode não é UTF-8, se tudo mudar pra UTF-8, então nada do que existe hoje serve.

Pois é... o barato é doido.

Mensagem por **Itamar M. Lins Jr.** » 15 Abr 2021 13:15

Olá!
Não é assim como você está entendendo.
Primeiro surgiu UNICODE depois, muito tempo depois o UTF-8.
https://www.joelonsoftware.com/2003/10/ ... o-excuses/

Lê ai que vc vai entender.
UTF-8 usa 1 byte para pegar os primeiros 128 "sinais" e expande isso ao infinito praticamente.

Thus was invented the brilliant concept of UTF-8. UTF-8 was another system for storing your string of Unicode code points, those magic U+ numbers, in memory using 8 bit bytes. In UTF-8, every code point from 0-127 is stored in a single byte. Only code points 128 and above are stored using 2, 3, in fact, up to 6 bytes.

Saudações,
Itamar M. Lins Jr.

Mensagem por **Itamar M. Lins Jr.** » 15 Abr 2021 13:20

Olá!

e do jeito que demora, talvez quando finalmente virar padrão pode mudar de novo kkkkk

Não mudou nada, aperfeiçoou com UTF-8.
UTF é uma forma mais inteligente de usar UNICODE.

Saudações,
Itamar M. Lins Jr.

Mensagem por **JoséQuintas** » 15 Abr 2021 13:26

UTF-8, UTF-16, UTF-32

A diferença entre eles é a "forma de compactar" a informação.
No UTF-32 é tamanho fixo 4 bytes.
Como a maioria dos textos se encaixam nos primeiros códigos, que não precisariam de 4 bytes, o UTF-8 acaba economizando espaço.

Então não é à toa que o Windows e o Linux estão cada vez maiores em tamanho.
Todos os textos precisam de mais espaço pra armazenamento....
Obrigatoriamente eles vão apresentar textos em qualquer idioma, e obrigatoriamente ELES precisam de codificação especial.

Mesmo assim fica a dúvida:

Meu aplicativo é local, usado só no Brasil, diferente do sistema operacional que vai pra qualquer lugar do mundo.
Será que realmente meu aplicativo precisa se preocupar com isso? ou minhas bases de dados?
Preciso mesmo multiplicar o tamanho de todos os textos? pra que?

Basta o sistema operacional entender, e se enviar pra algum lugar, ele que se vire.

Mas ok, no caso de aplicativos internacionais, isso pode ser útil.
Na China, por exemplo, vendendo para o mundo todo.

Mensagem por **Itamar M. Lins Jr.** » 15 Abr 2021 13:36

Olá!

Meu aplicativo é local, usado só no Brasil, diferente do sistema operacional que vai pra qualquer lugar do mundo.
Será que realmente meu aplicativo precisa se preocupar com isso? ou minhas bases de dados?

Sim e não conforme vc mesmo diz. Depende ai do que para vc é mais rápido.
No caso eu sei que UTF-8 faz tudo, mas fico tendo que escolher ISOx, etc quando pego letras acentuadas nas minhas planilhas HTML, dai se eu uso UTF-8 não fico tendo que lembrar qual página de código está esse ou aquele texto.
Nos editores de código kate, VSCODE o padrão é UTF-8, essa é a razão pq estou dizendo que é melhor usar UTF8, pq os editores estão vindo com esse padrão.
Mesma coisa a Minigui, (ainda mais!) pq é uma IDE usada por muitas nações(idiomas), o normal será ela adotar UTF8.

Saudações,
Itamar M. Lins Jr.

Mensagem por **JoséQuintas** » 15 Abr 2021 13:48

Itamar M. Lins Jr. escreveu:mas fico tendo que escolher ISOx, etc quando pego letras acentuadas nas minhas planilhas HTML, dai se eu uso UTF-8 não fico tendo que lembrar qual página de código está esse ou aquele texto.

Se as planilhas são brasileiras, estaria resolvido se fossem todas em PT-BR.
Mas como inventaram UTF-8... bagunçou.
Dá a impressão de que o UTF-8 vai resolver problemas que ele mesmo criou.

Mensagem por **Itamar M. Lins Jr.** » 15 Abr 2021 14:06

Olá!

Mas como inventaram UTF-8... bagunçou.

Não existe isso de PT-BR. PT-BR não é página de código.

Código: Selecionar todos

<!DOCTYPE HTML>
<html lang=”pt-br”>
<head>
<meta charset=”UTF-8”>
<link rel=”stylesheet” type=”text/css” href=”estilo.css”>
<title></title>
</head>
<body>

UTF8 não bagunçou nada.
No HTML usava ISO85xx não lembro, mas o editor era ANSI X etc...
Se usa UTF8 em tudo não precisa ficar lembrando se no notepad ta assim, no html tá assado, no DBF tá de outra forma.
Usando UNICODE via UTF8 é uma padronização.

Saudações,
Itamar M. Lins Jr.

Mario Mesquita · Mensagem por **Mario Mesquita** » 15 Abr 2021 16:20

Olá, pessoal.

Bom, vendo assim, só se fizer o sistema pelo Unicode, consertar todas as telas que ficaram com caracteres estranhos, deixar o codepage como "UTF8EX", mas aí
teria que fazer uma migração das tabelas de dados que estão em ANSI, convertendo pra UTF-8 e gravar nas novas tabelas nesse formato. Aí fecha.

Porquê rodar em Unicode mas com codepage diferente aparentemente não funciona bem. Só para eventuais conversões de dados já cadastrados em ANSI.
É o que tenho feito quando uso programa em Unicode lendo tabelas em ANSI.

E no caso de migrar pra SQL, definir o "collate" como UTF-8.

Contei rápido aqui, 138 forms de tela. Aí é analisar custo x benefício. Não sei o que pensar...

Sds,
Mario.

Mensagem por **JoséQuintas** » 15 Abr 2021 16:42

Mario Mesquita escreveu:Olá, pessoal.
Bom, vendo assim, só se fizer o sistema pelo Unicode, consertar todas as telas que ficaram com caracteres estranhos, deixar o codepage como "UTF8EX", mas aí
teria que fazer uma migração das tabelas de dados que estão em ANSI, convertendo pra UTF-8 e gravar nas novas tabelas nesse formato. Aí fecha.
Porquê rodar em Unicode mas com codepage diferente aparentemente não funciona bem. Só para eventuais conversões de dados já cadastrados em ANSI.
É o que tenho feito quando uso programa em Unicode lendo tabelas em ANSI.
E no caso de migrar pra SQL, definir o "collate" como UTF-8.
Contei rápido aqui, 138 forms de tela. Aí é analisar custo x benefício. Não sei o que pensar...

Vai ter que testar.
Como eu disse, o default do Harbour já é usar unicode, independente da codepage.
Tela não deveria ser problema.

E quanto ao editor de texto?
Isso também faz muita diferença.
Não adianta trocar codepage no programa, se não trocar codepage no editor de fontes.
E nem sempre a conversão do fonte é automática.

Se usar Ansi no Harbour, mas UTF-8 no fonte, não vai mostrar certo.
O mesmo se usar UTF-8 no Harbour, mas não no fonte.

Mensagem por **Itamar M. Lins Jr.** » 15 Abr 2021 17:21

Olá!

Contei rápido aqui, 138 forms de tela. Aí é analisar custo x benefício. Não sei o que pensar...

Coloca um tela, para dar uma ideia.
Não estou entendendo.

Saudações,
Itamar M. Lins Jr.

Mensagem por **JoséQuintas** » 15 Abr 2021 19:07

Teste simples.

Editor em Ansi.
HMG deve ser em Ansi também.

Mensagem por **JoséQuintas** » 15 Abr 2021 20:08

Crie um teste aonde a tela fica ruim, pra testar aqui.

Mario Mesquita · Mensagem por **Mario Mesquita** » 16 Abr 2021 08:13

Bom dia a todos.

Quintas, é isso mesmo: Ou tudo em ANSI ou tudo em UTF-8. Forms, programas-fonte e banco de dados. O que percebi é que combinar os dois não funciona 100%,
alguma coisa terá que ser convertida ou ter que se ficar alternando codepages ao longo do sistema. Eu montei duas versões do programa para testes, uma para o
Unicode e outra para o ANSI. No meu caso, o ANSI é mais simples, natural, direto, devido o programa ter sido feito no HMG 3.0.46 quando nem se aplicava essa visão.

Deduzo que ele era ANSI nativo, nunca precisei me incomodar com isso. A versão 3.5 ANSI com codepage "PTISO" tá 100%, fontes, forms e BD.

Para o Unicode, já converti os fontes pra UTF-8. Já funcionou essa parte, os textos acentuados dos relatórios ficaram ok. Agora tenho que fazer uma rotina de migração das tabelas aplicando uma função "Ansi to UTF-8" para ficar em conformidade.

Itamar, até por isso os forms estão prejudicados em todas as letras acentuadas. Porquê tudo foi feito na versão 3.0.46 do HMG, logo deve estar tudo ANSI.
Se eu botar o codepage "PTISO" nele, as telas ficam perfeitas, mas prejudica os textos dos fontes e a base de dados.

A solução é editar todas as telas e ajustar isso manualmente, a não ser que se possa fazer direto nos arquivos .FRM, mas como não tem como fazer uma troca
em massa, melhor ir ajustando na mão, já vi que dá também diferença em botões, tudo ficou meio bagunçado com a IDE Unicode.

Me confirmem, por favor, se quando eu preparar a BD MySql tenho mesmo que botar o "collate" UTF-8 explicitamente, pois o default é o "latin1...".

Saudações,
Mario.

Mensagem por **Itamar M. Lins Jr.** » 16 Abr 2021 08:47

Olá!

Itamar, até por isso os forms estão prejudicados em todas as letras acentuadas. Porquê tudo foi feito na versão 3.0.46 do HMG, logo deve estar tudo ANSI.
Se eu botar o codepage "PTISO" nele, as telas ficam perfeitas, mas prejudica os textos dos fontes e a base de dados.

É o preço que se paga. Pq para UTF8 podemos usar as funções normalmente. Mas quando a pagina não é UTF8 e a tela ou o texto foram feitos com UTF8 ai precisa das funções para ler converter pára UTF8.

Código: Selecionar todos

   hb_cdpIsUTF8()
   hb_StrIsUTF8()
   hb_StrToUTF8()
   hb_utf8Asc()
   hb_utf8At()
   hb_utf8Chr()
   hb_utf8Left()
   hb_utf8Len()
   hb_utf8Peek()
   hb_utf8Poke()
   hb_utf8RAt()
   hb_utf8Right()
   hb_utf8StrTran()
   hb_utf8Stuff()
   hb_utf8SubStr()
   hb_UTF8ToStr()
   hb_UTF8ToStrBox()
   HB_CODEPAGE_UTF8()
   HB_CODEPAGE_UTF8EX()

Quando está tudo em UTF8; len(), substr(), at(), todas funcionam normalmente.
Mesma coisa o contrario, tela em ANSI x, no caso PTISO que é ISO85x ai precisa converter para UTF8, isso para base de dados também.
E se usar acentos UTF8EX.
Se for jogar, usar nome de pessoas, descrição de produtos, etc e não for UTF8 do seu BD para paginas HTML ou Mobile etc... Precisa converter para UTF8, ou for editar nesses editores modernos precisa escolher a pagina, ISO85x(Latin etc...) usando UTF8[Ex] basta para tudo e não precisa ficar lembrando, se tava ISO85,(português, espanhol,) ou mais antigo 437 que é USA sem acento e por ai vai, UTF8 unifica tudo isso.
Não confundir com as mensagens do Harbour em português ou do Linux, "PT-BR", isso não é o CHARSET ou codepage, é apenas para informar que a linguagem de erros/avisos interna do Harbour será em português

Código: Selecionar todos

REQUEST HB_LANG_PT //Aqui as mensagens do harbour em português
REQUEST HB_CODEPAGE_PTISO //Aqui a pagina de código -> afeta tudo, tela e base de dados. a tal ISO85x(latin, unicode etc, no windows)

PROCEDURE MAIN ()
  HB_SETCODEPAGE('PTISO')
  HB_LANGSELECT('PT')
  string="àèéìùç"  
 ? "test"+string
 a=inkey(0)
 return

Saudações,
Itamar M. Lins Jr.