FiveTech Support Forums

Carles wrote:

Puedes poner un pantallazo de la definicion de routes?

C.

A ver...
No consigo subirla (nunca lo he hecho) aquí el link de la imagen: https://ibb.co/tpQsYBJC

Evidentemente he cerrado Hix para poder ver routes, y lo he puesto sobre el navegador para que se viera como estoy llamando a 'inicio'.

He probadfo con http://localhost/wweebb/public/escarolita/index.html y funciona.

Hola,

Tienes definido una ruta que se usara con el metodo POST. Si quieres usarla desde la barra del navegador has de usar un método GET

C.

Carles wrote:

Hola,
Tienes definido una ruta que se usara con el metodo POST. Si quieres usarla desde la barra del navegador has de usar un método GET
C.

Gràcies Carles lo probaré.

¿Cómo guardarías los datos en DBF? ANSI o UTF8. Para verlos en Web mejor UTF8 y no precisas convertir, no?
He perdido toda la tarde para esto y de momento lo aparco.

FiveWiDi wrote:

...
He perdido toda la tarde para esto y de momento lo aparco.

https://github.com/carles9000/hix/wiki/HIX

We can also specify which "verb" this route can use: GET, POST, PUT, DELETE, which allows us to better protect access to our app.

Carles wrote:

...
He perdido toda la tarde para esto y de momento lo aparco.

https://github.com/carles9000/hix/wiki/HIX

We can also specify which "verb" this route can use: GET, POST, PUT, DELETE, which allows us to better protect access to our app.

Si si, lo voy leyendo y lo releeré.
La tarde la perdí con el cambio de ANSI a UTF8 y viceversa. En teoría debería ser muy, muy simple (supongo), pero a Gemini "se le ha ido la olla".
De ahí la consulta de como es mejor guardar los datos, como no tengo experiencia en ello, voy a prueba error. WWW es totalmente nuevo para mi.

FiveWIDI,

Keep DBF internally in ANSI

DBF is historically ANSI / codepage-based.
This is stable and well understood for existing desktop logic in FiveWin / Harbour.

Convert to UTF-8 at the web boundary
When sending data to the web: ANSI → UTF-8

When writing data back: UTF-8 → ANSI
The conversion belongs at the interface, not inside the database.

Always speak UTF-8 on the web
Set HTTP headers correctly (Content-Type; charset=utf-8).

Browsers and JavaScript expect UTF-8 by default.
If this is done consistently, no workarounds are needed.

Avoid “trial and error” conversions
Use a clear encoding standard per layer:

ANSI in DBF
UTF-8 in Web / JSON / HTTP

This separation prevents exactly the kind of frustration described.

Why converting DBF to UTF-8 is risky

Switching DBF storage to UTF-8 is dangerous in practice:
UTF-8 is variable-length
Field lengths would typically need to be increased by ₃₀% on average
Existing indexes, layouts, and validations may break
Silent truncation errors are likely
For mature DBF systems, this kind of change introduces far more risk than benefit.

Otto wrote:

FiveWIDI,

Keep DBF internally in ANSI

DBF is historically ANSI / codepage-based.
This is stable and well understood for existing desktop logic in FiveWin / Harbour.

Convert to UTF-8 at the web boundary
When sending data to the web: ANSI → UTF-8

When writing data back: UTF-8 → ANSI
The conversion belongs at the interface, not inside the database.

Always speak UTF-8 on the web
Set HTTP headers correctly (Content-Type; charset=utf-8).

Browsers and JavaScript expect UTF-8 by default.
If this is done consistently, no workarounds are needed.

Avoid “trial and error” conversions
Use a clear encoding standard per layer:

ANSI in DBF
UTF-8 in Web / JSON / HTTP

This separation prevents exactly the kind of frustration described.

Why converting DBF to UTF-8 is risky

Switching DBF storage to UTF-8 is dangerous in practice:
UTF-8 is variable-length
Field lengths would typically need to be increased by ₃₀% on average
Existing indexes, layouts, and validations may break
Silent truncation errors are likely
For mature DBF systems, this kind of change introduces far more risk than benefit.

(Google translation)
I needed an answer like this.

I wasn't far off the mark; last night I asked AI to save all the DBF files in ANSI format and perform the necessary conversions so that 'www' only uses UTF-8.

I'll do some tests tonight.

Thank you very much, Otto.

Fivewidi,

Yo de tu haria unas pruebas de concepto antes. Puedes trabajar perfectamente con tus dbfs y no necesitas hacer ningun tipo de conversion, ni en las dbfs, ni en la web, ni en tu programa web.

Muchos hablais tambien de aplicaciones hibridas que comparten win/web. Como lo gestionarias? Convertirias todo a utf8? Y tambien modificarias la app win para trabajar con utf8? Vaya lio, no?

Ni que en la practica es recomendado en web hoy en dia usar utf8, no significa que sea la solucion correcta en muchos casos y mas usando harbour....

C.

I take “Müller Franz Pfälzerstraße” and show how it looks raw in the file, once as ANSI (e.g. Windows-1252) and once as UTF-8, exactly as you would see it in a hex editor.

Text

Müller Franz Pfälzerstraße

1️⃣ ANSI (Windows-1252 / typical DBF codepage)

In ANSI, each character is exactly 1 byte.

Raw (Hex, ANSI):

4D FC 6C 6C 65 72 20 46 72 61 6E 7A 20
50 66 E4 6C 7A 65 72 73 74 72 61 DF 65

• Bytes: 27
• Fixed length: yes
• Perfect for DBF fields

2️⃣ UTF-8 (Web / JSON / HTTP)

In UTF-8, umlauts and ß are multi-byte characters.

Raw (Hex, UTF-8):

4D C3 BC 6C 6C 65 72 20 46 72 61 6E 7A 20
50 66 C3 A4 6C 7A 65 72 73 74 72 61 C3 9F 65

• Bytes: 30
• Fixed length: ❌ no
• Problematic for DBF fields

3️⃣ The key difference at a glance

4️⃣ Why UTF-8 in DBF is dangerous

• DBF fields are byte-based
• UTF-8 silently increases string length
• Indexes and validations operate on bytes, not characters
• Truncation can happen without any error message

That is why you would have to:

• Increase field sizes by ₃₀% across the board
• Adjust layouts
• Retest reports
• Touch legacy code

For mature DBF systems, this introduces far more risk than benefit.

Carles wrote:

Fivewidi,
Yo de tu haria unas pruebas de concepto antes. Puedes trabajar perfectamente con tus dbfs y no necesitas hacer ningun tipo de conversion, ni en las dbfs, ni en la web, ni en tu programa web.

Muchos hablais tambien de aplicaciones hibridas que comparten win/web. Como lo gestionarias? Convertirias todo a utf8? Y tambien modificarias la app win para trabajar con utf8? Vaya lio, no?

Ni que en la practica es recomendado en web hoy en dia usar utf8, no significa que sea la solucion correcta en muchos casos y mas usando harbour....
C.

Si, precisamente lo que estoy haciendo sólo lo usará la familia por que para ellos será una novedad y ahí morirá. Me está sirviendo para experimentar, descubrir y aprender.

Las app de escritorio que pueda tener seguirán siendo tal cual son, ni 'harto de vino' contemplo que estén condicionadas por las appweb, los DBF serán y se gestionaran (crear, leer, guardar, borrar, indexar) como lo que son hasta hoy en día, si guardan en ANSI así seguirán.

El caso es que empecé con una tontería y la estoy llevando al extremo de que se ha convertido en una aplicación muy web, pero con procesos en PRG contra DBF (no he visto php en el código que ha generado AI).
Y quizás (sólo quizás por que lo desconozco) Hix puede tener un 1% de diferencia de un servidor web 'estándar' (que a su vez posiblemente también tenga su 1% de diferencia con otro servidor web al uso).

Por ejemplo en el caso de mi problema con UTF8-Ansi (y perdona por que ya has dicho que no comentarás respuestas de AI), Gemini se ha atrevido a decir que:
"...Si el problema persistiera, lo único que diferenciaría un caso del otro sería si el servidor web (Hix) tratara de forma distinta los datos que vienen de un fetch (árboles) vs un submit form clásico (perfil)...."

Aun así, esto que me ha dicho AI no me preocupa; si estuviera haciendo un mueble de madera con clavos y tornillos, la AI debería saber cuando usar un martillo y cuando un destornillador.

De momento sigo sufriendo y disfrutando con ello.

Muchas gracias por los comentarios

Carlos, What exactly is the problem you are running into? Could you share a small code snippet?

From our experience, working purely with codepages rarely works reliably in practice. In files that have been filled over 30+ years, you usually end up with mixed starting conditions, depending on history, tools, and environments.

For that reason, we implemented a very simple conversion approach in Harbour that behaves similarly to a codepage boundary: we read from the DBF as-is, convert to UTF-8 right before sending data as JSON, and convert back when writing data back. In other words, the conversion happens explicitly at the interface, not implicitly via global codepage settings.

This has proven to be predictable and much easier to reason about than relying on codepage handling alone.

That’s why I’m a bit puzzled why this has turned into such a mystery. It would really help the discussion if we could see a concrete example of the problem you’re facing. A few lines of code would already make things much clearer and allow others to give more targeted feedback.

Search here for: convertUmlaute

Hi Otto,

I gotta say, I disagree with you. (As usual, pretty much :D )

I just looked at your convertUmlaute function... Seriously, Otto?

function convertUmlaute( cVData )
    local cTest := ""
    local i := 0

// Beispiel zur Analyse einzelner Zeichen
// for i := 1 to Len( cVData )
//     ? ( cVData + CRLF + SubStr( cVData, i, 1 ) + "  #  " + Str( Asc( SubStr( cVData, i, 1 ) ) ) )
// next

// Umlaute klein
cVData := StrTran( cVData, Chr( 228 ), "ä" )
cVData := StrTran( cVData, Chr( 132 ), "ä" )

cVData := StrTran( cVData, Chr( 246 ), "ö" )
cVData := StrTran( cVData, Chr( 148 ), "ö" )

cVData := StrTran( cVData, Chr( 252 ), "ü" )
cVData := StrTran( cVData, Chr( 129 ), "ü" )

// Umlaute groß
cVData := StrTran( cVData, Chr( 196 ), "Ä" )
cVData := StrTran( cVData, Chr( 142 ), "Ä" )

cVData := StrTran( cVData, Chr( 214 ), "Ö" )
cVData := StrTran( cVData, Chr( 153 ), "Ö" )

cVData := StrTran( cVData, Chr( 220 ), "Ü" )
cVData := StrTran( cVData, Chr( 154 ), "Ü" )

// ß
cVData := StrTran( cVData, Chr( 223 ), "ß" )
cVData := StrTran( cVData, Chr( 225 ), "ß" )

// Weitere Akzente
cVData := StrTran( cVData, Chr( 224 ), "à" )
cVData := StrTran( cVData, Chr( 225 ), "á" )

return cVData
//----------------------------------------------------------------------------//

Every single time you call that function, you run 16 StrTran() operations on a string.

If I update just one record with only 10 fields = that's 160 times you're running it.

If you update just 10 records = that's 1,600 times.

I don't even want to think about what happens if you're dealing with memo fields. Seriously?

First off, like I've said before, you don't need to use UTF-8 on your website. It's definitely a good idea, but you can totally have a website using your DBF without doing any conversion at all.

Second, if you really need to encode in UTF-8 (which, fair enough, is the right way to go), you don't need to use this function you made. It's seriously killing the system's performance.

Just my two cents...

C.

Otto wrote:

Carlos,
What exactly is the problem you are running into?
Could you share a small code snippet?

From our experience, working purely with codepages rarely works reliably in practice. In files that have been filled over 30+ years, you usually end up with mixed starting conditions, depending on history, tools, and environments.

For that reason, we implemented a very simple conversion approach in Harbour that behaves similarly to a codepage boundary:
we read from the DBF as-is, convert to UTF-8 right before sending data as JSON, and convert back when writing data back. In other words, the conversion happens explicitly at the interface, not implicitly via global codepage settings.

This has proven to be predictable and much easier to reason about than relying on codepage handling alone.

That’s why I’m a bit puzzled why this has turned into such a mystery. It would really help the discussion if we could see a concrete example of the problem you’re facing. A few lines of code would already make things much clearer and allow others to give more targeted feedback.

Search here for: convertUmlaute

Otto,

No puedo ofrecer parte del código por que lo ha generado AI y como es una prueba le he dejado que lo haga como quiera y el resultado ha sido un código spaguetti enorme que no me he molestado en seguir su flujo operativo.
El problema es que es que en algunos situaciones guarda en UTF8 y en otras en Ansi, y en consecuencia a veces se ven bien los caracteres acentuados y en otras no, pero no veo donde está convirtiendo de UTF8 a Ansi y viceversa, y sólo le digo a la AI que lo corrija, quiero que lo haga él por que desconozco el mundo www.

Si que estoy de acuerdo en que la conversión, si es necesaria, debe ser en el momento de leer de DBF y en el momento de guardar a DBF, eso mismo hice en su día para una prueba de encriptación en una app de escritorio, realmente es muy simple de aplicar.

Gracias Otto.

FiveWiDi wrote:

Carlos,
What exactly is the problem you are running into?
Could you share a small code snippet?

From our experience, working purely with codepages rarely works reliably in practice. In files that have been filled over 30+ years, you usually end up with mixed starting conditions, depending on history, tools, and environments.

For that reason, we implemented a very simple conversion approach in Harbour that behaves similarly to a codepage boundary:
we read from the DBF as-is, convert to UTF-8 right before sending data as JSON, and convert back when writing data back. In other words, the conversion happens explicitly at the interface, not implicitly via global codepage settings.

This has proven to be predictable and much easier to reason about than relying on codepage handling alone.

That’s why I’m a bit puzzled why this has turned into such a mystery. It would really help the discussion if we could see a concrete example of the problem you’re facing. A few lines of code would already make things much clearer and allow others to give more targeted feedback.

Search here for: convertUmlaute

Otto,

No puedo ofrecer parte del código por que lo ha generado AI y como es una prueba le he dejado que lo haga como quiera y el resultado ha sido un código spaguetti enorme que no me he molestado en seguir su flujo operativo.
El problema es que es que en algunos situaciones guarda en UTF8 y en otras en Ansi, y en consecuencia a veces se ven bien los caracteres acentuados y en otras no, pero no veo donde está convirtiendo de UTF8 a Ansi y viceversa, y sólo le digo a la AI que lo corrija, quiero que lo haga él por que desconozco el mundo www.

Si que estoy de acuerdo en que la conversión, si es necesaria, debe ser en el momento de leer de DBF y en el momento de guardar a DBF, eso mismo hice en su día para una prueba de encriptación en una app de escritorio, realmente es muy simple de aplicar.

Gracias Otto.

Creo que lo estoy resolviendo.
https://www.fivetechsupport.com/forums/viewtopic.php?p=283554#p283554

Hello Charly,

the Umlaut Converter is working perfectly.
The extremely short execution times (0.001 s for 20 iterations) simply show
that file access and string processing in Harbour are highly efficient.

A web browser takes significantly longer because it additionally interprets, decodes, and renders the text.
Our test only measures reading and replacing operations in memory — exactly as intended.

The file (testtext.txt) has a size of 1.77 kB and can easily be displayed in any browser,
since it already contains valid HTML entities (Ü, ä, ß, etc.).

Everything works as expected — no issues, no misinterpretation.

Best regards,
Otto

#include "fivewin.ch"

function Main()
    local cFile := "testtext.txt"
    local cText, cResult
    local nStart, nEnd, nElapsed
	 local i := 0, nLoops := 20
	 
if !File( cFile )
    MsgInfo( "Die Datei " + cFile + " wurde nicht gefunden. Bitte erstelle sie mit deutschem Text.", "Fehler" )
    return nil
endif

cText := MemoRead( cFile )
 ? cText
nStart := hb_MilliSeconds()
   
for i := 1 to nLoops
    cResult := ConvertUmlaute( cText )
next



nEnd := hb_MilliSeconds()

nElapsed := nEnd - nStart

MemoWrit( "converted.txt", cResult )
	

MsgInfo( ;
        "Ersetzung abgeschlossen!" + CRLF + ;
        "Eingabedatei: " + cFile + CRLF + ;
        "Ausgabedatei: converted.txt" + CRLF + ;
        "Wiederholungen: " + LTrim(Str(nLoops)) + CRLF + ;
        "Gesamtzeit: " + Str(nElapsed/1000, 6,3) + " s" + CRLF + ;
        "Durchschnitt pro Lauf: " + Str(nElapsed/nLoops, 8,3) + " ms", ;
        "Umlaut-Konverter mit Schleife & Millisekunden" )

? cResult
return nil


function ConvertUmlaute( cVData )
    // Kleinbuchstaben
    cVData := StrTran( cVData, "ä", "ä" )
    cVData := StrTran( cVData, "ö", "ö" )
    cVData := StrTran( cVData, "ü", "ü" )
    cVData := StrTran( cVData, "ß", "ß" )

// Großbuchstaben
cVData := StrTran( cVData, "Ä", "Ä" )
cVData := StrTran( cVData, "Ö", "Ö" )
cVData := StrTran( cVData, "Ü", "Ü" )

return cVData


INIT PROCEDURE PrgInit
    SET CENTURY ON
    SET EPOCH TO YEAR(DATE())-98
    SET DELETED ON
    SET EXCLUSIVE OFF
    REQUEST HB_Lang_DE
    HB_LangSelect("DE")
    SET DATE TO GERMAN
RETURN

Grüße aus München!  

Übermäßig ölige Überraschung.  

Äpfel, Öl, Übung – schön süß, heiß & kräftig.

Robbie Williams hat in seiner Heimat die Beatles überholt: Dank des Erfolgs seines jüngsten Albums „Britpop“ schaffte der Popsänger es zum 16. Mal mit einem Album an die Spitze der britischen Charts. Die legendären Beatles hatten das nur 15-mal geschafft. „He’s the one!“ erklärte die Official Charts Company gestern in Anspielung auf Williams’ Superhit „She’s the One“.

View this post on Instagram

Seit dem Erfolg seines ersten Soloalbums „Life Thru A Lens“ aus dem Jahr 1997 standen 16 seiner Alben an der Spitze der Verkaufslisten, rund 20 Millionen Alben verkaufte Williams in Großbritannien. „Glückwunsch, Robbie“, gratulierte Martin Talbot, Chef von Official Charts.

Mit seinem neuen Rekord lässt Williams nicht nur die Beatles hinter sich, sondern auch die britischen Rolling Stones und den US-Star Taylor Swift, die jeweils 14-mal mit einem Album auf Platz eins der britischen Charts landeten. Nur eines von Williams’ Alben – das 2009 veröffentlichte „Reality Killed The Video Star“ – landete nicht auf Platz eins, sondern nur auf Platz zwei. Weltweit verkaufte Williams in seiner 35-jährigen Karriere mehr als 80 Millionen Alben.