PreTrainedTokenizerFast converted from SentencePiece Unigram behaviour difference 
Author: meliksahturker
Pull request: no

### System Info

transformers version: 4.28.1 (tested on 4.31.0 as well)
platform: windows
python version: 3.8.10

We have converted a pre-trained SentencePiece unigram tokenizer to PreTrainedTokenizerFast, setting vocabulary, special tokens and so on as below:

```
import sentencepiece as spm
from transformers import convert_slow_tokenizer

spm_tokenizer = spm.SentencePieceProcessor('SentencePiece_32k_Tokenizer.model')
spm_tokenizer.vocab_file = 'SentencePiece_32k_Tokenizer.model'
spm_converter = convert_slow_tokenizer.SpmConverter(spm_tokenizer)
converted = spm_converter.converted()
converted.save('converted.json')

tok = PreTrainedTokenizerFast.from_pretrained(pretrained_model_name_or_path='converted.json', clean_up_tokenization_spaces=False, pad_token='<PAD>', unk_token='<UNK>', bos_token='<BOS>', eos_token='<EOS>', mask_token='<MASK>', model_max_length=1024, padding_side='right', truncation_side='right')
tok.save_pretrained('ConvertedTokenizer')
```

You can download the original sentencepiece tokenizer from [here](https://vnlp-model-weights.s3.eu-west-1.amazonaws.com/SentencePiece_32k_Tokenizer.model) to reproduce.

### Who can help?

@ArthurZucker 

### Information

- [ ] The official example scripts
- [ ] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

Then  along with the original sentencepiece tokenizer (for comparison), we can load and use it as below:
```
spm_tokenizer = spm.SentencePieceProcessor('SentencePiece_32k_Tokenizer.model')
conv_tokenizer = PreTrainedTokenizerFast.from_pretrained('ConvertedTokenizer')
```

Converted tokenizer produces the exact same result with the original SentencePiece tokenizer on 99.8% of the cases.
For the 0.2% of the cases, the difference come from two classes:

1) Strings that end with "\n", "\ufeff" or "�"
```
t = "some string\ufeff"
print(spm_tokenizer.encode(t))
print(conv_tokenizer.encode(t))
```
produces
```
[2827, 167, 7285, 8181]
[2827, 167, 7285, 8181, 9]
```
Where 9 corresponds to empty string.
Replacing "\ufeff" with "\n" or "�" produces the same result.

2) Strings that contain repetitive characters
```
t = "eeeee"
print(spm_tokenizer.encode(t))
print(conv_tokenizer.encode(t))
```
produces
```
[152, 23128, 22]
[152, 22, 23128]
```

```
t = "Ürünün Videosu Detaylar Bölümünde mevcuttur...."
print(spm_tokenizer.encode(t))
print(conv_tokenizer.encode(t))
```
produces
```
[23708, 3965, 424, 20350, 18, 26330, 3288, 63, 4]
[23708, 3965, 424, 20350, 18, 26330, 3288, 4, 63]
```
However, for most cases, this happens only if continuous repetitive characters are part of a large string. Compare the example above with the below:
 ```
t = "Bölümünde mevcuttur...."
print(spm_tokenizer.encode(t))
print(conv_tokenizer.encode(t))
```
produces
```
[26330, 3288, 4, 63]
[26330, 3288, 4, 63]
```


### Expected behavior

Expected behaviour is that the two tokenizers should produce the same tokens no matter what.

Comments:
cc @ArthurZucker 

Hey  @meliksahturker sorry I did not have time to look at this. I ll have a look. 
cc @Narsil I think you already solved something like this! 

You can check this out: https://github.com/huggingface/tokenizers/pull/401

Basically 100% parity is not possible. `...` -> `..` + `.` vs `.`  + `..` is strictly equivalently OK from unigram algorithm perspective. Sentencepiece is not using stable sorts there so their own order will depend on the rest of the string.
`tokenizers` also uses `f64` everywhere, where sentencepiece uses a mix of `f32` and `f64` leading to also float imprecision and tiny difference in ordering.

If you check the linked PR you'll sentencepiece is not even consistent with itself in the same string.

If you want 100% the same tokens, you have to use sentencepiece all the way. However the differences shouldn't be that significant in the grand scheme of things.


> You can check this out: [huggingface/tokenizers#401](https://github.com/huggingface/tokenizers/pull/401)
> 
> Basically 100% parity is not possible. `...` -> `..` + `.` vs `.` + `..` is strictly equivalently OK from unigram algorithm perspective. Sentencepiece is not using stable sorts there so their own order will depend on the rest of the string. `tokenizers` also uses `f64` everywhere, where sentencepiece uses a mix of `f32` and `f64` leading to also float imprecision and tiny difference in ordering.
> 
> If you check the linked PR you'll sentencepiece is not even consistent with itself in the same string.
> 
> If you want 100% the same tokens, you have to use sentencepiece all the way. However the differences shouldn't be that significant in the grand scheme of things.

How about the first case that occurs for strings that end with "\n", "\ufeff" or "�" ?

Might be unigram bytefallback not being set in the conversion script. It was part of the latest release only 

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.