Laden...

[Gelöst] - Encoding-Problematik bei HttpWebRequest an eine SOAP-Schnittstelle

Erstellt von mosspower vor 14 Jahren Letzter Beitrag vor 14 Jahren 10.988 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren
[Gelöst] - Encoding-Problematik bei HttpWebRequest an eine SOAP-Schnittstelle

Hallo "Kollegen",

ich habe aktuell ein verzwicktes Problem.
Ich schicke mittels HttpWebRequest an eine SOAP-Schnittstelle (ja, ich muss es leider so verwenden, kann kein WCF verwenden, da Java-spezifisch) einen Request, der neben dem Envelope noch aus Attachments besteht (diese müssen ISO-8859-1 sein).

Erst mal mein Problem:
Schicke ich Requests mit bestimmten Sonderzeichen, z.B. é, aber nicht die deutschen Umlaute oder ß, dann verhält sich der Server wie folgt:

Verwandele ich vorher explizit in UTF-8 um, dann steht im Antwortattachment ein komisches Zeichen, dass ich nicht mehr hinbekomme, z.B. aus Patané wird Patané.

Ich muss die Antwort, Type Oktett-Stream, als PDF speichern, hier mache ich einfach einen StreamWriter auf und schreibe die Bytes weg (ohne jegliche Codierung, denn mit so einer funzzt das bei keinem Aufruf).

Wenn ich mit Default-Decoding oder ISO-8859-1 schicke, was ich ohne weiteres bei Umlauten machen kann, dann bekomme ich einen Internal Server (500) Error.

Problem ist, dass sich die Firma, die diesen Service anbietet auch überhaupt nicht auskennt, da die den Service wiederum von einem Drittanbieter haben, da kommen dann genau solche "Witzfehler" zurück oder in einer ErrorCollection steht, dass ein Fehler passiert ist, nur auf Englisch ohne weitere Angaben - von der Firma kann ich also nichts erwarten.

Ich bin jetzt echt verzweifelt hier, da ich schon fast zwei Tage an diesem Phänomän rummache. Es sind nur solche Sonderzeichen, die ja immer mal wieder in Namen vorkommen, Umlaute und Eszett machen keine Probleme. (wenn ich Encoding Default oder ISO-8859-1 bei Umlauten + Eszett verwende dann funzzt es, bei UTF-8 verzieht es beim PDF auch die Buchstaben bei den Umlauten, bzw. beim Eszett).

Problem ist auch, dass ich eine Java-Applikation portiere und mit genau dieser funzzt es ohne dass irgendswelche Codierungen übergeben werden, wird dann alles innerhalb von Axis behandelt.

Hat jemand eine Idee, bzw. wie kann ich anders als oben beschrieben aus dem Response (bzw. Abschitt Attachment Oktettstream) ein PDF generieren?

Ich habe hier keine Antworten mehr. Für etwaige Antworten danke ich euch schon einmal im Voraus.

3.170 Beiträge seit 2006
vor 14 Jahren

Hallo,

Ich vermute den Fehler in der Umwandlung von einem Encoding zum anderen.

Wie hast Du denn die Umwandlung der Encodings realisiert, bzw. wo kommen die ursprünglichen Daten her und wie sind diese codiert?

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Hallo MarsStein,

ich bin mir nicht ganz sicher ob es am Encoding liegt, denn wie oben beschrieben geht es und dann wieder mal nicht. Ich bin hier völlig ratlos.

Es ist nichts spezifiziert, sondern es wird alles "ausprobiert". Wenn ich Encoding.Default sende oder ISO-8859-1, dann funzzt das mit den Umlauten, aber wie schon beschrieben, nicht bei allen, bzw. bei obigen Beispiel nicht - vielleicht sollte ich mich nicht so auf das Encoding konzentrieren, ggf. ist es was anderes.

Die Fehler sind halt "erste Sahne".

Ich muss lediglich die Attachments mit Latin-1 senden.

Ich habe schon ausprobiert, wenn ich vor dem absenden explizit in UTF-8 umwandele, dann komme ich zwar immer! durch, jedoch sehen dann bei den PDFs die Umlaute eben alle so komisch aus.

Git es eine Möglichkeit herauszufinden, wie ein Stream codiert ist? .. wahrscheinlich hier unterschiedlich. Das Result-Envelop wird UTF-8 sein und die Attachments sind Oktett.

Wenn es eine Möglichkeit geben würde, bei einem BinaryWriter vorher von UTF-8 zu ... ja, zu was eigentlich, zu konvertieren, dann sollte mein Problem auch gelöst sein. Leider finde ich da gerade überhaupt nix.

Gegenwärtig suche ich im Response die PDF-Start-Marker und schreibe alle Attachments mit dem BinaryWriter wech (ohne Format), dann klappt das auch, wie gesagt, nur dann nicht, wenn ich explizit mit UTF-8 den Server aufrufe.

Naja, der Kunde weiß bescheid, vielleicht schickt er mir mal ein paar Fehlermeldungen, aber Server Error 500 ist schon total krass.

3.170 Beiträge seit 2006
vor 14 Jahren

Hallo,

schön und gut, aber damit hast Du meine Fragen nur geschickt umgangen statt sie zu beantworten:

  • wo kommen die Daten her, die Du versenden willst (Datei/Stream/etc.) ?
  • wie sind diese codiert ?

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Als Stream liegen die Daten vor. Ich rufe einen SOAP-Service mittels HttpWebRequest auf und lese dann den gesamten Stream. Hier steht dann alles drinnen (Response-Envelope + Attachments).

Ich weiß nicht, wie der Stream codiert ist. Wie bekommt man das raus?
Bin mir ziemlich sicher, dass er ISO-8859-1 codiert ist.

Gruß

5.657 Beiträge seit 2006
vor 14 Jahren

Ich verstehe auch nicht so ganz. Du schickst einen Request und bekommst eine Antwort, beides im SOAP-Protokoll. Aber wo kommt jetzt das PDF her? Erstellst du das lokal, oder kommt das auch vom Server?

Hängt denn die Codierung der Antwort in irgendeiner Form davon ab, wie du die Anfrage codierst?

Weeks of programming can save you hours of planning

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Ja, ich bekomme alles im Response-String.

Hier mal ein kleines Bild, über SOAP mit Attachments wie das aussieht.

Hier die Quelle

Moment, ich schicke euch mal gleich ein Original Response!

3.170 Beiträge seit 2006
vor 14 Jahren

Hallo,

im ersten Attachment steht schon mal "charset=utf8", das zweite ist binär.
Du kannst das nicht alles über einen Kamm scheren.
Die musst IMHO die Boundaries auswerten und Deine Attachments einzeln und angepasst einlesen, dann die Textteile in ISO-8859-1 umcodieren und anschließend weiterversenden.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Hier ein Beispiel der Antwort, also des Responses mit 2 Attachments, stark verkürzt.



------=_Part_4178_22893312.1268751536911
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Id: <B08CC99DB4B20D379E8DAE54BC091ACD>

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope />

------=_Part_4178_22893312.1268751536911
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Id: <3B8F144CD462E190508F662A492A188C>

%PDF-1.3
%????
5 0 obj
<<
/Type/XObject
/Subtype/Form
/FormType 1
/BBox [24.309 16.7898 577.2265 642.3445]
/Matrix [1 0 0 1 0 0]
/Resources <<
/ProcSet 1 0 R
/Font <<
/F 6 0 R 

u.s.w. bis EOF PFD ....


------=_Part_4178_22893312.1268751536911
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Id: <6AD19309D400706FAD78383ADE550B8E>

%PDF-1.3
%????
6 0 obj
<<
/Type/XObject
/Subtype/Form
/FormType 1
/BBox [69.6605 582.1368 534.7368 700.093]
/Matrix [1 0 0 1 0 0]
/Resources <<
/ProcSet 1 0 R
/Font <<
/F 5 0 R
>>
>>
/Filter/FlateDecode
/Length 509

u.s.w. bis EOF PFD ....

%%EOF

------=_Part_4178_22893312.1268751536911--


mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

@MarsStein,

genau das mache ich ja, ich werte die Boundaries (PDF-Attachments + XML-SOAP-Response-Envelope) aus.

Ich schreibe alles in den Boundaries, die nicht im ersten (hier SOAP-Envelope) mit BinaryWriter wech und das passt auch zu 95 Prozent, nur eben nicht zu 100 Prozent.

Kann mir vielleicht auch mal jemand sowas erklären, wie kann das gehen? Binär und XML-Encodierung Latin-1? 8o


------=Path-Separator
Content-Type: application/octet-stream 
Content-Transfer-Encoding: binary 
Content-Id: <order-attachment-1>  

<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?> ... usw, Content von Attachment für Request ...

Oktett bedeutet doch, dass jedes Zeichen aus genau 8 Bit besteht, oder?

5.657 Beiträge seit 2006
vor 14 Jahren

Ich nehme an, die beiden Attachments sind die PDF-Dateien? Und darin sind Werte aus deiner Anfrage enthalten, die falsch codiert worden? Dann liegt es sicher nicht an der fehlerhaften Codierung, sondern ander fehlerhaften Erstellung der PDFs.

Mich wundert vor allem folgendes:

wenn ich Encoding Default oder ISO-8859-1 bei Umlauten + Eszett verwende dann funzzt es

Klingt ja erstmal prima, aber funktioniert es nur im deutschen Sonderzeichen, oder auch mit á, è, €, ô usw.?

Verwandele ich vorher explizit in UTF-8 um, dann steht im Antwortattachment ein komisches Zeichen, dass ich nicht mehr hinbekomme, z.B. aus Patané wird Patané.

Das ist jedenfalls ganz normales Verhalten, das é wird beim zurückkonvertieren auch wieder umgewandelt. Die Frage ist, wozu brauchst du denn UTF8, wenn der Webservice damit sowieso nicht umgehen kann?

Weeks of programming can save you hours of planning

3.170 Beiträge seit 2006
vor 14 Jahren

Hallo,

jetzt muss ich aber doch mal doof nachfragen:
Lässt Du ein PDF erstellen mit Daten, die Du vorher an den Server schickst, oder lädst Du ein PDF herunter das aus "fremden" Daten generiert wird?

Im ersten Fall liegt das Problem vermutlich nicht in den Daten der Antwort, sondern bereits in denen des Requests den Du abschickst.
Im zwiten Fall kannst Du ja nur nehmen was Du kriegst, da kommst Du dann nicht mehr dazwischen.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

@MrSparkle,

ich kann es leider nicht zu 100 % sagen ob es am Encoding liegt.

Es gibt folgenden Sachverhalte nochmal kurz zusammengefasst:

Ich schicke immer den Request mit Encoding.Default, dann passen auch immer die PDF-Dokumente (also die Umlaute), aber nur dann, wenn der Request auch durchgeht, das bedeutet, wenn kein 500-er HTTP-Statusmeldung (Internal Server Error) kommt.

Schicke ich dagegen den Request mit Encoding.UTF-8, dann kann ich zwar immer den Server aufrufen (also kein 500er Error), aber hier passen die Umlaute dafür nie!

5.657 Beiträge seit 2006
vor 14 Jahren

Schicke ich dagegen den Request mit Encoding.UTF-8, dann kann ich zwar immer den Server aufrufen (also kein 500er Error), aber hier passen die Umlaute dafür nie!

Dann kann der Server offenbar nicht mit Unicode umgehen.
Was hat denn Encoding.Default bei dir für einen Wert? Hast du mal andere (übliche) Encodings ausprobiert?

Weeks of programming can save you hours of planning

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Hallo MarsStein,

Aufgrund des Requests werden die Dokumente auf dem Zielsystem generiert und im Response an den Client gesendet.

Problem ist wirklich, und jetzt trage ich hier nicht dicke auf, dass ich für manche Requests den Internal Fehler bekomme und dann für den absolut identischen 10 Minuten später durchkomme - bei manchen, wie eingangs erwähnt, komme ich nich durch (immer 500, wobei das total schwach ist, das bedeutet, dass die Anwendung, an die der Server weitergeleitet hat, hier Tomcat an Servlet, eine unbehandelte Ausnahme wirft ... leider gibt es hier nix, was gelogged wird - aufgrund einer Nachfrage, werden genau diese, also HTTP-Status 500, gar nicht mitgelockt, sind also dem System völlig unbekannt).

Die Requests sollten eigentlich, nach Rücksprache richtig sein.

Problem ist hatl, dass es mit Java läuft, ist ein auf Java optimierter SOAP, also verwendet Java-spezifische Objekte, so dass ich eben das Zeugs plain via SOAP und parsen der Boundaries durchführen muss.

Bei der Java-Lösung ist nix besonderes, außer, dass die Attachments auf der Festplatte in Form von XML-Dateien (ANSI-Default) zwischengelagert werden und AXIS dann den SOAP-Request zusammenbaut, der aber dann hinterher genau so wie der von mir gepostet aussieht, also Axis nimmt bei Java die Arbeit ab, was auf .NET-Ebene WCF machen würde.

3.170 Beiträge seit 2006
vor 14 Jahren

Hallo,

Aufgrund des Requests werden die Dokumente auf dem Zielsystem generiert und jetzt nochmal: woher kommen die Daten die Du in den Request schreibst? Ich vermute immer noch, daß das Problem bereits vor absetzten des Requests entsteht.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Hallo MrSparkle,

ja, ich verstehe es auch nicht, ich mache seit Jahren alles über UTF-8, aber es gibt ja Sachen "da draußen" ... X(

verstehen muss er das aber irgendwie schon, denn mit der Java-Lösung gibt es diesbezüglich überhaupt keine Probleme.

Encoding-Default ist bei mir Windows-1252 - Western Europe.

Wenn ich es explizit mit ISO-8859-2 probiere klappt es auch, also PDF passt mit Umlauten, bis eben immer zu den oben genannten Zwischenfällen, dann geht der Aufruf mit 500er Statuscode gar nicht erst (nie) durch.

Bin jetzt seit zwei Tagen über diesen Müll! 😜

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Sorry, ich sollte genauer lesen.

Die baue ich mir lokal mitels Daten aus Dateien und Datenbank zusammen.
welche über einen Kunden (der vierte hier im Bunde) an uns übermittelt werden.

5.657 Beiträge seit 2006
vor 14 Jahren

Klingt ja alles nicht so vielversprechend.
Aber fakt ist, daß bei manchen Encodings ein 500er kommt (bzw. irgendwo eine unbehandelte Exception geworfen wird) und bei anderen Encodings nicht. Also würde ich einfach mal alle Encodings durchprobieren, und auch verschiedene Sonderzeichen, die evtl zur Exception führen könnte.

Wenn man die Exceptions nicht ausgeben kann oder irgendwo mitgeloggt werden, kann man viele Vermutungen anstellen. Am Ende wird dir aber nix anderes übrig bleiben, als bei den Entwicklern des Webservice nachzufragen oder die Lösung per Try&Error selbst herauszufinden.

Wenn ich es explizit mit ISO-8859-2 probiere klappt es auch, also PDF passt mit Umlauten, bis eben immer zu den oben genannten Zwischenfällen, dann geht der Aufruf mit 500er Statuscode gar nicht erst (nie) durch.

Was bedeutet das konkret? Klappt es oder nicht oder nur manchmal? Üblich ist meistens ISO-8859-1 oder ISO-8859-15 (mit €-Zeichen).

Weeks of programming can save you hours of planning

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Was bedeutet das konkret? Klappt es oder nicht oder nur manchmal? Üblich ist meistens ISO-8859-1 oder ISO-8859-15 (mit €-Zeichen).

Sorry, ich meinte schon Latin-1 (aka ISO-8859-1). Die Typen können mit meinen Fragen nichts anfangen, die haben null Plan - die haben den Service programmieren lassen und das erstellen der PDFs läuft bei denen intern über einen dritten Anbieter. Die schreiben wirklich in ErrorCollections rein, wenn ein Fehler passiert ist die ErrorMessage, Error occurred (das wars, nix weiter!). Es ist zum verzweifeln.

Problem ist halt, warum die sich so langsam bewegen, dass intern eine funktionierende Javalösung vorhanden ist, die quick 'n' dirty "hingezaubert" wurde ... ich darf das jetzt "saubermachen" 🙁 ... würde das auch gern, aber kann ich ja nicht. Das kann 1000 Gründe haben!

Der Ansprechpartner hat mir vorhin bestätigt, dass die Requests richtig sind, also bei Ihnen generiert werden kann und auch heute Vormittag in Produktion ist es auch gegangen, nur wenn ich dann mit .NET "daherkomme" funzzt das nicht (immer).

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

OK, vielleicht kann mir jetzt einer helfen bei spezieller Problematik oder jemanden kommt das bekannt vor. Vorab, wie der Header des Aufrufs aussieht:


this.webRequest.Method = "POST";
this.webRequest.ContentType = "multipart/related; type=\"text/xml\"; start=\"<soap-envelope>\"; .boundary=\"----=Path-Separator\"";
this.webRequest.Accept = "application/soap+xml, application/dime, multipart/related, text";
this.webRequest.Headers.Add("Cache-Control", "no-cache");
this.webRequest.Headers.Add("Pragma", "no-cache");
this.webRequest.Headers.Add("SOAPAction", this.xxxConsumerJobCustomConfig.SoapAction);

Jetzt habe ich folgendes herausgefunden:

  1. Request A hat Apostroph im Request -> Aufruf schlägt fehl (Internal Server Error HTTP-Code 500)

  2. Request B wird der Name von Request A, also mit Apostroph hinzugefügt -> Aufruf ohne Fehler, Apostroph steht im PDF File

  3. Jetzt wird es total verrückt. Request A Apostroph wird ersetzt mit XXX -> Aufruf ohne Fehler, PDF Files OK (natürlich steht da XXX)

Jetzt bin ich völlig verwirrt, denn es liegt bei Request A am Apostroph, der aber nicht zu einem Fehler bei Request B führt 8o

Hat jemand schon einmal eine ähnliche Erfahrung gemacht, denn ich komme hier definitiv nicht weiter.

Ich dachte dann noch, dass es ein Caching-Problem ist, was ich jetzt definitiv ausschließen kann, da vorhin auf Anfrage der Server neu gestartet wurde.

5.657 Beiträge seit 2006
vor 14 Jahren

was ist denn der Unterschied zwischen Request A und Request B?

Weeks of programming can save you hours of planning

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

was ist denn der Unterschied zwischen Request A und Request B?

Hallo MrSparkle,

Wie oben beschrieben, Request a hat Apostroph drinnen und funzzt nicht und in Request b wurde das Apostroph reinkopiert und funktionierte das.

Ich habe den Fehler jetzt gefunden. Immer wenn in einem ganz bestimmten Feld im Attachment-XML ein Umlaut steht (oder sonstige Sonderzeichen), dann knallt es. Kurios ist, dass es manchmal einenen halben Tag später geht und dann wieder erst zwei Tage später, bzw. bei anderen Requests das völlig OK ist. Es kracht aber nur bei dem einen Feld (das nicht mal verwendet wird) ... bei Sonderzeichen, bzw. Umlauten in anderen Feldern (Straße, Ort ect.) fuzzt es und es wird auch das PDF richtig generiert.

Ich habe das weitergeleitet, das können die ausmachen. Ich bin hier mit meinem Latein am Ende. Bin echt mal gespannt was da zurückkommt.

Was erschwerend noch hinzukommt ist die Tatsache, dass es eben beim Java-Programm immer geht.

Das einzige was mir noch einfällt wäre Caching-Problem, aber da habe ich auch schon "rumgespielt" mit den Eigenschaften auf no-cache usw.

5.657 Beiträge seit 2006
vor 14 Jahren

Reinkopiert? Also Strg-V?
Dann solltet ihr mal checken, mit welcher Codierung die Benutzeroberfläche funktioniert. Vielleicht ist das auch auf verschiedenen Betriebssystemen unterschiedlich, und die DB kommt nicht damit zurecht. Vielleicht wird der Umlaut der Zwischenablage dann umgewandelt? Oder nicht umgewandelt? Oder falsch umgeandelt? Oder richtigumgewandelt, aber in einer anderen Codierung als die Datenbank? Alles nur Vermutungen, ich verstehe nicht wirklich, was du gerade beschrieben hast 8)

Weeks of programming can save you hours of planning

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Hallo MrSparkle,

wenn ich ganz ehrlich bin, dann verstehe ich das auch alles nicht mehr.
Das Java-Programm läuft auf einer Windows-Kiste und auch der Server.

Man kann es kurz auf den Punkt bringen:

Ich lese aus einem File eine XML ein (UTF-8-Encoding) und baue damit den Request zusammen. Steht in einem bestimmten Element ein Umlaut, dann kracht es, lösche ich den raus aus dem File und lasse das Programm wieder laufen, dann geht es.

Öffne ich jetzt wieder das File und schreibe einen Umlaut rein, dann kracht es wieder.
Wie gesagt, bezieht sich das alles nur auf ein bestimmtes Element - bei allen anderen gibt es keine Probleme mit den Umlauten.

Noch verrückter ist, dass z.B. morgen oder übermorgen genau das File dann doch geht, also mit Umlauten in dem einen bestimmten Feld.

Ja, das ist soz. der völlige Wahnsinn! (und verstehen muss es nun wirklich niemand)

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Erst mal vielen Dank für eure Anregungen und Hilfestellungen.

Das Problem wurde nun ausfindig gemacht, dank Sniffer via WireShark.
Bei jedem Request wird der Envelope im UTF-8-Format erwartet, und die Attachments in Latin-1-Kodierung.

Axis verschlüsselt Sonderzeichen, die nicht explizit als UTF-8 kodiert sind, mittels der Entity-Schreibweise, z.B. wird aus einem ü

&XFC;

Bei den Attachments wird mittels AXIS immer der Latin-Code-1, welcher hier beim ü, auch der gleiche wie bei UTF-8, nämlich FC ist.

Ich habe natürlich bei den Anfragen im Envelope gleich UTF-8 genommen, denn warum soll ich Filtern, es gibt zig Namen, die Sonderzeichen besitzen usw.
Das bedeutet, dass z.B. ein ü im Envelope und in den Attachments als FC übermittelt werden.

Nun muss den Leuten, die die Schnittstelle zur Verfügung stellen, das auch schon aufgefallen sein, und die haben angefangen zu filtern - denn, bei allen bis auf zwei Elementen, funktionieren Sonderzeichen.

Bei den zwei Elementen gingen übrigens nur das kleine ü und das kleine ö nicht - wahrscheinlich im Filter vergessen oder Copy-und-Paste-Fehler.

Die Fehlermeldung, also der Internal Server (500) Error war:

An invalid XML character (Unicode: 0xfc) was found in the element content of the document. 😁

Wirklich sehr peinlich, denn 0xfc steht für ein kleines ü sowohl beim Latin-1-Code, wie auch im UTF-8-Code.

Dieser Fehler (+ Fehlermeldung) hat es somit in meine TOP-5 der verrücktesten Vorfälle in meiner fast 10 jährigen Programmierlaufbahn geschafft.

Dank an euch allen - case closed!

5.657 Beiträge seit 2006
vor 14 Jahren

Kann ich nur mit dem Kopf schütteln drüber. Warst du der Beta-Tester oder warum ist sowas noch nicht aufgefallen?

Weeks of programming can save you hours of planning

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

Wir sind die ersten, die die Funktionalität nutzen, aber aus Zeitgründen hat eine Kollegin das mittels Java implementiert.

Jetzt beim Migrieren ist dieser (eigentlich verrückter) Fehler an die Oberfläche gepoppt.

5.657 Beiträge seit 2006
vor 14 Jahren

Wir sind die ersten, die die Funktionalität nutzen, aber aus Zeitgründen hat eine Kollegin das mittels Java implementiert.

Jetzt beim Migrieren ist dieser (eigentlich verrückter) Fehler an die Oberfläche gepoppt.

Das verrückte daran ist ja eigentlich das fehlende Error Handling. Eine Nachricht wie "An invalid XML character (Unicode: 0xfc) was found in the element content of the document." hätte einen ja sehr schnell auf die richtige Spur gebracht...

Weeks of programming can save you hours of planning

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 14 Jahren

LOL, genau das war der Grund, warum meine E-Mails gegenwärtig überprüft werden, bevor ich die zum Kunden schicken darf 😉 ... naja, so krass ist es nicht, aber da hat es schon gewaltig gescheppert bis nach ganz oben.

Die bringen auch Fehler zurück in einer ErrorCollection, wo dann als Text sehr oft drinnen steht, dass ein Fehler passiert ist, aber nicht näher spezifiziert. So nach dem Motto, immer der gleiche Fehlercode und die Meldung, Hallo, es ist ein Fehler passiert.

Der absolute Hammer ist, dass die die Fehler mitloggen in der DB und ich als Benutzer muss dann anrufen und ggf. manuell eingreifen, bzw. Fragen, welcher Fehler denn bitte aufgetreten ist.

Auch verrückt ist, dass die öfters die Datenbank (Oracle) durchstarten müssen, danach geht es (andere Fehler, nicht die Threadproblematik) dann wieder 8o ?( HALLO!

Naja, die bringe ich schon noch auf Vordermann 🙂