5. Juni 2013 13:29
Hallo,
wahrscheinlich ganz einfach - aber ich kenn die Lösung nicht...
Wir haben einen Report, der die Artikelstammdaten liest und für einen Webshop ausgibt. Die Ausgabe erfolgt als txt.-Datei. Vor Ausgabe des Textes erfolgt der Aufruf für CU GeneralMgt.Ansi2Ascii - trotzdem werden die Sonderzeichen falsch dargestellt. Beispielsweise wird das Grad-Zeichen als Durchmesser dargestellt. Die Umlaute sind korrekt.
Hat jemand eine Idee, woran das liegen kann?
Vielen Dank und viele Grüße
Mike
Zuletzt geändert von Mike24 am 6. Juni 2013 09:05, insgesamt 2-mal geändert.
5. Juni 2013 13:42
Schon mal geprüft ob GeneralMgt.Ansi2Ascii das °-Zeichen konvertiert?
und mit welchem Editor und mit welchem Zeichensatz des Editors schaust du dir die Datei an?
Gruß, Fiddi
5. Juni 2013 13:55
Hallo Fiddi,
ja, das Zeichen ist in der Konvertierung enthalten. Betrachtet habe ich die Datei mit dem normalen Windows-Editor und mit Ultraedit Zeichensatz 1252 und automatisch.
Viele Grüße
Mike
5. Juni 2013 14:16
Mike24 hat geschrieben:wahrscheinlich ganz einfach - aber ich kenn die Lösung nicht...
Mike24 hat geschrieben:Vor Ausgabe des Textes erfolgt der Aufruf für CU GeneralMgt.Ansi2Ascii
Müsste bei der Ausgabe nicht eine Konvertierung von ASCII -> ANSI erfolgen
5. Juni 2013 15:02
Müsste bei der Ausgabe nicht eine Konvertierung von ASCII -> ANSI erfolgen
Kommt drauf an, was die Gegenstelle haben möchte
Aber du hast Recht NAV arbeitet ja schon mit "ASCII (CP850+€)", dann sollte man auch ASCII- >nach ANSI konvertieren, wenn die Gegenstelle ANSI haben möchte. Will Sie "ASCII" haben tut man besser gar nichts.
Dann muss man aber auch im Editor die Codepage auf CP850+€ umstellen, damit die Datei korrekt aussieht
Gruß, Fiddi
5. Juni 2013 15:51
Hallo,
peinlich, peinlich - es ist ASCII2ANSI
Manchmal weiß man nicht mehr, was man eigentlich getan hat...
Quelle: üäö"°ßÜÖĵ²³
Code .... Textzeile := CUGenMgt.Ascii2Ansi(Textzeile);
Ergebnis: ...|üäö"øßÜÖÄæýü|||
Sorry für die Irreführung
Viele Grüße
Mike
5. Juni 2013 16:03
Also wenn du die Standard Cu 11501 benutzt, und sich die seit Version 5 nicht geändert hat, dann ist in NAV 2013 (die hab ich gerade zur Hand) weder "²","³","°",noch "ß" im Konvertierungs- "From"- String enthalten, was bedeutet, das er auch nicht konvertiert wird.
Gruß, Fiddi
5. Juni 2013 16:36
fiddi hat geschrieben:Also wenn du die Standard Cu 11501 benutzt, und sich die seit Version 5 nicht geändert hat, dann ist in NAV 2013 (die hab ich gerade zur Hand) weder "²","³","°",noch "ß" im Konvertierungs- "From"- String enthalten, was bedeutet, das er auch nicht konvertiert wird.
Also hier in einer R2/CH DB ist auch im auskommentierten DE-Teil ¹,³,ß enthalten. Das ² und ° fehlt dafür.
5. Juni 2013 17:22
Oh je, Fiddi hat recht - das Gradzeichen ist nur im ANSI-Teil nicht im ASCII-Teil...
Da hab ich wohl den Wald vor lauter Bäumen nicht mehr gesehen....
VG
Mike
19. Mai 2015 11:42
Hallo Meik,
Ich weiss, Dein Post ist schon älter. Ich stehe vor dem genau gleichen Problem. Kriege das Grad Zeichen ° nicht richtig exportiert, trotz Einsatz von Ascii2Ansi.
Wenn ich mir die Funktion im GM anschaue dann wird ° nicht geprüft, weshalb verständlich ist, dass in Ansi dann eben leider der Durchmesser rauskommt.
Nun - was hast Du geändert?
Wenn ich im FROM Teil das ° Zeichen hinzufüge, welches Zeichen muss ich denn im TO Teil hinterlegen, damit ich in meinem exportierten ASCI textfile auch wirklich das Gradzeichen erhalte?
Vielen Dank!
19. Mai 2015 15:58
Izzy hat geschrieben:Wenn ich im FROM Teil das ° Zeichen hinzufüge, welches Zeichen muss ich denn im TO Teil hinterlegen, damit ich in meinem exportierten ASCI textfile auch wirklich das Gradzeichen erhalte?
An derselben Position wie das °... D.h. es wird z.B. das 25. Zeichen in from durch das 25. Zeichen in to ersetzt.
20. Mai 2015 11:35
Hallo Markus,
Vielen Dank für Deine Antwort!
Die Position ist mir soweit klar, nur wenn ich beim ToString da auch ein ° einfüge, erhalte ich im exportierten File immer noch das Durschnittszeichen, anstatt halt eben dem gewünschten Gradzeichen.
So wie Du das beschreibst würde ich ° mit ° ersetzen, wodurch sich nichts am Output ändert, das habe ich schon getestet.
Hast Du sonst noch eine Idee was ich falsch mache?
Danke Dir!
20. Mai 2015 13:09
Izzy hat geschrieben:Die Position ist mir soweit klar, nur wenn ich beim ToString da auch ein ° einfüge, erhalte ich im exportierten File immer noch das Durschnittszeichen, anstatt halt eben dem gewünschten Gradzeichen.
So wie Du das beschreibst würde ich ° mit ° ersetzen, wodurch sich nichts am Output ändert, das habe ich schon getestet.
Hast Du sonst noch eine Idee was ich falsch mache?
Als nächstes würd ich das °, wenns eh nicht konvertiert werden soll, ganz rausnehmen...
20. Mai 2015 14:15
Hallo Markus,
Ich glaube wir reden aneinander vorbei :)
Ich habe in den ExtendedTextLines von Artikeln Texte drin, die das Zeichen ° beinhalten.
Wenn ich diese Artikel via Dataport exportiere und den Text vorher von ASCII2ANSI wandle, weil ich ihn nachher in SQL importieren will, dann zeigt mir das (ANSI) TextFile anstelle ° das DurchschnittZeichen Ø.
Deshalb wollte ich das ° Zeichen wandeln, nur Frage ich mich, welchen Code man korrekterweise verwenden muss. Ich kann mir nicht erklären, warum das ° Zeichen im ASCII Format von Navision angezeigt, aber nach Export in ANSI also Ø dargestellt wird.
Würdest Du sagen, dass das ° Zeichen eigentlich direkt korrekt exportiert werden können sollte?
20. Mai 2015 16:02
Erweitere doch die Ascii2Ansi bzw. schreib für dich eine eigene Funktion wenn du die Codeunit nicht bearbeiten kannst.
Je nachdem welches Zeichen du nimmst:
Ascii2Ansi:
(Alt 248) ° zu (Alt 176) ░
(Alt 167) º zu (Alt 186) ║
mfg,
winfy
20. Mai 2015 17:38
Hallo Winfy,
Vielen Dank für Deinen Support!
Leider komme ich immer noch nicht weiter.
Wenn ich bei mir Alt+186 oder Alt+176 eingebe dann erscheint in BEIDEN Fällen im Code das folgende Zeichen: ¦
Wenn ich es so laufen lasse habe ich nachher im Ansi File wiederum folgendes Zeichen, anstatt des Grad-Zeichens: und 10Ý Innenkonus.
Ich kann auch Deine beiden Zeichen kopieren und bei mir im Code einfügen, sie erscheinen aber wieder als ¦.
EXIT(CONVERTSTR(_String,'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ°',
'óÚÔõÓÕþÛÙÞ´¯ý’µã¶÷ž¹¨ Íœ°úÏÎâßݾ·±Ð¬‡Š«Œ‹“”‘–—¤•ËÈÊš›™¦'));
Hartnäckiges Problem!
21. Mai 2015 09:02
hmmm... interessant:
wenn ich hier im forum ALT+176 tippe erhalte ich korrekt: ░
wenn ich das gleiche im C/SIDE 5.0 SP1 mache dann erscheint: ¦
Das zweite ergibt dann eben leider nicht das ° Zeichen sondern Ý
Könnte das an einer Navision Einstellung liegen, verwende ich eine falsche Codepage?
21. Mai 2015 09:06
Izzy stimmt klappte nicht.
Hatte es nicht im Navision getestet.
Mit Char sollte es aber klappen.
- Code:
S:=176; // S vom Typ Char
_String:='In Berlin sind es gerade 18° !';
_String:=CONVERTSTR(_String,'°',FORMAT(S));
mfg,
winfy
21. Mai 2015 09:15
Hallo,
vielleicht ist die Lösung folgende:
- Besorge dir einen Editor, der sowohl OEM850- Codepage als auch Ansi kann. z.B. Notepad++
- exportiere dein Objekt als Text- Datei.
- öffne die Datei im Notepad++
- stelle die Kodierung unter "Kodierung" auf "Ansi"
- trage im Ansi- String dein '°'- Zeichen ein.
- markiere das '°'- Zeichen, und kopiere es in die Zwischenablage
- stelle die Kodierung im Editor unter "Kodierung\Zeichensatz\Westeuropäisch\" auf "OEM 850" ein.
- trage im NAV- String an der gleichen Stelle dein '°'- Zeichen aus der Zwischenablage ein.
- Speichere die Datei
- importiere und kompiliere die Datei in NAV und teste.
evtl. reicht es auch nur die Texte in den Editor zu kopieren, dann aber auf die richtige Kodierung achten.
Gruß, Fiddi
21. Mai 2015 11:05
Hallo fiddy und winfy,
Nochmals vielen herzlichen Dank für Euren Support, den ich sehr schätze.
Ich habe beides probiert: bei fiddi's vorschlag habe ich festgestellt, dass als resultat 2! zeichen auf einmal erscheinen: ┬░
Diese werden aber von ConvertString als 2 anstatt 1 Zeichen gelesen, wodurch natürlich der From und To String nicht die gleiche Länge haben - > nicht erlaubt.
Die Variante von winfy führt jedoch zum Ziel. Ich prüfe nun zuerst explizit auf das ° Zeichen und ersetze es mit einer Char-Variablen die den Wert 176 hält.
So klappts - in zwei Schritten halt:
- Code:
GradeSign := 176; // Type Char
_String:=CONVERTSTR(_String,'°',FORMAT(GradeSign));
EXIT(CONVERTSTR(_String,'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ',
'óÚÔõÓÕþÛÙÞ´¯ý’µã¶÷ž¹¨ Íœ°úÏÎâßݾ·±Ð¬‡Š«Œ‹“”‘–—¤•ËÈÊš›™'));
Ich danke Euch ganz herzlich für Eure Hilfe!! cool!
21. Mai 2015 11:30
- Code:
EXIT(CONVERTSTR(_String,'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔ°',
'óÚÔõÓÕþÛÙÞ´¯ý’µã¶÷ž¹¨ Íœ°úÏÎâßݾ·±Ð¬‡Š«Œ‹“”‘–—¤•ËÈÊš›™'+FORMAT(GradeSign)));
So geht es auch in einem Schritt, aber dann sind die Zeichen irgendwann nicht mehr schön untereinander gegliedert. ;)
mfg,
winfy
21. Mai 2015 11:42
Hallo,
also ich habe das ganze gerade noch mal ausprobiert. mit der Standard CU 11501 GeneralMgt. Da ist diese Funktion schon drin, nur auch ohne '°'- Zeichen.
Die Funktionen sehen nach dem Export (Ansi- kodierte Darstellung) so aus:
- Code:
PROCEDURE Ansi2Ascii@10(_String@1150001 : Text[250]) _Output@1150000 : Text[250];
BEGIN
// Converts from ANSI to ASCII
EXIT(CONVERTSTR(_String,'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ',
'€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©µ¶·ÒÓÔÖ×ØÞàáâãéêë'));
END;
PROCEDURE Ascii2Ansi@1150001(_String@1150001 : Text[1024]) @1150000 : Text[1024];
BEGIN
// Converts from ASCII to ANSI
EXIT(CONVERTSTR(_String,'€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©µ¶·ÒÓÔÖ×ØÞàáâãéêë',
'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ'));
END;
Der erste Schritt ist es jetzt das Gradzeichen in den jeweiligen Ansi- String einzubauen, da wir den Editor im Ansi- Modus betreiben. Das Zeichen kann ganz normal über die Tastatur eingegeben werden.
- Code:
PROCEDURE Ansi2Ascii@10(_String@1150001 : Text[250]) _Output@1150000 : Text[250];
BEGIN
// Converts from ANSI to ASCII
EXIT(CONVERTSTR(_String,'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ°',
'€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©µ¶·ÒÓÔÖ×ØÞàáâãéêë'));
END;
PROCEDURE Ascii2Ansi@1150001(_String@1150001 : Text[1024]) @1150000 : Text[1024];
BEGIN
// Converts from ASCII to ANSI
EXIT(CONVERTSTR(_String,'€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©µ¶·ÒÓÔÖ×ØÞàáâãéêë',
'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ°'));
END;
der Zweite Schritt ist es den Editor auf OEM 850 umzuschalten (code ist jetzt in OEM 850- Kodierung), und wieder das Grad- Zeichen über die Tastatur diesmal im "ASCII"- Text einzugeben.
- Code:
PROCEDURE Ansi2Ascii@10(_String@1150001 : Text[250]) _Output@1150000 : Text[250];
BEGIN
// Converts from ANSI to ASCII
EXIT(CONVERTSTR(_String,'óÚÔõÓÕþÛÙÞ´¯ý─┼╔µã¶÷‗¹¨ Í▄°úÏÎâßݾ·±Ð¬║┐«┴┬└╩╦╚═╬¤╠Ë▀ÈÊ┌█┘░',
'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ°'));
END;
PROCEDURE Ascii2Ansi@1150001(_String@1150001 : Text[1024]) @1150000 : Text[1024];
BEGIN
// Converts from ASCII to ANSI
EXIT(CONVERTSTR(_String,'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ°',
'óÚÔõÓÕþÛÙÞ´¯ý─┼╔µã¶÷‗¹¨ Í▄°úÏÎâßݾ·±Ð¬║┐«┴┬└╩╦╚═╬¤╠Ë▀ÈÊ┌█┘░'));
END;
Nicht darüber wundern, dass das °-Zeichen im Ansi- String jetzt als anderes Zeichen dargestellt wird und in NAV später als 'Ø'.
Jetzt kann man die Textdatei speichern, in NAV importieren und kompilieren. Dies ist übrigens die einzige saubere Möglichkeit um das ganze in NAV2013 oder höher zu bewerkstelligen (wg. Unicode).
Gruß Fiddi
21. Mai 2015 13:49
Hallo winfy, hallo fiddy,
bin beeindruckt - da hätte mir das know how schlicht gefehlt. Ich habe nun das ganze nach fiddi's vorschlag nachgebaut und siehe da, es klappt! auch ich verwende natürlich die CU 11501. Mein Problem war nur: wie kriege ich das ° zeichen korrekt als ascii output da rein.
genial!
DANKE!!!!
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.