2013-10-03 10 views

risposta

2

Sembra un problema difficile. Il caso ideale naturalmente è prendere la stringa che contiene le barre e usare semplicemente string.split!

In caso contrario, l'unica strategia che posso iniziare a pensare è provare a scorrere la stringa, controllando se esistono cartelle per varie lunghezze della prima parte della stringa, ecc. Ciò può causare problemi anche se si intende trovare una cartella "MyFolder (2)" e c'è anche una "MyFolder". Non so molto della maglia, ma consiglierei di provare a trovare un modo diverso per afferrare la corda che ti serve.

+3

Grazie.Quello che ho finito è stato aggiungere un evento di modifica al tag di input del file e al suo interno analizzare il nome del file dato che ha ancora delle barre a questo punto e inserire quel valore in un input nascosto. Questo input nascosto viene quindi inviato insieme al resto del modulo. – kombat

+0

Felice di vedere che sei stato in grado di risolverlo. – Drifter64

+1

aggiungi la tua risposta a questa domanda piuttosto che inserirla in un commento, in modo che sia più applicabile –

1
  1. Aggiungi un evento di modifica al input di un file
  2. analizzare fuori il nome del file in quanto ha ancora barre, a questo punto
  3. Stick che apprezzano in un ingresso nascosto

Questo input nascosto poi viene inoltrato insieme al resto del modulo.


@kombat ha trovato questa soluzione e pubblicata come commento. Per meglio questo è ora ripubblicato come una risposta wiki della comunità.

0

Stavo ricevendo quell'errore quando ho provato il browser Eclipse. Quando ho provato il mio codice su Chrome, FormDataContentDisposition.getFileName() andava bene.

0

È un insetto in Jersey. Nella discussione di Nabble, http://jersey.576304.n2.nabble.com/Jersey-truncating-the-slashes-from-the-uploaded-file-name-td5984041.html, l'autore del bug si rivela e riconosce "riutilizzare il codice" per analizzare le intestazioni HTTP per analizzare lo Content-Disposition. Tuttavia, la RFC 2616 citata non specifica che i campi Content-Disposition devono essere sottoposti a escape in base alle regole specificate per le intestazioni HTTP. Proprio il contrario, c'è scritto che:

Content-Disposition non è parte dello standard HTTP, ma dal momento che è ampiamente implementata, stiamo documentando il suo utilizzo e dei rischi per implementatori.

Questo bug ha già una soluzione brutta nella classe org.glassfish.jersey.media.multipart.internal.MultiPartReaderClientSide nella versione attuale di Jersey, tuttavia non funziona con IE 11 ed Edge perché controlla User-Agent parte che ha cambiato. C'è una richiesta pull con correzione: https://github.com/jersey/jersey/pull/233/files, ma per quasi 2 anni nessuno si è preoccupato di unirlo.

Hai 3 soluzioni:

1) aplly una 'correzione' sul lato client, che è secondo me un approccio sbagliato, perché non c'è un bug su lato client, il bug è a Jersey!

2) Variazione Jersey ad altri framework, in cui gli sviluppatori di prendere i problemi di compatibilità più seriamente invece di concentrarsi sulla massimizzazione il riutilizzo del codice, ecc

3) Patch Jersey manualmente. Scarica i sorgenti, applica la richiesta di pull, compila e rilascia con il numero di versione modificato.

Problemi correlati