0

多くの UNIX ベースのファイルシステムを扱っていますが、それらはすべて、ユーザー名フィールドで特定の文字を使用できないという同様の一連の制限を共有しています。これらの制限の 1 つは、"@" 、"_"、または "." を使用しないことです。名前で。UNIX であるため、他にも多くの制限があります。

問題は、電子メール アドレスを取得して、それを予測可能な UNIX ファイル名に変換できる、よく知られているアルゴリズムがあるかどうかです。メールを取得するには、ある時点でこれを元に戻す必要があります。

"."->"DOT"、"@"->"AT" などを考えましたが、サイズ制限など、一般的に問題となるものがあります。電子メールの @xyz.com 部分を特別な文字などにマップできるようにすることで、最適化することもできます。各実装には、サポートする必要がある最大 3 つのドメインしかありません。誰かが膨大な数のトレードオフなしで解決策を見つけたことを願っています。

更新: - 2 つのターゲット ファイルシステムは、AFS と NFS です。

・Base64は対応文字が無いため動作しません。"/"

・読める方が望ましい。

@xyz.com ドメインを単一の非標準文字に置き換えてから、名前の最初の部分をさまざまなファイルシステムのユーザー名の長さの制限に収まるように縮小できる関数を用意するのが最善の答えのようです。 . しかし、そのための良い機能は何ですか?

4

4 に答える 4

2

URI に使用される URL パーセント (%) エンコード方式の修正版を試すことができます。

特定のファイルシステムでパーセント記号が許可されていない場合は、許可されている別の文字に置き換えるだけです (その文字が出現する場合は、適切にエンコードすることを忘れないでください)。

この方法の使用: mail.address@server.com

次のようになります。 mail%2Eaddress%40server%2Ecom

または、置換する必要がある場合は (たとえば)、記号 aの代わりに文字を使用します。%ma61ila2Ea61ddressa40servera2Ecom

おそらく人間が正確に読めるわけではありませんが、エンコードアルゴリズムを介して簡単に処理できます。スペース効率を最大限に高めるために、エスケープ文字は、ファイルシステムで許可されているものの、アドレスに頻繁に出現する可能性が低い文字にする必要があります。

このエンコード スキームには、ほとんどの通常の文字のサイズが大きくならないという利点があります。文字列の長さは、ファイルシステムでサポートされていない文字に対してのみ増加します。

于 2011-08-24T21:04:52.813 に答える
1

base64 をチェックしてください。エンコードとデコードは明確に定義されています。いつでも自分のフォーマットをロールバックするよりも、これを好みます。

于 2011-08-24T21:11:09.300 に答える
0

与えられた...-
  さまざまなファイルシステムで許可されている限られた文字セット
  -エンコードされた電子メールアドレスを短くしたいという願望(人間の読みやすさとファイルシステムの制限に関する懸念の両方のため)
...可能なアプローチは2つのステップかもしれません電子メールが

  • 最初に Lempel-Ziv などの可逆圧縮アルゴリズムを使用して圧縮し、効果的に「バイナリ」形式に変換して、より短いバイト配列に格納します
  • 次に、このバイト配列は、Base64 のようなアルゴリズムを使用してエンコードされます

アイデアは、バイナリ表現のサイズを最小限に抑えることです。これにより、エンコーディングのストレージの非効率性に関連する拡張 (1 文字あたり約 6 ビット (おそらく少し少ない) しか格納できない) によって、エンコードされた文字列が発生しなくなります。長すぎること。
圧縮もエンコードも過度に洗練されていなければ、そのようなシステムはおそらく入力文字列サイズ (電子メール アドレス) の 4/5 であるエンコードされた文字列を生成する可能性があります。 、バイナリ形式のサイズが 8/5 大きくなります。

圧縮率を改善する努力により、より「無駄な」エンコーディング スキーム (より小さな文字セットを使用) を選択できるようになる可能性があります。これにより、出力をより人間が読み取れるようにし、さまざまな種類のファイル システムでより広く安全にすることができます。たとえば、Base64 が最適と思われます。スペースに関しては、大文字 (基数 26) のみを使用することで、ファイル名の大文字と小文字が区別されないファイル システムへの基本的なスキームの移植性が保証される場合があります。初期の一般的な圧縮
のもう 1 つの利点は、有効な入力キー(電子メール アドレスはこちら)の構文について仮定する必要があるとしても、ほとんど必要ないことです。

圧縮のアイデア:
LZ は良い選択のように思えますが、電子メール アドレスに見られる一般的なパターン (たとえば、".com" や "a.com"、"b.com" など) を持つ初期バッファーを primin と見なすこともできます。
この初期バッファにより、圧縮された電子メール アドレスごとに複数の「引用」のインスタンスが確保されるため、全体的な圧縮率が向上します)。数バイトをさらに圧縮するには、LZH またはその他の LZ バリエーションを使用できます。
上記のバッファのプライミングとは別に、別のカスタマイズとして、通常の LZ アルゴリズムよりも短いバッファを使用することがあります。これは、圧縮する必要がある文字列 (電子メール アドレス インスタンス) 自体が非常に短く、たとえば 512 バイトのバッファではメリットがないためです。 . (バッファサイズが短いほど、引用のコードを短くすることができます)

エンコードのアイデア:
Base64は、スラッシュ (/)、プラス (+)、イコール (=) 文字のため、そのままでは適していません。これらを置き換えるために代替文字を使用できます。ダッシュ (-) が頭に浮かびますが、ターゲット ファイル システムのすべての「フレーバー」で許可されている 3 つの文字を見つけるのは難しいかもしれません。それでもなお、Base64 と 3 ペイロード バイトあたりの 4 出力文字の比率は、[許容可能な文字セットの]ストレージ効率の
おそらくほとんど達成できない上限を提供します。
この効率の下限は、おそらく配列内のバイトの 16 進数値の ASCII 表現です。. ペイロード バイトが 2 倍になっているこの形式は、長さ方向に受け入れられる可能性があり、その単純さから興味深いものです (入力の各ニブル (4 ビット) とエンコードされた文字列の文字の間に直接的で単純な関係があります
。Base32これにより、A ~ Z はそれぞれ 0 ~ 25 をエンコードし、0 ~ 5 は 26 ~ 31 をそれぞれエンコードします。本質的に、5 ペイロード バイトあたり 8 出力文字の比率を持つ Base64 のバリエーションは、非常に実行可能な妥協点になる可能性があります。

于 2011-08-24T23:54:16.443 に答える
0

うーん、あなたの質問から私はこの点について完全に明確ではありませんが、何らかの変換が必要だったので、少なくとも人間が読める何かが必要だと思いますか?

各 OS には異なる制限があるかもしれませんが、ユーザー名で何が受け入れられるかを調べたりテストしたりできるプラットフォームに十分近いですか? 置換を行うためだけに使用できる 3 つの「特殊な」文字を見つけることができれば、問題ありませ'@', '.', '_' ん。(それは包括的ですか?そうでない場合は、それらすべてを知っていることを確認する必要があります。そうしないと、衝突する可能性があります。)POSIX標準があるかどうかを少し検索しましたが、何も見つかりませんでした。何が有効かをテストできれば、それが最も直接的なルートになると思います。

特殊文字が 1 つでもあれば、URL エンコーディングを行うことができます。利用できる場合は「%」を使用し、利用できない場合は何でも選択して「!」と言ってから{ '@'->'!40", '_'->'!5F', '.'-> '!2E' }. (仕様 [RFC1738] http://www.rfc-editor .org/rfc/rfc1738.txt ) は文字を US-ASCII として定義しているので、たとえばウィキペディアの ASCII 記事でテーブルを見つけて、そこで正しい 16 進数を調べることができます。) または、独自の単純なマッピングを行うこともできます。 ASCII セット全体は必要ありません。エスケープ文字ごとに 2 文字のマップを作成し、たとえば、'!a','!u','!p'アットマーク、アンダースコア、ピリオドを使用できます。

「%」と「!」などの 2 つの特殊文字がある場合、、、、などの文字を表すテキストを区切ることができ%at!ます。(これはほとんど html スタイルのエンコーディングですが、'&' と ';' の代わりに利用可能なものを使用しており、独自のニーモニックを作成しています。) もう 1 つのアイデアは、シンボルの実行を使用して、変換された文字を決定します。各新しい文字は、どのシンボルが使用されているかをフロップします。(許可されていない文字を 2 つ並べて配置する必要がある場合、これにより便利に実行が停止します。) したがって、ピリオドが 1、アンダースコアが 2、アットマークが 3 の '%' と '!' を仮定すると、になります。他にもバリエーションがありますが、これはコーディングが簡単です。&us!'&pd!''mickey._sample_@fake.out''mickey%!!sample%%!!!fake%out'

これがどれもオプションではない場合 (たとえば、シンボルがまったくなく、[a-zA-Z0-9] だけ)、Base64 の回答はほぼ正しいと思います。実際、単純な置換以外の何かに到達すると (さらにはそれさえも)、それが目標である場合、入力するのがすでに難しくなっています。しかし、メールをほとんど読めるようにする必要がある場合は、何らかのエスケープを実装する必要があります。'0' をエスケープ文字として使用することを考えているので、'0' は '00' になり、'@' は '01' になり、'.' になります。は「02」になり、「_」は「03」になります。だから今、'mickey01._sample_@fake.out'なるでしょう'mickey0010203sample0301fake02out'。美しくはありませんが、うまくいくはずです。生の 0 をエスケープしたので、エスケープ文字として選択したもののマッピングを必ず定義してください。問題ないはずです..

それは私がatmについて考えることができるすべてです。:) 確かに、これらのユーザー名を生で読み取る必要がない場合、スラッシュを生成できるため、Base64 は明らかに機能しないようです。ええ、わかりました。各文字の 2 桁の US-ASCII 16 進値だけで完了です...] は良い方法です。デバッグされ、十分にフィールドテストされたコードがたくさんあり、問題を非常に簡単に解決します。:)

于 2011-08-24T22:40:21.737 に答える