PC Toledo

Tenho algumas aplicações antigas de 1995 quando trabalhava com clipper converti para o harbour depois de fazer uma faxina tirando rotinas removendo algumas libs que não rodam em harbour tive sucesso meus aplicativos estão em harbour melhor hmg.3.1.5 com mingw com interface console ou terminal não sei como se diz tela texto no meio de tão excelentes programadores, recentemente resolvi melhorar colocando acentuação só estava usando:

Request HB_CODEPAGE_PTISO
Request HB_CODEPAGE_PT850
HB_CDPSELECT("PTISO")

Não estava dando certo parei de tentar implementar a acentuação mas lendo recentemente um livro postado aqui no fórum INTRODUÇÃO A PROGRAMAÇÃO USANDO A LINGUAGEM HARBOUR VLADEMIRO LANDIM JUNIOR, fica aqui já meus parabéns pela iniciativa muito bom.
Resolvi retomar a acentuação de minhas aplicações com UTF8EX que foi recomendado pelo livro por ser uma tabela de caracteres mais usado no mundo e mais completa.

REQUEST HB_CODEPAGE_UTF8EX // Disponibiliza o suporte a UTF8
hb_cdpSelect("UTF8EX") // Seleciona o suporte a UTF8

Como os editores de texto trabalham basicamente com ansi os caracteres de box ou moldura não aparecem nos editores mas se não convertermos o padrão ansi no notepad++ as telas de moldura não aparecem corretamente no editor mas o aplicativo depois de compilado aparece corretamente. Usava o recurso alt e o número conforme tabela abaixo:

Página de caracteres sem seleção de tabela (ASCII)

Caracteres de Caixa (Box Characters)
https://www.itlnet.net/programming/prog ... 2e087.html

Usando o padrão utf8ex esses caracteres são substituídos por outros, as tela ficando com outro caracteres, então resolvi fazer um pequeno programa para exibir a tabela utf8ex para ver aonde foram parar os caracteres ascii das tabela acima, já ouvi falar que a utf8ex tem milhares de caracteres de todas língua mundiais. Veja um programa com 10000 caracteres utf8ex:

Percebi que dá para montar minhas antigas telas mesmo usando o utf8ex usando por exemplo:


Mas dessa forma não funcionou, sai outros caracteres só deu certo assim:

Alguém sabe porque o CHR não funcionou da forma anterior? Estava pensando em montar uma tabela tipo a ASCII.

Olá, anexei dois arquivos exemplos.

O primeiro mostra :

(1) que uma string acentuada (ou com qualquer caractere extendido) pode impactar no resultado de funções que foram herdadas do Clipper. Acho que por questões de compatibilidade. Um caractere extendido ocupa dois Bytes em vez de apenas um. "Á" em UTF-8 tem tamanho 2. Isso com certeza pode gerar a resultados indesejáveis com funções que dependem do tamanho de uma string.
(2) as molduras saem corretamente usando as funções de moldura do Harbour (as mesmas do clipper)

O segundo mostra um modelo de tela em modo texto.
Na minha opinião UTF-8 vale a pena quando o seu sistema vai ser desenvolvido "do zero", e você já quer garantir a compatibilidade direta com banco de dados SQL, webserver e outras aplicações.

Se o seu sistema já está funcionando, talvez não compense ter essa trabalheira e você pode recorrer a funções que realizam a conversão na hora da gravação de dados no banco ou no envio de arquivo para um webserver. Principalmente se for um sistema complexo. Um exemplo de função de conversão é a hb_UTF8ToStr( cStr ) e a hb_StrToUTF8( cStr ).

Algumas certezas eu tenho :

(1) Mesmo que você tenha seu sistema todo bonitinho com UTF-8 (o que é o ideal), sempre vai ter uma ocasião em que você vai ter que se comunicar com sistemas legados e aí entra as funções de conversão. Não tem como fugir disso.

(2) Muitas pessoas não adotaram UTF-8 e estão aí ganhando muito dinheiro. Na hora de "conversar" converte usando as funções de conversão.

(3) O Harbour poderia melhorar o suporte. Acho que o desenvolvimento da linguagem parou nesse aspecto e poderia evoluir nesses ultimos cinco anos desde que o ebook foi escrito.

(4) É difícil evoluir sempre mantendo a compatibilidade com padrões antigos. Esse é uma discussão antiga na comunidade harbour.

Um mundo ideal :

(1) Uma base de dados sem caracteres acentuados

(2) Um padrão único.

Uma primeira coisa é entender tudo isso direito, mas eu também não sei... kkkkk
É importante dizer que até o Windows se perde nisso.

O que fiz foi adotar o ANSI do Windows como padrão, PTBR.
E continuei não usando acentuação nas tabelas.
O Clipper também tinha essa opção de codepage, mas acho que poucos usavam.

Principal 1: Base de dados

Se usa DBF, não invente de usar UTF8
DBF tem tamanho fixo, mas UTF8 não.
E atenção também a Substr(), At(), e outras funções pra caractere, pelo mesmo motivo
Com base nisso, parece que o melhor é continuar usando ANSI, até que se entenda melhor o UTF8.
O que já está cadastrado: bom... vai continuar na codepage antiga. Ou continua com a mesma, ou adota uma nova e esquece o que existia antes.

Principal 2:

Vai usar uma codepage nas telas do Harbour: então use um editor de programas com a mesma codepage
Não adianta querer digitar de um jeito no editor, e querer que saia de outro no Harbour.

Outros:

Quanto aos caracteres de boxes:
Deixe por conta do Harbour
Ao invés de usar @ 5, 5 SAY Replicate( Chr(196), 80 ), use @ 5, 5 TO 5, 85
Lembre-se que conforme a codepage, Chr(196) vai trazer um caractere diferente.

Acho que basicamente é isso: pensar no CONJUNTO, e não apenas numa parte ou na outra.
Se ficar misturando codepage, aí ferrou, porque a solução de uma codepage vai ser diferente da solução de outra.
Se mudar no meio do caminho, o que funcionava antes pode deixar de funcionar.
É TUDO OU NADA.
Ou parte pra UTF8, editor de textos UTF8, codepage UTF8, e enfrenta tudo que é conversão..... ou parte pra ANSI e alguma codepage específica.

Como eu já disse, ainda não entendi o uso desse UTF8, preferi o ANSI PT-BR, que é o padrão do Windows, e pode ser o padrão de console, seja Windows ou Linux.

Por enquanto a única certeza que eu tenho é que colocar codepage diferente no editor de textos só atrapalha.

E se usar LIB gráfica.... tem LIB gráfica que tem solução própria pra codepage, o que também pode atrapalhar, porque vai ter que obedecer a LIB e não o Harbour.

Ola!
Pode usar UTF8 com DBF a vonte.
Quando for desenha a tela só mudar a pagina de código.
Tem aqui no forum exemplos.
No caso do UTF8 basta usar as funções para UTF8
C:\sgc\fonts\HARBOUR>hbmk2 -find utf8
Núcleo Harbour (instalado):
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()

Saudações,
Itamar M. Lins Jr.

Ola!
Lembrando que quando está em UTF8, len(),right()... etc funciona normalmente.
Essas outras é para converter! Se a pagina está em PTISO, usamos para exportar uma string para UTF8.


Saudações,
Itamar M. Lins Jr.

Senhores obrigado pelas respostas conforme o prós e os contras, vocês que tem uma visão mais avançado dos problemas que vamos ter por decisões errôneas me digam o seguinte, minhas aplicações vou deixá-las do que jeito que estão se optar para o seguinte:

No editor de texto notepad++ estavam em ANSI vou trocar para OEM 850;
Nos módulos do programa vou usar :
REQUEST HB_CODEPAGE_PT850 // Disponibiliza o suporte a PT850
hb_cdpSelect("PT850") // Seleciona o suporte a PT850

Estava analisando o prompt ou console do Windows 10 está usando 850 (OEM - Latino Multilingue I).

Acho que se fizer assim mesmo os caracteres acentuados terão um 1 byte?

Ola!
Quando usa qualquer code page, o caractere volta 1 quando acentuado, melhor usar UTF8 para tudo.
Eu uso assim: Mas usando o harbour como CGI eu uso tudo UTF8.
No desktop só pq já tava (antigo) e eu não quero ficar convertendo DBF velho para UTF8.
No caso "ção" com "UTF8" são 3 caracteres, com "PTISO" idem, com "EN" 5 pq no "INGRÊS" não tem acento.
Detalhe UTF8 tem vários desenhos legais(smiles) para colocar na aplicação. Use o hbrun que não precisa nem compilar.

Saudações,
Itamar M. Lins Jr.

Olá!

Uso Windows-1252, tanto no editor de texto (VSCode) quanto no banco de dados (Postgres).
Não uso tela caracter e não testei desenho de tela.
No sistema:
REQUEST HB_CODEPAGE_PTISO
REQUEST HB_LANG_PT

HB_SETCODEPAGE( "PTISO" )
HB_LANGSELECT( "PT" )

No Notepad++, para selecionar Windows-1252, siga esta sequência no menu: Formatar > Conjunto de Caracteres > Europa Ocidental > Windows-1252