本申请涉及多语言处理技术领域，特别涉及一种基于Http的动态即时自适应多语言处理方法。
背景技术：
软件系统的多语言支持存在多种不同的场景。对于基于浏览器和服务器(B/S：Browser/Server)架构的系统，现有技术存在一些对于前端页面部分进行国际化处理的方法。例如：现有技术存在一种完全基于客户端的方法，该方法将语言资源预先内置于客户端，在部署后难于实现对新增语言种类的支持；并且涉及到浏览器引擎的定制，因此，该方法在使用方式上也受到限制。现有技术还存在一种界面部分通过多种语言信息资源的方式实现多语言支持的方法，但是该方法需要预先设置和保存语言资源，在系统上线后的平滑扩展语言支持方面也是存在问题的。
可见，现有技术无法很好地实现软件系统的多语言支持。
技术实现要素：
本申请提供了一种基于Http的动态即时自适应多语言处理方法，以很好地实现软件系统的多语言支持。
本申请提供了一种基于Http的动态即时自适应多语言处理方法，包括：
前端对访问者的语言偏好进行自动检测，将检测结果作为当前的语言偏好信息，通过自定义的http头部传递给后端；
前端根据当前的语言偏好信息，依据最优匹配原则加载对应的资源文件并渲染对应的页面元素；
后端对前端传递的语言偏好信息进行线程本地化管理，对后端生成的用户可见信息进行动态的多语言处理。
较佳的，前端对访问者的语言偏好进行自动检测包括：通过浏览器的语言偏好参数，获取访问者的初始的语音偏好信息。
较佳的，所述语言偏好信息包含语言信息和区域信息；
所述依据最优匹配原则包括：先匹配语言和区域均符合的，如果未匹配到语言和区域均符合的，则再匹配语言符合的，如果未匹配到语言符合的，则选择系统认为的最符合的。
较佳的，对前端和后端所需要使用的语言进行资源化处理，按照不同语言种类，分别设置对应的资源文件。
较佳的，所述资源文件的命名规则为：能够识别所述资源文件对应的语言种类以及附带的区域信息。
较佳的，该方法还包括：在前端的界面提供语言切换选择列表，允许访问者选择其他的系统支持的语言种类。
由上述技术方案可见，本申请提供的基于Http的动态即时自适应多语言处理方法，首先通过前端对访问者的语言偏好进行自动检测，得到当前的语言偏好信息，病通过自定义的http头部传递给后端；然后，前端根据当前的语言偏好信息，依据最优匹配原则加载对应的资源文件并渲染对应的页面元素；再由后端对前端传递的语言偏好信息进行线程本地化管理，对后端生成的用户可见信息进行动态的多语言处理。应用本申请公开的技术方案，能够很好地实现软件系统的多语言支持
本申请所提供的方案已应用于平台IES2.0版本中，并基于其良好的可移植性，作为基础组件，用于光伏监控系统和生产管理系统中。
附图说明
图1为本发明基于http协议的动态即时自适应多语言处理方法的原理示意图。
具体实施方式
为使本申请的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本申请作进一步详细说明。
通过对现有技术的分析，申请人发现以下技术问题，并提出相应的改进方案：
(1)现有技术不能基于客户端浏览器的特征，自动识别当前访问者的语言偏好：
现有的多语言方案都要求用户自行选定所偏好的语言信息，而浏览器作为B/S架构的软件系统的客户端访问工具，通常能够通过相应的属性表示用户偏好的语言信息，该偏好信息在大多数时候，可以直接作为当前访问者的语言偏好。基于此，本申请提出：通过浏览器的语言偏好参数自动获取当前访问者的默认语言偏好，并使用统一约定的格式表示，从而提高用户体验。
(2)对于后端生成的前端可见信息，现有技术没有给出多语言处理方案：
当访问者通过界面操作软件时，有些可见的信息是在服务端产生，然后再传回到客户端进行展现的，这部分信息同样需要多语言处理。对于这类信息的多语言化，现有技术没有给出完整有效的解决方案，对此，本申请提出：后端将前端请求中包含的语言偏好信息进行线程本地化管理，使联机事务处理过程(OLTP：On-Line Transaction Processing)系统后端生成的对用户可见的信息也能够动态化的进行多语言处理，并且这种动态化是随着前端请求而变化的，是一种自适应的机制。
(3)现有技术对于新增语言支持种类的可扩展性欠佳：
对于多语言，将语言信息资源化属于通用的方法。但是，在此基础上，如何实现软件系统整体的，在多语言支持上良好的可扩展性，让语言资源具体的使用者不关注当前使用的语言本身，在新增语言种类时，实现平滑的扩展，使得使用语言资源的软件组件不感知这种变化，现有方案并未给出有效的解决方案。而本申请提出：通过封装好的框架自动加载语言资源，提取并施加渲染。前端界面组件对于语言资源本身不感知。新增语言支持时，只需要新增语言资源即可。前端需要的语言资源根据匹配结果自动动态加载，语言资源本身不需要被前端直接感知，所以新增语言扩展时，只需要增加新的语言资源文件即可。
(4)现有技术所提供的解决方案通常缺乏可移植性：
一种多语言解决方案，需要考虑非常容易的迁移并且被不同的软件系统引入，而且这种引入对于已经存在的软件系统而言，也是以一种非强加的，可注入的方式，而非代码耦合的方式实现。对于这样的要求，现有技术没有给出解决方法。而本申请通过使用自定义的http头部来传递语言偏好信息，并将自定义的http头部封装于http请求中发送。这种方式能够与http协议相配合，具有良好的可移植性，对于现有广泛使用的基于http协议进行远程交互的分布式系统而言，没有迁移成本。前端和后端对于多语言的处理进行框架方式封装，在不同系统之间具有良好的可移植性。后端所需要的语言偏好参数通过线程本地变量传递，对于现有系统采用该方案，软件代码层面没有感知，移植成本很低。
(5)现有技术没有基于最优匹配规则的机制：
现有的多语言方案中，用户只能选择现有的语言来使用，当一个用户初次访问时，如果系统没有内置对应的语言资源，是无法进行选择的。本申请的发明人考虑到：基于用户目前的偏好语言，包括区域特征，是能够通过最优匹配的方式先给用户展示与用户需要的匹配度最高的语言的。因此，本申请提出：语言偏好同时包含语言和区域信息，以做到最优匹配。最优匹配时，先匹配语言和区域均符合的，如果未匹配到，则再匹配语言符合的。这样，就能够优先选择最优匹配，同时，在最优匹配不能满足时，也能尽可能的提高匹配度。
基于以上分析，本申请提出一种基于Http协议的，自动识别访问者语言偏好的完整的软件系统即时动态多语言机制和方法，该方法的原理如图1所示，主要包括：前端(即：如图1所示的前端多语言处理机制(Framework))对访问者的语言偏好进行自动检测，将检测结果作为当前语言偏好信息，并通过自定义的http头部将当前语言偏好信息传递给后端(即：如图1所示的后端多语言处理机制(Framework))，并且，前端根据当前语言偏好信息自动加载资源文件并自动渲染页面元素，后端组件在根据资源项标识或者语言偏好信息进行处理时，自动根据匹配的语言进行过滤。整个过程描述如下：
(1)对系统前端和后端所需要使用的语言进行资源化处理，按照不同语言种类，分别设置资源文件。资源文件的命名规则要求能够准确识别该资源文件对应的语言种类以及附带的区域信息。
(2)前端多语言处理机制封装为framework，其逻辑自动检测浏览器语言偏好信息，作为当前访问者的初始的语言偏好。同时，界面提供语言切换选择列表，允许访问者选择其他的系统支持的语言种类。
(3)前端framework逻辑根据当前的语言偏好信息，依据最优匹配原则，加载资源，并渲染对应的页面组件。整个过程中，页面组件不感知使用的具体的资源以及资源的变化。
(4)最优匹配规则的处理逻辑：在匹配语言资源时，优先选择语言种类和区域均符合的，不存在该匹配的情况下，再选择只有语言种类符合的，最后，当仍然未得到匹配时，则选择系统认为的最为符合的。在一般场景下，系统都会内置中文和英文两种语言支持，此时，对于非中文偏好且未得到任何匹配语言资源的访问者，可以选择英文作为最优匹配结果，因为英文具有事实上的国际语言的地位。
(5)前端在向后端发出请求时，依据当前的语言偏好信息，使用自定义http头部设置对应信息，该信息包含语言种类和区域两个部分。后端处理线程依据当前http请求对象中的对应的自定义头部信息，设置线程本地变量，表示当前请求的语言偏好信息。该语言偏好信息是动态的随着请求即时变化的。
(6)后端服务启动时，加载所附带的所有的语言资源。
(7)后端获取语言资源项，并封装成多语言framework，涉及使用语言资源的对象只需要传入资源项标识即可，不需要关注语言偏好信息。封装逻辑内部从线程本地变量中获取当前访问者的语言偏好信息，并能够根据最优匹配原则选择相应的语言资源使用。
(8)后端逻辑涉及处理多语言时，调用封装逻辑，对实际资源情况不做感知。对于异常，提示性业务信息，返回对象通过封装好的逻辑，自行携带对应的语言种类的业务信息。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。