我们正在开发一个使用UTF-8,UTF-16和UTF-32 Unicode字符标准对超过50种国际语言进行模糊匹配的系统.到目前为止,我们已经能够使用Levenshtein距离来检测德语Unicode扩展字符词的拼写错误.

我们想扩展这个系统来处理以Unicode表示的普通话中文表意文字.我们如何在类似汉字之间执行Levenshtein距离计算？

首先,只是为了澄清：汉字不像德文或英文一样.大多数你认为是文字的东西(使用“单词”的语义或句法定义)由1-3个字符组成.通过将Levenshtein距离表示为UCS-2或UCS-4码点的序列,可以直接应用Levenshtein距离.由于大多数单词很短(特别是长度为1或2个字符的单词),可能是有限的使用.

但是,由于您的问题具体涉及个人角色之间的编辑距离,我认为需要采用不同的方法,确实可能非常困难.

首先,您必须将每个字符表示为组成的组件/笔画的顺序.有两个问题：

>某些组件由更小的组件组​​成,所以如何将角色分解为“原子”组件并不是唯一定义的.如果你做到单个笔画的水平,你需要描述每一个笔画(角色,形状,方向等等).我不认为任何人都这样做(如果有人告诉我,我会最感兴趣的).
>您需要将笔画或组件放在一个顺序中.明显的候选人是字典的规范笔画顺序,在词典中有描述,甚至有字典网站都有动画笔画顺序图.然而,我知道的数据源(对于日语),生成这些动画作为位图图形的序列;我从来没有看到适用于编辑距离计算的表单中的人物或机器可读代码来代表笔画序列(甚至单个笔画的名称).

可以尝试一个最后一件事是渲染字符字形,并根据需要改变多少个像素(或向量)将一个字符转换为另一个字符来计算编辑距离.我曾经在OCR修正后的背景下做了拉丁字符和字符组合(以像素为单位),结果相当令人鼓舞.

对larsmans的一个快速回答如下：Unicode标准定义了两个相关概念(下面我参考6.0 version,chapter 12)：

>基于激进和中风计数的指标.每个汉字由几个组成部分组成,其中一个是激进的.激进/笔触计数索引是由根基(即,共享相同基团组合在一起的所有字符)排序的字符列表,并且每个激进特定组在内部根据字符的其余部分中使用的笔画数进行排序.不幸的是,即使这并不是唯一的定义 – 有不同传统词汇定义不同的字符,笔画计数也很难.以下是Unicode标准的内容：

To expedite locating specific Han ideographic characters in the code charts,radical-stroke indices are provided on the Unicode web site. […]
The most influential authority for radical-stroke information is the eighteenth-century
KangXi dictionary,which contains 214 radicals. The main problem in using KangXi radicals today is that many simplified characters are difficult to classify under any of the 214
KangXi radicals. As a result,varIoUs modern radical sets have been introduced. None,however,is in general use,and the 214 KangXi radicals remain the best kNown. […]
The Unicode radical-stroke charts are based on the KangXi radicals. The Unicode Standard
follows a number of different sources for radical-stroke classification. Where two sources
are at odds as to radical or stroke count for a given character,the character is shown in both positions in the radical-stroke charts.

注意,即使我们假设激进/中风指数是明确和正确的,它不足以将字符转换成一个组件序列的信息源,因为完全描述的字符的唯一组件是激进.
>表意描述序列(第12.2节)：Unicode定义了字符的基本组件的代码点(大多数可以自己被用作独立字符),并且有一些代码点用于将它们粘合在一起以形成描述的组件序列组成更复杂的人物.所以这样做的方式类似于组合字符,但有重要的区别：

>组件的顺序不是唯一定义的
>这种序列的渲染机制没有定义
>没有从普通字符到对应的表意描述序列的映射(虽然标准提到这种映射在某种程度上存在于用于编译汉字符集的源中).

标准表明,表意描述序列用于描述没有由任何现有代码点表示的复杂或罕见的特征;但是它明确地阻止使用描述序列代替普通字符：

In particular,Ideographic Description Sequences should not be used to provide alternative graphic representations of encoded ideographs in data interchange. Searching,collation,and other content-based text operations would then fail.

我如何获得appdata文件夹路径？这个id我的代码：

begin
Winexec(PAnsichar('%appdata%\TEST.exe'),sw_show);
end;
end.

但没有工作.

您无法将环境变量传递给WinExec().你必须先解决它们：

uses
  ...,SysUtils;

function GetPathToTestExe: string;
begin
  Result := SysUtils.GetEnvironmentvariable('APPDATA');
  if Result <> '' then
    Result := IncludeTrailingPathDelimiter(Result) + 'TEST.exe';
end;

uses
  ...,Windows;

var
  Path: string;
begin
  Path = GetPathToTestExe;
  if Path <> '' then
    WinExec(PAnsiChar(Path),SW_SHOW);
end;

或者：

uses
  ...,SysUtils,Windows;

function GetPathToTestExe: string;
var
  Path: array[0..MAX_PATH+1] of Char;
begin
  if ExpandEnvironmentStrings('%APPDATA%',Path,Length(Path)) > 1 then
    Result := IncludeTrailingPathDelimiter(Path) + 'TEST.exe'
  else
    Result := '';
end;

获取APPDATA文件夹路径的更可靠(和官方)方式是使用SHGetFolderPath()(或Vista上的SHGetKNownFolderPath())：

uses
  ...,Windows,SHFolder;

function GetPathToTestExe: string;
var
  Path: array[0..MAX_PATH] of Char;
begin
  if SHGetFolderPath(0,CSIDL_APPDATA,SHGFP_TYPE_CURRENT,Path) = S_OK then
    Result := IncludeTrailingPathDelimiter(Path) + 'TEST.exe'
  else
    Result := '';
end;

但是,无论如何,自Windows 95以来,WinExec()已被弃用,你真的应该使用CreateProcess()代替：

uses
  ...,Windows;

var
  Path: String;
  si: TStartupInfo;
  pi: TProcessinformation;

Path := GetPathToTetExe;
if Path <> '' then
begin
  ZeroMemory(@si,SizeOf(si));
  si.cb := SizeOf(si);
  si.dwFlags := STARTF_USESHOWWINDOW;
  si.wShowWindow := SW_SHOW;

  if CreateProcess(nil,PChar(Path),nil,FALSE,@si,pi)
  begin
    //...
    CloseHandle(pi.hThread);
    CloseHandle(pi.hProcess);
  end;
end;