2016-12-02 32 views
0

PowerShellを使用して、アンパサンド(&)を持つ2つの文字列(つまり、 "&プロシージャ"という文字列)を比較しています。PowerShellでアンパサンドを持つ文字列を比較する方法

私が試しても、これらの文字列を一致させることはできません。余分な空白を取り除くために文字列を整えてみました。私は、単一引用符と二重引用符(および両方の組み合わせ)の両方の文字列をラップ試してみました:

"Policies & Procedures" 
'Policies & Procedures' 
"'Policies & Procedures'" 

私は文字列を比較するために使用していたコードは次のとおりです。

if ($term1 -eq $term2) { 
    do something 
} 

は、視覚的に文字列を検査します - それらは同一ですが、if文が真と評価されることはありません。これらの2つの文字列を比較して真と評価する方法はありますか?

EDIT

私はこの文字列をやっている状況を比較SharePointサイトの分類でいう名を募集しています。ここで私が使用していたコードです:私は画面にterm.NameとTERMNAMEの両方を印刷している

function getTerm($termName) { 

    foreach($term in $global:termset.Terms) { 
    $termTrimmed = $term.Name.trim() 
    Write-Host "term name = $termTrimmed" -foregroundcolor cyan 
    if ($termTrimmed -eq $termName) { 
     return $term 
    } 
    } 
    return null 
} 

、彼らは同じです。文字列にアンパサンドがない場合、この関数は機能します。アンパサンドがある場合、この関数は失敗します。これは、アンパサンドが問題であることを私が知る方法です。

+0

ちょうど以下のコードを試して、期待通りに '$ true'を返しました。文字列を生成しているコードを表示できますか? '$ TERM1 = 'ポリシー&Procedures'' ' $ TERM2 =' ポリシー&Procedures'' '$ TERM1 -eq $ term2' –

+0

同じ事、私のために' $ true'を返します。 – 4c74356b41

+0

Ampersandは[PowerShell文字列の特殊文字ではありません](https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.core/about/about_quoting_rules)です問題を引き起こす特定のものとして? – TessellatingHeckler

答えて

1

これはknown quirkです:

あなたは は、SharePoint分類

私たちのお気に入りと最もして再生するときに注意する必要があるアンパサンドの2つのタイプがあります。愛された

  • & ASCII番号:38

そして詐欺師

  • ASCII番号:65286

Nick Hobbsthis articleを読んだ後、それはあなたが用語を作成するとき、それは と38アンパサンドを置き換えること 明らかになりました65286アンパサンド。

元のソース(スプレッドシート、データベースなど)と比較する場合は、 と同じではないため、問題が発生します。

ニックの記事で詳細に説明したように、あなたは比較のために あなたの文字列の「分類」バージョンを作成するために TaxonomyItem.NormalizeNameメソッドを使用することができます。

(本当のSharePoint上でテストされていない)、これを試してみてください:

function getTerm($termName) 
{ 
    foreach($term in $global:termset.Terms) { 
    $termNormalized = [Microsoft.SharePoint.Taxonomy.TaxonomyItem]::NormalizeName($term.Name) 
    if ($termNormalized -eq $termName) { 
     return $term 
    } 
    } 
    return null 
} 
+0

ASCIIは7ビットエンコーディングであるため、 'ASCII'コードとして' 65286'を見るのは難しいです。 '65286'の値は、FULLWIDTH AMPERSANDのUnicodeコードポイントです。 – lit

+0

これは私よりはるかに洗練されたソリューションです。これを投稿していただきありがとうございます! – user5013

1

両方の文字列をchar配列に変換し、アンパサンドのユニコード値を比較した後、問題が明らかになります。検索文字列で使用されるアンパサンドの値は38ですが、SharePoint用語ストアから返されるアンパサンドの値は65286です(通常のアンパサンドと同じに見えますが、フルアンパサンドと呼ばれます)。

解決方法は、私自身の文字列比較関数を記述し、アンパサンド値の違いを考慮に入れたものです。ここでは、コードは次のようになります。

function getTerm($termName) { 

    $searchChars = $termName.toCharArray() 
    $size = $searchChars.Count; 
    foreach($term in $global:termset.Terms) { 
    $match = $True 
    $chars = $term.Name.trim().toCharArray() 
    if ($size -eq $chars.Count) { 
     for ($i = 0; $i -lt $size; $i++) { 
     if ($searchChars[$i] -ne $chars[$i]) { 
      # handle the difference between a normal ampersand and a full width ampersand 
      $charCode1 = [int] $searchChars[$i] 
      $charCode2 = [int] $chars[$i] 
      if ((($charCode1 -eq 38) -or ($charCode1 -eq 65286)) -and (($charCode2 -eq 38) -or ($charCode2 -eq 65286))) { 
      continue 
      } else { 
      $match = $False 
      break 
      } 
     } 
     } 
    } else { 
     $match = $False 
    } 
    if ($match -eq $True) { 
     return $term 
    } 
    } 
    return $null 
} 
関連する問題