我有一些没有拉丁字符的链接资源,例如 åäö 这些通常是用户上传的文件
问题是我没有成功编码它们
使用 filename.encodeAsURL 似乎没有以正确的方式对其进行编码
例如字符 ö 变成 o%CC%88 测试在 Firefox 中键入相同的内容并复制内容给出 %C3%B6
这些编码有什么区别,我应该用什么来获得正确的编码?
我有一些没有拉丁字符的链接资源,例如 åäö 这些通常是用户上传的文件
问题是我没有成功编码它们
使用 filename.encodeAsURL 似乎没有以正确的方式对其进行编码
例如字符 ö 变成 o%CC%88 测试在 Firefox 中键入相同的内容并复制内容给出 %C3%B6
这些编码有什么区别,我应该用什么来获得正确的编码?
两种编码都是正确的。您实际上看到的是两个不同字符串的编码。
这里的关键是注意o
字符串开头的 :
o%CC%88
是o
后跟Unicode Character Combining Diaeresis的字母,它在渲染时与前一个字符结合。
%C3%B6
是带有分音符号的Unicode 字符拉丁小 O。
您看到的是,在第一种情况下,输入的字符串类似于这两个字符:o
¨
,实际上呈现为ö
. 在第二种情况下,它是实际的字符ö
。
我的猜测是您看到了两个不同输入之间的差异。
根据以下讨论进行更新:如果您正在动态处理 Unicode 字符,并且您无法控制输入法,您可以尝试使用java.text.Normalizer(Java 1.6 或更高版本)来规范化 Unicode。
规范化尝试确保所有字符的表示一致,以便重音字符始终由组合字符表示或始终由字符+组合标记表示。
粗略的例子:
String.metaClass.normalizeUnicode = {
return java.text.Normalizer.normalize(delegate, java.text.Normalizer.Form.NFC)
}
input = input.normalizeUnicode()
标准化有四种形式。我根据对它们工作方式的描述选择了似乎最适合您的情况的一种,但您可能更愿意尝试其他的,看看哪种方法最一致。
话虽如此,如果您尝试在 URL 中表示 Unicode 字符,并且代码没有直接加载和处理它们,那么最好完全避免使用非拉丁字符。这不仅具有一致的好处,而且还具有显着更短和更清晰的 URL。 boo.pdf
比 . 更容易阅读bo%CC%88o.pdf
。