PDF Dokument aus TextDatei parsen und darstellen

Hallo,

ich bekomme eine PDF Datei innerhalb einer Text Datei übertragen (Stichwort HL7 ORU Nachricht).
Die PDF Datei ist im Plain-Text vorhanden (nicht Base64 oder UU-codiert).

Die Zeilenumbrüche sind ursprünglich als “\x0A” bzw. “\x0D” vorhanden, die ich in “\r” bzw. "
" umwandle.

Wenn ich das PDF Dokument dann als “test.pdf” anlege, kann ich das Dokument öffnen, jedoch ohne Inhalt.
Im Texteditor sieht das PDF Dokument für mich normal aus…

		
		   BufferedReader br = new BufferedReader(new FileReader("tempDump.hl7"));
		  
		   
		   String pdf = null;
		    try {
		        
		        String line = br.readLine();		    
		        while ((line = br.readLine()) != null) {
		        	if(line!=null && line.length()>0) {
		        		//*log.info("Found: "+line);
		        		
		        		if (line.contains("%PDF")) {
		        			int startIndex = line.indexOf("%PDF");
		        			
		        			String pdfHandle = line.substring(startIndex);
		        			int endIndex = pdfHandle.indexOf("|");
		        			pdf = pdfHandle.substring(0, endIndex);
		        			pdf = pdf.replace("\\x0D\\", "\r").replace("\\x0A\\", "
");
		        			
		        			
		        		}
		        	}
		        	
		        }
		    } finally {
		        br.close();
		       
		    }
		    
		    byte[] bytePDF = pdf.getBytes();
		    File someFile = new File("pdf.pdf");
            OutputStream fos;
            fos = new FileOutputStream(someFile);
            fos.write(bytePDF);
            fos.flush();
            fos.close(); 
		
		    log.info(pdf);

		

	}```

Kann mir jemand einen Tip geben was ich falsch mache bzw. wie ich den Fehler im PDF aufspüren kann?

GGK

schreibe den String evtl. mit einem BufferedWriter statt getBytes() und OutputStream,

aber das ist nur eine von vielen Nahtstellen an denen Encoding gewechselt wird, Zeichen geschrieben usw.
im Gesamtprozess schwierig zu beurteilen,

hast du das als Aufgabenstellung von jemand anders? irgendeine Person oder Quelle die seriös behauptet, dass das grundsätzlich geht?
will es gar nicht abstreiten, noch nicht ausprobiert, aber wäre ein wichtiger Anfang

wenn ich bei mir ein PDF mit Editor öffne sehe ich u.a.


xœµ}K“$¹qæ½E]ÖlhÖ“xèFjHJ²5ŠâŒiË=ÔTgÏÔ2«ªU¡òß/üíˆÌìŽlrI“Øñ@¸;îwÄox÷ëßO71ìÂÍßáÿܽ7?½‹7¡ÿ7ÞÌËn

… was auch noch nichts heißen muss, aber nicht gerade das leichteste

beziehst du dich auf ein bestimmtes Test-PDF?
lade das als korrektes Original hoch, sowie ein erstellte Kopie von dir, vergleiche sie ruhig auch selber bereits,
stimmen nur einzelne Zeichen nicht, etwa die Umbrüche, oder alles komplett anders?

kannst du auch den Code bereitstellen, der vom PDF aus arbeitet, falls Java?
wenn tempDump.hl7 eine feste Datei im Prozess ist, dann diese auch hilfreich, hochladen

Wenn es eine HL7 ORU Nachricht ist, dann ist es ein medizinischer Befund. Den wird er wohl nicht hier hochladen :wink:

Technische Dokumentation zum Standard hast du dir aber durchgelesen?
(kurzes Googlen traf auf http://www.corepointhealth.com/resource-center/hl7-resources/hl7-oru-message - vielleicht kennst du das noch nicht)

Danke für die rasche Antwort…

Mit einem BufferdWriter sieht es gleich aus…ein leeres PDF

Zu deinen Fragen:
das PDF kommt über einen HL7 Datenstrom daher und ist ein reguläres PDF Dokument das als File in tempDump.hl7 abgelegt wird
ich habe leider keine anonymisierte Form des PDF Dokumentes so dass ich das hochladen kann…ebenso kein Test-PDF ohne personenbezogene Daten

GGK

Dann musst du doch nur herausfinden, wie eingebettete Daten encodiert werden, also welche Ersetzungen genau vorgenommen werden.

die daten werden nicht codiert…jene, die uu-encodet oder base64 encodet daher kommen, konnte ich schon parsen…
ich scheitere jetzt nur hartnäckig an an den plain.übertragenen pdfs

*** Edit ***

[QUOTE=cmrudolph;83257]Wenn es eine HL7 ORU Nachricht ist, dann ist es ein medizinischer Befund. Den wird er wohl nicht hier hochladen :wink:

Technische Dokumentation zum Standard hast du dir aber durchgelesen?
(kurzes Googlen traf auf HL7 Observation Result (ORU) Message | Rhapsody - vielleicht kennst du das noch nicht)[/QUOTE]

ich habe deine Nachricht erst jetzt gesehen…klar :wink:

GGK

dann darfst du aber

[quote=GGK;83250]Die Zeilenumbrüche sind ursprünglich als "\x0A" bzw. "\x0D" vorhanden, die ich in „\r“ bzw. "
" umwandle.[/quote]
auch nicht machen.

wenn ich base64 codierte PDF Dateien verarbeite mache ich genau das, nur dass ich nach dem replace noch decodiere.
Die HL7 Datei stammt unrsprünglich von einem Linux System…die PDF Darstellung aber auf einem Windows System statt.

Das ist egal. Entscheidend ist, wie das Programm die Datei erstellt. Pdf ist dabei plattformunabhängig (das P steht immerhin für portable :wink: ). Kannst du aus dem Quellsystem die Rohdatei direkt als PDF exportieren, sodass sie lesbar ist? Dann hättest du immerhin eine Möglichkeit die Unterschiede zwischen der eingebetteten und der funktionierenden Version zu vergleichen.

nein…ich habe nur den HL7 Dump zur Verfügung.
Spielt es eine Rolle, ober ich das PDF File als String (wie derzeit) einlese oder als Byte…und dann in einen String umwandle?

dein Ziel ist aktuell, die Datei so wie sie ist zu belassen, bis auf Zeilenumbrüche, und sie dann PDF zu benennen?

wie kommt es dazu überhaupt, wer erstellt HL7, ist demjenigen bewußt fast ein richtiges PDF zu haben,
gibt es gute Gründe warum genau und ausschließlich die Zeilenumbrüche falsch sein sollten?

überprüfe jedenfalls ob du dein Ziel erreichst,
lies in einem anderen Programmteil mit BufferedReader beide Dateien ein, gehe alle chars nacheinander durch, bei den Umbruchstellen entsprechend überspringen,
stimmen die Dateien soweit überein?

dasselbe dann auf byte-Ebene, sind abgesehen von Umbruchstellen alle Bytes exakt dieselben?
insbesondere sollte es leicht sein, den Anfang bis zum ersten Umbruch genau zu vergleichen, wobei vielleicht der Umbruch auch schnell kommt

falls Unterschiede bei Bytes kann man über falsche Wahl des Text-Encodings nachdenken,
Text als UTF-8 einlesen?

sollte auch andere String-Ausgabe in Java geben,
aber ohne Vergleich hilft das nicht unbedingt viel

wenn die HL7-Datei von Linux erstellt wird und dein Programm auf Windows läuft wäre das eine heiße Spur,
auch das Abspeichern aus Java dann wieder UTF-8,
mit getBytes() kommt man bei richtiger Bedienung sicher auch dahin, aber Streams und Writer recht verläßlich dazu

evtl. auch UTF-16 versuchen, habe ich jetzt irgendwo zu PDF gelesen, nur so als Strohhalm

*** Edit ***

hierzu funktioniert es mit getBytes() abzuspeichern? hmm

die daten werden nicht codiert…jene, die uu-encodet oder base64 encodet daher kommen, konnte ich schon parsen…
ich scheitere jetzt nur hartnäckig an an den plain.übertragenen pdfs

kannst du ein und dieselbe Datei einmal mit den anderen Wegen erfolgreich holen und dann den aktuellen Weg?
dann hättest du Vergleichsdatei & Zwischendaten satt, wenn schon nicht hier, dann für dich für Vergleiche

ja, da ich annehme (zurecht?), dass die PDF Datei plain im HL7 File abgelegt ist.
Ich versuche UTF-8, UTF-16…beides funtkioniert nicht.

die bas64 encodeden Files habe ich über decodeBuffer(String) encoded.

Ich vermute, dass das PDF nicht so “Plain” übergeben wird, wie ich das annehme…

GGK

Öhm, bestehen deine PDFs nur aus einer Zeile oder hast du auf ein pdf = pdf + pdfHandle vergessen? So wird jedenfalls immer nur die letzte Zeile vom Dokument gespeichert.