因此,当前正在从事一个项目,并且在ios的Safari版本中遇到一个奇怪的问题,该问题涉及从服务器播放音频文件。
我目前面临以下问题:
现在,音频文件是通过Java脚本小程序提供的,该脚本具有以下代码段:
String fn = saveTo + file_name;
f = new File(fn);
String fname = f.getName();
String contentType = "audio/wav";
if(fname.endsWith("mp3")){
contentType = "audio/mp3";
}
response.setContentType(contentType);
response.setHeader("Content-Transfer-Encoding", "binary");
response.setHeader("Content-disposition", "attachment;filename="+f.getName());
response.setHeader("Content-Length", ""+f.length());
FileInputStream fin = null;
try{
fin = new FileInputStream(f.getCanonicalFile());
byte[] data = new byte[1024];
int x = 0;
while((x = fin.read(data, 0, 1024))>=0){
response.getOutputStream().write(data, 0, x);
Thread.sleep(1);
}
} finally {
if(fin != null) {
try{
fin.close();
}catch(Exception ex){}
}
}
现在我知道代码无论如何都不是最好的,这也不是我的代码,并且显然我们正在假设已找到文件。
我在使用Mac上的 Debug模式在iPhone上进行调试时发现,它似乎没有显示返回状态代码。它没有显示响应头,但显然必须接收到某些内容。服务器日志似乎认为其返回状态200,此状态在Chrome和Firefox中显示。
上面的代码似乎可以在Chrome和Firefox上正常使用,但不能与Safari一起使用。
我唯一猜测的是它与Safari不喜欢的文件如何被推送到输出流有关,或者它变得混乱并且应该具有不同的状态代码。我已经为此奋斗了好几天,并尽我所能阅读有关Safari的内容,尽管我发现的大多数文档都是关于其“独特”的网络音频实现,以及使用单个通道似乎与此无关。
任何帮助,将不胜感激。
最佳答案
我在iOS上的Safari中遇到了相同的问题,经过大量调试后,我发现该问题与应用于响应的 header 组合有关。
我的应用程序是基于C#的,但是此解决方案应该独立于平台(因为如前所述,这是一个响应头问题)。
必要标题:
在检查了通过Akamai的内容交付服务交付的MP3的响应之后,我设计了此方法。
关于ios - 来自服务器的音频的iOS Safari问题,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/34190593/