浏览器端TS/JS访问S3多字节Unicode文件的编码适配问询

S3的对象键采用字节精确匹配机制，不会自动对文件名做Unicode格式对齐，其存储的文件名统一使用Unicode NFC（预组字符）标准化形式：即带变音/附加符号的字符合并为单个Unicode码点存储，例如示例中的Ö存储为单码点U+00D6，对应UTF-8编码为%C3%96，和S3控制台显示的编码结果完全一致。

你遇到的编码不匹配问题，本质是浏览器默认的URL编码逻辑和S3的存储规则采用了不同的Unicode标准化形式：

• 浏览器在对URL路径的未编码字符串做自动转码时，默认使用NFD（分解形式）标准化，会把带附加符号的字符拆成「基础字符+组合符号」的多码点序列，例如Ö被拆为基础字母O（U+004F）+组合分音符（U+0308），对应UTF-8编码为O%CC%88，和S3存储的字节序列不一致，直接导致资源匹配失败。
• 两种形式的字符串肉眼完全无差异，但字节序列不同，S3会判定为两个完全不同的对象键。

不需要手动维护多字节字符映射表，不需要引入第三方依赖，直接使用浏览器原生ES标准API即可解决，适配逻辑兼容全语种多字节文件名：

1. 拿到Lambda返回的原始文件名后，第一时间调用原生字符串标准化方法，强制转换为S3兼容的NFC格式：

// 后端返回的原始文件名，与Windows本地文件名完全一致
const rawFileName: string = res.fileName;
// 转换为S3使用的NFC预组字符形式
const nfcFileName: string = rawFileName.normalize('NFC');

2. 按照你现有已经调通的S3特殊字符处理逻辑，对NFC格式的文件名做URL编码，处理[、]、#、空格等特殊字符。
3. 编码完成后再拼接完整S3资源路径，赋值给HTMLAudioElement的src属性，再调用load()方法。

关键注意点：不要直接把未编码的NFC格式文件名直接赋值给src属性，否则浏览器会在请求发起阶段再次自动做NFD转换，导致配置失效。必须在赋值前完成所有编码操作，传入的是已经转义完成的完整URL，避免浏览器介入做二次编码。

Angular环境下的完整实现示例：

initAudioPlayer(s3BucketBaseUrl: string, rawFileName: string): void {
  const audioEl = new Audio();
  // 第一步：转NFC标准化对齐S3编码规则
  const nfcFileName = rawFileName.normalize('NFC');
  // 第二步：编码+适配已有特殊字符规则，可根据你的现有逻辑调整替换规则
  const encodedFileName = encodeURIComponent(nfcFileName)
    .replace(/%5B/g, '[')
    .replace(/%5D/g, ']')
    .replace(/%20/g, '+'); // 对齐S3控制台的空格编码规则，可按需保留或调整
  // 第三步：拼接完整路径赋值，避免浏览器自动转码
  audioEl.src = `${s3BucketBaseUrl}/${encodedFileName}`;
  audioEl.load();
  // 后续播放、事件监听逻辑按原有业务实现
}

• 该方案兼容所有Unicode语种，无论是西欧变音字符、西里尔字母、中日韩统一表意文字还是其他小语种文字，normalize('NFC')都会自动完成标准化对齐，无需手动维护映射规则。
• 所使用的String.prototype.normalize()为ES2015标准API，所有Angular支持的现代浏览器均原生兼容，无需引入额外polyfill或依赖。
• 后续新增文件上传逻辑时，可在上传前就将本地选中的文件名转为NFC格式再传入S3，从源头统一所有对象键的编码标准，避免新旧文件出现编码差异。

内容的提问来源于stack exchange，提问作者Neoheurist