Вопросы Теги

Поразрядно И, Поразрядно Включительно ИЛИ вопрос, в Java

Я знаю только несколько способов:

  1. Просто поместите его в постоянную переменную или, если хотите, в вашей структуре, которая обрабатывает все ваши ключи. Вот и все.
  2. UserDefaults.
  3. Используйте библиотеки, чтобы каким-то образом запутать ваши ключи, например, https://github.com/orta/cocoapods-keys
  4. Keychain.

Последний обсуждается Apple.

Хранение закрытого ключа в цепочке для ключей - отличный способ защитить его. Данные ключа зашифрованы на диске и доступны только для вашего приложения или приложений, которые вы авторизуете.

blockquote>

https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave

Также некоторые интересные обсуждения:

    [ 118]

    Как в iOS можно сохранить секретный «ключ»? что позволит мне общаться с моим сервером?

  2. swift3 - Как защитить секретный ключ

Надеюсь, это поможет.

11
задан Dave 20 April 2010 в 07:28
поделиться

7 ответов

Как другие ответы, уже указанные, (currentByte & 0x7F) | (currentByte & 0x80) эквивалентно (currentByte & 0xFF). JLS3 15.22.1 говорит, что это продвинуто на int:

Когда оба операнда оператора и, ^, или | имеют тип, который конвертируем (§5.1.8) к примитивному целочисленному типу, двоичное числовое продвижение сначала выполняется на операндах (§5.6.2). Тип выражения побитового оператора является продвинутым типом операндов.

потому что JLS3 5.6.2 говорит это когда currentByte имеет тип byte и 0x7F int (и дело обстоит так), затем оба операнда продвинуты на int.

Поэтому buffer будет массив типа элемента int или шире.

Теперь, путем выполнения & 0xFF на int, мы эффективно отображаем оригинал byte диапазон-128.. 127 в неподписанный диапазон 0.. 255, операция, часто используемая java.io потоки, например.

Вы видите это в действии в следующем фрагменте кода. Обратите внимание, что для понимания, что происходит здесь необходимо знать, что Java хранит целочисленные типы, кроме char, как 2's дополнительные значения.

byte b = -123;
int r = b;
System.out.println(r + "= " + Integer.toBinaryString(r));
int r2 = b & 0xFF;
System.out.println(r2 + "= " + Integer.toBinaryString(r2));

Наконец, для реального примера, проверьте Javadoc и реализацию read метод java.io.ByteArrayInputStream:

/**
 * Reads the next byte of data from this input stream. The value 
 * byte is returned as an <code>int</code> in the range 
 * <code>0</code> to <code>255</code>. If no byte is available 
 * because the end of the stream has been reached, the value 
 * <code>-1</code> is returned. 
 */
public synchronized int read() {
return (pos < count) ? (buf[pos++] & 0xff) : -1;
}
9
ответ дан 3 December 2019 в 05:59
поделиться 
 (currentByte & 0x7F) | (currentByte & 0x80)

эквивалентно

 currentByte & (0x7F | 0x80)

который равняется

 currentByte & 0xFF

который является точно тем же как

 currentByte

Править: Я только посмотрел на правую сторону присвоения, и я все еще думаю, что эквивалентность верна.

Однако кажется, что код хочет бросить байт со знаком к большему типу при интерпретации байта как неподписанного.

Существует ли более легкий способ бросить байт со знаком к неподписанному в Java?

4
ответ дан 3 December 2019 в 05:59
поделиться

Результат поразрядной операции И имеет 1 на этом биты, где оба бита равняются 1, в то время как результат операции битового "ИЛИ" затуманивает на этом биты, где любой из битов бота равняется 1.

Так оценка в качестве примера для значения 0x65:

  01100101 0x65
& 01111111 0x7F
===============
  01100101 0x65

  01100101 0x65
& 10000000 0x80
===============
  00000000 0x00

  01100101 0x65
| 00000000 0x00
===============
  01100101 0x65
2
ответ дан 3 December 2019 в 05:59
поделиться

Я думаю, что кто-то сделал слишком много взглядов здесь. Это просто не правильно.

Я имею только один комментарий

  • Исходный автор волновался по поводу времени выполнения, заменяющего байт с собственным целым числом со знаком (по-видимому, 32-разрядный), и явно пытается сказать нам что-то о знаковом бите, являющемся "особенным"?

Это - оставленный позади код. Если Вы не знаете, что находитесь на подозрительном времени выполнения? Каков тип 'буфера' так или иначе?

3
ответ дан 3 December 2019 в 05:59
поделиться

Оказывается, файл, из которого читался байт, был в разрядной нотации со знаком, и другой длины, поэтому это требовалось выполнить эту задачу позволить этому быть расширенным на тип интервала Java при сохранении его корректного знака :)

0
ответ дан 3 December 2019 в 05:59
поделиться

Хорошая вещь об этих видах логических операций: можно попробовать каждую возможную комбинацию (все 256 из них) и проверить, что Вы получаете ответ, который Вы ожидали.

0
ответ дан 3 December 2019 в 05:59
поделиться

Сложная поразрядная логика является абсолютно лишней.

for (int i = 0; i < buffer.length; i++) {
    buffer[i] = filebuffer[currentPosition + i] & 0xff;
}

делает то же самое. Если буфер объявляется как массив байтов, можно даже не учесть и 0xff, но к сожалению объявление не показывают.

Причина может состоять в том, что исходный разработчик был смущен байтами, подписываемыми в Java.

2
ответ дан 3 December 2019 в 05:59
поделиться
Другие вопросы по тегам:

Похожие вопросы: